Categories Tutorials

Using PowerShell to assess Active Directory health

Although there are plenty of pricey tools available for monitoring the health of your Active Directory environment, it is also possible to use PowerShell as an alternative. PowerShell is part of the Windows operating system, and therefore has insight into the Active Directory, making it perfect for keeping tabs on your AD environment and Active Directory health.

Of course, if you are going to build a PowerShell script to monitor your Active Directory health, then you will need to figure out exactly what checks your script will perform. Because of space limitations, I can’t even begin to touch on all of the cmdlets that you can use to assess the health of your Active Directory (it would probably fill an entire book), but I wanted to show you a few of my favorite techniques.

Service health

If you want to use a PowerShell script to make sure that your Active Directory is healthy, then you may want to start by verifying that the dependency services are all running. You can find out what the dependencies are by logging onto a domain controller and entering the Services.msc command at the Run prompt. This will launch the Windows Service Control Manager. Right-click on the Active Directory Domain Services, and choose the Properties command from the shortcut menu. This will cause Windows to display the service’s properties sheet. Click on the Dependencies tab, and you will see a list of the services that the Active Directory Domain Service depends on, as shown in the figure below.


Keep in mind that the list of dependency services may vary from one version of Windows Server to the next. In addition to the dependency services, I also recommend checking the state of the NetLogon service. It’s also important to not forget to check the Active Directory Domain Services.

Here are a couple of commands that you can use to check to make sure that the necessary services are running:

$Services='DNS','DFS Replication','Intersite Messaging','Kerberos Key Distribution Center','NetLogon',’Active Directory Domain Services’
ForEach ($Service in $Services) {Get-Service $Service | Select-Object Name, Status}

The first command defines a variable named $Services. Its job is to store the names of all of the services that need to be checked. The second command goes through the list of services and displays the name and status of each. You can see what this looks like in the next figure. As you look at the screenshot, you will notice that PowerShell displays some of the service names in a slightly different way from what the Service Control Manager does. For instance, the Active Directory Domain Services are displayed as NTDS.


You could even expand the script so that it automatically starts any service that might have stopped. Here is what such a command sequence might look like:

$Services='AppMgmt'
$Check=Get-Service $Services
$Check | Select-Object Name, Status
If ($Check.status -eq 'Stopped'){Start-Service $Services}
$Check=Get-Service $Services
$Check | Select-Object Name, Status

I limited my example to a single service for the sake of simplicity, and I also opted to use a service that was not related to the Active Directory because I didn’t want to stop any critical services. Even so, you can see in the screen capture below that these commands check the status of, and then start a system service.


Another thing that you can do without getting too deep in the weeds is to use the DCDIAG command to verify that the Active Directory is functioning properly.

If you aren’t familiar with DCDiag, it is a command-line tool that is designed to validate a domain controller’s health. There are numerous tests that are built into DCDiag, and you can use these tests to check various aspects of the Active Directory’s health.

If you are running the DCDiag command locally on a domain controller, then all you have to do is to specify the /Test switch, followed by a colon and the name of the test that you want to run. You can get a list of the available tests by entering the DCDiag /? command.

Incidentally, you can use the DCDiag command to run a series of diagnostic tests against a remote domain controller. To do so, you will have to the/S switch, followed by a colon and the name of the domain controller that you want to test. If necessary, you can append another colon after the domain controller’s name, and then enter the LDAP port number that you want to use.

The DCDiag tool also makes it possible to provide a set of administrative credentials. Unfortunately, you won’t be able to use PowerShell’s Get-Credential cmdlet because of a reason that I will discuss in a moment. If you want to provide credentials, then enter the /U switch, followed by the username in Domain\Username format. Similarly, you can enter your password by using the /P switch and then specifying your password. All of this is outlined on the help screen when you enter the DCDiag /? command.

As I mentioned a moment ago, you can’t use PowerShell’s Get-Credential cmdlet to supply a set of administrative credentials to the DCDiag command. The reason for this is that DCDiag isn’t a PowerShell cmdlet. Instead, it is a command-line utility that predates PowerShell.

The other reason why the DCDiag command’s age is problematic is that it does not generate its output in a way that PowerShell can understand. Sure, you can display DCDiag’s test results on-screen with very little effort, but if DCDiag does detect a problem, you can’s use the PowerShell pipeline to take action – at least not without jumping through a few hoops. Thankfully, someone has found a way to parse DCDiag’s output so that it can be more easily be used within a PowerShell script.

Active Directory health and PowerShell: Almost no limits

When it comes to using PowerShell as a tool for monitoring Active Directory health, you are limited only by your imagination. PowerShell provides tools that can be used for remediation and notification, and you can even use the Windows Task Scheduler to run your script automatically.
When using PowerShell as a tool for monitoring Active Directory health, you are limited only by your imagination

Brien Posey

Brien Posey is a freelance technology author and speaker with over two decades of IT experience. Prior to going freelance, Brien was a CIO for a national chain of hospitals and healthcare facilities. He has also served as a network engineer for the United States Department of Defense at Fort Knox. In addition, Brien has worked as a network administrator for some of the largest insurance companies in America. To date, Brien has received Microsoft’s MVP award numerous times in categories including Windows Server, IIS, Exchange Server, and File Systems / Storage. You can visit Brien’s Website at: www.brienposey.com.

Share
Published by
Brien Posey

Recent Posts

SD-WAN: Is this going to be your network of the future?

As businesses evolve into a SaaS/IaaS model for accessing applications, new network technology is crucial. SD-WAN is just such a…

29 mins ago

Monitoring Exchange and the rest of your network to avert disasters

What you don’t know about Exchange and your network can come back to bite you. Monitoring Exchange is one way…

17 hours ago

Quick tip: Removing warning messages from Azure cmdlets

Warnings are nice, except when they are annoying and unnecessary. Here’s a tip to show you how to remove warning…

19 hours ago

Is the Group Policy Central Store still relevant in the age of Windows 10?

Having a Group Policy Central Store in Active Directory made life easier for administrators. But does it still work in…

21 hours ago

Review: Specops uReset Active Directory self-service password reset solution

Specops uReset helps companies reign in helpdesk costs by giving users a self-service portal where they can reset their password.…

1 day ago

User-friendly web design tools for a user-friendly website

If you want your business to succeed these days, you need a user-friendly website. Put these tools in your toolbox…

2 days ago