Before You Install System Center … Clean Up Those Computer Accounts

First, I hope you’ve done some planning/architecture/proof of concept.  Next, clean up the environment.  Products that deploy agents, such as System Center Essentials (SCE), Configuration Manager (SCCM/ConfigMgr), and Operations Manager (SCOM/OpsMgr), will allow you to track the success of agent deployment.  And if your network is like most others I’ve encountered over the years, nobody has bothered to clean up the inactive/obsolete computer accounts.  The computer discovery process will use some sort of discovery process, most likely based on computer accounts found in Active Directory.  It may find computer accounts that have been there since 2000 and no longer are valid.  It may find 50% more computer accounts than actually exist.

Before you deploy agents you need to do some spring cleaning.

Computer Accounts

My favourite tool for this in the past was oldcmp.  The page doesn’t list Windows 2008 or 2008 R2.  I last used it with Windows Server 2008 in a lab and it worked fine.  It allowed you to work with user and computer accounts:

• Report only
• Disable
• Move and disable (to a “disabled” OU)
• Delete

The last time I was an admin of a large environment I was very fussy about inactive accounts.  We used to run oldcmp as a scheduled task on a monthly basis.

If you want something that is supported then try this.  Identify & disable computer accounts that were inactive for the last 4 weeks:

dsquery computer -inactive 4 | dsmod computer -disabled yes

Then you can identify and delete computer account that have been inactive for the last 8 weeks:

dsquery computer -inactive 8 | dsrm computer

Put that in a script and run it every month and you’ll automate the cleanup nicely.  Inactive machines for the last 4 weeks will be disabled and you can re-enable them if a user complains.  After 8 weeks, they get completely removed.  If you have people away for longer periods then you can extend this, e.g. disable after 26 weeks and delete after 52 weeks.  Or you might bundle that caution about deleting with a secure mindset, e.g. disable after 4 weeks and delete after 52 weeks.

Note: dsquery, dsmod, and dsrm can be easily used for lots more, e.g. user accounts. Check the help (at command prompt) and test-test-test before putting it into use.  You probably can do all of this with PowerShell and the useful –whatif flag.

DNS Records

I hate stale DNS records because they can lead to all sorts of false positives when there is IP address re-use, especially when trying to remotely manage/connect to PCs in a DHCP environment.  You can configure DNS scavenging of stale records on a DHCP server (for all zones) or on a per zone basis.

Be careful with this one.  I’ve been especially careful with the intervals since the 2003 days when I had a Premier support call open.  Scavenging didn’t like me using smaller intervals, even if they were correctly configured.

Once you have the environment cleaned up, you can start deploying agents.  Now when you see a “failed” message, you know you can take it seriously and schedule a human visit.

Note: I don’t think I’ve ever used ConfigMgr to build collections of users.  Users roam and I don’t want to install software needlessly.  But ConfigMgr 2012 will have a more reliable user-centric approach that detects a user’s primary PC.  Therefore, you’ll want to do a user clean up before deploying it … and that should be standard security practice anyway.