EDIT 10/18/2010: Removed the reference to upcoming fix (no fix current planned).
Some customers are finding that when they try to replicate their public folder content to Exchange 2010, it will not replicate. Looking at the application log, you may find an event like this:
Log Name: Application
Source: MSExchange Store Driver
Event ID: 1020
Level: Error
Description:
The store driver couldnt deliver the public folder replication message "Hierarchy (PublicFolder@contoso.com)" because the following error occurred: The Active Directory user wasn't found.
This happens because we assume that if a Servers container exists, there will be a System Attendant object somewhere inside it. However, in an environment where Exchange 2000 or 2003 previously existed, and all those servers have been removed, you probably have a First Administrative Group or some other Administrative Group still hanging around with a Servers container, but no servers inside it. When the Exchange 2010 Store Driver stumbles across this empty Servers container, this error is the result.
To work around the issue, get rid of that empty Servers container. Exchange System Manager won't let you delete it, but you can use the ADSI Edit tool to remove it. Just be sure that the Servers container you are deleting is one that has nothing in it!
This workaround invariably brings up the question: Can't we just delete the old Administrative Group since we don't need it anymore? After all, Exchange System Manager will let you gracefully delete an Administrative Group. The answer to that is a little more involved.
The current documentation on TechNet strongly recommends against deleting old admin groups, and it states that if you do, and you see mail backing up in the System Attendant mailbox, you must then use ADModify to change the legacyExchangeDN on all your users from the old admin group. However, this is not entirely true, and that documentation is being changed.
Items stuck in the System Attendant mailbox
The System Attendant is responsible for publishing free/busy messages to public folders for certain clients such as OWA. When it can't publish these items to the appropriate free/busy public folder, the items stay in the System Attendant mailbox until the problem is corrected.
The most common cause of this problem is that there is simply no replica of the free/busy folder for a given admin group, which usually happens when the public folder stores for that admin group have been ungracefully removed (such as deleted through ADSI Edit) without properly replicating all the content off. This actually has nothing to do with the removal of the admin group itself, but rather with the removal of the public stores in that admin group.
Fortunately, this problem is easy to correct. Forcibly deleting all the public stores in an admin group does not delete the free/busy folder from the hierarchy - it just means all the replicas are gone. To correct this, you can use your public folder admin tool of choice to navigate to the System Folders and find the free/busy folder in question. Then, just add a replica of that folder to a public store in some other admin group. After allowing time for replication, the System Attendant mailbox should clear.
The important point here is that mail backing up in the System Attendant mailbox is not a reason to change the legacyExchangeDN on the users from that old admin group. Just add a replica, and you should be good to go.
A missing free/busy folder
Removing a legacy admin group does not typically cause a problem. However, there is a possible situation to be aware of.
Every admin group has a siteFolderServer attribute. This attribute points to the public folder store that is responsible for the free/busy folder for that admin group. Most of the time, that public folder store doesn't have to do anything, but it is responsible for making sure that the free/busy folder exists. If the free/busy folder for that admin group is missing, it's up to that public folder store to create it.
You can't delete the free/busy folder through any admin tool (ESM, the cmdlets, etc, won't let you), or even through something like ADSI Edit - it's an object in the store, not in the Active Directory. However, it is theoretically possible that somehow, that folder could go missing. If you deleted all your public folder databases and started over with clean ones, or something else unusual happened, you could end up in a situation where there is no free/busy folder for a particular legacy admin group. If that legacy admin group no longer exists in the directory, and thus has no siteFolderServer specified, then the free/busy folder will not get recreated, and you'll see items backing up in the System Attendant.
Even in this situation, there's a fairly easy way to fix the problem. If you still have Exchange System Manager, you can use it to recreate the legacy admin group. Alternately, you can use ADSI Edit to do the same. The important thing is to make sure the legacyExchangeDN is correct - make sure it matches the legacyExchangeDN on the users that were created in that old admin group. On the new admin group object, make sure you have a siteFolderServer that points to an existing public store in some other admin group. Within 24 hours, the free/busy folder for that admin group will get recreated.
If you don't want to recreate the admin group, then your other option at this point is to change the legacyExchangeDN on the users from that admin group. The steps for this are still documented in TechNet.
Our recommendation
We recommend you leave the old admin groups around, simply because there's no reason to remove them. Also, it's possible your free/busy folder could go missing at some point, and then you either have to recreate the admin group or change the legacyExchangeDN on the users.
If you decide to remove an admin group anyway, you should always do it through Exchange System Manager, which will prevent you from deleting it if it still contains objects you need - like the public folder hierarchy object. Deleting the admin group while it still contains the hierarchy object will completely break public folder replication and your ability to administer the folders, among other things.
For these reasons, our recommended workaround for the public folder replication issue is to delete the empty Servers container using ADSI Edit. But technically, yes, you could delete the admin group - gracefully from ESM - to achieve the same end. This doesn't usually cause a problem, and situations where you have to change the legacyExchangeDN of the users should be pretty rare.
- Bill Long
