This article explains the public folder referral functionality in Exchange 2000 Server and in Exchange Server 2003.
↑ Back to the top
In Exchange 2000 and Exchange 2003, the public folder referral
functionality (known as public folder affinity in Exchange Server 5.5) enables
MAPI, Outlook Web Access (OWA), and IMAP clients to access public folders in
remote Exchange routing groups. Public folder referrals are created for
each individual connector when they are required, which gives you, as an
administrator, greater flexibility when you design your public folder
topology.
On each individual Exchange connector, you can prevent
public folder referrals. To do this, right-click the connector, click Properties, and then click to select the Do not allow public folder
referrals check box. By default, this check box is not selected.
Connector Costs
Like Exchange Server 5.5, each Exchange 2000 and Exchange 2003 connector (SMTP, X.400,
or Routing Group connector) has a cost associated with it; the cost ranges from
1 to 100. The cost is used to optimize message flow. Messages are routed
according to lowest cost, and if two or more routes are available with the same
cost, the load is distributed as equally as possible between them. This cost is
also used in calculating the most appropriate route that the client can use to
access public folders on remote servers (through public folder
referrals).
If the connector has an infinite cost associated with it,
one or more connectors for an available route to the public folder have the
Do not allow Public Folder referrals option selected. This
route is not used to access the public folder; it is discarded from the list of
available routes that the public folder server uses to select the Information
Store and Routing Service.Transitive Exchange 2000 and Exchange 2003 Connector Costs
In Exchange Server 5.5, public folder affinity is not
transitive. For example, if Site A has public folder affinity with Site B, and
Site B has public folder affinity with Site C, Site A does not have public
folder affinity with Site C.
However, in Exchange 2000 and Exchange 2003, public
folder referrals are transitive. If Routing Group A allows public folder
referrals to Routing Group B, and Routing Group B allows public folder
referrals to Routing Group C, then Routing Group A allows public folder
referrals to Routing Group C, and vice versa.Requesting Public Folder Contents
When a client asks for the contents of a public folder, the
following process occurs:
First, a call is made into the Information
Store, which returns a list of all servers in the organization that currently
have a copy of the requested public folder. The Information Store then makes a
call to Routing Service (REAPI), which returns the cost associated with the
route to that public folder.
NOTE: The Information Store caches the cost for each server that has
the requested public folder for one hour. This functionality prevents repeated
calls to the Routing Service. To delete the cache, restart the Information
Store service (MSexchangeIS).
Next, the Information Store discards
any servers that have an infinite cost. It also discards a server if the link
state to that server is currently down. The link state of both SMTP and Routing
Group connectors is calculated before a message is sent across these
connectors. However, for X.400 connectors, the link state is assumed to be up
until a message cannot be delivered across it. The Information Store then sorts
the list by cost.
If the public folder server is local, for example,
if the mailbox is on the same server as the public folder, the client is
directed to this server for the public folder contents. If the public folder
server is in the same routing group, the client is sent to this
server.
If there is not a copy of the public folder contents in the
local Routing Group, then the Information Store calculates the lowest cost
route to a server in the organization that has a copy of this public folder. If
there isn't a route, the client is not able to view the contents of the public
folder it requested
If multiple servers in the same routing group
have a copy of the requested public folder contents, the Information Store
provides a list of servers that the client can choose from. The client then
randomly picks one server, and assigns that server a number.
The next
time the client attempts to access this public folder, it contacts the same
server (based on the number that it assigned to this server). Each client
chooses its own random number, therefore the number is different for each
client. This process provides load balancing among various clients that are
attempting to access the same public folder. The process also gives clients a
consistent view of the public folder, because they tend to access the same
server repeatedly.
↑ Back to the top