Select the product you need help with

XADM: Users Cannot Access Public Folders or Delegate Mailboxes on a Separate Server

Article ID: 324353 - View products that this article applies to.

This article was previously published under Q324353

SYMPTOMS

Some or all users may not be able to access public folders that do not have a replica on the local public folder store if they are using a MAPI client such as Microsoft Outlook. Even though the users have the correct permissions, they receive access denied error messages when they try to access the public folders that do not have a local replica.

The users receive an access denied error message for all public folders if a public folder store on another server is set as the default public folder store for the user's mailbox store. However, these users can access remote public folders by using Microsoft Outlook Web Access (OWA). This issue also affects delegate access to mailboxes on remote servers when users use a MAPI client.

Back to the top | Give Feedback

CAUSE

This issue occurs because the msExchMailboxSecurityDescriptor attribute for the affected users is not set in Active Directory.

Back to the top | Give Feedback

RESOLUTION

Use Active Directory Users and Computers to resolve this issue. Your computer must have Microsoft Exchange 2000 Server Service Pack 2 or later installed for this procedure. Follow these steps:

Select the accounts that experience the issue.
Right-click the selected accounts, point to Exchange Tasks, and then click Remove E-mail Attributes.
Start Exchange System Manager, and then locate the mailbox store that contains the mailboxes where the e-mail attributes are removed.
Right-click the mailbox store, and then click Run Cleanup Agent.

An icon that shows a red X appears next to the affected mailboxes. The red X indicates that the mailboxes are no longer associated with a user account.
Select each mailbox that is labeled with a red X, right-click the mailbox, and then click Reconnect to reconnect the mailbox to the correct user account.

Note If you must use either the Mbconn utility (Mbconn.exe) or a script that uses Csvde.exe and Ldifde.exe to reconnect the mailboxes to the correct user account, contact Microsoft Product Support Services to obtain a script. This script can be run after the users are reconnected to populate the msExchMailboxSecurityDescriptor attribute.

Back to the top | Give Feedback

STATUS

Microsoft has confirmed that this is a problem in the Microsoft products that are listed at the beginning of this article.

Back to the top | Give Feedback

MORE INFORMATION

Typically, the msExchMailboxSecurityDescriptor attribute is not set for one of the following two reasons:

The Ldifde utility/Active Directory Service Interface (LDIFDE/ADSI) was used to create the account.
Either the Killmail utility or the Exchange 2000 Service Pack 2 (SP2) Remove Exchange Attributes option was used to remove the mail attributes on the account, and then the Mbconn utility was used to reconnect the account.

If you want to use LDIFDE/ADSI to create users, Microsoft recommends that you use LDIFDE/ADSI to create only the user accounts, and then use Active Directory Users and Computers to create the mailboxes.

If you use the IMailboxStore::CreateMailbox method in Microsoft Collaboration Data Objects for Exchange Management (CDOEXM) to create user accounts, those accounts do not experience this issue. You must install Exchange 2000 SP2 on the Exchange 2000 server before you can use CDOEXM. For additional information about using CDOEXM to create mailboxes, click the following article number to view the article in the Microsoft Knowledge Base:

304935

(http://support.microsoft.com/kb/304935/EN-US/ )

HOWTO: Set Exchange 2000 Mailbox Rights at Mailbox Creation Time

Back to the top | Give Feedback