I’m at a Microsoft Active Directory Services workshop this week, and one of the things i’ve come accross (a little late, it seems..) is the Active Directory Powershell module that ships with Server 2008 R2.
It’s… interesting. Obviously you’ve got a lot of 3rd party AD cmdlets and scripts already out there, so obviously comparisons are going to be drawn. While some of the decisions and implementations seem sensible, I find two things a little odd.
The first one is – why on earth does the default psdrive setup by the AD provider use X500 format? This means that because the paths now contain ‘,’ and ‘=’ you’ve got to encase paths in speech marks and tab completion will not function for paths! This seems bizzare in the face of the fact that you can create a drive using Canonical format instead (which is firstly a damn site easier to read and type, and secondly support tab completion) but you have to use a switch that isn’t normally recognised by new-psdrive…
Second thing – the objects returned by cmdlets. One of the things that i believe is important about powershell is that once you’ve learned how to retrieve and filter objects in one sphere, you’ve pretty much got it down for anything else we can hook into. Sending an object off to get-member to explore it becomes pretty standard behaviour. However, the AD cmdlets only return an extremely limited set of values for most objects. Users objects in particular are crippled by this. While all the AD cmdlets have a -filter attribute that allows us to search on properties that aren’t normally retrieved (read – most of them!) it would have been nice to be able to type:
Get-ADUser | Where {$_.Description -like “*”} | Ft DisplayName,Description
and get a listing back. Now, I understand that by using the -filter param i’m not grabbing all AD users and then searching through them on the local machine, but the fact that even with -filter param the searched for attribute values are not appended to the returned object means that although i can go and grab all users out there that have a VBScript set as their logonscript, i can’t display the script in the results!
…Has no one on the AD Powershell team seen the Exchange *-User cmdlets? They may not be able to return custom attributes (or even most hidden ones) but at least they return the ones that you’re probably going to want to use most of the time. Or, use the same method as the ADSI provider, and provide a subset of attributes when returning results, and append the attribute searched on to the return object.
Still a good start overall though, especially the way they’ve handled connection state (as long as you don’t mind changing path during heavy operations). Let’s just hope that they make some changes to behaviour before the final release..
