Houston, We’ve Had a Problem! Office Communications Server and an Active Directory Catastrophe

If it hasn’t happened yet, it will! One day something bad will happen in Active Directory and damage will be done to a User or an entire Organizational Unit, Domain or Forest. After you’ve realized the scope of the problem and taken a few breaths you will certainly be headed down the road to recovering the user, Organizational Unit, Domain, etc. However, Office Communications Front End servers(this article applies to LCS 2005 and OCS 2007 equally well! ) will still be up and running! Naturally your user(s) who no longer exist in Active Directory won’t be doing much Instant Messaging but the Front End services will still be running. Of course, with no users who can log on, the Front Ends won’t be doing anything…..or will they?

User Replicator

Actually they will! By default, your Front Ends (in an Enterprise Pool it will be a specific Front End) will periodically(every 2 hours by default) trigger the User Replicator process. What is User Replicator? Its responsibility is to ensure that Active Directory and the RTC(Real Time Communications aka OCS) databases are synchronized. Any time an OCS user is created or modified in Active Directory it is the User Replicator’s job to make sure the changes are pushed into thedatabase. OK, so we have a User Replicator that can’t add or modify user data to the database ….So what? My Active Directory is messed up! That’s the least of my problems!...

The bad news is that it can still delete user data from the RTC database! When User Replicator runs, it will notice any and all users in the RTC database who are not in Active Directory. It will take the data for these users in the database and delete it! That includes any and all of their contacts and block/allow lists! Not good, but User Replicator is doing exactly what it is supposed to do! It doesn’t know the reason that it can’t find the user in Active Directory, nor does it really care! So now you’ve had some sort of Active Directory catastrophe and once the User Replicator runs your user’s contacts and block/allows have been wiped out….Now What?

The answer to this is pretty simple and covered in the Office Communications Server Administration and Backup and Restore Guides. Recovering this data is neither rocket science nor a big deal if you’ve done your backups and you are the DBA and/or can reach the DBA! However, why not prevent the problem in the first place? All you have to do is shut down the Office Communications Server services at the onset of the Active Directory catastrophe! Most folks in this situation will shutdown Exchange’s services, just add shutting down the OCS services to your disaster protocol and you will save yourself some time while recovering your systems! One more Best Practice suggestion…..

DB Import/Export - DBIMPEXP

Take advantage of DBIMPEXP (you can find it on the installation media or via the Internet-use the version specific to your servers; i.e. use the LCS dbimpexp if you have and LCS server). It will save your bacon some day! DBIMPEXP is a tool used to backup/export and restore/import user information from the RTC database usually via an XML file. Predominantly this information is the user’s contacts and block/allow list. Anyone ever have a user say, “I accidentally deleted one of my contacts and for the life of me, I can’t remember his IM address! Any chance you can help me out?”

Solution A: Just restore/import the RTC and RTCConfig databases….NOT! This will overwrite ALL the contacts for ALL your users! The guy with the missing contact will be real happy but the rest of your users…..

Solution B: Figure out a way to run a DBIMPEXP backup/export on a regular basis (Ideally, the Office Communications Server services should be stopped when running this backup/export but not required).

The best place to run this is from the Front End Server itself because the ID you are using to run the Front End Server probably has the appropriate permissions to do both a backup/export, restore/import using DBIMPEXP. Of course, periodically test the backup/export and restore/import!

Once you have this backup/export you can either restore/import the info for all users (do this with the services shut down!) or restore/import the info for a single user! You cannot directly restore/import the info for a specific contact for a specific user but it’s easy enough to look at the XML file created by DBIMPEXP and lookup the contact for the user and provide him with the appropriate information. Realistically, it won’t take you very long to configure a daily run of DBIMPEXP to backup/export everything and overwrite the backup file. If you want to get fancy and rig it to store the information to a different file name every day or something more exotic, go for it!

The Bottom Line:

· Make sure you have a good, current SQL backup of your RTC database.

· Run DBIMPEXP on a regular basis. Backup/export your user data to someplace you can get to it!

· When you have an Active Directory catastrophe, shut down Office Communications Serverservices as quickly as practical!