Should I Upgrade to Latest Windows PowerShell Version?

Doctor Scripto

Summary: Richard Siddaway discusses the issues around upgrading your version of Windows PowerShell. Microsoft Scripting Guy, Ed Wilson, is here. Today’s post is provided by Richard Siddaway…

Richard is based out of the UK and spends his time automating anything, and everything, for Kelway, Ltd. A 7-year Windows PowerShell MVP, Richard is a prolific blogger, mainly about Windows PowerShell, (Richard Siddaway’s Blog: A PowerShell MVPs site) and a frequent speaker at user groups and Windows PowerShell conferences. He has written a number of Windows PowerShell books: Windows PowerShell in Practice, Windows PowerShell and WMI, Windows PowerShell in Depth (co-author), Windows PowerShell Dive (co-editor), and Learn Active Directory Management in a Month of Lunches (which features lots of Windows PowerShell). Some new Windows PowerShell books are in the pipeline. All of the books are available from www.manning.com.  Hey, Scripting Guy! I’m not using the latest version of Windows PowerShell. Should I upgrade? —KT  Hello KT, Richard Siddaway here. That’s a really good question, and it has a short answer and a long answer. The short answer (as with so much in IT) is, “It depends.” The long answer is the rest of this blog post. IT pros always want the new shiny toys to play with. I’m no exception. But there can be a downside to blindly pushing out an upgrade across all of your servers. Upgrading Windows PowerShell is no exception, and there are a few questions you should be able to answer before performing an upgrade:

• What benefits am I going to get?
• What’s the risk—will any of my applications break?
• Do I actually need the new functionality?
• Is the machine a client or a server?

Let’s start working our way through these questions. Other questions will come to mind that are specific to your organization and for which you are the only one who can see the issues and find the answers. I’m assuming that you are looking to upgrade only Windows PowerShell. If you upgrade the underlying operating system, you will automatically upgrade Windows PowerShell, but operating system upgrades are a topic for another time and place. The first consideration must be about the benefits you are going to get. Most people I speak to are using Windows PowerShell 2.0 or later. I can’t really think of the last time I discussed using Windows PowerShell 1.0. That means your upgrade choices are Windows PowerShell 4.0 or Windows PowerShell 3.0. You will notice that I have deliberately excluded Windows PowerShell 5.0. At the current time, Windows PowerShell 5.0 is a Community Technology Preview (CTP). It can (and does) change between preview versions. Using a CTP in a production environment is not recommended, and it carries a significant risk that a change will break your code. You have been warned. Having said that, I’ll explain the currently known benefits of using Windows PowerShell 5.0 so your thinking is future proofed—at least until the next version of Windows PowerShell appears. Windows PowerShell 3.0 brought a large set of new functionality:

• Windows PowerShell workflows
• CIM cmdlets
• Cmdlets over objects (CDXML)
• Windows PowerShell Web Access
• Module automatic loading
• Updatable Help
• Robust and disconnected sessions
• Scheduled jobs

This isn’t the full set of enhancements. For that, read What’s New in Windows PowerShell (which also talks about features in Windows PowerShell 5.0 and Windows PowerShell 4.0). Windows PowerShell 4.0 followed shortly afterwards and brought:

• Desired State Configuration (DSC)
• Save-Help
• Windows PowerShell Web Access improvements
• Workflow enhancements
• New features for Windows PowerShell Web Services

Windows PowerShell 5.0, although still under development, has these known new features:

• Classes can be defined in functionality
• DSC enhancements
• OneGet for managing software packages
• PowerShellGet for managing Windows PowerShell modules through OneGet
• Transcriptions available in all hosts
• Major enhancements to debugging, including the ability to debug Windows PowerShell jobs
• Network switch module
• Performance gain when using COM objects

After you review the functionality you gain, you need to decide if you actually need the benefits. If you aren’t planning to use DSC, for instance, do you need to upgrade to Windows PowerShell 4.0? Only you can answer that question in the context of your organization. The next question you have to answer is about risk. Will upgrading Windows PowerShell break any of my applications? Unfortunately the answer is that it might. The Release Notes for Windows PowerShell 4.0 supply the following list of applications with which Windows PowerShell 4.0 is incompatible:

• System Center 2012 Configuration Manager (not including SP1)
• System Center Virtual Machine Manager 2008 R2 (including SP1)
• Microsoft Exchange Server 2013, Microsoft Exchange Server 2010, and Microsoft Exchange Server 2007
• Microsoft SharePoint 2013 and Microsoft SharePoint 2010
• Windows Small Business Server 2011 Standard

