How to choose between PowerShell Core and PowerShell

In an effort to increase usage of PowerShell (PS) in multi-platform organizations such as those that see IT charged with managing Linux and macOS clients in addition to Windows devices, Microsoft has developed PS into an open source project. PowerShell has gone from a Windows-only management tool to an app that can be installed on multiple OS types to extend the management features across to all supported environments.

The change in direction has yielded not one, but two PS instances available for use. Depending on the use case, admins will find themselves utilizing the older version (5.1) used exclusively by and for Windows devices, and based on the .NET Framework. Admins tasked with managing OSs based on Unix or those wishing to stay on the cusp of the latest PS version will find that PowerShell Core (PSC), which is based on the new .NET Core runtime, will be the way to go beginning with version 6.0.

Just to clarify, PSC 6.0 is available for all versions of supported OS types. This includes Windows clients as well, with the newer version sitting side-by-side nicely with the older version natively installed on modern versions of the Windows OS. With this said, Microsoft has already made clear that the future of PS development will be squarely aimed at PSC—not the previous PowerShell 5.1 version.

SEE: PowerShell scripting: Seven tips to reduce errors (free PDF) (TechRepublic)

With all these sweeping changes in place, there are a few pros and cons IT will no doubt encounter during daily use. Below I will cover some of the more common scenarios IT might face and how to work through them during transition. The first of which will be juggling multiple versions as the former will actively receive regularly scheduled updates, including new features, while the latter will only receive updates relating to fixing critical bugs, as necessary.

PowerShell Core vs. PowerShell 5.1: Understanding the differences

Missing cmdlets

A major difference between PowerShell and PSC that users will notice on the outset is the number of cmdlets available is currently (as of this writing) double for PS than for PSC. This comes down to nothing more than Microsoft electing to not include a number of cmdlets that are not supported for products across all lines.

For example, Microsoft’s Active Directory (AD) service which allows enterprises to centrally manage users, groups, and computer objects, is not found natively in PSC. While this removes access to AD’s management features out-of-the-box for PSC users, those that require the management capability can simply import the module to obtain the missing functionality.

While the number of supported cmdlets will logically grow proportionately over time as PSC usage grows (and eventually overtakes native PowerShell use), IT departments may be better served by testing out the limits of PSC and developing alternative workflows prior to making the switch a requirement.

SEE: 20 PowerShell cmdlets you can use instead of CMD commands (free PDF) (TechRepublic)

Unsupported modules

Just like the missing cmdlets above, PS and PSC both gain their cmdlet support from modules–the collections of available/supported commands that may be used within the shell. Owing the change from .NET Framework to .NET Core, modules will need to be rewritten in order to take full advantage of the newer runtimes that form the foundation of PSC. Until developers take this action, certain modules will simply not be available—this means users relying on a specific set of commands, or rather scripts that leverage particular cmdlets, might be left out in the cold for the time being.

The guidance here is pretty straightforward: Test the scripts used by your organization prior to wading full bore into the PSC waters. As updates to PSC are made by Microsoft and third-party developers migrate their workflows to support PSC more fully, issues like these will eventually be less commonplace.

Cross-platform support

One of the greatest benefits (if not the greatest) from a management standpoint is the built-in cross-platform support that occurs automatically when PowerShell and PowerShell Core are used. The reason for this is very easy to comprehend: They’re the same codebase! This means that cmdlets integrated into both shells will work seamlessly between one or other.

This cross-platform support means that scripts created and currently in use that work in PowerShell v5.1 will work identically as it would in PowerShell v6.0 and vice-versa. This is, in my opinion, a huge boon for IT pros that have already committed to the learning curve of learning the PowerShell language and implemented it into their administrative management processes for their existing fleet of devices enterprise-wide without having to edit or modify scripts before, during, or after the transition.

PowerShell Core and PowerShell: Major takeaways

• PowerShell Core is the new, open-sourced version of PowerShell that offers support for managing Linux, macOS, and Windows clients.
• PowerShell now comes in two flavors: PowerShell (5.1) and PowerShell Core (6.0).
• .NET Framework is the dependency for PowerShell for Windows-only support, while PowerShell Core is dependent on .NET Core runtime for cross-platform support.
• Organizations transitioning to PowerShell Core should be aware of modules and cmdlets not being available initially due to foundational differences in the code.
• PowerShell 5.1 will only receive stability updates, as needed, to fix critical bugs. PowerShell Core 6.0 will have on-going development, including new features moving forward.