Hey, Scripting Guy! What’s Up with Active Directory Domain Services Cmdlets?

 Bookmark and Share


Hey, Scripting Guy! Question

Hey, Scripting Guy! I have heard that Windows PowerShell 2.0 includes cmdlets to work with Microsoft Active Directory Domain Services (AD DS). However, when I use the Get-Command cmdlet to list the available cmdlets in my Windows PowerShell session, I do not see any AD DS cmdlets. What gives? Is this more of the notorious Microsoft vaporware?

-- JM


Hey, Scripting Guy! AnswerHello JM,

Microsoft Scripting Guy Ed Wilson here. Today is a lovely day in Charlotte. The sky is clear blue with high cirrus clouds, the sun is shining brightly, and the birds are moonwalking on my front lawn while looking for take-away meals. Charlotte has successfully dug out from the 2010 snowstorm that never came. Just because Charlotte did not receive any snow did not keep our citizens from acting in sympathy with our northern neighbors. The stores were all mobbed by panic buyers. Businesses were closed and schools shuttered their doors. And (wait for it) the snow never arrived. We were robbed! I wanted to take a snow day, and make a snow version of Dr. Scripto in my front yardmajor bummer. Meg in New York on Twitter offered to box up and ship some snow to us, but I figured it would melt before it arrived so I politely declined. The sky outside reminds me of when I was in London teaching a Windows Management Instrumentation (WMI) class to a Microsoft Premier customer. One day the sky cleared, revealing a beautiful deep blue sky.

Image of The London Eye


JM, the AD DS Windows PowerShell cmdlets are not vaporware, but unless you are running Windows Server 2008 R2 with the AD DS role on your laptop, you probably do not have access to the cmdlets. The first thing you need to do is download the Remote Server Administration Tools (RSAT) for Windows 7. After you have downloaded and installed the RSAT tools, you still have to go into Programs and Features in Control Panel, and click Turn Windows features on or off. This opens the Windows Features dialog box, which is shown in the following image.

Image of Windows Features dialog box

After you have accessed the Windows Features dialog box, you still must choose the administrative tools you wish to install. Just installing the RSAT module does not actually install any of the RSAT tools. It merely gives you the ability to install RSAT tools. Though this is a nice granular feature, it can be a bit annoying because there is no “click to install all the tools” feature. The nice thing is if you find you have left something out, you can easily add it back in without needing to have access to the original bits again. You use the same Turn Windows features on or off dialog box that you use to, for example, add or remove games. The Turn Windows features on or off dialog box is seen in the following image, with a portion of the RSAT section highlighted. There are so many tools, they will not fit on the screen without scrolling (depending on your screen resolution of course).

Image of so many tools in the Windows Features dialog box


After you have installed the RSAT tools and added the appropriate, there is one more thing you must do before you are able to use the AD DS cmdlets. You must import the Active Directory module. You can use a wildcard character to shorten the typing requirements, as seen here:

PS C:> Import-Module active*
PS C:>

If everything is working correctly, you will see the Windows PowerShell progress bar displayed in your Windows PowerShell console, which is shown in the following image.

Image of Windows PowerShell progress bar


To check to see if the AD DS cmdlets have been imported to your Windows PowerShell console session, use the Get-Command cmdlet with the –module parameter:

Get-Command -Module active*

The Get-Command cmdlet, when used with the –module parameter, will return cmdlets that are exported by the specified module. If you are curious about how many cmdlets are exported, you can pipe the results to the Measure-Object cmdlet, as seen here:

PS C:> Get-Command -Module active* | Measure-Object

Count    : 76
Average  :
Sum      :
Maximum  :
Minimum  :
Property :

PS C:>

If you are not sure of the name of the module, you can use the Get-Module cmdlet with the –ListAvailable switch. Keep in mind that the list of modules returned by this command will depend on which modules you have created or installed on your system:

PS C:> Get-Module -ListAvailable

ModuleType Name                      ExportedCommands
---------- ----                      ----------------
Script     BasicFunctions            {}
Script     DotNet                    {}
Manifest   FileSystem                {}
Manifest   IsePack                   {}
Manifest   PowerShellPack            {}
Manifest   PSCodeGen                 {}
Manifest   PSImageTools              {}
Manifest   PSRSS                     {}
Manifest   PSSystemTools             {}
Manifest   PSUserTools               {}
Manifest   TaskScheduler             {}
Manifest   WPK                       {}
Manifest   ActiveDirectory           {}
Manifest   AppLocker                 {}
Manifest   BitsTransfer              {}
Manifest   FailoverClusters          {}
Manifest   GroupPolicy               {}
Manifest   NetworkLoadBalancingCl... {}
Manifest   PSDiagnostics             {}
Manifest   TroubleshootingPack       {}

PS C:>

To create a new user in Active Directory, use the New-ADUser cmdlet. Two parameters are required when creating a new user: the name parameter and the path parameter. The name parameter is the name of the user object to create, and the path parameter specifies the organizational unit that will contain the new object. The path parameter uses standard LDAP syntax, as seen here:

