Summary: Microsoft Scripting Guy, Ed Wilson, talks about using the AD: drive to explore Active Directory Domain Services.
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
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.
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 DistinguishedNameattribute. 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.
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 Usersis 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