Microsoft PowerShell has been made open source with additional support for Linux and macOS to manage multiple operating system environments from an integrated console.
In an effort to increase the use of PowerShell (PS) in cross-platform organizations such as those that see IT in charge of managing Linux and macOS clients in addition to Windows devices, Microsoft has developed PS in an open source project. PowerShell has gone from being an exclusive Windows administration tool to an application that can be installed in various types of OS to extend the administration functions to all compatible environments.
The address change has not produced any, but there are two instances of PS available for use. Depending on the use case, administrators will find themselves using the previous version (5.1) used exclusively by and for Windows devices, and based on the .NET Framework. Administrators responsible for managing Unix-based operating systems or those who wish to keep abreast of the latest version of PS will find that PowerShell Core (PSC), which is based on the new runtime of .NET Core, will be the way to continue starting with version 6.0.
Just to clarify, PSC 6.0 is available for all versions of supported OS types. This also includes Windows clients, with the most recent version next to the previous version installed natively in modern versions of the Windows operating system. That said, Microsoft has already made it clear that the future of PS development will be directly aimed at PSC, not the previous version of PowerShell 5.1.
SEE: PowerShell scripts: Seven tips to reduce errors (Free PDF) (TechRepublic)
With all these radical changes in place, there are some advantages and disadvantages that you will certainly find during use daily. Next, I will cover some of the most common scenarios that IT might face and how to solve them during the transition. The first one will be juggling with several versions, since the first will receive regularly scheduled updates, including new functions, while the second will only receive updates related to the correction of critical errors, as necessary.
An important difference between PowerShell and PSC, users will notice at the outset that the number of available cmdlets is currently (as of this writing) twice for PS than for PSC. This comes down to nothing more than Microsoft that chooses not to include a number of cmdlets that are not compatible with products on all lines.
For example, Microsoft's Active Directory (AD) service that allows companies to centrally manage users, groups and computer objects is not found natively in PSC. While this eliminates access to ready-to-use AD management functions for PSC users, those who require the ability to administer can simply import the module to obtain the missing functionality.
While the number of compatible cmdlets will grow logically proportionally As the use of PSC increases (and finally exceeds the native use of PowerShell), IT departments can be better served by testing PSC limits and developing workflows alternatives before making change a requirement.
SEE: 20 PowerShell cmdlets that you can use instead of CMD commands (free PDF) (TechRepublic)
Like cmdlets Missing earlier, PS and PSC get their cmdlet support from the modules: collections of available / compatible commands that can be used inside the shell. Due to the change from the .NET Framework to the .NET Core, the modules must be rewritten to take full advantage of the newer runtimes that form the basis of the PSC. Until developers take this action, certain modules will simply not be available; This means that users who rely on a specific set of commands, or rather scripts that take advantage of particular cmdlets, may be cold for now.
The guide Here is quite simple: test the scripts used by your organization before diving into the waters of the PSC. As Microsoft makes updates to PSC and third-party developers migrate their workflows to support PSC more completely, problems like these will eventually become less common.
One of the greatest benefits (if not the best) from the point of view of administration is the built-in multiplatform support that occurs automatically when using PowerShell and PowerShell Core. The reason for this is very easy to understand: they are the same code base! This means that the cmdlets integrated in both shells will work smoothly between one or the other.
This cross-platform support means that scripts created and currently in use that work in PowerShell v5.1 will work identically as you would in PowerShell v6.0 and vice versa. This is, in my opinion, a great blessing for IT professionals who have already committed to the learning curve of learning the PowerShell language and have implemented it in their administrative management processes for their existing fleet of devices throughout the company. without having to edit or modify scripts before, during or after the transition.
- PowerShell Core is the new open source 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 PowerShell dependency for Windows exclusive support, while PowerShell Core depends on the .NET Core runtime for cross-platform support.
- Organizations the transition to PowerShell Core should be aware that modules and cmdlets are not initially available due to fundamental differences in the code.
- PowerShell 5.1 will only receive stability updates, as necessary, to correct critical errors. PowerShell Core 6.0 will have continuous development, which will include new features in the future.