Export (0) Print
Expand All

Problems with Permissions in a Mixed Exchange Server 2003 and Exchange Server 5.5 Environment

 

Topic Last Modified: 2005-06-21

A user's inability to see public folders in Outlook is often the first sign of a permissions problem. This section describes ways that you can determine whether the problem is caused by permissions replication, and how you can track the source of the problem.

Determine which of the following situations is preventing a user from seeing the public folder in Outlook:

  • The public folder was not replicated to the server.
  • The public folder permissions were not converted successfully.

The best way to determine the cause of the problem is to view the folder tree in Exchange System Manager. If the public folder appears in the tree when Exchange System Manager is connected to a particular public folder store, but a user with a mailbox on the same server as the public folder store cannot see the public folder, the problem has to do with permissions, not replication. However, if the public folder does not exist in the tree, you may have a replication problem.

In mixed-mode environments where permissions in access control lists (ACLs) were not successfully converted to ptagNTSD data, users may not be able to access the folder, even though the permissions appear to be correct in Exchange System Manager. For more information about the conversion process and the properties involved, see "Working with Permissions for Public Folders and Mailboxes" in the Exchange Server 2003 Administration Guide.

When you use Exchange System Manager to view the permissions for a public folder in the default Public Folders tree (also called the MAPI tree), Exchange System Manager displays the permissions that are contained in the ptagACLData property (if one exists) rather than recalculating the permissions from the ptagNTSD property. Exchange System Manager displays permissions from the replicated in property (which Exchange normally discards) rather than the permissions that are calculated from the ptagNTSD property, which actually control access to the folder. Use the following procedure to view the ptagNTSD permissions.

For detailed steps about how to view the ptagNTSD permissions on a folder in Exchange System Manager, see How to View the ptagNTSD Permissions on a Folder in Exchange System Manager.

You can use diagnostic logging to record permissions events to the application event log in Event Viewer. By default, the public folder logging level is set to None, which logs only critical errors.

You can use the Diagnostics Logging tab in the Properties of a server running Exchange Server 2003 to increase the logging level on a public folder. This increased logging level allows you to obtain more detailed permissions information.

To view the attempts of individual users to access folders and show the permissions that are granted to users when they try to access folders, set the Logons and Access Control diagnostics to maximum.

For detailed steps about how to set the Logons and Access Control diagnostics to maximum, see How to Set the Logons and Access Control Diagnostics to Maximum.

When users other than folder owners are not able to access a folder, look for events 9548 and 9551 in the application event log. (Event 9551 is discussed in the following section.)

Event ID: 9548

Date: 2/11/2000

Time: 9:44:25 AM

User: <user>

Computer: <servername>

Description:

Disabled user <user> does not have a master account SID. Please use Active Directory MMC to set an active account as this user's master account.

If you view the client permissions for the folder using Exchange System Manager, initially they look correct. However, viewing the permissions using the Advanced dialog box (these are the raw permissions that are stored in the ptagNTSD property) reveals that only the owner has been converted successfully from the Microsoft Exchange Server 5.5 version of the permissions to the Exchange Server 2003 version.

There are two potential causes for this problem:

  • The Active Directory directory service does not have a trust set up to the Microsoft Windows NT Server 4.0 domain that holds the user's account.
  • The user has been disabled manually and does not have an external account.

You should be able to fix the problem using the following approaches:

  • Remove the disabled accounts from the ACL.
  • Give the disabled accounts associated external accounts.
  • Create a trust between the Windows NT Server 4.0 (or external Windows) domain and Active Directory. This trust gives the disabled accounts associated external accounts. It also gives master account security identifiers (SIDs).

When users other than folder owners are not able to access a folder, look for events 9548 and 9551 in the application event log. (Event 9548 is discussed in the previous section.) When event 9551 occurs, it is logged each time a user attempts to access the folder:

Event ID: 9551

Date: 2/11/2000

Time: 9:44:25 AM

User: <user>

Computer: <servername>

Description:

An error occurred while upgrading the ACL on folder <folder> located on database <database>.

The Information Store was unable to convert the security for <user> into a Microsoft Windows 2000 Security Identifier.

It is possible that this is caused by latency in the Active Directory Service, if so, wait until the user record is replicated to the Active Directory and attempt to access the folder (it will be upgraded in place). If the specified object does NOT get replicated to the Active Directory, use the Microsoft Exchange System Manager or the Exchange Client to update the ACL on the folder manually.

The access rights in the ACE for this DN were 0x41b.

noteNote:
If the folder has been replicated from a server running Exchange Server 5.5 to the Exchange Server 2003 server, the ACL shows the name in uppercase letters because distinguished names are always uppercase. However, remember that to view permissions, Exchange System Manager connects to a store that holds an actual content replica of the folder. If Exchange System Manager connects to an Exchange Server 5.5 server, the ACL appears to be correct. Do not be misled by the appearance of the ACL. If the store is logging 9551 events, the cause of these events must be fixed before Exchange Server 2003 users can access the folder.

There are three potential causes for upgrade problems:

  • No user connection agreement is in place to replicate the Exchange Server 5.5 mailboxes into Active Directory.
  • The user has been deleted from Active Directory.
  • There is replication latency.

When Exchange Server 2003 receives the replication message, Exchange Server 2003 will attempt to upgrade the data stored in ptagACLData to Windows NT Server 4.0 SIDs. If the upgrade process fails, only owners are stored in ptagNTSD. No one else will be able to access the folder.

You should be able to fix the problem using the following approaches:

  • Remove the bad entry.
  • Replicate the missing user to Active Directory.

When users that belong to a specific distribution list or group cannot access a folder, look for events 9552 or 9556 in the application event log. Following are the event descriptions for Events 9552 and 9556:

9552

While processing public folder replication, moving user, or copying folders on database <database>, DL <distribution list> could not be converted to a security group.

Please grant or deny permissions to this DL on Folder <folder> again. This most likely is because your system is in a mixed domain.

9556

Unable to set permission for DL <distribution list> because it could not be converted to a security group. This most likely is because your system is in a mixed domain.

In addition, Outlook users that attempt to set permissions involving users that do not have access may see the following error:

The modified permissions could not be saved. The client operation failed.

Administrators using Exchange System Manager who attempt to set permissions involving users that do not have access may see the following error:

The operation failed. ID no 8004005 Exchange System Manager.

The most likely cause for these errors is that the Exchange Server 5.5 distribution list to which the users belong was replicated into an Active Directory mixed-mode domain rather than into an Active Directory native-mode domain. As a result, the universal distribution group that corresponds to the distribution list was created in an Active Directory mixed-mode domain. The domain into which groups are replicated is configured in the user connection agreement that governs the migration of Exchange Server 5.5 distribution lists to Active Directory.

To be used in setting permissions, the universal distribution group must be converted to a universal security group. This conversion can only take place if the universal distribution group has been created in a native-mode domain. For more information about this conversion process, see "Working with Permissions for Public Folders and Mailboxes" in Exchange Server 2003 Administration Guide.

To fix the conversion problem, do the following:

  1. Create a native-mode domain in Active Directory.
  2. Configure the user connection agreement to use the new domain for groups that it migrates from Exchange Server 5.5.
 
Was this page helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft