Welcome to Dirteam.com/ActiveDir.org Blogs Sign in | Join | Help

The things that are better left unspoken

a blog by Sander Berkouwer

Related

AD Manager Plus
 

Blog roll

News



Archives

Why I don’t like the Quest Active Directory PowerShell Cmdlets

PowershellMany 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 (with the RSAT update installed) and Windows Server:

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. Now, let’s move on.

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

Comments

erntsnst said:

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.

# January 15, 2014 3:16 PM
Anonymous comments are disabled