PowerShell & Active Directory

I’ve had a bunch of folks ask, recently, why PowerShell has an [ADSI] type accelerator, but doesn’t have an Active Directory PSDrive. I’ve also wondered a bit, myself about why PowerShell’s [ADSI] type doesn’t work as well with WinNT queries as it does with LDAP queries.

To elaborate: You can, in PowerShell, do something like this:

[ADSI]$user = “LDAP://cn=DonJ,ou=Tech,dc=domain,dc=com”

And PowerShell will run out, get that user, and put the user object in the $user variable. Very cool. And you can pipe that user to Get-Member to see what it can do:

$user | get-member

However, try that with a WinNT query, rather than an LDAP query, the the Get-Member output doesn’t include the full list of methods and properties you’d expect from a WinNT object – say, a user object. Why? The answer lies not in PowerShell, but rather in the underlying .NET Framework DirectoryEntry type, which is what PowerShell is actually getting for you. Remember, PowerShell’s true functionality comes from the .NET Framework; all the cmdlets are is (oversimplifying just a bit, here) is a thin layer to make the .NET Framework a bit more task-oriented. So PoSH asks the Framework to execute your query and gives you back whatever the Framework comes up with. The Framework’s directory services classes were intended to be fairly generic, like LDAP; they don’t provide specific classes that represent the various unique WinNT-style classes. So, when you execute a WinNT query, you get back essentially the same object that an LDAP query would return. That doesn’t mean you can’t do all the things you want to with the WinNT object, mind you; you just have to do so in a more generic way. For example, you’d use Get and Put methods to view and modify user properties, rather than using direct-named properties. Just takes a bit of getting used to, really: All the functionality is still there.

Now about that other question: Why doesn’t PoSH let you browse Active Directory like you can the Registry, file system, certificate store, etc? In other words, why isn’t AD exposed as a PS Drive?

Well… it was going to be. And it almost certainly will be, someday. Earlier betas of PoSH had the beginnings of an AD PSDrive provider, but the team wasn’t able to get it up to the level of functionality they wanted in time for v1.0’s ship date. They knew this early on; the provider disappeared in the Beta 3 timeframe, in fact, as they made the decision to start focusing on finishing other functionality, instead. Unfortunately, even a giant like Microsoft has limited resources: You’ve got “x” number of people and “y” number of days, so you can only ship “z:” The number of features that those folks can finish in that amount of time. Sure, an AD PSDrive would be awesome – but it’ll be something to look forward to in v1.1 or v2.0 or whatever.

Meantime, if you haven’t done so, check out the registry PSDrive snap-in (run something like cd hkcu: to get into it). PSDrives allow PoSH to expose nearly any kind of hierarchical data as a file system, meaning registry values look like files and registry keys look like folders. The theory is that admins are already comfortable working with a file system from the command line, so why not make EVERY type of storage look like a file system? It’s a pretty bold step (for Windows; Unix systems have more or less always worked this way) and it definitely works: You only have to know ONE st of techniques for navigating storage, and it works for everything.