Article ID: 812271
Article Last Modified on 10/27/2006
APPLIES TO
- Microsoft Exchange Server 5.5 Standard Edition
- Microsoft Outlook 2000 Standard Edition
- Microsoft Outlook 2002 Standard Edition
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).
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.
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.
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
Additional query words: spike pinned hung mapi
Keywords: kbprb KB812271
