Playing with the AD: Drive for Fun and Profit

Doctor Scripto

Summary: Microsoft Scripting Guy, Ed Wilson, talks about using the AD: drive to explore Active Directory Domain Services.

Hey, Scripting Guy! Question Hey, Scripting Guy! I will confess that I love using the Active Directory module for Windows PowerShell. I love the way I can use Windows PowerShell to create new users or to easily search for and find users and other stuff. What I do not get is the drive that the Active Directory module creates. I mean, what good is it? Every time I try to change to my domain “folder,” all I get is an error. I guess that it is used under the covers for something, but it seems a shame that I cannot use it too. Not sure if there is a question here other than, “Can I actually use the AD: drive?” If the answer here is, “Yes,” I need a follow up question, “How?” Thanks for listening and for all the good work you do.

—RR

Hey, Scripting Guy! Answer Hello RR,

Microsoft Scripting Guy, Ed Wilson, is here. This morning I am sipping a cup of English Breakfast tea and listening to Abba. I was looking at some of the pictures Teresa and I took while we were in Stockholm, and for some reason Abba songs kept coming to my mind. When this happens, it seems that all I can do to extinguish the tune is to flood it. I am also thinking about, “I am your Scripting King…” Hmm…

Understanding the AD: drive

You get the Active Directory module as part of the Remote Server Administration Tools for Windows 8. One of the cool features in Windows PowerShell 3.0 is when I use a cmdlet, Windows PowerShell automatically loads the module that contains the cmdlet if it is not already present. Autoloading is great.

Therefore, when I use Get-ADComputer, Windows PowerShell automatically loads the Active Directory module. However, if the Active Directory module is not already loaded, attempting to set my working location to the AD: drive generates an error. This is shown here.

PS C:\> sl ad:

sl : Cannot find drive. A drive with the name ‘ad’ does not exist.

At line:1 char:1

+ sl ad:

+ ~~~~~~

    + CategoryInfo          : ObjectNotFound: (ad:String) [Set-Location], DriveNotFoundException

    + FullyQualifiedErrorId : DriveNotFound,Microsoft.PowerShell.Commands.SetLocationCommand

Load the Active Directory module to use the drive

After you import the Active Directory module, the AD: drive becomes available. I can then set my working location to the AD: drive. I can also use Get-ChildItem to retrieve the contents. This is shown here.

PS C:\> sl ad:

PS AD:\> dir

 

Name                 ObjectClass          DistinguishedName

—-                 ———–          —————–

iammred              domainDNS            DC=iammred,DC=net

Configuration        configuration        CN=Configuration,DC=iammred,DC=net

Schema               dMD                  CN=Schema,CN=Configuration,DC=iammred,D..

DomainDnsZones       domainDNS            DC=DomainDnsZones,DC=iammred,DC=net

ForestDnsZones       domainDNS            DC=ForestDnsZones,DC=iammred,DC=net

Unfortunately, what I see on the AD: drive is not what you need to use to actually interact with the drive. This leads to confusion. Therefore, when I attempt to set my location to the iammred container, an error arises. This is shown here.

PS AD:\> sl iammred

sl : Cannot find path ‘AD:\iammred’ because it does not exist.

At line:1 char:1

+ sl iammred

+ ~~~~~~~~~~

    + CategoryInfo          : ObjectNotFound: (AD:\iammred:String) [Set-Location],ItemNotFoundException

    + FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.SetLocationCommand

The error is a bit misleading because obviously iammred does exist. I can prove that it exists by piping the object to the Where-Object as shown here.

PS AD:\> dir | ? name -eq ‘iammred’

 

Name                 ObjectClass          DistinguishedName

—-                 ———–          —————–

iammred              domainDNS            DC=iammred,DC=net

I use the up arrow, and send the output to the Format-List cmdlet to view all of the information in my search for a hint. The output from the command is shown here.

Image of command output

Change my working location to the domain

I decide to use the Set-Location cmdlet to change my working location to the actual domain. To do this, I specify the DistinguishedName attribute. Because the components of the name separate via commas, I place the string in quotation marks. When I have my working location on the domain drive, I use the Get-ChildItem cmdlet to produce an output. These commands are shown here.

PS AD:\> sl “dc=iammred,dc=net”

PS AD:\dc=iammred,dc=net> dir

The commands and the output associated with the commands are represented in the image that follows.

Image of command output

To change location to the child containers, the first portion of the distinguished name is required. Therefore attempting to set the location to the Users container fails when attempted as follows.

sl users

