Often during OCS deployments, there are failed installations or servers get removed without proper deactivation. This results in objects being left in Active Directory (AD) that reference the old server name. This can sometimes lead to problems when customers try and reintroduce the same server / pool names back into the environment. If this is a new OCS deployment, then it’s not much of a problem as you can simply remove the entire RTC Service object and viola! AD thinks OCS has never been installed. However, for a mature OCS environment with multiple servers & pools, this is not an option.
For example, an existing OCS 2007 pool that is migrating to an OCS 2007 R2 pool, but something goes wrong with the R2 deployment. So the customer tries to deactivate the server roles and remove the pool, but this doesn’t succeed. As a result, some server roles are left activated and the pool has to be ‘force’ removed. It appears from the OCS admin tool that the server / pool is gone. When the customer tries to reinstall the server / pool with the same name(s), they run into errors since there are already object(s) in AD with the same name. Now it becomes a chore of looking through the RTC Service container and all the objects to locate the specific entries. Anyone who has had the pleasure of running ADSIEdit against a existing OCS deployment knows this is a time consuming and dangerous task. This post will show you an easier, safer method for locating the specific entries for manual removal from AD.
NOTE: This procedure requires use of tools that could be very dangerous to your OCS deployment and AD in general if used incorrectly. DO NOT proceed unless you are confident in the use of these tools and have the proper domain rights to perform the operation.
NOTE: Whenever possible, attempt to deactivate all OCS server roles and remove (even if you must force remove) the pool. This will greatly reduce the number of entries you must manually delete later on. For example, an OCS 2007 R2 Enterprise Edition deployment might be made up of 4 server nodes. If 3 of these servers successfully deactivate and only one server has roles that will not deactivate, you have dramatically reduced the number of objects in AD to locate and remove.
It’s not a bad idea to repeat this process again to verify that the FQDN’s you were interested are no longer present, especially after domain replication has completed.
I hope this helps.
<p>Good post man, keep them coming!</p>