by shawnwat at 2013-01-10 08:01:53
I have been using powershell since v1. I had to use Quest AD commandlets in v1 as i am not smart enought to do all the ADSI stuff. Now that we are on v3, Is there a reason to use the Quest commandlets or should i just learn the native MS commandlets?by Infradeploy at 2013-01-10 13:44:02
I’ve been battling with the same thing.by Klaas at 2013-01-11 01:46:55
They both have quirks. Quest cmdlets is an extra installation, but ad cmdlets do not behave like other cmdlets in a lot of ways.
In the end am going with the native ad cmdlets, because they’re just there. And i can’t install quest cmdlet at every client.
In the shell I use AD- and QAD-cmdletsa lot, and they are both very usefull, but in my scripts mostly I go the ADSI way. About a lot of scripts I can’t be sure I’ll never use them on machines where the snapin or module won’t be available.by RichardSiddaway at 2013-01-12 01:14:13
Maybe Quest will stop the development or the snapin will be uncompatible with newer PS versions and then I would have to rewrite a lot of scripts. It’s a bit more work to write it all myself, but I believe it to be more timeless.
AD cmdlets too are not always available, you need to execute the script on a domain controller or have RSAT installed. So I only use them in scripts of which I’m pretty sure they will only be used on a domain controller.
I’m sure you are smart enough to use ADSI, it’s not that hard. I learned everything I needed to know about it from Richard’s "Powershell in Practice" and there are examples from the scripting guy and others too.
Thanks for the endorsement of the book Klaas. PowerShell in Practice is a couple of years old now but is still very relevant.by Matt Hitchcock at 2013-01-22 09:13:53
I have used scripting, the Quest cmdlets (I was a beta tester) and the Microsoft cmdlets. I still use all three.
In my test lab I’m using the Microsoft cmdlets mostly - mainly because I’m running Windows 2012 and the book I’m writing has the examples using the MS cmdlets
Many organizations use the Quest cmdlets because they still have Windows 2003 domains controllers.
I’m not happy about the need to install the AD web services on domain controllers to get the MS cmdlets on pre-Windows 2008 R2 domains. The really nice thing about the Quest cmdlets is that you can just install them on your workstation. Unfortunately, the Quest cmdlets are toed to their Active Roles product and so tend to follow its lifecycle. I haven’t heard when, or if, there will be a new version of the Quest cmdlets.
At the moment I would say the MS cmdlets have the edge for two reasons - firstly the site, subnet and sitelink cmdlets from Windows 2012 & secondly the ability to use a filter constructed using PowerShell syntax BUT you need to be to get them installed.
Scripting is a great fall back when all else fails. I prefer the cmdlets because there is less typing and some of the searching becomes much, much easier with the cmldets.
I did a big series of blog posts last year showing how to perform many different AD tasks using MS cmdlets, Quest cmdlets, MS provider and script. I would recommend checking them out to see the differences. I might pull them together into an ebook if there is sufficient interest
I use the Quest cmdlets for AD Object management and the MS ones for topology. We are heavy ActiveRoles users so makes sense to use the Quest cmdlets to get the ActiveRoles connection.by dsf3g at 2013-01-23 08:01:09
One thing about having to install the cmdlets everywhere, you don’t have to if you use Remoting and/or import the modules from a server to your session.
There are three things I like about Quest:
1) The documentation. I truly wish Microsoft provided a command reference as user friendly and complete as the Pdf that you can dowload and print out for Quest’s commandlets. Makes everything so much simpler. And I for one love to pick up a paper book like that and just browse though it for ideas.
2) The syntax: maybe it’s just because I’m more used to working with Quest, but I feel the syntax is more flexible. As an example, you can put just about anything after the Get-QADUser command (a SAMACCountName, a dn, a display name) and it will do its darndest to come up with something that makes sense. Microsoft’s AD commands tend to be looking for something much more specific.
3) I do a lot of work across forest trusts, and Quet’s Connect-QADService command makes life soooo much easier for me. I’m sure there’s a way of doing the same with Microsoft’s commadnlets, but I gave up trying to figure that out after a while.