It also fails when I attempt to connect to OU=Users as seen here. This is understandable because Users is a container and not an organizational unit (OU).

sl “ou=users”

When I use Set-Location to change the working location to cn=users, does the command work? This is shown here.

PS AD:\dc=iammred,dc=net> sl “cn=users”

PS AD:\cn=users,dc=iammred,dc=net>

I can use the .. shortcut to move up a level in the hierarchy as shown here.

PS AD:\cn=users,dc=iammred,dc=net> sl ..

PS AD:\dc=iammred,dc=net> dir

I use the same technique to change to the Charlotte OU. This command is shown here.

PS AD:\dc=iammred,dc=net> sl “ou=charlotte”

PS AD:\ou=charlotte,dc=iammred,dc=net>

To move to the root of the C: drive from the AD: drive, use the Set-Location cmdlet and specify the C: drive. This technique is shown here.

PS AD:\ou=charlotte,dc=iammred,dc=net> sl c:\

PS C:\>

From the root of the C: drive, to go back to the Charlotte OU, I use the full path as shown here.

PS C:\> sl “AD:\ou=charlotte,dc=iammred,dc=net”

PS AD:\ou=charlotte,dc=iammred,dc=net>

When I navigate, I like to use Push and Pop. So, from the Charlotte OU, I use the Push-Location cmdlet to store the path to my current location, and then I change to the C: drive This is shown here.

PS AD:\ou=charlotte,dc=iammred,dc=net> push-location

PS AD:\ou=charlotte,dc=iammred,dc=net> sl c:

PS C:\>

Next, I use Pop-Location to return me to the Charlotte OU. This technique is shown here.

PS C:\> Pop-Location

PS AD:\ou=charlotte,dc=iammred,dc=net>

Create a new Windows PowerShell drive for a favorite OU

If I find myself spending a lot of time in the Charlotte OU, I do not want to deal with a lot of typing to change to the OU. So I can create a new Windows PowerShell Drive only for Charlotte. First, I need to know the name of the provider. I get this by using the Get-PSProvider cmdlet. This is shown here.

PS C:\> Get-PSProvider

 

Name                 Capabilities                    Drives

—-                 ————                    ——

Alias                ShouldProcess                   {Alias}

Environment          ShouldProcess                   {Env}

FileSystem           Filter, ShouldProcess, Crede… {C, D, E}

Function             ShouldProcess                   {Function}

Registry             ShouldProcess, Transactions     {HKLM, HKCU, HKCR}

Variable             ShouldProcess                   {Variable}

ActiveDirectory      Include, Exclude, Filter, Sh… {AD}

It is as I suspected. Now I create my new Windows PowerShell drive by using the New-PSDrive cmdlet. The only thing that is tricky is the value for Root. I copied the string that I used earlier with Set-Location, and it worked perfectly here.

PS C:\> New-PSDrive -Name Charlotte -PSProvider ActiveDirectory -Root “AD:\ou=charlot

te,dc=iammred,dc=net”

 

Name           Used (GB)     Free (GB) Provider      Root

—-           ———     ——— ——–      —-

Charlotte                              ActiveDire… //RootDSE/ou=charlotte,dc=ia…

Remember, I now have a Windows PowerShell drive, so I need the colon at the end of the drive name to navigate there. This is shown here.

PS C:\> sl charlotte:

PS Charlotte:\>

When I am on the drive, I can use standard cmdlets to work with the data. Here I use dir (alias for Get-ChildItem) to obtain a list of all members of the Charlotte OU.

PS Charlotte:\> dir

Name                 ObjectClass          DistinguishedName

—-                 ———–          —————–

ED-PC                computer             CN=ED-PC,OU=Charlotte,DC=iammred,DC=net

ed wilson            user                 CN=ed wilson,OU=Charlotte,DC=iammred,DC…

EDLT                 computer             CN=EDLT,OU=Charlotte,DC=iammred,DC=net

HYPERV2              computer             CN=HYPERV2,OU=Charlotte,DC=iammred,DC=net

Regular User         user                 CN=Regular User,OU=Charlotte,DC=iammred…

Sample User          user                 CN=Sample User,OU=Charlotte,DC=iammred,…

SQL                  user                 CN=SQL,OU=Charlotte,DC=iammred,DC=net

Teresa Wilson        user                 CN=Teresa Wilson,OU=Charlotte,DC=iammre…

RR, that is all there is to using the AD: drive. Active Directory Week will continue tomorrow when I will talk about searching Active Directory by using the AD: drive.

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy 

0 comments

Discussion is closed.

Feedback usabilla icon