Microsoft KB Archive/141342

= XADM: Public Folders Automatically Get New Home Site/Server =

Article ID: 141342

Article Last Modified on 10/28/2006

-

APPLIES TO


 * Microsoft Exchange Server 4.0 Standard Edition

-



This article was previously published under Q141342



SYMPTOMS
When you look at the properties of a public folder using the Microsoft Exchange Server, version 4.0, Administrator program, the Home Site and Home Server information may have been changed without any user intervention. The permissions on the public folder may also have been changed.



CAUSE
If there is a public folder in the public information store on a server in one site (site1) AND there are no public information stores containing that folder in the folder's present home site (site2), then when the DS/IS checker is run on a server in site1, it will re-home the folder in its site (to a server that contains a public information store).

The state in which a public folder has no replicas in the site where it was created could be caused by any of the following situations:
 * With the Microsoft Exchange Administrator program, you explicitly remove all servers in the folder's home site from the replica list. The Administrator program will usually not let you remove the last server in the folder's home site from the replica list and will try to prevent this, but it can still be done as follows. Suppose Serv1 and Serv2 are servers in the public folder's home site and contain replicas of the folder. Run the Microsoft Exchange Administrator program against both Serv1 and Serv2. At nearly the same time, in Serv1 remove Serv1 as a replica and in Serv2 remove Serv2 as a replica. On both servers there is one other server in the home site still left in the replica list, but when replication happens, both servers do get removed and the folder can thus be orphaned.
 * Let Fold1 be a public folder whose replica is only on server, Serv1 in Site1. Let Serv2 be a server in Site2, with Site2 having public folder affinity to Site1. Let a user on Serv2 open folder Fold1. Because of affinity, the user connects to Serv1 and opens the folder. Now, let the user create a subfolder Fold2. The subfolder is physically created in the user's home server Serv2, and initially Serv1 and Serv2 are both in the replica list for Fold2. But, Serv2 is only temporarily in this replica state and will soon be removed by the mdb automatically, leaving only Serv1 as the replica for the subfolder Fold2. This leads to the state of the folder Fold2, being homed in Site2 but having replicas only in Site1. This behavior was needed to support the exact inheritance of replica list when creating a subfolder.
 * Create a Fold1 folder on Serv1 present in Site1. Make servers Serv1 and Serv2 in sites Site1 and Site2 respectively as replicas. Now delete the connector between the two sites (a site tear down). After this, Serv2 no longer knows about Serv1. Now when the DS/IS checker is run on Serv2, it will create a new DS object for the folder and it will become the home mdb for the folder. After this, reconnect the sites. Initially, the Distinguished Name (DN) of the folder is different in Serv1 and Serv2 (both think they are the home mdb for this folder). After replication occurs, one version will win. If the folder was last changed in Serv2, its version will win and so it will remain the home mdb. So, magically the home mdb is changed from Serv1 to Serv2.

Additional query words: exsrv public fld rehome

Keywords: kbenv kbprb KB141342

-

[mailto:TECHNET@MICROSOFT.COM Send feedback to Microsoft]

© Microsoft Corporation. All rights reserved.