Should I Upgrade to Latest Windows PowerShell Version?

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

Hey, Scripting Guy! Question Hey, Scripting Guy! I’m not using the latest version of Windows PowerShell. Should I upgrade?


Hey, Scripting Guy! Answer 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.


Thanks, Richard. I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy

Comments (7)

  1. happysysadm says:

    Very informative. Thanks for taking the time to trace this sort of ‘compatibility matrix’.

  2. Hi Glenn

    Thank you for the question.

    My discussion was primarily based at servers. I view PowerShell as a tool for adminsitering my server estate rather than configuring individual workstations. My comments about the risks of upgrading because ceratin applications would break were definiitely
    aimed at servers.

    My admin workstation I want to be running the latest version of PowerShell I can. In production that means PowerShell 4.0. I have 5.0 running in a lab and once the feature set is stable I’ll think about upgrading my admin workstation.

    My servers I tend to leave on the version of PowerShell that came with the OS. Unless there is a compelling reason I don’t upgrade. There are some caveats to that in that I’ll upgrade any gateway type servers e.g. running PowerShell Web Access or acting as
    a jump off server for administration of the rest of the estate. I tend to do this by upgrading the operating system rather than just upgrading PowerShell as I often need the additional functionality brought by the OS.

    Other workstations I tend not to worry about and leave them as installed as I rarely have need to use PowerShell on them.

    Having said all that your environment could well be different to mine and you need to approach things in a diffeernt manner. I’m not aware of any major workstation applications breaking because the version of Powershell has been upgraded. But remember that
    a lot of the functionality that you see in PowerShell 3.0 & 4.0 on Windows 8/8.1 is based on CDXML modules and the underlying CIM classes won’t be available on other versions of Windows so you don’t get the full functionality so if you’re going to be actively
    using PowerShell on those machines you’re better off upgrading the OS


  3. Great tip about versions. Will have to read this in more details later.

  4. Glenn says:

    I think the discussion could be divided a bit more to speak to the aspect of upgrading PS on servers compared to upgrading PS on the client population. Specifically, could you clarify, or point to a resource, that would describe the risks for upgrading
    just a client to 3.0 or 4.0? I translated the mention that upgrading could break the apps listed in your risk paragraph to mean it would break them if you upgraded PS on the servers, not the clients that may use these resources. I’ve been using 4.0 for a while
    and we’re still on Exchange 2010 and Sharepoint 2010 but I haven’t found any issues using either in my daily use. I don’t personally administer them or interact with them with PS, so maybe there could be a concern with updating PS on the admin clients?

  5. mosaic says:

    Thank you for this information – you saved me a great deal of time.
    The reason I am looking to upgrade from v2.0 is that v3.0 has quite a lot of new syntax that can make the code more intuitive and clean but does not actually represent new functionality. I find more and more that snippets of code (and even whole modules) found
    on the net can run on v2.0 but only after being translated "down" to v2.0 syntax.

  6. TJ says:

    I am interested in how different versions of powershell cause problems in the same AD. My file server is running 3.0. The domain controllers run 2.0. My workstation which is where I write and run scripts, runs 4.0. The folks in charge are trying to bring up SCCM. But I don’t use powershell to interact with that. So am I safe to run it anyway? We are seeing some corruptions in our AD that pop up in different places, unpredictably. Boss wonders if it’s because of all the mismatched versions in the domain. I can’t find any information on this situation. We run Server 2008 R2. My workstation where the scripts are built and run, is Windows 7 with posh 4.0.

Skip to main content