Exchange Public Folder Troubleshooting Resources

  • Article

 

This article provides links to documentation that you can use to help troubleshoot Microsoft® Exchange Server public folders.

Before you troubleshoot, it is highly recommended that you run the Microsoft® Exchange Server Best Practices Analyzer Tool in your environment. The Exchange Server Best Practices Analyzer automatically examines the Exchange Server deployment and determines whether the configuration is set according to Microsoft best practices. You can install the Exchange Server Best Practices Analyzer on a client computer that is running Microsoft .NET Framework 1.1. With the appropriate network access, the Exchange Server Best Practices Analyzer examines all your Microsoft Active Directory® directory service and Exchange servers.

You can determine the overall health of your Exchange servers and topology by using the Exchange Server Best Practices Analyzer to perform the following tasks:

  • You can generate a list of issues, such as suboptimal configuration settings and unsupported or non-recommended options.

  • You can determine the general health of a system.

  • You can help troubleshoot specific problems by collecting alert-specific documentation for each warning, error, and non-default configuration message.

You can run the tool against a whole deployment, a specific server, or a set of servers.

The following items are examples of the specific public folder configurations that the Exchange Server Best Practices Analyzer reports on:

  • Aging Clean Interval registry value

  • Background Cleanup registry value

  • Replication Expiry registry value

  • Minimum Runtime registry value

  • Replication Folder Tombstone Age Limit registry value

  • Replication Folder Conflict Age Limit registry value

  • Preferred Backfill Source registry value

  • The size of the public folder store database

  • The location of the public folder store database

  • Public folder stores that do not have an e-mail address

  • Public folder database tree assignments

  • Tracking of duplicate registry values

  • Content indexing configurations

  • Permissions on top-level hierarchy (TLH)

  • Configurations for deleted item retention

  • Configurations for the offline address book

  • Configurations for the public folder hierarchy

  • Public folder connection agreements that are made by the Active Directory Connector (ADC)

Deleting Exchange Server Public Folders

This section provides some general best practices to help you when you delete public folders and public folder databases. You must delete Exchange Server public folders and public folder databases with care.

Using Exchange System Manager

To delete public folders, under Folders, right-click the appropriate folder, and select Delete. This action results in the following actions:

  • It deletes the public folder.

  • It generates an outgoing hierarchy replication message.

  • It sends the outgoing hierarchy replication message from this server to all other public folder servers in the organization. The outgoing hierarchy replication message provides information about the deletion of the public folder.

In Exchange Server 5.5, administrators could delete public folders so that no record of the folder or the delete event was captured. In Exchange 2000 Server and Exchange Server 2003, an administrator can enable the auditing of public folder deletion by adjusting diagnostic logging for the Public Folders General category to Medium or High. This adjustment causes an event to be logged in the application logs on the server every time a public folder is deleted. The event lists the name of the public folder that has been deleted and the user account that was used to delete the public folder.

If you try to delete a public folder tree, Exchange Server will not delete the tree until the associated store is deleted. When you delete public folder stores and public folders, Exchange System Manager updates Active Directory appropriately. Before you remove a public store, you should remove or replicate to another server any folders that exist on the store. The contents of any public folders that are only replicated to the public store that you are deleting will be permanently lost after the public folder is deleted.

It is not a best practice to manually delete public database files (.edb and .stm files). After these files have been manually deleted, Exchange Server re-creates them the next time the Exchange Server store mounts. At this time, the folder hierarchy backfills, and if one or more of the folders on the deleted store had replicas on other folders, the content also backfills.

Warning

You can also remove public folders by using the Remove Server option in Exchange System Manager. By right-clicking on a server in Exchange System Manager and selecting Remove Server, you can force the server out of the organization. This method bypasses all the checks that are made by other methods. However, this method is the most destructive way of removing a server and can cause the most problems. You should only use this method if the server itself has been lost. For example, if the server has experienced a catastrophic failure and you have no backup, you could use this method. However, even in this case, you should use this method with additional caution.

Site Folder Considerations

The first Exchange server that is installed into an administrative group contains the administrative group's site folders. The site folders maintain copies of the offline address list and the free and busy data for that administrative group. The site folders also hold replicas of other site folders from other administrative groups. If you try to delete a store that contains the site folders, Exchange System Manager will not delete the store until the site folders have been re-homed to another server in the administrative group.

