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.

Discuss this Blog Entry 2

Dmitry Sotnikov (not verified)
on Jul 21, 2010
Just a minor point on the supportability side:

You do actually get commercial support for Quest's AD cmdlets if you buy commercial license for Quest ActiveRoles Server (plus a bunch of other features such as delegation, approvals, workflows: http://dmitrysotnikov.wordpress.com/2009/08/03/audit-powershell-changes-in-ad/).

And, AD and PowerShell forum at http://powergui.org/forum.jspa?forumID=173 is obviously extremely active and helpful.

Dmitry





Poshoholic (not verified)
on Jul 21, 2010
Hi Don,

One comment about the Filter parameter.

The Quest AD cmdlets don't retrieve all of your AD objects by default either, for the same reason that Microsoft's AD cmdlets don't: you want to think about what you want to retrieve from AD and use LDAP filtering to limit what is returned from the server rather than retrieve everything and filter on the client. The key difference between the two approaches that I think makes the Quest AD cmdlets a little friendlier is that the Quest cmdlets will retrieve a default maximum of 1000 objects unless you specify a different size limit (the same limit that is applied in native Microsoft tools such as the Exchange Management Console). This gives you some data to work with right away with no knowledge other than the cmdlet name (i.e. no need to learn how to use a parameter to get started) so that you can start to look at that data and then apply filters using parameters to work your way down to the right data set. I mention this only because I didn't get the impression that you were aware that it worked this way from your comment in the article.

Kirk out.





Please or Register to post comments.

What's PowerShell with a Purpose Blog?

Don Jones demystifies Windows PowerShell.

Blog Archive

Sponsored Introduction Continue on to (or wait seconds) ×