for a hotfix applicable to Microsoft Exchange 2000.
for information about this event.
If you are running McAfee GroupShield for Exchange, the see "Network Associates Support Solution ID: nai3676".
See the links to "EventID 9551 from source MSExchangeISPublic" and "EventID 9551 from source MSExchangeIS" for additional information on this problem.
As per Microsoft: "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."
According to one user that managed to fix this problem:
"All I did was reboot the Global Catalog Server (We only have one on our network). And I had recently made it a Global Catalog Server about 4 days before without a reboot. I had to move the server to another rack, so I took it down for about 5 minutes, brought it back up and it worked. The global catalog server is not the exchange box in my case."
Recently upgraded a Exchange 5.5 server to Exchange 2000 server. Since I forgot to setup the ADC, none of the Distribution groups made it over. Had to go into the client permissions for each public folder and remove the associated distribution groups. Once that was accomplished, they all showed up again and were accessible. The groups were then recreated in active directory and reassigned.
As per Microsoft, the cause for this is "The ACEs are entries that originate from Microsoft Windows NT security for Exchange Server 5.5 disabled accounts. This problem may occur if the Exchange Server 5.5 mailboxes (or public folders) were migrated to Exchange 2000 and the DS/IS consistency adjuster was not used on the Exchange Server 5.5 store to remove these entries from the ACL." The recommended solution is to run the DS/IS consistency checker against the information store before migration". See ME318549
for more details.
From a newsgroup post: "This may be due to zombie ACLs on your Exchange 5.5 public folders. Let's say you hired Bill and granted him specific access rights to a public folder. Two months later, you fired him and deleted his mailbox. His permission entry on the public folder still exists, but it no longer resolves to a mailbox. This entry generate a 9551 event in your app log, and it will cause performance problems and hierarchy expansion delays. DS/IS Consistency against public folders will resolve this issue. Please see ME309788
Our issue was caused by a ACE that could not resolve back to a name. We recently upgraded to Exchange 2000. This particular folder was originating from an Exchange 5.5 server and could be seen from the site associated with this server, but a replica could not be seen on two of our upgraded Exchange 2000 servers. From the Exchange 2000 System Manager I looked at the client permissions which had an access entry showing a guid number instead of a name, meaning the user account was removed from the organization. I removed this entry and the folder immmediately appeared on my two Exchange 2000 servers.