Many Active Directory admins use and like the Quest Active Directory PowerShell Cmdlets, that are part of the free ActiveRoles Management Shell for Active Directory. They have been freely available since 2007 and have been the long trusted scripting companion for many.
I am not one of them. It’s nothing personal. Let me explain.
The 2007 situation
Back in April 2007, when the ActiveRoles Management Shell for Active Directory was introduced as simply AD Cmdlets by Quest Software, Microsoft offered no PowerShell support for Active Directory.
PowerShell itself, you could say, was still in its infancy; a version 1 product, you could download for Windows XP, Windows Server 2003 and Windows Vista. When Windows Server 2008 came around in February 2008, PowerShell 1.0 was an optional feature.
Windows Server 2008, however, offered no PowerShell Cmdlets for Active Directory.
Back in those days, the Quest Active Directory Cmdlets made sense.
Today, with the release of Windows Server 2012 R2 and PowerShell 4.0, Microsoft offers 147 PowerShell Cmdlets to manage and deploy Active Directory (growing from 135 available Active Directory-related PowerShell Cmdlets in Windows Server 2012). I haven’t found anything I couldn’t do with them (and the Active Directory drive), that I could with the Quest Active Directory PowerShell Cmdlets.
These PowerShell Cmdlets are built-in, easily kept up to date through Windows Updates and ServicePacks, and are easily unlockable with a single line of PowerShell code in both Windows 8 and up (with the RSAT update installed) and Windows Server 2012 and up:
Add-WindowsFeature RSAT-AD-PowerShell
PowerShell History Viewer
However, when you run the above PowerShell line, I also urge you to use the following line:
Add-WindowsFeature RSAT-AD-AdminCenter
This enables the Active Directory Administrative Center (dsac.exe). This management tool contains the Active Directory PowerShell History Viewer. You can access it by clicking on the up arrow in the bar called Windows PowerShell History in the right bottom corner of the Active Directory Administrative Center screen. This flicks up a the Active Directory PowerShell History pane. Now, whenever you perform an action using the drag and drop interface, you see the equivalent of the PowerShell steps involved to do so in the PowerShell History viewer.
The Active Directory PowerShell History Viewer makes it extremely easy to learn the Active Directory PowerShell Cmdlets, by showing the equivalent PowerShell Cmdlets, associated with actions in the Graphical User Interface of the Active Directory Administrative Center.
Lifecycle management
Whenever I install software on multiple machines in a network environment I remind myself of asking the following question: “Am I introducing the next Java?”.
Oracle Java is a programming language platform that has implementations for almost all Operating Systems (OSs) and in this way allows code to run on all these platforms without recompiling. The Java implementation on Windows has been updated many times since its inception in 1996, but topped the list of the most vulnerable Windows-based applications many times. No wonder, that in my book, Java is an abbreviation for Just another vulnerability announcement…
Now, when a business is using a Java implementation, it is hard to get rid of Java. Often, the program using Java needs to be rewritten, often multiple programs use Java, programs need different Java versions, etc. … and Java needs to be kept up to date. Monthly. Java gets updated, but updated versions might break the business application, etc.
I’m better off without software like Java on my network. I don’t need the headache.
The same goes for the Quest Active Directory Cmdlets. It’s software running on my Domain Controllers. It needs to be kept up to date. I need to check my scripts against new versions of the Cmdlets before I can update them.
Concluding
I feel the Quest PowerShell Active Directory Cmdlets are harder to install, harder to maintain and harder to learn than the PowerShell Cmdlets Microsoft ships with Windows Server nowadays.
It’s been a good ride. Quest has shown the way forward. Quest deserved to win prizes with their Cmdlets.
What do you think?
Further reading
Free PowerShell Commands for Active Directory
How to add Quest AD tools to your native PowerShell
Quest Powershell for Active Directory
Active Directory Administration with Windows PowerShell
sander, i like the article. have a question for you. you have here "easily unlockable with a single line of PowerShell code in both Windows (with the RSAT update installed) and Windows Server" …
assuming this is referring to windows workstation OS and specifically windows 8 since we're talking about windows 2012. did you have success using the -windowsfeature commands? i tried on two different windows 8.1 machines and got the following:
add-windowsfeature : The target of the specified cmdlet cannot be a Windows client-based operating system.
I think it's because they're already installed?
"The same goes for the Quest Active Directory Cmdlets. It’s software running on my Domain Controllers."
You should only log into a DC when you absolutely need to. Assuming you have patch management it should only be when there are issues with Active Directory or the DC itself. There's no requirement for the Quest Cmdlets to be installed on a DC, nor for your scripts to run from a DC either.
For the most part, I don't use the Quest tools; I do, however, keep them in my toolbelt. Here's why:
The newer (post 2008 R2) AD cmdlets from Microsoft are great, but they can't easily connect to older domain controllers. I still occasionally have to interface with old 2000 and 2003 domains, and Quest just works with them.
The other reason I use them is when I need to do a quick and dirty search for something. Quest's syntax for that is just so much easier that having to type out a filter and making sure to import the needed properties, every single time.
Quest's tools will be valuable for a little while yet. Since you don't actually need them on the servers themselves, I don't see any problem with continuing to use them.
In my opinion the Quest CmdLets are more intuitive, and have more functionality built into each cmdlet.
Examples:
To list all empty groups: Get-QADGroup -Empty
To list all nested Group members: Get-QADGroupMeber -Type Group (-indirect)
I have used Quest CmdLets for some years now and upon formating my machine now and trying to document every tool I use so that my fellow IT colleagues can use those as well, I ran into a requirement for QADCmdlets 1.6 that it needs ".NET 3.5". Looking for a newer version I can see they have version 1.7 but not available for free, so I googled some more and ended up here. I haven't really used MS built-in commandlets, particularly because I rarely do my admin tasks on the DCs but will rather set up my local environment. Will think twice before really installing .net 3.5 + Quest 1.6.
Though, I find Microsoft's module persnickety, when compared to Quest's forgiving Snap-In…
I see a misconception in some of the above comments, there is no need to access a domain controller, or even a server, to use Microsoft's ActiveDirectory module. The module is part of the Remote Server Administration Tools (RSAT) which can be installed on a Workstation.
I certainly don't agree that the quest comandlets are dead for lots of reasons some of which have been mentioned in other replies, but the key one is that if you are using Quest Active Roles Server (ARS) in your environment; Then, you can manage all of your domains from a single point and view objects from all domains in a single request. Best of all, you do not need to delegate native rights to AD DS as the Quest commandlets have a proxy switch.
The delegation model in ARS is something Microsoft should be adopting as it's child play to administer and view who has access where, but that's completely off topic here other than you can tap into this with the Quest commandlets but not with the Microsoft ones.
I could not disagree more with this article. Today, almost 10 years later, SET-QADUSER gives you out of the box the option to bulk load users from csv skipping empty fields. SET-ADUSER stops processing when it finds an empty field in the csv file. You have to literally enter several lines and IF statements to do the same that QADUSER does automatically.
I have the file QUEST Active Roles Management file saved on my OneDrive.
What is SAD is that 11 years later, Microsoft has not catch up yet with something it was so well developed. Then Quest was bought by DELL and started charging for that and eventually deprecated.
You forget about Permission templates, Policies, Provisionning, Deprovisionning and history all stuff Microsoft do not do..