UC Unleashed

My friend and colleague Patch Charron wrote an interesting article on why do we use PowerShell. In that article, Patch mentions that he wondered why he could spend more time writing and testing a script than if he just performed the scripted tasks manually. He gives pretty good reasoning.

I was on a project last year where I was tasked with automating the installation of some Exchange 2010 servers for a good-sized financial client. This was to ensure that the servers were each deployed in a consistent, repeatable way. One of the problems we ran into was that the servers were prepped for our build by different people from time to time. And even though the client had a “standardized process”, we received the servers in many different configurations. So I devised a prerequisite script that would verify each of the required settings and produce an output to both the screen and text file. It would identify each parameter, it’s required setting, and it’s actual configured setting. Settings such as server name, paging file, DNS domain suffix & search list were all issues that would vary depending on who would build the base server. The client’s procedures for resolving some of these problems would often take a considerable amount of time. So, I wrote another script to actually fix the problems that a script could fix. This was then implemented in the beginning of the server build framework. Two CSV files and 3,000+ lines of PowerShell, and I was able to build 163 Exchange servers, including more than 40 in one day. From a domain joined server to provisioned SAN storage, configured NICs, prerequisites installed, Exchange installed and configured, and more. Repeatable steps that the client could use going forward if needed. Every task, from copying the source files, scripts, tools, and others was automated.

My point is that PowerShell was not only able to automate a time-consuming, complex series of steps for building servers, but also able to identify and resolve nearly any issue that could either block the installation, or cause problems down the road.

Another issue PowerShell was able to resolve for a client was to streamline the employee onboarding and offboarding process. Onboarding employees would require creating an Active Directory account, and Exchange mailbox, a Lync account, SharePoint sites, etc. In larger organizations, these tasks are often performed by different groups of people. Many of these processes can (and were) automated. Create a user account in a certain OU (or in my case any OU that contained the word “employees”), and PowerShell can automatically mailbox, Lync, and SharePoint enable the user. And logic was built in to handle configuration of things like Lync policies, etc. This allows administrators to spend more time working on more important issues, and less time doing mundane tasks.

Microsoft isn’t the only company that builds PowerShell into its products. Other companies like Netapp and Kemp have built it into their products or have it as an option. This is key as you can us it to perform provisioning, maintenance, and disaster recovery.

So – back to Patch. Spending more time to write and test the script than to manually do the task might be tough, especially for internal staff that might not have to do that task, like building Exchange servers, again for years. But the rewards are great when you have an infrastructure that’s running more smoothly. If you’re a consultant, then scripting common tasks can help you as you can more quickly deploy solutions on future projects. Your clients will appreciate that.

I’ve seen it said many times that you either learn PowerShell, or find another line of work. I believe that to be a true statement. There are a truckload of great resources online to help you jump into PowerShell, find code examples, and broaden your skill set. Good luck!