If your machine is running any of these products, do not install Windows PowerShell 4.0. Windows PowerShell 3.0 has a very similar list. Some of these applications (such as Exchange Server 2013) are made compatible with a service pack. You will need to determine if a service pack or another fix is available for your particular application and situation. The other issue you need to resolve is will the new version of Windows PowerShell break any of your existing code. Unfortunately, under some circumstances the answer will be, “Yes.” You can find details in the Release Notes about any breaking changes that have been introduced. The Windows PowerShell team has done an excellent job minimizing the number of breaking changes, but it is never possible to ensure that there aren’t any when a new version is created. The safest way to ensure that your code will run in a newer version of Windows PowerShell is to test it. Of course, being a Windows PowerShell user, you will want to automate those tests. Assuming you’ve determined that your applications are compatible with the new version of Windows PowerShell, you need to determine the new features in which you are really interested. If you want the parallelization and ability to survive restarts, you need Windows PowerShell 3.0, and Windows PowerShell 4.0 would be better due to the enhancements. Don’t try to convert all of your production scripts to new functionality as soon as you have the new version. A much better approach is to use the new functionality in new code. You can modify existing code as you make major modifications to your scripts and modules. The machines you will be using to run Windows PowerShell have an impact on the version of Windows PowerShell you can use. Following are lists of appropriate operating systems for each version. Windows PowerShell 4.0:

• Windows Server 2012 R2
• Windows Server 2012
• Windows Server 2008 R2
• Windows 8.1
• Windows 7 with SP1

Windows PowerShell 3.0:

• Windows Server 2012
• Windows Server 2008 R2
• Windows Server 2008 SP2
• Windows 8
• Windows 7 with SP1

For servers, the current pattern is Windows PowerShell version N is available for Windows Server version N to N-2, where N is the latest version. Client operating systems are slightly more complicated in that Windows PowerShell 4.0 isn’t available for Windows 8 (use the free upgrade to Windows 8.1), and Windows PowerShell 3.0 isn’t available for Windows Vista. One other aspect to think about when considering operating systems is that a lot of Windows PowerShell functionality in Windows 8 and Windows Server 2012 is delivered as CDXML modules. These modules utilize the cmdlets over objects technology by starting with a CIM class, wrapping it in XML, and publishing the resulting .cdxml file as a Windows PowerShell module. If you install Windows PowerShell 4.0 on Windows 7, for instance, you won’t get that new functionality, which can amount to 60% of the cmdlet set. The reason you won’t get the functionality is that the required CIM classes don’t exist on the older versions of Windows. The CDXML modules can’t access them, and therefore, they won’t work. They aren’t included in the download for the older operating systems to simplify matters. It’s better for them not to be present rather than present and not working. You also need the appropriate CIM class to be on any remote server you are trying to administer using those cmdlets. If you are looking at upgrading the version of Windows PowerShell on your administration machine (workstation or server), I would recommend upgrading the operating system so that you get the maximum benefit. If you are upgrading an existing server, I would actually question the need to perform an upgrade. The reason for this statement is that Windows PowerShell remoting is compatible across versions, so you can connect to and administer a machine running Windows PowerShell 2.0 from a machine running Windows PowerShell 4.0 (or any other combination of the versions discussed earlier). One point to keep in mind is the version of WSMAN. It changed from 2.0 in Windows PowerShell 2.0 to 3.0 in Windows PowerShell 3.0. This mainly impacts the ability to use CIM sessions (analogous to Windows PowerShell remoting sessions, but used by the CIM cmdlets). They default to using WSMAN to connect to remote machines, but it has to be WSMAN 3.0. If your remote machine is running WSMAN 2.0 you will get an error message when trying to connect. The solution is to drop back to DCOM for the connection to those machines. If you are building new servers, I would recommend installing the latest version of Windows PowerShell that is compatible with your version of the operating system. This ensures that you have the functionality if you need it. One final thing you must never ever forget when upgrading: Ensure that everything goes through your organization’s change control process. It really will protect you if something goes wrong. Upgrading the version of Windows PowerShell is a very interesting question, and as you have seen, there isn’t a right answer. The decision to upgrade has to be based on the circumstances of your organization and the systems involved. If you decide to perform an upgrade, please remember to test everything. I hope your upgrades go smoothly and you enjoy the new functionality. Bye for now. ~Richard Thanks, Richard. I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy

Doctor Scripto Scripter, PowerShell, vbScript, BAT, CMD

Follow