Microsoft KB Archive Search

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.

  1. Home
  2. XADM: Public Folders Lose ACEs After Exchange 2000 Is Introduced to an Existing Exchange Server 5.5 Organization

XADM: Public Folders Lose ACEs After Exchange 2000 Is Introduced to an Existing Exchange Server 5.5 Organization

View products that this article applies to.

This article was previously published under Q296051

↑ Back to the top

Symptoms

When an Exchange 2000 server joins an existing Microsoft Exchange Server 5.5 organization, the public folder Access Control Lists (ACLs) may lose some Access Control Entries (ACEs).

An event ID 9551 message that is similar to the following may also be logged in Event Viewer:
Event Type: Warning
Event Source: MSExchangeIS Public Store
Event Category: General
Event ID: 9551
Date: 2001-03-29
Time: 08:31:33
User: N/A
Computer: Exchange Server
Description:
An error occurred while upgrading the ACL on folder [Public Folders]/PF located on database "First Storage Group\Public Folder Store (Exchange Server)".
The Information Store was unable to convert the security for /O=Org/OU=Site/CN=RECIPIENTS/CN=DL into a 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.

↑ Back to the top

Cause

This issue occurs because all of the recipients in Exchange Server 5.5 must be represented in Active Directory before an Exchange 2000 server can join the site. You can make sure that the Exchange Server 5.5 recipients are represented in Active Directory by using the Active Directory Connector (ADC). If the Exchange Server 5.5 recipients are not represented in Active Directory before an Exchange 2000 server joins the site, the issue that is described in the "Symptoms" section of this article may occur.

↑ Back to the top

Workaround

To work around this issue, make sure that all of the Exchange Server 5.5 recipients are represented in Active Directory before you start a migration.

You may also be able to work around this issue by restoring a backup of one of the Exchange Server 5.5 public folder information stores on a spare server, exporting the permissions with PfAdmin, and then importing the permissions again by using PFAdmin. For additional information about this procedure, click the article number below to view the article in the Microsoft Knowledge Base:
199319� XADM: Extracting Public Folder Permissions Using PFADMIN

↑ Back to the top

Status

This behavior is by design.

↑ Back to the top

More information

The problem occurs if a change on the Exchange 2000 side requires replication to Exchange Server 5.5, and not all users are represented in Active Directory. The Exchange 2000 server is identified as more recent than the others. The Exchange 2000 server sends a status message for its entire hierarchy; 24 hours later, other servers request the Exchange 2000 server's hierarchy. This causes Exchange 2000 to replace the data in ptagACLData, (the earlier-version Exchange Server 5.5 ACL) with the data in ptagNTSD that contains the Exchange 2000 ACL. The ptagNTSD only contains accounts in Active Directory that are security principals.

Because of this, the ptagACLData that contains the earlier-version permissions for Exchange Server 5.5 removes all ACEs that are not represented in Active Directory. The ptagACLData is then replicated with the rest of the hierarchy to Exchange Server 5.5, and the ACEs are removed in the Exchange Server 5.5 ACL as well.

↑ Back to the top

Keywords: KB296051, kbprb

↑ Back to the top

Article Info
Article ID : 296051
Revision : 5
Created on : 2/27/2007
Published on : 2/27/2007
Exists online : False
Views : 282