We recently announced that Windows PowerShell 2.0 is being deprecated in the Windows 10 Fall Creators Update. Deprecation is a process whereby technologies or applications are marked as legacy, signalling to users that they may be removed in the future, and that should move away from them and towards newer alternatives.
We do not currently have a timeline to remove Windows PowerShell 2.0, but as we continue to evaluate its usage in the PowerShell ecosystem, we will be working to remove it in a future release. When this decision is made, we will give plenty of notice via official Windows deprecation channels (like the above support link), as well as this blog. However, at this time, we recognize that it’s usage is still prevalent, and we won’t make this decision without giving ample time for users to migrate away from it.
I’m a PowerShell expert, just give me the quick version
If you’re very familiar with the PowerShell ecosystem, this is a quick guide for moving off of Windows PowerShell 2.0. If not, read on through the rest of the blog for a better explanation of the technical details.
If you’re running any scripts using powershell -version 2, you should use a later version of PowerShell (like Windows PowerShell 5.1 or PowerShell Core 6.0).
If you’re hosting any PowerShell assemblies (e.g. System.Management.Automation.dll) in a .NET CLR2 (i.e. .NET Framework 2.0 – 3.5) application, you should work to move your application to CLR4 (i.e. .NET Framework 4.6+) or .NET Core.
What is Windows PowerShell 2.0?
Windows PowerShell 2.0 first shipped as the version of Windows PowerShell built into Windows 7 (where it was not an optional feature). It was also shipped, via the Windows Management Framework (WMF) to older versions of Windows, including:
- Windows Server 2008
- Windows Vista
- Windows Server 2003
- Windows XP
When Windows PowerShell 3.0 was released as part of Windows 8, Server 2008 R2, and WMF 3.0, Windows PowerShell moved to a newer version of the .NET Framework (CLR4) that was not compatible older applications. In order to maintain backwards compatibility with these older applications, we kept Windows PowerShell 2.0 as an optional, side-by-side component in later versions of Windows and Windows Server. You could take advantage of this optional component by using powershell -version 2 to start the older version of the engine, or by continuing to use a PowerShell assembly in a .NET CLR2 application. Note: specifying any version higher than 2 with -version (e.g. 3, 4, or 5) will load the latest, non-2.0 version of Windows PowerShell on the machine, regardless of the number specified.
Why is it being deprecated?
Windows PowerShell 5.x has some great new features that enhance security including enhanced transcription logging and AMSI protection.
As PowerShell Core 6.0 enters the marketplace, we’d like to reduce the complexity of the PowerShell ecosystem. Removing an outdated version of .NET from the equation makes development easier for cmdlet and script authors by focusing on the .NET Standard ecosystem that includes only .NET Framework 4.6+ and .NET Core 2.0.
What does this mean for me?
You can check whether Windows PowerShell 2.0 is installed by running the following (as an administrator).
On Windows 7/8.1/10, the following will return a State as either Enabled or Disabled:
Get-WindowsOptionalFeature -Online -FeatureName MicrosoftWindowsPowerShellV2
On Windows Server, the following will return an InstallState of either Installed or Removed:
Get-WindowsFeature PowerShell-V2
If Windows PowerShell 2.0 is not installed on your machine(s) and everything is working fine, you probably don’t need to worry about deprecation.
If Windows PowerShell 2.0 is installed, there are a few cases where you might be using it:
Scripting with Windows PowerShell 2.0
- You’re running
powershell.exe -version 2(often shortened topowershell -v 2) when running scripts or as a shell. This is the easiest to mitigate: simply try running your scripts without the-version 2. If it works fine, stop using-version 2. - You’re running a PowerShell script that calls
#requires -version 2at the top. If Windows PowerShell 2.0 is installed, this will automatically start and run the script with it regardless of where the script is executed. (Note: if Windows PowerShell 2.0 is not installed, this line is ignored and the script is executed with whatever version of Windows PowerShell is installed.)
Hosting Windows PowerShell 2.0 in a .NET 2.0/3.5 Application
If you’ve developed an application with .NET 2.0/3.5 (aka CLR2), and you’re hosting a PowerShell assembly like System.Management.Automation.dll, then you’re using the Windows PowerShell 2.0 version of those assemblies. If this is the case, you should work to migrate your application to .NET 4.6+ (aka CLR4) using reference assmeblies from Windows PowerShell 3.0 or later. That way, you’ll be using the latest version of the Windows PowerShell assemblies available on the box. (Note: this may require that your Windows 7 or Server 2008 R2 users install .NET 4.6+ and/or WMF 3.0 or higher.)
Installation Checks for Windows PowerShell 2.0
You may also have a legacy application that checks for the existence of Windows PowerShell on the box via the registry, particularly for the existence of HKLM:\Software\Microsoft\Windows\PowerShell\1\PowerShellEngine. As long as your application only targets supported versions of Windows and Windows Server (7/8.1/10 and Server 2008R2/2012/2012R2/2016), you can remove this validation altogether.
If not, you should instead check for the existence of the file %systemroot%\system32\WindowsPowerShell\v1.0\powershell.exe. If your installer absolutely requires a registry-based validations, you should first check for HKLM:\Software\Microsoft\Windows\PowerShell\3\PowerShellEngine (note the 3) before falling back to HKLM:\Software\Microsoft\Windows\PowerShell\1\PowerShellEngine.
Using a Microsoft Application Leveraging Windows PowerShell 2.0
There are a number of first-party Microsoft applications that continue to use Windows PowerShell 2.0 under the hood, including some System Center applications, some versions of SQL Server, some versions of Exchange, and others. We will be working with these teams over the coming months to migrate them off of Windows PowerShell 2.0. In the meantime, Windows PowerShell 2.0 will remain a part of Windows 10 and Windows Server 2016, and we have no plans to remove it until those dependencies are mitigated.
That’s it!
In summary, the deprecation of Windows PowerShell 2.0 doesn’t mean that it’s being removed yet, but you should work to move off of it, as we may decide to remove it in a future release. When we do have more concrete plans to remove it, we’ll give fair warning before taking it out. In the meantime, do your best to migrate away from it, using the above as a guide.
Joey Aiello
Program Manager, PowerShell