Understanding the Windows PowerShell Release Cycle
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
One common question I receive from my students: "Does Windows PowerShell have a release cycle?" Answering this question involves some muddiness; I typically respond, "Yes and no." By the time you finish reading this article, I want you to understand the issues:
- Which Windows versions are compatible with which PowerShell versions
- How PowerShell is timed to Windows operating system releases
- How you can update your PowerShell bits by using the Windows Management Framework (WMF)
Let's begin!
Untangling the Relationship Between Windows and PowerShell
We'll start by studying a table that I included in my book Sams Teach Yourself Windows PowerShell 5 in 24 Hours.
Windows PowerShell Version History in a Nutshell
|
Windows PowerShell Version |
Release Date |
Associated Operating Systems |
Can Upgrade From |
Standout Features |
Available via WMF? |
|
1.0 |
2006 |
Windows Server 2003, Windows Server 2008, Windows XP SP2, Windows Vista |
N/A |
Initial release |
No |
|
2.0 |
2009 |
Windows Server 2008 R2, Windows 7 |
N/A |
Remoting, jobs, modules |
No |
|
3.0 |
2012 |
Windows Server 2012, Windows 8 |
Windows Server 2008 R2, Windows 7 |
Updatable help, code completion, snippets, resumable sessions |
Yes |
|
4.0 |
2013 |
Windows Server 2012 R2, Windows 8.1 |
Windows Server 2008 R2, Windows 7 |
Desired State Configuration, exportable help, network diagnostics |
Yes |
|
5.0 (Preview) |
2014 |
N/A (Public preview as of this writing) |
N/A |
OneGet, PowerShellGet, switch management improvements, classes |
Yes |
The table includes some important takeaways for us:
- Computers running Windows Server 2008 R2 or Windows 7 can upgrade to PowerShell v4, but not PowerShell v5.
- You can update your PowerShell version by using WMF, starting with PowerShell v3.
- The PowerShell team appears to ship a new PowerShell version with each major Windows OS release.
To make the point boldly, we can make the first of two general conclusions:
We can expect to see a new PowerShell version whenever the Windows teams release a major version of Windows Server and Windows client.
Cool. But you may wonder what the Windows Management Framework is. We'll address that issue right away, but first I want to say just a couple of words about the .NET Framework.
Windows PowerShell and the .NET Framework
Many IT professionals are confused about what the .NET Framework is. Briefly, the .NET Framework is a runtime environment for Windows applications, including the base operating system. What's cool about the .NET Framework is that its application programming interface (API) has hooks that allow us to access all aspects of local and remote computers: processor, memory, disk, network—you name it.
Windows PowerShell is essentially an IT pro-friendly way to interact with the powerful .NET Framework. Moreover, Windows PowerShell versions are tied to particular .NET Framework versions. Here's the summary for Windows PowerShell versions from v3 to v5 preview:
- Windows PowerShell v3: .NET Framework v4.0
- Windows PowerShell v4: .NET Framework v4.5
- Windows PowerShell v5: .NET Framework v4.5
The good news is twofold:
- As long as you're using Microsoft Update, Windows will automatically provide you with new .NET Framework versions as Microsoft releases them.
- You can (and probably do) have multiple .NET Framework versions installed simultaneously on your Windows computers.
Understanding the WMF
If you've ever heard PowerShell inventor Jeffrey Snover speak, you can tell right away how enthused he is about the language. Microsoft's core PowerShell team is so excited about the technology, in fact, that they want Windows systems administrators always to have a) previous major releases available for upgrade; and b) the latest preview bits available for our experimentation.
Enter the Windows Management Framework (WMF). The WMF is a bundle that includes the PowerShell runtime environment and associated assets. For example, to upgrade PowerShell on a Windows 7 workstation to version 4.0, you simply visit the Microsoft Download Center, download the update package, install, reboot, and you're done.
Examining WMF Components
Let's investigate the WMF 3.0 components:
- PowerShell v3 runtime environment: The PowerShell "engine."
- Windows Management Instrumentation (WMI): Expands how PowerShell interacts with your computer's WMI systems-management repository.
- OData IIS Extension: Allows PowerShell to participate in RESTful Web services.
- Server Manager CIM Provider: Supports PowerShell remoting.
Sometimes WMF includes a new version of the Windows PowerShell Integrated Scripting Environment (ISE); the specific parts and pieces of a WMF release depend upon the features included in that release.
Upgrading Your PowerShell Version
The PowerShell team writes the environment to be backwardly compatible with previous versions as much as possible. For instance, let's say you update a Windows 7 machine (which ships with PowerShell v2) to PowerShell v4. Let's check the version from an elevated PowerShell console session:
PS C:\> $PSVersionTable.PSVersion Major Minor Build Revision ----- ----- ----- -------- 4 0 -1 -1
Okay. Now we'll type cmd to exit PowerShell and start an "old school" Cmd.exe session. We use the -version 2.0 switch to start a legacy PowerShell session, like so:
C:\>powershell –version 2.0
To finish with a flourish, we'll recheck the PSVersion property in the same session:
PS C:\> $PSVersionTable.PSVersion Major Minor Build Revision ----- ----- ----- -------- 2 0 -1 -1
Pretty cool, isn't it? The ability to start a v2.0 session might be just what you need for compatibility with old-but-good scripts. Remember that when you're running a legacy PowerShell session, you won't have access to commands present in later releases. Check this out:
PS C:\> Update-Help Update-Help : The term 'Update-Help' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
Ouch!
Installing WMF
Once you've performed your due diligence and determined that you do indeed want to update the PowerShell version on your Windows server or client computer, first you need to download the correct WMF version from the Microsoft Download Center. Here are some helpful links:
In this example, I'm going to download the latest WMF v5.0 preview bits to test on my Windows 8.1 computer. The first (minor) hurdle to overcome is figuring out which Microsoft Update .msu package applies to your computer. Take a look at Figure 1 to see what I mean.
)
Figure 1 Be sure to download the correct WMF installer.
Each .msu package is associated with a Microsoft Knowledge Base (KB) identifier and an architecture specifier (x64 for 64-bit hardware, x86 for 32-bit). The Windows 8-RT package is aimed at Windows RT-based tablets, so in all likelihood we want the x64 .msu. (The "Windows Blue" moniker refers to Microsoft's internal code name for Windows 10 and Windows Server vNext.)
The actual WMF installation process is uninteresting, as you can see in Figure 2. Be aware that you'll need to restart your computer in order for the PowerShell update to go into effect.
)
Figure 2 Installing a new PowerShell version is an uneventful process in most cases.
Believe me, you'll know right away if you try to install a WMF version that isn't compatible with your operating system. Glance at Figure 3 for evidence.
)
Figure 3 This is what happened when I tried to install WMF 5.0 on a Windows 7 computer.
Uninstalling PowerShell
The classic answer to the question "How can I uninstall PowerShell?" is another question: "Why would you want to do that?" Frankly, the only reason I can see for wanting to uninstall PowerShell is a situation in which I updated PowerShell and found that the new version conflicted with software I have running on that box.
In this example, I'll remove WMF 4.0 from my Windows 7 computer using (wait for it) PowerShell and Cmd.exe. First, let's look up the WMF 4.0 hotfix by referencing its KB identifier:
PS C:\> Get-HotFix -Id KB2819745 Source Description HotFixID InstalledBy InstalledOn ------ ----------- -------- ----------- ----------- TIMPC1HMIM Update KB2819745 timpc1hmim\Tim 9/30/2014 ...
Next, let's invoke Cmd.exe and the Windows Update Standalone Uninstaller (wusa.exe) to perform the WMF uninstall:
PS C:\> cmd /c wusa.exe /uninstall /KB:2819745 /quiet /norestart
After a reboot, my Windows 7 box is back to Windows PowerShell v2.0:
PS C:\> $PSVersionTable.psversion Major Minor Build Revision ----- ----- ----- -------- 2 0 -1 -1
Wrap-Up
So what do you think? Are you wondering when Microsoft will release the next version of Windows, so we can get a final version of PowerShell v5? Well, from the looks of it, PowerShell v5 will be in preview mode for a long time—Microsoft delayed Windows Server vNext until 2016, and Windows 10 isn't expected to ship until (very) late 2015.
In any event, you now understand the Windows PowerShell release cycle. I'll leave you with my two key tips to keep safe in your conceptual "shirt pocket" regarding PowerShell versions:
- Only use GA PowerShell on production computers.
- Feel free to experiment with the latest WMF bits on test computers.
- Microsoft times PowerShell GA releases with Windows OS releases.
I'll see you next month. Until then, more power to the shell!