Deprecate Old Systems From Active Directory

Update

There is an updated version that pulls UDA user info out of ConfigMgr here.

---
So with a show of hands, who knows the best way to keep ConfigMgr clean and happy? By keeping Active Directory clean and happy of course. That is super easy right? Sure it is. Not. This post focuses on keeping machine objects from taking over.

Overview

My firm has several hundred IT staff and many tens of thousands of machine objects. For various reason's they don't always remove a machine object from AD so it in turn gets removed from SCCM. Additionally we have lots of machines that are off the domain for months at a time and get stolen or lost without IT being notified in a timely fashion. Either way, machine objects are cluttering up OUs in AD, and over in Configuration Manager they are cluttering up Collections and Reports.

Once again Cory to the rescue coding to my quirky ideas. I refer to it as 'Purgatory', however some others didn't like that so we went with the creative name of ADCleanup. It is ran daily and what it does is look at the last time a machine made contact with the Domain via the lastLogonTimeStamp attribute being updated.

In the root of the user/machine Domain we have an 'ADCleanup' OU with a couple sub OUs called 'Active' and 'Disabled'. Additionally we have a separate structure for Servers. By segregating these older systems we can exclude these OUs from ConfigMgr reports for more accurate reports yet the best part is the removal of these objects.

Process

After 90 days of no contact the machine object is moved into the 'Active' OU and the description attribute is appended to reflect it was moved.

 ::Account Automatically Moved - [5/1/2014 11:37:13 PM]  

Then after an additional 30 days, the object is disabled and moved to the Disabled OU. Again the description is updated. Disabling was requested by our InfoSec team.

 ::Account Automatically Disabled - [4/11/2014 11:35:50 PM]  

Then when another 30 days has passed the object is deleted from AD.

Fun part is if the object is updated (lastLoginTimestamp) while in the Active OU, the script will move it back to where it was found. If the object is manually enabled while in the Disabled OU, it will try to move it back to where it was found.

Additionally it also generates an email that goes to our Process Management team who keeps an eye on it and deals with any manual tasks generated from it.

 Disabled computer account ABC12345. Account was moved on 3/25/2014 11:35:20 PM.  
      ABC12345 was moved to ou=Disabled,ou=ADCleanup,DC=mydomain,DC=local.  
      Updated the description for account ABC12345.  
 Moved ABC09876 with last logon of 1/24/2014 6:12:25 PM from CN=ABC09876,OU=Computers,OU=MYOFFICE,OU=,DC=mydomain,DC=local to ou=Active,ou=ADCleanup,DC=mydomain,DC=local.  
 Enabled computer account ABC5678 was moved back to OU location of OU=Computers,OU=MYOFFICE,OU=,DC=mydomain,DC=local.  
 Unable to move computer account BAD1234 from CN=BAD1234,OU=Computers,OU=MYOFFICE,OU=,DC=mydomain,DC=local to ou=Active,ou=ADCleanup,DC=mydomain,DC=local Error:-2147024891.  

Download

Sound useful?  The time frames and paths can be modified so review lines 1 through 27 and 654. Line 19 lets you choose specific OS versions to work with to include Servers for example. We use an older version of this script for Servers specifically. There are two optional support files available. One for Excluded Computers and one for Excluded OU's. They are used to exclude objects manually created for non Windows devices such as SAN or Linux systems as well as special purpose OUs that need excluded.

This script is provided as-is, no warranty is provided or implied.The author is NOT responsible for any damages or data loss that may occur through the use of this script.  Always test, test, test before rolling anything into a production environment.

You can get the script here.