How to search AD for OCS objects

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.

Needed Tools

• ADSIEdit – To locate the distinguished name (DN) of the RTC Service object and later to manually delete the orphaned objects
• LDIFDE – To export out the RTC Service data to a text file
• Notepad – To search the exported data and list the orphaned entries
• FQDN’s of the server(s) you need to remove

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.

1. Locate the RTC Service object in the System container – OCS 2007 originally recommended placing the objects in the root domain System container, OCS 2007 R2 changed this to the Configuration container.  The change was due to issues with customers with large deployments and unreliable communications with the root domain.  OCS 2007 R2 provided a migration script to allow you to move the objects, more about that here.  Anyway, many times customer do not know where the object reside and even if they do it’s a good exercise to verify.

   Using ADSIEdit.msc (Windows support tools), connect to the root domain and expand the System container.  Navigate to the Microsoft container and see if it contains the RTC Service object.  If it does have an RTC Service object, proceed to step 3.  If you don’t see the RTC Service object here, then proceed to step 2.

2. Locate the RTC Service object in the Configuration container – If you didn’t find the RTC Service object in the System container, then most likely it is in the Configuration container.

   Using ADSIEdit.msc (Windows support tools), connect to the current domain and expand the Configuration container.  Navigate to the Services container and see if it contains the RTC Service object.  If you don’t see the RTC Service object here, then you are either in the wrong domain OR OCS is not installed in this forest.  :)

3. Right click on the RTC Service object and select properties.  Scroll through the attributes and select the ‘distinguishedName’ attribute, click Edit.  Copy the distinguishedName to the clipboard.  We will need this later for our export command.

4. Now that we have the DN of the RTC Service object, we can use it to form the LDIFDE.exe command line to export all the data it contains.  Open a CMD prompt and type the following command;

   LDIFDE –d “” –f outputfile.txt

   Now paste the RTC Service DN from the clipboard in between the quotes.  The finished command should look something like this;

   for a System container location
   or
   for a Configuration container location

   Execute that command and a success should look like this;
   

5. Now type the following command (using your export filename) to view the exported data;

   NOTEPAD outputfile.txt

   Using the find menu item in Notepad, search for the FQDN of the server(s) you are interested in removing;

   In this case, UC_OCS_R2_SE.uc.vm.com

   As you find the entries, copy the dn: line above each section to a separate notepad to make your list of orphaned entries.  When you reach the end you should now have a list of each entry that still references the orphaned server object(s).  Repeat for each server FQDN you might be looking for.

6. Return to your ADSIEdit.msc window and locate the various entries you found above.  If you are 100% confident these are the correct entries, right click and delete them.  Wait for domain replication and you should be free of any orphaned objects referencing to old server names.

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.

/\/\arkBarr

Comments

• Anonymous
  December 11, 2009
  Good post man, keep them coming!

• Anonymous
  May 18, 2015
  You might want to fix your code - your hyphens are fancy and not "real" hyphens, so if you copy paste, this errors.