PowerShell 6 expands reach but lags behind Windows version
Cross-platform PowerShell arrived without all the functionality that's available in Windows PowerShell -- but it brings the ability to manage Linux and macOS systems.
What PowerShell 6 lacks in functionality, it adds in reach.
Microsoft released PowerShell Core 6 in January 2018, the first release since the company shifted the Windows-based standard automation engine and scripting language to an open source, cross-platform product to manage Linux and macOS machines. PowerShell 6 is not a direct upgrade for Windows PowerShell version 5.1. The two products can work side by side, and they will have to until PowerShell Core reaches feature parity with Windows PowerShell.
PowerShell 6 not a Windows PowerShell replacement
The primary difference between the two PowerShell products is that Windows PowerShell runs on the Windows-only .NET Common Language Runtime, whereas PowerShell 6 runs on .NET Core, which works on Windows, many Linux distributions and macOS.
PowerShell Core works alongside Windows PowerShell, but the executables have different names. PowerShell Core lacks the PowerShell Integrated Scripting Environment; Microsoft recommends PowerShell Core users adopt Visual Studio Code, a cross-platform product, as its replacement.
Microsoft encourages administrators to shift away from Windows PowerShell. Pictured is the shell of Windows PowerShell version 5.1 with the PowerShell Integrated Scripting Environment script editor.
The cross-platform nature of PowerShell Core means it lacks some Windows-centric features, such as event log cmdlets and Windows Management Instrumentation cmdlets. PowerShell workflows are also missing in PowerShell Core. Some of this functionality will return to PowerShell Core with the future release of the Windows Compatibility Pack for .NET Core.
The cross-platform nature of PowerShell Core means it lacks some Windows-centric features, such as event log cmdlets and Windows Management Instrumentation cmdlets.
There are several different sources of the functionality currently available in Windows PowerShell version 5.1:
the foundational PowerShell functionality supplied by the PowerShell team;
modules shipped as part of the Windows operating system, such as NetAdapter and storage;
modules supplied as part of a Windows feature, such as the Active Directory or domain name system modules, including the modules from the Remote Server Administration Tools utility;
modules supplied with a Microsoft product, such as Exchange Server or SQL Server;
modules supplied through the PowerShell gallery; and
modules supplied by third-party vendors.
PowerShell 6 seems light on functionality because it only covers the first item. Many of the modules in the second item will run under PowerShell Core, but not all.
New PowerShell users can develop comprehensive yet compact scripts once they master the pipeline feature.
When we get further down the list, some modules, such as Active Directory and Exchange, won't work on PowerShell 6 because they are written for full .NET rather than .NET Core. The .NET Core Windows Compatibility Pack enables scripting against Active Directory.
Hopefully, PowerShell Core will regain all this functionality, but that will take time to achieve.
Remote administration made easy
Managing one server is easily accomplished with the standard tools. By the time you're managing 100, 1,000 or more servers, the standard tools just don't scale. PowerShell establishes sessions on remote machines to run the same action -- or set of actions -- on multiple machines. This fan out approach -- defining what you want to happen and then automating those tasks -- is key to administer large numbers of servers remotely.
PowerShell works with the Windows scheduler to perform routine admin jobs during overnight periods. Administrators can build scripts that report errors and perform remedial actions to overcome issues.
Microsoft converted its Windows PowerShell automation engine and scripting language into an open source, cross-platform product. Pictured is the shell for PowerShell Core with Visual Studio Code, the preferred scripting editor for this cross-platform version of PowerShell, in the background.
PowerShell remoting uses the Web Services for Management (WSMan) protocol for remote connectivity in Windows PowerShell versions 2.0 through 5.1. This works within an Active Directory domain, but issues could arise when working across domains or when remoting to and from machines in a workgroup.
PowerShell Core offers WSMan-based remoting for Windows systems -- the WSMan implementation on Linux and macOS isn't complete -- and Secure Socket Shell (SSH) remoting. When remoting between Linux machines, or if Linux is at one end of a connection and Windows is at the other, then SSH is the protocol to use.
How PowerShell measures up to other tools
PowerShell and its capabilities are the focus of this third article in the server management landscape series. The first article discussed the types of tools available. The second article examined the standard Windows and Linux utilities and where each fits in different scenarios.
SSH remoting simplifies access to a machine outside the domain, but it's difficult to set up fan out remoting with it. It's possible to create WSMan-based remoting sessions to a number of computers simultaneously, but using SSH means creating each session individually and supplying a password interactively unless the remote machines use SSH keys to support key-based user authentication. This requires a lot of setup effort.
Should you switch to PowerShell 6?
Should you stay on Windows PowerShell or migrate to PowerShell Core 6? If your data center consists of purely Windows machines in an Active Directory domain, there is no benefit to switching at this time due to a drop in feature capabilities. If you manage a mixture of Windows and Linux machines -- or a significant number of non-domain Windows machines -- then PowerShell Core offers a cross-platform administration choice, but it's likely your setup will involve both PowerShell platforms.
PowerShell's ability to handle a range of systems and scenarios -- single tasks on a single server; single tasks on multiple servers; multiple tasks on multiple servers, non-domain machines, and non-Windows machines -- provides the versatility required in many businesses.
Dig Deeper on Microsoft messaging and collaboration
