The Lonely Administrator

Last week I was interviewed on the Mind of Root podcast about what administrators can do to promote PowerShell and automation in their environments. The show is now available for streaming or download. I still think your best approach is to gently let everyone know that it’s not a matter of if you will use PowerShell, only a matter of when. PowerShell is Microsoft’s management strategy. That doesn’t mean you need to script or use a console. I discussed Exchange 2007 as an example in the podcast. You may use PowerShell and not even realize it. But for complex and hard-core tasks, you will need to drop to the console.

I also encourage people to find a regular IT task that is now performed manually and create a PowerShell alternative. Try to stick to someting you can do with one or two lines of PowerShell. Remember, the goal is to reinforce the idea that PowerShell is first and foremost an interactive management shell. As an alternative, you might also find a short script you use now and achieve the same results with a few lines of PowerShell.  Personally, I think VBScript files using WMI are great targets.

I hope you’ll listen to the podcast and let me know what you think.

Last summer, Ed Wilson was looking for help with a small part of the book he was finishing up, Windows PowerShell 2.0 Best Practices. The topic he was working on was, “How do I know this script is safe to run?” Which is a great question and one with greater significance as more administrators come to PowerShell and are tempted to run scripts created elsewhere while not having perhaps all the experience and training to fully appreciate what might happen. I offered some comments on some things I would do. I also decided to write a script (trust me) that an administrator could run that would analyze a PowerShell script and produce a report, or profile, for that script.

I’ve been doing a lot with the ActiveDirectory module that ships with Windows Server 2008 R2 and which you can also use with the Remote Server Administration Tools on WIndows 7.  As I was trying things out with the PSDrive provider I discovered something very cool.

Some of my readers may have realized I don’t blog much about Active Directory here, despite having written a book on the subject. That’s because I also blog and help moderate The Experts Community. This site, although run by Quest Software, is not a commercial site. It is intended as a community drive site centered on Active Directory and Identity Management. You’ll find questions and answers, links to useful tools and resources and blog posts on AD related topics. I blog there at least once a week, typically on how to use PowerShell to administer Active Directory, but I expect to branch out to more topics this year.

The site is also intended as an ongoing virtual extension to The Experts Conference which is probably the best AD-centered conference you could possibly attend.

In the mean time, you are welcome to join the community, and I hope you will.  Feel free to use this link http://theexpertscommunity.com/index/refer/code/347-5ff25 to visit and create an account.

Last week I was helping someone out in the PowerShell forum at ScriptingAnswers.com. The specific problem is irrelevant;l however I  learned something in the process that will affect how I write my own PowerShell functions from now on. Not being a developer I never picked up on this subtle (at least to me) distinction. Here’s the deal.

This question comes up quite often: “How can I encourage adoption of Windows PowerShell in my organization?” I periodically poll people about their adoption plans and what sort of things are standing in the way. Most of the obstacles in my opinion can be cleared with experience, exposure and education. On Twitter today, @ChuckBoyceJr was asking for guidance in getting his organization to accept and presumably adopt Windows PowerShell. His concern was that their lack of scripting knowledge was a hurdle.

I don’t think this is a hurdle, or at least one you should worry about. The reason is that I think the better approach is to “sell” PowerShell as a management tool, not a scripting tool.  When people hear “scripting’ they think it will be some combination of “it’s complicated”, “it’s prone to security vulnerabilities”,and “it has little to no long term practical value”. I’m not about to fight that battle here and neither should you.

Instead, stress that PowerShell is an interactive management console. You type a command and something happens. You can manage local and remote computers. You can manage 100 remote computers as easily as you can 1 or 10.  Granted, some PowerShell expressions can get a little long, but they work and can accomplish some amazing tasks that often would be next to impossible with a graphical tool. But if your co-workers want graphical management tools, you can give it to them but still use PowerShell.  You can create your own using Windows Forms. Or grab a copy of PowerGUI. Finally, stress that fact that Microsoft has adopted Windows PowerShell as it’s de facto management tool going forward. It’s not a matter of if you will be using PowerShell, only a matter of when.

Here’s what I would do. First, gain some experience and proficiency in PowerShell yourself. Then identify a common management task you do now, perhaps through a GUI or some other tool. Write a one or two line PowerShell expression to accomplish it.  Don’t write a script. Save that for later for the truly complex tasks.  Or if you use another scripting language, such as VBSCript, take one of your management scripts and write a short set of PowerShell expressions that you can run interactively to get the same result.  Your goal is to show how much you can accomplish of your daily work with PowerShell and how much more efficient you can be.

At the very least, demonstrate some of the basic management cmdlets such as showing all running services on a group of servers, finding the last 10 error messages in the system log, or getting basic WMI information from a group of servers and present it in a nicely formatted table. Feel free to use any scripts or tools here to help close the deal.

For the rest of you who have been successful in promoting PowerShell, what obstacles did you overcome and how? Do you have a killer PowerShell one-liner (or 2-3 lines) that has a big “wow” factor for management types?  I’ll have to come up with some of my own but in the meantime I hope you’ll share.

I often talk about using PowerShell GUIs vs the console experience. There is certainly a place for a GUI, but sometimes you need the raw power that comes with a console session. Here’s an example.