New-ADUser -Name HSG_Test -Path "ou=test,dc=nwtraders,dc=com"

If you do not specify the path when creating a new user, an error message will be returned after a few seconds:

PS C:> New-ADUser -Name HSG_Test1
New-ADUser : Unable to contact the server. This may be because this server does not exist, it is currently down,
does not have the Active Directory Web Services running.
At line:1 char:11
+ New-ADUser <<<<  -Name HSG_Test1
    + CategoryInfo          : ResourceUnavailable: (:) [New-ADUser], ADServerDownException
    + FullyQualifiedErrorId : Unable to contact the server. This may be because this server does not exist, it i
   ently down, or it does not have the Active Directory Web Services running.,Microsoft.ActiveDirectory.Manageme

PS C:>

If you try to supply the name of the new user object in the path and leave out the name parameter, you will be prompted for the user name:

PS C:> New-ADUser -Path "cn=HSG_TestUser1,ou=test,dc=nwtraders,dc=com"

cmdlet New-ADUser at command pipeline position 1
Supply values for the following parameters:

After you supply the name for the user object, an error will then be returned:

New-ADUser : Unable to contact the server. This may be because this server does not exist, it is currently down, or it
does not have the Active Directory Web Services running.
At line:1 char:11
+ New-ADUser <<<<  -Path "cn=HSG_TestUser1,ou=test,dc=nwtraders,dc=com"
    + CategoryInfo          : ResourceUnavailable: (:) [New-ADUser], ADServerDownException
    + FullyQualifiedErrorId : Unable to contact the server. This may be because this server does not exist, it is curr
   ently down, or it does not have the Active Directory Web Services running.,Microsoft.ActiveDirectory.Management.Co

PS C:>

After the New-ADUser cmdlet has been used to create the new user and the name and path supplied, no feedback is displayed on the Windows PowerShell console. You can use Active Directory Users and Computers to see if the user object has been created, as shown in the following image.

Image of using Active Directory Users and Computers


If you do not want to bother with opening Active Directory Users and Computers, you can use the Get-ADUser cmdlet to search for your newly created user:

PS C:> Get-ADUser -Filter "name -like 'hsg*'"

DistinguishedName : CN=HSG_Test,OU=test,DC=NWTraders,DC=Com
Enabled           : False
GivenName         :
Name              : HSG_Test
ObjectClass       : user
ObjectGUID        : 62d45f11-dad4-4752-b82d-562f8f58243f
SamAccountName    : HSG_Test
SID               : S-1-5-21-3746122405-834892460-3960030898-1159
Surname           :
UserPrincipalName :


JM, that is all there is to using the Windows PowerShell cmdlets to create a bunch of new users in Active Directory. Active Directory Week will continue tomorrow.

If you want to know exactly what we will be looking at tomorrow, follow us on Twitter or Facebook. If you have any questions, send e-mail to us at scripter@microsoft.com or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.


Ed Wilson and Craig Liebendorfer, Scripting Guys


Comments (9)

  1. Boe Prox says:

    Unless you are running PowerShell V3/4 (in which the module would be auto-loaded for you when you attempted to run the cmdlet), you will need to load the module into your current session using Import-Module ActiveDirectory prior to using any of the ActiveDirectory module cmdlets. See example below:

    Import-Module ActiveDirectory

  2. Anonymous says:

    Hi Ed,

    Thank you very much! This is what I am looking for! Expecting the coming ones.

  3. bshwjt says:

    Thanks for sharing.

  4. Anonymous says:

    Hello Ed,

    Good article.

    Mark Minasi last week posted an article (http://www.minasi.com/newsletters/nws1001b.htm) on how to get this to work with a Windows 7 client and a Windows 2003 or 2008 (non R2) server.

  5. JP says:

    Thanks for this post!

    jmcclugg, thanks for your link as well, that was very helpful.

  6. El presidente says:

    I run Powershell directly from my Windows 2008 Server, but I have the same problem: the AD management Powershell commands such as get-ADObject are definitely vaporware: they do not appear in the list of available commands. How can I get them, please?

  7. IDM Mike says:

    When I type Get-Module -ListAvailable, I get the following response:
    ModuleType Name ExportedCommands
    ————– —– ———————-
    Manifest ActiveDirectory ()
    Manifest AppLocker ()
    Manifest BitsTransfer ()
    Manifest FailoverClusters ()
    Manifest GroupPolicy ()
    Manifest NetworkLoadBalancingCl… ()
    Manifest PSDiagnostics ()
    Manifest TroubleshootingPack ()

    And I still get an error message when I run the following:
    PS C:> Get -ADRootDSE
    The error message:
    The term ‘Get’ is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
    At line:1 char:4
    + Get < <<< -ADRootDSE + CategoryInfo : ObjectNotFound: (Get:String) [], CommandNotFound Exception + FullyQualifiedErrorId : CommandNotFoundException PS C:>

    I am a rookie, so I expect this to be an elementary problem. But can you assist in resolving?

  8. Hassan Parthasarathy says:

    Nice article. It helped me. Thanks

Skip to main content