A bit of boring exciting (if you’re a true nerd) history
It’s 1990 and Microsoft just released Windows 3.0. I was 9 years old then which tells you 1). I’m quickly approaching my middle-age crisis and, 2). wow, Windows has been around a long time. When a computing technology has been around for 25 years, it’s considered “established” to put it modestly, and “old school” if you want to be blunt.
Windows 3.x was the only major OS to support x86 Intel-type processors at the time, but it was also so successful because it made computing simple for the everyday user (whom we affectionately refer to as non-nerds… please try not to be offended). It proved that, with a modest learning curve, virtually anyone could use a complicated machine (which computers most certainly were at the time). We take that for granted today but it was a huge achievement. So Windows 3.x started “Client-Based Computing” and successive versions quickly dominated the market and turned the “Client-Based Computing” into “Personal Computers”- as in, friendly devices for the masses. By the time Windows Server 2000 launched, Microsoft endured the data server because they managed to create GUI-based tools for what is commonly complicated command-line based operations.
Despite all the commercial success, most experts agreed that UNIX like OSs were far more superior operating systems, not only because they exhibit security, efficiency and light software structures as a core principles for their design elements, but also because UNIX includes powerful system scripting languages. Now that last sentence with “scripting languages” sounds super nerdy, but what it translates to is: *INX admins run their systems with the philosophy of “Do it once and do it well.” That is, what a script really does is automate human tasks so that they are done perfectly, in exactly the same manner, every time (if you’re a good automation engineer). For a long time, any UNIX admin would laugh if you compared Shell scripting to Windows Batch (CMD) scripting. First the shell itself is far more superior, and languages available for scripting from within the shell are far more powerful.
Fast forward 2006: you can optionally install PowerShell 1.0 on Windows XP, 2003, Vista, 2008. PowerShell is a new command-line interface for Windows. It’s far superior yet “smells like a *NIX Shell” interface. After all this GUI success, Microsoft is introducing a new command line shell. Most thought it was hilarious- that is until they realized you could create 2000+ Exchange 2007 mailboxes with a 10-line script… something unheard of in the Windows world before.
PowerShell 2.0 was released couple of years later and it was a pretty significant release. That’s when it was apparent that the Microsoft is pretty serious about turning PowerShell into a core technology for upcoming server products, with features like PowerShell remoting, modules, script debugging, error checking and eventing (similar features been around in a *NIX system scripting for quite a while).
More features kept piling up until the latest release of PowerShell (v5), which includes thousands of PowerShell commands (CMDLETS) that allow you to manipulate every aspect of a Windows OS. Although you could do the same with PS 2.0 via WMI queries and access to .NET class, Microsoft decided to make almost every configuration in Windows subject to change and manipulation via direct PowerShell commands (CMDLETS).
So why is Microsoft so adamant on keeping this PowerShell push?
Putting aside the Metro touch interface, the actual desktop interface in Windows didn’t really change since Windows 7. Windows 10 does a fine job of separating the tablet experience from the desktop experience but the point is that the “Windows” themselves (with File, Edit, Menus, Windows Explorer, My Computer, etc.) haven’t really changed Windows 7. Even so, MS keeps piling on the PowerShell features. You can’t help but ask- why is the company who popularized the GUI for IT not investing the time in building more GUI for IT Pros?
From what I can tell, there are couple of reasons for this change in Microsoft’s philosophy:
- Too much GUI hurts the eyes. Clutter is not good in any interface (Windows Vista anyone?).
- There are more devices and services to manage (i.e. more things to click on) which means more man hours to do the same tasks.
- Increased manual effort means a higher likelihood for human error and sloppy outcomes.
- With Cloud computing in the mix, service providers and IT managers can no longer afford such errors. They require tested procedures and tasks with minimal errors as fast as possible (AKA scripts and automation platforms).
Let’s Throw Out a Simple Example
Your HR manager announced you are acquiring a new company, “ABC.” Your infrastructure manager stated that the “ABC” AD domain is in bad shape and that you might as well create new accounts for new hires. He gave you an excel sheet of 500+ users and asked to you to:
- Create users according to corporate standard (first intial, last name)
- Set a common password for all with require changing password at first logon
- Make all users members of the group “SEC_FileShare”
- Make “ABC Division” as the department name on all accounts
- All user accounts need to be in OU “ABC”
If you are a GUI kinda guy, you must be hating your boss because that’s about two weeks’ worth of dedicated clicking and then, you better hope that:
- You spelled all the names correctly
- You set the same password across the board
- You clicked “change password on next logon”
- You put the users in “SEC_FileShare” and not, let’s say in “SEC_Finance”
- You put all accounts in the appropriate OU
What is the probability of human error in all above 5 scenarios, multiplied by 500? Quite substantial. And that’s just with a 500-user scenario. With passwords and security access in the mix, it’s enough to trip up even the best IT pros, causing them to be questioned or worse, lose their job entirely! Suddenly a two-week request from your manager turns into months of painstaking work for fear of an outcome that’s anything less than perfect. Doesn’t sound like a job anybody would want, does it?
So what’s the alternative? You can be a “GUI kind of guy”, or if you are a PowerShell script wiz, you can:
- Convert the excel doc to a CVS file
- Spend X amount of time to write the code below or something similar
Let’s demo the pieces. I created a sample CSV “Users.CSV” file and placed on my desktop. This file was actually exported from excel. The CSV file content:
Then I wrote below PowerShell code which will do all the tasks Mr. hypothetical boss assigned to you/me.
I won’t go into the inner workings of the script. All you have to do modify the user variables section parameters to your liking.
I did invest 1 hour and 3 minutes creating the first script above, but I created the next 10 users in 3 seconds. So what’s the point? If I had a bigger CSV file with 500 users, it would take maybe a total of 30 seconds to create them. If I have 2000+ users, it would likely take 2 minutes. Better yet, I can use it anytime I want from this point forward. Two weeks’ worth of GUI work turned into minutes worth of sitting back and watching it magically do its thing.
DISCLAIMER: Script provided above was tested in a lab so please test it in your own before using it or simply write your own.
Get with the program – The Future of System Admins is in Automation
Considering that pretty much all Microsoft products (SQL, Hyper-V, SharePoint) and all reputable software vendors (VMware, Citrix, EMC) are creating automation APIs with PowerShell in mind, you can imagine how much more efficiently and accurately the administrator who masters PowerShell will be able to deliver tasks for those products. This means they are more likely to stay relevant in the job market.
Some Windows IT Pros still don’t understand what’s going on. I still hear many Windows administrators say things like “Well, I’m just a GUI kind of guy!” IT Pro to IT Bro… if you’re in IT and you don’t know PowerShell to some extent, you’re in for some tough times. Run a quick search on Indeed.com or any similar site for Windows System Administrator job titles and see how many of them ask for PowerShell experience.
So get with the program! You don’t necessarily have to become a script wizard right away. Start using PowerShell on a daily basis and eventually you will become a script wiz. Once you master some basic logic and techniques, it becomes so much easier to fire up a script than doing things by hand.
I would add that once you learn the programing/scripting logic in PowerShell, you can easily learn other *NIX scripting languages like Python, Shell Scripting and Rubby which will only benefit you if your job required such skills in the future.