Getting Admin’s to adopt PowerShell

The RTM of PowerShell was released over 2 years ago. But still there are multiple occasions in which I find myself trying to convince someone that they should really start looking into using this incredible new tool but they end up fighting me pretty hard. There have been a couple consistent themes that I have detected in these conversations that I think are very valid points.

First, I would like to point out that my role at work is a System Engineer. I am not the Operations guy down in the trenches with Ninjas on fire chasing me everywhere I go. My role on the Infrastructure team is to figure out how to incorporate new technology into our existing infrastructure without breaking stuff. I also help troubleshoot issues that get escalated to our team. So suffice to say, I am not an Admin. But, here is some feedback I have gotten from our Ops team members.

The first is that Admins are never going to use something unless they need to. Necessity is the mother of invention, or innovation for that matter. Why would anyone switch from something that works to something that may work but they don't know how to  use yet? I think the PowerShell team is working very hard to address this very issue, although I think sometimes we miss it in the background when we are introducing people to PowerShell. One of the beauties of PowerShell is that it is a solid consistent language that can be used across multiple technologies. Regardless of whether you are administering an Exchange server or Virtual Machine manager, you are going to likely be doing a "get-doohickey | set-Doohickey." Also there is tremendous power in the consistency of naming parameters and arguments. All Cmdlets are verb-noun -parameter argument.

I think what the Admin is thinking is that PowerShell is just one more thing to learn. We are having a hard time telling them that the investment they make in learning PowerShell to manage Exchange will also help them with VMM, desktop management, AD,Group Policy, and Terminal Services, just to name a few.

The second issue is really a two-edged a sword. There is an awesome community supporting PowerShell and a ton of great content on the web that has been worked on over the years and is really quite mature. The problem here is that newcomers to PowerShell start seeing some of this stuff and get completely overwhelmed right away. If a complete beginner asks "How can I filter the services to see just the ones that are stopped?" and they find something like "gsv | ? {$_.status -eq "Stopped"}" they will completely freak out. On the other hand, they may use it but not understand what is going on and just save it as another tool in their tool bag, without understanding that they can filter just as easily on processes or on Virtual Machines.


There is one thing that I believe has not been sold quite as much as necessary is Tab-Completion. Take the example below copied from a blog entry from the MS Exchange Team

This is the Exchange Management Shell (EMS) command Tom would enter to generate the cert request to be provided to the 3rd party CA in order to generate the actual certificate:

New-Exchangecertificate -domainname,, contoso.local,, server01.contoso.local, server01 -Friendlyname contosoinc -generaterequest:$true -keysize 1024 -path c:\certrequest.req -privatekeyexportable:$true –subjectname "c=US o=contoso inc,"

We have found that the '–subjectname' option is the most confusing. The help contents in EMS are vague as well. The best description is found in the TLS whitepaper mentioned at the beginning of this post so we're not going to reproduce it here.


As an admin I would look at this and say something like, "Crap, who created this huge long command line entry. Editing this is going to suck." What people don't get is that they have Tab Completion available, not just for the Cmdlets but for parameters as well. This just doesn't get conveyed when we are posting examples. Now if you throw in PowerTab or Intellisense from PowerShell Plus, its just gravy.

And so, I would like to pose the question to you, how do you as an engineer or an admin get your teammates to start using PowerShell. What walls have you come up against and what can we as a community to do to help break down these walls.

One thing I have been doing lately is using PowerShell in the build guides and Ops guide that I write, to at least get people started with using it. What else can we do?

Comments (7) -

It seems to me that PowerShell faces two different markets: sys admins who write scripts using something else (VBScript, Perl, batch etc.), and sys admins who never script anything.

Getting admins to write PowerShell rather than VBScript seems easy. If someone is writing scripts, then you can compare features of the two environments. Convincing someone that they can/should write scripts is a much harder problem.

PowerShell deployment is certainly not a slam dunk yet.  I got some great comments about why PowerShell has NOT been deployed.

Andy,  I wrote my reply on my site here:

This is something I think local advocacy will work best for.  It's a running joke that I think almost any repetitive task can be done with PowerShell, but that joke is my advertisement to convert my co-workers and it's working.


That is indeed a great list. I know you guys at Sapien have done some great training for folks which is awesome.

However, I am interested in trying to figure out how to get the people that would never read a blog about PowerShell or go to traiing for scripting for that matter, interested in PowerShell.

Unfortunately, I am an engineer and not a marketing guy. I am looking for ways that we can introduce people to PowerShell for the first time so that they leave the experience with a good taste in their mouth, and not just thinking it is something else they have to do.

Expanding on John's point, I am(was) a would-write-scripts-if-I-had-the-time type admins. The biggest thing that got me to finally start using Powershell was to stop thinking in terms of scripting and using it as a replacement for cmd.exe. The ability to interactively explore the language gave me that extra push to start scripting solutions.

Also I had already been exposed to the .net libraries via some web programming tasks in a previous job, so I jumped at the chance to incorporate that into my workflow without needing to use Visual Studio and C#.

Hi Andy,
I am a sysadmin and I'm crazy in love with Powershell. Some colleagues indeed sigh when I open Powershell instead of cmd to do a ping or ipconfig. But then I organized a presentation for them and showed them the power in powershell through many examples. They were inspired. Still, only a few want to learn it themselves, but everybody starts asking me: "Could you do this with Powershell, or that?" I created some scripts for monitoring our servers and try to have other sysadmins use them. I also sometimes have a "script-off" between a colleague using vbscript and myself using Powershell and I have yet to lose one. I'm always faster and more efficient in terms of number of lines of code.
Anyway, you have to become the Powershell Evangelist of your company to get your colleagues excited. Good luck.

Well I am a sysadmin/network engineer and I dispise powershell.  It is a huge monolithic scripting engine that does NOT provide a quick solution when you don't know exactly what you are looking for.

A good case in point for me was in deploying Exchange 2007 we wanted to grant several users the ability to access any mailbox on server.  There is NO option in the management console, which we consulted first.  I checked PowerShell, but just doing a list of commands there were over 100 different options.

Finally it was just easier to set the permissions at the organazation level using Exchange 2003 System Manager.  Problem solved.  I spent about 3 hours looking for a solution on the web, etc. not knowing exactly what I needed.  Even just looking at permissions is painful unless you already know the command you are looking for.

Microsoft is doing a great dis-service to the multi-headed tech who needs to do almost everything from installing computer, setting up applications, network hardware, servers, etc.  We don't have time to learn yet another language.  We need solutions that are quick, graphical and easy to find.  The exchange 2003 system manager was MUCH easier to find what I was looking for that either option for Exchange 2007.

I am ranting, but I feel Microsoft needs to offer feature complete configuration tools for both the graphically inclined and the script kiddies.  Linux is gaining in popularity not because scripting is becoming more popular, but because the GUI's that are wrapped around the product are becoming more intuitive and powerful.

NO ONE would pick edit.exe over Microsoft Word or Open Office, even though Edit.exe may technically be quicker.  Exchange 2007 is a very frustrating and unsatisfying product for me due to the large amount of re-training I need to do in order to do the same things that were easy with Exchange 2003.  Setting and viewing permissions is extremely painful for me in the Exchange 2007 Management Console (No Security tab on most pages), is similarly hard with the Management Shell, but is cake with Exchange System Manager.  I find myself NOT wanting to decomission my last Exchange 2003 server for just this reason.

Powershell is for experts.  The Management Console is for the rest of us.  I find myself wanting to purchase the Add-Ons from third parties to add back in the features to the Gui that Management Console is missing.  I guarantee that I am NOT alone in this regard.  This is VERY dangerous for Microsoft as this causes us to look around and see if the competition is better, at least for me.

I know for one I am disappointed in the Exchange 2007 management tools.  The product seems half finished does not have the polished feel that Exchange 2003 seemed to have.  The stability of the product is good, I just don't like the management options.

Comments are closed