You can’t be a 21st century admin without PowerShell

When I was at school my father gave me a copy of an article he’d seen at work. I remember nothing of the article itself, but the title has stayed with me: “You can’t be a 20th century man without maths”. I think even then “You can’t be a [time] [person] without [skill]”  was a  Snowclone - I’ve adapted it from time to time - hence the title.  In a recent conversation someone asked me if I knew “That sunscreen thing” which was turned into a song by Baz Luhrmann (On you-tube) and having been reminded of it, I found it wanted to morph into the the opening of a session I was doing on managing Server 2008-R2 The original began

Ladies and gentlemen of the class of '97: Wear sunscreen.
If I could offer you only one tip for the future, sunscreen would be it. The long-term benefits of sunscreen have been proved by scientists, whereas the rest of my advice has no basis more reliable than my own meandering experience. I will dispense this advice now.

newskill.. it was all I could do to avoid opening with “Ladies and Gentlemen: Learn Powershell. If I could offer you only one tip for the future, PowerShell would be it”, the long term benefits of PowerShell …”

I’ve been saying the same thing in different ways a lot recently. The slide on the left was in the session I delivered at the big Wembley event in October.  A few people picked up that I’d said “Everyone should learn PowerShell”, and I’ve since had to explain that this requires a suitable definition of “Everyone”. But it is my firm belief that IT professionals working Microsoft technology are at an advantage if they know at least the basics of PowerShell. Being able to automate complex processes , and show that the steps have been followed isn’t a new idea ; it always was important in the mainframe and mini computer world. There are plenty of situations where using a graphical interface is easier than using an obtuse command line tool, yet the focus on GUI tools in the Microsoft world means that command line and scripting skills are less prevalent among system admins than is the case in Unix / Linux world. Those skills can mean better efficiency, or allow tasks to be carried out which would otherwise be impractical. If the setup is simple or IT management is not a persons main job, doing the work optimally matters less because there isn’t much of it. If there is little repetition writing a script takes more time than it saves. When IT is your main role and includes repetition of complex tasks then scripting puts you ahead. Of course I equate “scripting” with “PowerShell” which simplifies things too much: the tools will vary between environments – I took the following list from one of the Slides in the Wembley deck: – it is not designed to be complete but to show pre-eminence of PowerShell in the Microsoft world.

In Server-R2 there is: Not forgetting that we also have
  • PowerShell for Active Directory
  • PowerShell for Applocker
  • PowerShell for Best Practices
  • PowerShell for BITS transfer
  • PowerShell for Clustering
  • PowerShell for Group Policy
  • PowerShll for Installing components
  • PowerShell for Migration
  • PowerShell for Remote-Desktop
  • PowerShell for Server Backup
  • PowerShell for Web admin
  • PowerShell for Exchange 2007
  • PowerShell for HPC
  • Powershell for HyperV @ codeplex.com
  • PowerShell for OCS in the OCS Res-kit
  • PowerShell for SQL 2008 R2
  • PowerShell for System Center

You can see anyone who says “I don’t do PowerShell” is at a disadvantage, and the first thing to explain to them  that opening up a PowerShell window and running the cmdlets which are provided by any of the above is no different from starting a CMD.EXE Window and entering commands there – in fact it’s easier because the way parameters and help are handled is consistent. The idea of an environment extended with task-related Snap-ins which we saw with the GUI management console is the same in PowerShell – we load something which understands the task into an environment which provides the UI. The cmdlets are just a foundation: building things up from them takes things to another level. But you can build things up around free-standing programs too – by allowing them to be scripted, PowerShell makes it possible to deliver things which otherwise would be too time consuming. The example I’ve been using to show this is the following:  In Server 2008 R2 we have a new feature called off-line domain join; ODJ allows you to create a domain account for a computer, and a file containing the information needed for that computer to be added to the domain. This file can be applied to the OS offline without needing to boot it, logon as an administrator, connect and change the computer name and member-of setting from the default workgroup to the chosen domain. The command to do this is a traditional .EXE and it looks like this.

djoin /provision /domain MyDomain /machine MachineName /savefile filename

Great … but what if you have 1000 machines ? Are you really going to sit there all day typing the names in, and checking you didn’t mistype any or miss any out ? If you have a list of machine names in a text file, you could do this with PowerShell

Get-content Machines.Txt | forEach-object {djoin /provision /domain MyDomain /machine $_ /savefile $_ }

For each machine name (line)  in the file machines.txt the command will run djoin with that name as both the machine parameter and the filename parameter.

The successful admin is not automatically the one who knows every possible way to use every possible command in PowerShell. Nor the one who turns their back on GUI to do everything from the command line , but the one who understands the tools available for the task at hand, can select the right one, and can put it to use competently. PowerShell is one of the tools available in so many cases in the Microsoft world, that you can’t meet that definition without it.