Managing Active Directory via PowerShell: Introduction

As a platforms PFE, I spend a good deal of my time at customer sites working with Active Directory administrators. During my travels, I've found that many AD admins are either unaware of what Server 2008 R2 brings to the table with PowerShell and AD, or they're afraid to use it due to the perceived learning curve associated with PowerShell. I spoke with an administrator a few months ago who had manually enabled accidental deletion protection across several hundred OUs - one at a time. He spent several days doing something that could have been done in moments with a one line PowerShell script.

My goal with this series of posts is to outline the requirements of using the Active Directory PowerShell module, and then to show examples of different administrative tasks. By the end of the series, I hope that a reader will feel comfortable with using this module to manage their own AD environment. So let's get to it.


  • The AD PowerShell module requires a Server 2008 R2 DC in your environment, unless you follow Ashley's guide located here.
  • The AD Web Services service needs to be running on at least one DC in the environment. Read more about ADWS here.

During this series, I will start with a new forest running a single Windows Server 2008 R2 domain controller. From there, I'll show how to create subnets, sites, users, groups, and more - all with PowerShell. If you don't have a test environment built, I recommend doing that before starting. You'll want a sandbox where you can add and remove objects without worrying about breaking something in production. Go ahead and build that now... I'll wait.



Ok, now that you've got your brand new test lab running a single Windows Server 2008 R2 domain controller, log on to the DC. There are a few different ways to load up the Active Directory module. The first way to load the AD Module is to click Start, go to Administrative Tools, and find "Active Directory Module for Windows PowerShell." That will start PowerShell and automatically load the module. That requires too many clicks for my liking, so I generally hit the shortcut on the taskbar and type Import-Module ActiveDirectory. It should look like this:

Now, you might see that error message. If you do, no worries. The message is telling you exactly what you think it's telling you: ADWS isn't running. Assuming you're logged on to the 2008 R2 DC, you could just use net start to start the service...but this is a series about PowerShell. To verify the state of the service, utilize the get-service cmdlet.

Running that cmdlet shows that the service is stopped. Using start-service, we can start the service, then unload and import the module again.

And now you've successfully imported the AD module for PowerShell.


At this point, you've got at least one Windows Server 2008 R2 domain controller running the AD web service and are successfully able to import the AD PowerShell module. If you want to verify that it's working, you can use the AD PSDrive Provider to do a quick check.

The PSDrive is just what is sounds like: A "drive" that is mapped to AD. To get to the AD PSDrive, you simply type cd AD: and hit enter. That's it. Once you're there, type get-childitem and you should see a list of all naming contexts found on that DC.

This indicates that ADWS is running, the AD module has been imported, and we're able to retrieve data from the directory. Watch for my next post when I start to describe how to build out your subnets and sites using only PowerShell.


Comments (3)

  1. Anonymous says:

    Nice job on the post. Looking forward to more like this.

  2. Nice intro, can't wait to see what else is down the pipe.

  3. David Kaminski says:

    Well done. Looking forward to the rest.

Skip to main content