This article was previously published under Q273479
This article has been archived. It is offered "as is" and will no longer be updated.
This article explains the public folder referral functionality in Exchange 2000 Server and in Exchange Server 2003.
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.
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.