Why You Can't Afford to Ignore PowerShell

- select the contributor at the end of the page -

Windows PowerShell has come a long way since version 1.0 was officially released in November 2006. With version 3.0 debuting alongside Windows Server 2012 this past October, the tool is more accessible and useful than ever.

I started using PowerShell when it was released, but in a limited fashion because it was so new. At that time, .NET still seemed to be a mystery to people around me, so the fact that you had to have .NET 2.0 as a pre-requisite greatly slowed its adoption in my work environments.

That adoption obstacle changed with Server 2008 R2, which was released in July 2009 and had .NET and Windows PowerShell version 2.0 packaged with the operating system by default.

Now with Windows Server 2012, Microsoft has continued working toward its goal of providing more complete coverage for Windows PowerShell, so you can do just about anything from this tool. There are over 2,300 cmdlets in this release. As a matter of fact, the new Microsoft MCSA and MCSE certifications actually have questions on Windows PowerShell, which is a strong indicator of how serious Microsoft is about this technology and how important it is and will be moving forward.

Microsoft has a set of “engineering directives” that it establishes for all of its products, which are known as the “Common Engineering Criteria” (CEC). As 2009, Microsoft now has Windows PowerShell listed as a technology that all server products must support. Microsoft Exchange 2007 was the first big product out of the gate with full Windows PowerShell support. Windows PowerShell was, and still is, so tightly integrated into Exchange that the actual administrative user interface for Exchange (2007, 2010 and 2013) are actually all layered on top of Windows PowerShell.

It's this tight integration and “100 percent coverage” that TrainSignal instructor J. Peter Bruzzese often mentions when justifying why Exchange administrators should invest in Windows PowerShell training, and he's been offering this advice for several years.

Coming back to Windows Server 2012, you'll still find Windows Scripting Host (WSH) engine so you can still script in VBScript, if that's your preference, but its days are numbered. WSH has been considered grandfathered for years. I haven't been able to find an official announcement, but I wouldn't be surprised if Windows Server v.Next no longer supported WSH at all.

Windows Server 2012 has a lot of improvements relating to Windows PowerShell. The new Server Manager is built on Windows PowerShell. For example, there is new functionality provided by the Server Manager to not only manage the server locally, but also remote systems using the new Windows PowerShell Workflow feature. Windows PowerShell Workflow is something that TrainSignal instructor Jeffery Hicks covers in “PowerShell v3 New Features” training course, which launched December 11.

One more bonus with Windows Server 2012: Windows PowerShell remoting is enabled by default. Previously, enabling Windows PowerShell remoting had to be done manually or using Group Policy, but now it is on by default, which helps to reduce any obstacles to its adoption in the Enterprise.

Over the years, people have asked about what kind of things they can actually do with Windows PowerShell. If you've worked with VMware, you might be aware of VMware's “PowerCLI.” VMware has done a great job at implementing Windows PowerShell management of their products. I've actually used it several times to save hours, even days of work. For example, I've used it to automate the copying of entire environments that had special configuration requirements. One other time, I helped a co-worker create a script to automate the reconfiguration of the storage being presented to VMware hosts. In the latter, we wrote a script that ran for 24 hours straight. Imagine if this reconfiguration task had to be done manually, it would have taken weeks, and based on priorities, it might never have been done at all. Now, there's a script that can be run on a monthly basis, for example, and we let Windows PowerShell do all of the work for us. If you're interested in doing more with Windows PowerShell to administer your VMware environment, make sure to check out TrainSignal instructor Hal Rottenberg's couse on http://www.trainsignal.com/VMware-vSphere-PowerCLI-Training.aspx PowerCLI.

I once remember being asked by a manager to add hundreds of users from an Excel spreadsheet to a Microsoft Active Directory group. The manager already knew I had scripting experience, but was still surprised by my “Done” email a few minutes after having received the spreadsheet. I still remember him standing up from his desk and asking me, “What do you mean? It's finished?!” My work went something like: save XLS to CSV, import-csv, Quest/Dell Active Directory cmdlets (great for Windows Server 2003 AD environments!). You gotta love Windows PowerShell!

Get our content first. In your inbox.

1229

Loading form...

If this message remains, it may be due to cookies being disabled or to an ad blocker.

Contributor

Marco Shaw

Marco Shaw is an IT consultant working in Canada. He has been working in the IT industry for over 12 years. He was awarded the Microsoft MVP award for his contributions to the Windows PowerShell community for 5 consecutive years (2007-2011). He has co-authored a book on Windows PowerShell, contributed to Microsoft Press and Microsoft TechNet magazine, and also contributed chapters for other books such as Microsoft System Center Operations Manager and Microsoft SQL Server. He has spoken at Microsoft TechDays in Canada and at TechMentor in the United States. He currently holds the GIAC GSEC and RHCE certifications, and is actively working on others.