PowerShell not only knows file system drives but also supports drives that enable you to access the Registry, the certificates store, and the AD. Thus, you can navigate and work in those hierarchical structures with the same commands as in directory trees.

Windows 8.x and Server 2012 (R2) extended the PowerShell command set greatly and introduced new Active Directory management cmdlets that range from user and password administration to the assignment of access rights and Group Policy settings.

Numerous AD management cmdlets ^

The downside of this powerful command set is considerable complexity because you first have to learn the syntax of the corresponding cmdlets. This becomes particularly apparent when you work with the interactive PowerShell and you permanently have to search for the correct commands.

The advantage of mounting the registry or AD as a drive is that you can work with the same cmdlets that you know from managing files. However, in the case of Active Directory, you have to deal with a few syntactic peculiarities when navigating through the tree structure.

Mounting AD: drive ^

Before you change to Active Directory with the Set-Location cmdlet (alias cd), you should verify whether it is actually available as a drive. You can do this with the Get-PSDrive cmdlet that you can restrict to AD drives with -PSProvider ActiveDirectory. By default, the AD drive is not mounted, so you first have to load the AD module:

Import-Module ActiveDirectory

You can now use the well-known cd command to change to the root directory:

cd ad:

Aside from Set-Location (alias sl, ls, or cd), Get-Location, push, and pop are available for navigating through the AD tree. As usual, you can get an overview of a subtree’s containing objects with Get-ChildItem (alias gci, dir). Among other objects, you’ll find the forest’s domains in the AD root.

Viewing AD objects with Get-ChildItem

Viewing AD objects with Get-ChildItem

Changing to a domain or an OU ^

If you try to change to a domain by using its DNS name (for instance, cd contoso.com), you’ll receive the error message “Cannot find path 'AD:\contoso.com' because it does not exist.” because PowerShell expects you to specify the distinguished name:

cd "DC=contoso,DC=com"

The same applies to OUs, groups, and containers. For instance, to change to the OU with the name “sales,” you have to execute the following command:

cd OU=sales

I’ve assumed here that the OU is located one level below the current location. If the OU is a subdirectory of the parent directory, you can use the next command:

cd ../OU=sales

And, to change to the Computers container, you need the following command:

cd CN=Computers

As in the file system, PowerShell also supports autocomplete for AD object names. After you enter the equal sign in the distinguished name, you have to press the TAB key to get a list of possible options.

Listing and filtering objects ^

Within OUs or groups, you can easily list users and computers with the above-mentioned Get-ChildItem cmdlet. As expected, without parameters, the cmdlet displays all objects in the current container; if you use the -Recurse switch, it includes all subdirectories. If you want to restrict the output by name, you can filter the result with Where-Object:

gci | where {$_.Name -like "F*"}

In the case of user objects, gci shows three attributes by default. If you want to view more or other properties, you have to use the -Properties parameter; if you pass “*” as a value, you will receive all attributes, which you can filter with the help of select:

gci -properties * | where ObjectClass -eq "user" | select displayname, name, mail, telephoneNumber

Displaying tabular data in the GUI ^

Because the output of a large number of user objects with more than three attributes can be confusing, you might want to use Out-GridView. This cmdlet displays the output of gci in a graphical table with sortable columns so that you can easily scroll through the list:

gci -properties * | where ObjectClass -eq "user" | select displayname, name, mail, telephoneNumber | Out-GridView

Deleting or copying objects ^

The examples so far only demonstrated how to read AD objects. However, the PowerShell drive also supports write access. For example, you can delete user objects with Remove-Item or duplicate them with Copy-Item.

Remove-Item ".\CN=FLee"

It goes without saying that this kind of operation should be carried out with extreme caution because you can easily destroy entire subtrees this way.

Creating new users ^

Creating new users is possible as well. For instance, the following command creates the user with the name Sam Sample in the Marketing OU:

New-Item -ItemType user -path "OU=Marketing" -name "CN=Sam Sample"

Analogous to this, you can also create an OU if you pass the value “OU” to -ItemType.

Changing object attributes ^

A frequent application of the AD drive is changing attributes of existing objects. The following command would change the attribute “company” to Northwind:

Set-ItemProperty -Filter "Company=Contoso" -Name Company -Value Northwind -Path *

In this example, only users of the current OU or group would be affected. Of course, you can also add the parameter -Path to modify objects at another location.


Leave a reply

Your email address will not be published.


© 4sysops 2006 - 2022


Please ask IT administration questions in the forums. Any other messages are welcome.


Log in with your credentials


Forgot your details?

Create Account