PowerShell in Depth, Second Edition (2015)

Appendix C. PowerShell versions

There have been four versions of PowerShell since the original release in November 2006 that was announced at TechEd Europe in Barcelona. You’re likely to meet, at least, versions 2 through 4 in your work. In this appendix, we’ll provide information on the various PowerShell versions so that you are aware of the capabilities of each. You can use this information to determine how you’ll administer your environment and possibly modify your approach to manage the differences between versions.

The four PowerShell releases are outlined in table C.1. The table includes release date, required .NET version, and where you can find the download, as of this writing.

Table C.1. The four PowerShell releases

Starting with Windows Server 2008, PowerShell became part of the operating system. The details of which versions of Windows support which versions of PowerShell are supplied later in this appendix.

PowerShell, as we’ve pointed out numerous times, is based on the .NET Framework. The version of .NET required by PowerShell changes as you progress through the versions. Notice that PowerShell v2 requires .NET 2.0 only if you’re using the console. You’ll need .NET 3.5 if you intend to use ISE or the Out-GridView cmdlet.

The PowerShell download for Windows Vista wasn’t released until January 2007, so you may see references in the literature to PowerShell being released in 2007.

There was a significant change in terminology between PowerShell versions 1 and 2. Starting with v2, PowerShell became part of the Windows Management Framework (WMF). This meant that you got PowerShell and a set of supporting, or parallel, technologies that you need to manage your Windows environment. Table C.2 outlines the major components in each release.

Table C.2. Download contents

PowerShell v2 introduced remote administration over the WinRM service. This service had a version change in version 3. Note that PowerShell v4 is still using WinRM 3.0. You can successfully perform PowerShell remoting between WinRM 2.0 and 3.0, meaning that any combination of PowerShell v2, v3, or v4 can be used as the local and remote machines.

The same can’t be said of the CIM cmdlets introduced in PowerShell v3. They default to WSMAN (WinRM) for making remote connections and are version-specific in expecting WinRM 3.0. You can’t upgrade WinRM independent of PowerShell, so if you need to use the CIM cmdlets against a system running PowerShell v2, you must revert to using DCOM for remote connectivity by creating a CIMSessionOption. Of course, you can simplify your PowerShell experience by making sure all your systems are running at least PowerShell v3.

PowerShell is part of the Windows operating system now, and each new version of Windows is accompanied by a new version of PowerShell. We often see questions in the forums about using PowerShell’s feature “X” on a particular version of Windows. Very often that feature can’t be used because you can’t install the particular version of PowerShell you need on the version of Windows you are dealing with. Table C.3 shows which versions of Windows can support a particular version of PowerShell.

Table C.3. PowerShell and operating system support matrix

Keep these points in mind:

· PowerShell v4 can’t be installed on Itanium (IA64) versions of Windows Server 2012 or Windows Server 2008 R2.

· PowerShell can’t be installed on Windows Server 2008 Server Core. A number of people published hacks showing how it could be achieved. Running PowerShell on Windows Server 2008 Server Core isn’t supported by Microsoft and isn’t a recommended practice.

· The support plan roughly follows the pattern that the latest version of PowerShell is installed as part of the latest versions on Windows and downloads are provided for the previous two releases of Windows. There are exceptions—for example, you can’t install PowerShell v4 on Windows 8.

IT pros usually want the latest and greatest set of features—which means upgrading the instance of PowerShell on your older versions of Windows subject to availability, as shown in table C.3.

There’s a problem. Some other applications are tied to particular versions of .NET, and if you try to upgrade PowerShell on a system with these applications installed, you’ll cause problems and may need to completely rebuild your system. The known incompatibilities are listed in table C.4.

Table C.4. Known incompatibilities

In some cases, a service pack for the application will allow the application to be installed on a system with a previously incompatible version of PowerShell. Exchange 2013 SP1, for instance, enables the application to be installed on Windows Server 2012 R2, which means that it can co-exist with PowerShell v4.

Tip

The bottom line here is to not perform a PowerShell upgrade but upgrade the whole system so that you don’t break your application. In many cases, upgrading may not be possible, so you’ll need to work around missing functionality.

Table C.5 shows how the main functionality groups map to the sequence of PowerShell releases.

Table C.5. PowerShell functionality matrix

You can get a full list of the new features, bug fixes, and enhancements in PowerShell v3 and v4 from http://technet.microsoft.com/en-us/library/hh857339.aspx. Also check out this help file: about_Windows_PowerShell_4.0.

One thing that seems to be causing a lot of confusion is the number of modules, and corresponding functionality, installed with PowerShell v3 and v4. What you get depends on the operating system version you’re using.

If you run this:

Get-Module –ListAvailable

on a Windows 8.1 system (PowerShell v4), you’ll find a total of 58 modules installed in $pshome\modules—that is, C:\windows\system32\WindowsPowerShell\v1.0\Modules.

Note

This result is assuming a new, clean install. If you’ve installed any features such as Hyper-V, you may have more.

These are the modules installed as part of PowerShell. Right?

Compare this with a Windows 7 machine that’s been upgraded to PowerShell v4. Repeating the exercise, you’ll find a grand total of 15 modules. So where has the other 75 percent of your functionality gone?

This is the breakdown of the modules installed on the Windows 7 machine. The terminology is ours (feel free to disagree with the groupings):

Core PowerShell:

· Microsoft.PowerShell.Diagnostic

· Microsoft.PowerShell.Host

· Microsoft.PowerShell.Management

· Microsoft.PowerShell.Security

· Microsoft.PowerShell.Utility

· CimCmdlets

· ISE

· Microsoft.WSMan.Management

File Transfer module

· BitsTransfer

Troubleshooting:

· PSDiagnostics

· TroubleshootingPack

Other related engines:

· PSDesiredStateConfiguration

· PSScheduledJob

· PSWorkflow

· PSWorkflowUtility

And that’s it. Everything else as far as we can determine is CDXML-based and therefore can’t be made available on legacy systems. The modules in table C.6 are included in that category.

Table C.6. CDXML modules in PowerShell v3 and v4

As you saw in chapter 39, a CDXML-based module is produced by taking a CIM (WMI) class and wrapping it in some simple XML and saving it as a CDXML file. This file can then be published as a PowerShell module. The CIM classes won’t be made available on down-level systems, so you won’t find this functionality on anything earlier than Windows 8 or Windows Server 2012.

If you need the functionality supplied by these modules, you’ll have to use either the old command-line tools or a WMI class. Much of the functionality of the NetAdapter and NETCPIP modules, for instance, can be duplicated using Win32_Network-Adapter and Win32_NetworkAdapterConfiguration.

So where does this leave you? We’d like to say upgrade everything to the latest available operating system so that you can get the latest version of PowerShell, but that’s an unrealistic expectation. If at all possible, install PowerShell v3 on all of your servers with Remoting enabled so that you can manage them from your desktop. On your desktop, at a minimum we think you need PowerShell v3, although v4 with RSAT installed would be even better. If you are stuck with legacy systems, try to get at least v2 installed so that you can perform some basic remote management and use WMI. And if you’re stuck with systems that are PowerShell v1, well, you have our sympathy and you’ll have to accept the fact that your management options will be extremely limited.

With that, we’ll say good luck!