Notice: This website is an unofficial Microsoft Knowledge Base (hereinafter KB) archive and is intended to provide a reliable access to deleted content from Microsoft KB. All KB articles are owned by Microsoft Corporation. Read full disclaimer for more details.

XADM: Problems When You Create or Delete a Public Folder


View products that this article applies to.

Symptoms

When you try to create or delete a public folder, either from an Outlook client or from the Exchange server, you may experience one or more of the following symptoms:
  • The creation or deletion process may take a long time. For example, up to 10 or more minutes.
  • The Information Store process (Store.exe) on the server may consume a high percentage of CPU cycles. For example, up to 99 percent.
  • During the creation or deletion process, the Outlook client program may stop responding (hang).

↑ Back to the top


Cause

This behavior may occur if both of the following conditions exist:
  • A large number of users are logged on to the Exchange server.
  • The top-level public folder in which you create or from which you delete the public folder is either opened by a large number of users or is subscribed to by a large number of users.

↑ Back to the top


Workaround

To work around this issue, use one or more of the following methods to reduce the number of users who have the same public folders open:
  • Divide the users between multiple public folder servers.
  • Reduce the permissions structure on the public folder structure.
  • Reduce the number of top-level public folders. For example, make the public folder tree deeper.

↑ Back to the top


More information

When you create or delete a public folder, the Information Store (Store.exe) process must parse a notification list. To do so, Store.exe must expand any distribution lists that are connected to the public folder, and perform CPU-intensive computations for each logged-on user who subscribes to a folder. This is to determine if the subscribers have the rights to view the newly-created folder, and so should be notified about it.

This issue becomes more noticeable with each additional logged-on client who subscribed to a folder with that folder open, or with a "notify" on that folder. This occurs because for each logged on user, Exchange must recalculate the whole view permissions, expanding the distribution list each time. This issue is most noticeable with folder creations because it is possible that a logon does not have the rights to view the new folder.

When a new folder inherits a set of permissions (from DLs or mailboxes), each member of a DL in this set is compared to the currently-logged on users to the server. Exchange Server determines which permission holders of the newly-created folder are currently logged on. For each user who is logged on and has a window open in which the new public folder will be displayed, the Information Store process must see if that user exists in a distribution list that has access to the new public folder or if the user has permissions to view the new public folder. When a very large number of people are logged on, this can take a long time.

When a public folder is deleted, each logged on user who has a parent folder of the deleted folder open, must be notified by Exchange that the folder is removed. Exchange Server notifies the subscribers to the folder (again, the currently-logged on users) to update their view of the parent folder to remove the listing for the now-deleted public folder.

For additional information about related topics, click the following article numbers to view the articles in the Microsoft Knowledge Base:
172813� XADM: Troubleshooting high CPU utilization by Store.exe
282533� Exchange Server 5.5 post-Service Pack 4 information store fixes available
159197� XADM: Controlling folder index aging
253297� XADM: Discussion of public folders and temporary replicas
224811� XADM: How to designate the home of subfolders

↑ Back to the top


Keywords: KB812271, kbprb

↑ Back to the top

Article Info
Article ID : 812271
Revision : 5
Created on : 10/27/2006
Published on : 10/27/2006
Exists online : False
Views : 403