Therefore, to remove the first Exchange server in an administrative group, or to remove the public folder store that contains the site folders, you must first replicate the public folders to another Exchange server in the administrative group. Additionally, you must replicate the offline address list and the Schedule+ Free/Busy folder to another server.

Resources for Managing Public Folders

For more information about managing public folders, see the following Microsoft Knowledge Base articles:

Replication

Before you can effectively troubleshoot replication issues, you must understand how replication works. You should understand the types of replication messages that Exchange Server uses, and you should understand change number sets (CN sets). For a description of these concepts, see "Controlling Public Folder Replication,” in Working with Exchange Server 2003 Stores. Also, for information about best practices for deploying and configuring public folder replication in Exchange 2000 Server and Exchange Server 2003, see Exchange Public Folder Best Practices: Implementing Replication.

The following section provides some general best practices to help you troubleshoot replication issues.

The Backfill Process Takes a Long Time

Sometimes, the backfill process can take a long time, especially if the store is down and has missed the original replication update and the subsequent status message. Here are several common scenarios in which the backfill process is slow.

  • Exchange Server is backfilling from an out-of-date server. If a backfill request is sent to a server that does not have the missing data, the backfill request is not satisfied. An example of this scenario is when you have recently restored an old backup to a server, and a backfill request is sent to that server after you have restored the backup. In this scenario, the store must send multiple backfill requests. This process can take many hours or even days.

  • Exchange Server is sending status requests to a new server. If the server that sends the initial status request is a new store itself, the server may have only the hierarchy. In that case, the stores will appear to be in sync with each other, even though they are out of sync with the rest of the organization. This problem will be resolved eventually as updates arrive from other stores in the organization. However, because the initial request was satisfied, the subsequent backfills can take hours or even days.

  • A new routing group is created. Exchange Setup starts the Exchange public store before there is a transport link to the rest of the organization. The store sends out its status request, but because transport is not yet operational, the store does not receive a response. The store then falls back to using the revised schedule before it sends additional status requests. After the transport link is established, the server attempts to send the status request or updates. Additionally, status messages from other stores may indicate that the store requires a backfill. But because the initial status request was lost, the data backfill can take hours or even days.

  • The Recipient Update Service has not updated mail attributes on the store. It is possible for a public folder store to attempt to send a status request before its directory object has been stamped with the required mail attributes. Of course, this status request causes a non-delivery notification (NDR) for the replication message. Again, because the initial status request failed, the store may take hours or even days to get back in sync.

In all of these scenarios, either the initial replication messages are lost, or the store requests information from a store that has no information about the public folders. Eventually, these situations resolve themselves as other servers discover that data is missing. If you notice that the folder is out of sync and the folder does not seem to get back into sync after a number of backfill timeouts, you should modify a replica of the folder that is up to date.

To verify that a folder is up-to-date, you must visually confirm that all folder items are present. For example, if you are experiencing problems with incomplete hierarchies, modify the hierarchy on the up-to-date replica. You can do this by changing a permission entry on the up-to-date replica. Additionally, if you are experiencing problems with missing content, modify the content on the up-to-date replica by posting a message. This action forces a replication message to be sent to the out-of-sync store and triggers a backfill request.

Diagnostic Logging

You can troubleshoot replication issues by setting diagnostic logging to the maximum level for incoming and outgoing replication on a specific server.

To set diagnostic logging to Maximum for incoming and outgoing replication on a specific server

  1. On the Properties page of the server, click the Diagnostic Logging tab.

  2. Expand MSExchangeIS, and then expand Public Folder.

  3. On the Public Folder tab, set Replication Incoming Messages and Replication Outgoing Messages to Maximum.

This procedure produces several event IDs, including notification of replication messages that are sent and receipt for public folder updates. Event IDs for the inbound replication messages range from 3011 to 3020, and event IDs for outbound replication messages range from 3021 to 3030. These are good general-purpose replication event messages that can help you narrow the replication issue.

After you have determined the specific replication area, you can turn up logging appropriately on other replication logging objects. The other replication objects are Replication Site Folders, Replication Expiry, Replication Conflicts, Replication Backfill, and Replication Errors. Make sure that you set the logging back to None, or Minimum when you finish troubleshooting, because Maximum logging levels can fill up the event logs quickly.

