And the Preferred Set of AD Cmdlets is...

Last week, I asked you what your PREFERRED set of cmdlets for managing Active Directory would be. There was a pretty resounding response for both the Quest cmdlets and Microsoft's own AD cmdlets - with great reasons on both sides of the argument. If you haven't considered using "the other ones" (that is, whichever ones you aren't), here are some reasons from your peers to maybe change your mind.

(I'm not including anyone's names, just their words)...

IN FAVOR OF THE QUEST CMDLETS...

"I have a love-hate relationship with the (Microsoft) AD module. For example, the -Identity parameter doesn't accept wildcard characters." Totally agree. We're seeing a v1 implementation from Microsoft, here, and their offering just doesn't have some of the fine details that Quest has built up over the past couple of years.

"When I run Get-ADUser, I want to get ALL user objects, but you have to provide a -filter parameter." This one, I'm kinda on Microsoft's side about. It's a poorer practice to pull over thousands of objects from the domain controller, and the -filter parameter kinda forces you to think about whether or not you REALLY need to do that. I love that -filter accepts PowerShell-style comparisons (-eq, -gt, -like, and so on), too. Yeah, typing -filter is a bit more typing - but it's not exactly a tragedy.

"The AD provider is great but very hard to navigate." Absolutely true. Frankly, I never use it to navigate, only to maintain security connections to other domains. Microsoft could definitely improve the syntax of the provider.

"Quest doesn't require a management gateway to manage 2003 and above domains." Yeah, this is a big deal. While Microsoft's module DOES work on 2003+ domains, it only does so aft you download and install a free Microsoft add-on to at least one non-2008R2 domain controller. Quest also lets you manage ADLDS on Windows 7, and Microsoft's cmdlets don't.

"QAD cmdlets are easier to use, and you will fine more community examples." More examples, definitely. Easier? I dunno. I think "easier" equates to "what you're used to." I don't find Microsoft's cmdlets to be especially harder or even all that drastically different.

"QAD cmdlets allow you to retrieve any attribute including custom AD extensions, not so for the MSFT cmdlets." And this is perhaps Microsoft's BIGGEST failing. You can't even use their cmdlets to access Terminal Services settings. Massive oversight. Of all the reasons presented to me by folks, this is the one I agree with the most, and I still can't believe Microsoft didn't include this ability in their cmdlets - it seems like it would have been pretty straightforward.

IN FAVOR OF THE MICROSOFT CMDLETS...

"We can't have any third-party AD management tools without a rigorous approval process, and that process generally requires that we be BUYING the tool and paying for support and maintenance." A good point - Microsoft's cmdlets are from Microsoft, and they're supported. In some companies, that'll make a difference.

Personally, I like the Microsoft cmdlets because they allow me to illustrate some key points about using PowerShell generally, and to do so in a meaningful, real-world way. Pipeline parameter binding is a big example - right now Quest's cmdlets don't support that, although I understand they're thinking about that.

"The Microsoft cmdlets let you map drives to other domains, and the drive maintains that authentication." True - and a convenience in multi-domain environments.

AND THE WINNER IS...

So who wins? Both. Neither. You pick. In reality, you'll probably want to have BOTH available to you for whenever circumstances demand. After all, free is free, and you can never have too many free tools!

By the way: Don't forget about my PowerShell Home page, my PowerShell-focused Twitter feed, and my availability for training classes.