Ticket: Public Folder Replication Fails Due To Empty Legacy Administrative Group

 

Exchange 2007 Event 8207 MSExchangeFBPublish Finally Fixed

Error updating public folder with free/busy information on virtual machine claexc01. The error number is 0x80004005

Hi Michael, I'm not sure whether to be impressed or shocked that my site is blocked in China. Here's a new URL to try (http://blog.stealthpuppy.com/exchange/exchange-server-2007-and-public-folder-replicas), otherwise here's a copy of the text:


During a migration from Exchange Server 2003 to Exchange Server 2007 you need to add the Exchange 2007 server to replicas for each of the Public Folders (as you would need with any Exchange server migration) and this includes the System folders as well.
In our case I missed the SCHEDULE+ FREE BUSY folder. This resulted in Outlook 2003 clients unable to see Free/Busy information when creating a meeting request. The user would see this error in Outlook when attempting to see another users schedule:
    no free/busy information could be retrieved
In addition to this, the following error was logged on the Exchange Server:
    Event Type: Error
    Event Source: MSExchangeFBPublish
    Event Category: General
    Event ID: 8207
    Date: 8/05/2007
    Time: 3:16:17 PM
    User: N/A
    Computer: EXCHSVR
    Description:
    Error updating public folder with free/busy information on virtual machine exchsrvr. The error number is 0×80004005.
After a bit of digging around, it occurred to me that I’d missed adding the new server to the Public Folder replicas. To add the replicas you will need to get the list of the sub-folders of the SCHEDULE+ FREE BUSY folder. You can see this list with this command (replace exchsrvr with the name of your server):
[PS] C:\>Get-PublicFolder -server exchsvr “\non_ipm_subtree\SCHEDULE+ FREE BUSY” -recurse | Format-List

Then to add the replicas run these commands (you’ll have to add your own server and organisation names):
[PS] C:\>Set-PublicFolder –Identity “\NON_IPM_SUBTREE\SCHEDULE+ FREE BUSY\EX:/o=Company/ou=First Administrative Group” –Replicas “exchsrvr\Public Folder Database”

[PS] C:\>Set-PublicFolder –Identity “\NON_IPM_SUBTREE\SCHEDULE+ FREE BUSY\EX:/o=Company/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)” –Replicas “exchsrvr\Public Folder Database”
Once I did this and ran OUTLOOK.EXE /cleanfreebusy, so I didn’t have to wait for the free/busy data to be published, all was well.

 

Public Folder Replication Fails Due To Empty Legacy Administrative Group
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.

Comments

Popular posts from this blog

E15 CU3–Update Failed–AD replicated Exceeded the tombstone lifetime.

202301 - Exchange onpreme - PowerShell Serialization Payload Signing

Ticket: RemoteAPP certificate revocation check error