When you troubleshoot public folder replication issues, you may notice that the event log shows no errors. However, newly created public folders and the contents of old public folders may not be correctly replicated across groups, even though the replication time period may have passed. This discrepancy may be caused by the fact that the replication messages have been sent out, but they are not being received by the destination servers. Message tracking is a useful tool to determine the cause of this discrepancy. Stores send e-mail to one another through applications, and these e-mail messages can be tracked by using the message tracking tools.

For more information about how to use message tracking to diagnose and resolve public folder replication issues, see Knowledge Base article, XADM: Public Folder Hierarchy and Content Is Not Being Replicated Across Routing Groups.

Resources for Troubleshooting Replication

For more information about troubleshooting replication, see the following Knowledge Base articles:

Permissions

Two common problems that are related to permissions on public folders can negatively affect accessibility for users and performance of the Exchange server. These issues are the result of a migration from Exchange Server 5.5 to Exchange 2000 Server or Exchange Server 2003.

First, there are instances where the permissions that are applied to public folders do not appear to persist. For example, you may go through the process of giving a user access to a public folder by adding the user on the Permissions tab on the public folder property page. Although the user appears to have been added, the user is not allowed access to the folder. Additionally, when you refresh the Permissions tab, the user is not listed.

This issue is caused by a problem with the Active Directory account that you are adding to the permissions of the public folder. It is likely not an issue with the public folder itself. The account that you are trying to provide access is probably a mail-enabled account with the msExchMasterAccountSID attribute defined. The information store does not consider a mail-enabled user who has an msExchMasterAccountSID attribute a valid configuration. If you examine the application logs on the Exchange server, you will likely see 9548 events, which refer to the user who has the msExchMasterAccountSID attribute.

The MSExchMasterAccountSID attribute is created on disabled mail-enabled user objects that are created by the ADC. The MSExchMasterAccountSID attribute is set with the security identifier (SID) from the user account that is associated with the Exchange 5.5 Server mailbox. In migration scenarios, this user account is typically a Microsoft Windows NT® 4.0 user account. However, depending on the scenario, it might be an Active Directory user account from another forest that is associated with the Exchange 5.5 Server mailbox.

This issue is most common when the disabled mail-enabled user accounts that were created by the ADC have been manually enabled instead of using a tool, such as the Active Directory Migration Tool, to migrate the accounts to Active Directory. It is recommended that you not manually enable the disabled accounts. For more information about fixing this issue, see the Resources for Troubleshooting Replication later in this article.

Another common issue with public folder permissions is also the result of upgrading from Exchange 5.5 Server. Sometimes, a mailbox that had permissions to a public folder in the Exchange 5.5 Server organization does not have a user object that is associated with the mailbox in Active Directory. This discrepancy may cause access issues when users who have Exchange 2000 Server or Exchange Server 2003 mailboxes try to view public folders. The users may experience access issues. Additionally, Exchange Server may suffer general performance issues.

The most common symptom that you will likely experience with public folder permissions is users who can no longer see certain public folders from Microsoft Office Outlook®. The individual folder itself does not show up. This symptom only affects users who have been migrated to either Exchange 2000 Server or Exchange Server 2003. Users who are still on Exchange 5.5 Server are not affected.

When you look in Exchange System Manager, the public folders are visible. If you then examine the permissions of the public folder in Exchange System Manager, the users who cannot view the public folder are listed as having permissions. If you change permissions so these users have owner permissions, they will see the public folder in Outlook, and they will be able to access it. However, if you then change their permissions back to non-owner, the public folder will not appear in Outlook when they try to view it again.

This behavior is the result of an Access Control List (ACL) conversion problem. There is probably a mailbox that is listed on the public folder as having permissions, but it no longer exists. The mailbox probably was deleted from the Exchange 5.5 Server but was not removed from the ACL of the public folders or mailboxes. Alternatively, there are users who are listed on the public folder and have permissions that are not yet represented in Active Directory. If you examine the application logs on the Exchange 2000 Server or Exchange Server 2003, you will probably see 9551 events and possibly 9552 events. The events will list the public folders with which the server is having ACL conversion problems. The events will also list the user or group that is causing the issue. For more information about fixing this issue, see the following resources.

Resources for Troubleshooting Replication

For more information about troubleshooting replication, see the following Microsoft Knowledge Base articles:

For More Information

To learn more about public folders in Exchange Server, see the following resources: