The Surly Admin

Active Directory Operational Testing

One of the things I’ve been working on lately is some kind of operational testing for Active Directory.  It’s such a reliable product that as Administrators we tend to neglect it.  Then Irwin Strachan came up with his Active Directory tests using Pester, and this was the first time I’d seen Pester used in something other than code testing and it really got the mind turning.  So when we started getting really serious about monthly capacity planning at athena health then I wanted to do this kind of testing for our Active Directory.

A Funny Thing about Active Directory Diagnostics and PowerShell

The reality is, as I began searching the web to see what others were already doing I soon realized that there wasn’t a ton of stuff out there.  Certainly there is content, but nothing along the lines I was looking for.  Even Irwin’s excellent script really just checked configuration drift, not so much the down and dirty diagnostics I needed.  This led me to DCDiag, which has been the standby diagnostic tool for Active Directory for years, and there simply is no PowerShell equivalent to it.  My first thought was to go through each test in DCDiag and recreate the test in PowerShell but the amount of work surrounding this was going to be immense, and to be honest I expect Microsoft to be doing this, so me repeating that work didn’t make a lot of sense.

That means DCDiag is the tool, and since it creates output straight to the screen then there’s no reason I can’t parse that output and tie it in with Pester.  I got lucky and found a nice script from Anil Erduran on how to parse the output and produce nice object output.  Of course, this wasn’t without it’s problems, one bit in particular were the test names.  DCDiag has several instances where it runs the same test on several different partitions and at first I was only reporting on the test name.  This left me with about 6 to 8 entries in the report all the same–and wondering what was going on!  This meant I also needed to capture the partition I was in during the test, and include that in the test name.  Luckily the parsing framework lent itself very well to this.  Another “glitch” was I also wanted to run the full DNS test, which a normal DCDiag does not run.  Unfortunately this repeats the Connectivity tests that have already been run, so no need to include those in the resulting report so for the DNS DCDiag I just excluded that test from the output.

I also wanted to add a couple of extra checks in there.  One was a really comprehensive replication check.  I know DCDiag does a replication check, but I wasn’t sure it did everything and one of the early versions of this project was to produce a replication report and I really didn’t want to abandon that code–call me sentimental.  The idea I had was to take that report, and SUM the number of files that are backlogged.  Since a fully functioning AD shouldn’t have any backlogged objects then this should always be 0.  Here’s how I did that part (so much easier when you have PowerShell cmdlet’s to work with!):

Another test that DCDiag is doing is SysVolCheck, which checks the registry to make sure the SysVol is being advertised.  What it doesn’t do is make sure you have enough space on your hard drive  for day to day operations.  Which led to the next question, how much is enough space?  I went with 25% free space.  I’m assuming most people are doing no less then 50gb for their C: drive–and again I’m assuming you’re using the C: drive because in some 20 years of being a Windows administrator I’ve never seen a server that wasn’t set up that way–so 25% of that is a good number.  In fact about a year ago we switched over to 75gb C: drives simply because SxS is so large these days that managing the C: with 50gb was taking up too much time.

Using Switch and RegEx

One of the nice surprises I found was using Switch and RegEx is a super effective way of parsing a text file when you’re on the lookout for multiple things.  I’ve not used this particular method much and I really wish I had.  The other surprise was Switch fully supports named text captures from RegEx, which really helped me in this project.   In DCDiag I noticed when running a partition or enterprise test the output was identical except for the word partition or enterprise.  So instead of doing 2 different searches to capture this, why not do one search, capture the text and use that?  Here’s an example of what I mean, the array at the beginning is just example text:

This made capturing that type of test (partition or enterprise) and where it was running easy and efficient to capture.

Wrapping Up

After this it was pretty easy to run the Pester tests, capture the output (using -Passthru on the Invoke-Pester cmdlet) and produce a nice HTML report.  Right now I’m emailing the report but when I do the official release on GitHub I might just have it save the HTML to a file (it’s already doing that so really just take out the email).  Not sure what I’m going to do there.  I have already posted everything on GitHub but it’s not fully baked at this time.  I am currently skipping a few key tests because they’re failing in my environment because we have that blocked by the firewall–we recently locked down our domain controllers and still going through the growing pains–and have yet to put in the comment based help.  Good chance I’ll do that today though so by the time you read this it may already be there.

That’s it!  Hope you like, here’s the link to Active Directory Operational Testing on GitHub.

November 28, 2016 - Posted by Martin9700 | PowerShell | Active Directory, dcdiag, pester