Most of the examples shown in this book are executed with Windows PowerShell 5.1. You can work with this latest Windows PowerShell version either by just using a Windows 10 machine, or by upgrading the PowerShell version of your current Windows environment. This is described later in this chapter, in the Windows PowerShell 5.1 section.

The following operating systems will be supported: Windows 7 Service Pack 1, Windows 8.1, Windows 10, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, and Windows Server 2016.

The code for the book can be found at https://github.com/PacktPublishing/Learn-PowerShell-Core-6.0. It includes a folder for each chapter and additional installation instructions.

Some examples use PowerShell Core 6. You can download and install the latest PowerShell Core version at https://github.com/PowerShell/PowerShell/releases.

Let's start with some historical background. In the year 2002, Jeffrey Snover, the inventor of PowerShell itself, described the Monad Manifesto. Its first public beta release was on June 17, 2005. Monad was described as the next-generation platform for administrative automation, and it leveraged the .NET platform, providing excellent value propositions for application developers, application testers, power users, administrators, and Graphical User Interface (GUI) users:

• Administrators should program faster and more easily—this was provided by having a unified parser and taking over many standard tasks
• Monad should be object-oriented and always accept and return .NET Framework objects and not just text
• It should be possible to execute scripts remotely on many computers
• It should be possible to use GUIs

Afterwards, on April 25, 2006, Monad was renamed Windows PowerShell, and Release Candidate 1 of PowerShell version 1 was released at the same time.

On November 14, 2006, it was announced at TechEd Barcelona, Release Candidate 2 of PowerShell version 1 was finally released to the web for Windows XP SP2, Windows Server 2003 SP1, and Windows Vista.

Version 1.0 is obsolete today.

Starting with version 2, PowerShell was shipped with Microsoft operating systems. Therefore, it is integrated in Windows 7 and Windows Server 2008 R2, and was released for Windows XP with Service Pack 3, Windows Server 2003 with Service Pack 2, and Windows Vista with Service Pack 1.

PowerShell version 2 brought the first substantial change to the PowerShell API, and around 240 additional cmdlets. The creation of new cmdlets was simplified; they could also be written as scripts and combined to modules. PowerShell remoting was made available using WS-Management, and the updateable help, as well as job scheduling, has been introduced.

Starting with this version also, its reputation improved and its number of users increased. One reason for this is the release of the PowerShell Integrated Scripting Environment (ISE), a graphical interface with built-in console:

It is still commonly used today, and we will take a closer look at the available and recommended tools out there in the next chapter.

The next big step was achieved with PowerShell version 3, which is integrated with Windows 8 and Windows Server 2012. It is also available for Windows 7 SP1, Windows Server 2008 SP1, and Windows Server 2008 R2 SP1. It was shipped with Windows Management Framework 3.

Big advantages of version 3 were improved code-writing techniques, such as IntelliSense, and automatic module detection. In addition, the number of cmdlets increased again, and PowerShell continued to gain more popularity. It also introduced major component upgrades and, very notably, the PSReadline integration feature, which enabled Jason Shirk's PSReadline module, which has been part of the core user experience since PS5. The AST was made available, allowing highly complex language parsing and paving the way for several major modules, including the PSScriptAnalyzer module.

The next version, PowerShell version 4.0, is integrated with Windows 8.1 and Windows Server 2012 R2, and has also been made available for Windows 7 SP1, Windows Server 2008 R2 SP1, and Windows Server 2012. Its biggest achievements are the Desired State Configuration, and some scripting enhancements, such as the new syntaxes for Where and ForEach.

Not long ago, PowerShell version 5 was released to the web on February 24, 2016, and is integrated with Windows Management Framework 5.0. The support of Chocolatey's repository-based package management was accomplished with new integrated cmdlets. To appeal to developers and administrators alike, classes such as .NET classes were added as well. Additionally, many improvements on DSC were introduced, such as the authoring of DSC resources using PowerShell classes. This version is a major milestone, with various new features and language extensions.

And lastly, PowerShell version 5.1 was released on August 2, 2016, and is integrated with the Windows 10 Anniversary Update and Windows Server 2016, and is also shipped within the Windows Management Framework 5.1. There is also a UserVoice open for this version, where feedback can be shared: https://windowsserver.uservoice.com/forums/301869-powershell.

Up until now, the versions are all primarily targeted to the Windows operating system, and therefore are called Windows PowerShell. But today, PowerShell is moving in a completely different direction, which started with making PowerShell open source (https://azure.microsoft.com/en-us/blog/powershell-is-open-sourced-and-is-available-on-linux/) on August 18, 2016. It was a substantial change, not only making the code open source, but also making PowerShell platform-independent and allowing the community to collaborate on and be involved in upcoming new features.

Shortly after, Windows Server 2016 was released, which brought us the Nano Server. The PowerShell version has also been divided in terms of the editions. Until then, every PowerShell release had been an edition of the Desktop, which can be retrieved (explained in Chapter 3, Basic Coding Techniques) from the $PSVersionTable variable (available after PowerShell version 2):

Starting with Windows Server 2016 Nano Server, a new type of PSEdition was introduced, which is called Core and is bundled with .NET Core. This version can also be found in Windows IoT operating systems.

On November 17, 2017, the Release Candidate of PowerShell Core 6 was released, followed by the official General Availability (GA) on January 10, 2018. This was the start of a completely new direction, which is indicated by the added word, Core. Every PowerShell version 6.0 or higher will only be available with the PSEdition Core.

Due to some security issues, Windows PowerShell 2.0 was deprecated with the Windows 10 Fall Creators Update. We will cover the reasons and consequences in depth in Chapter 7, Understanding PowerShell Security.

Another big milestone was achieved on September 26, 2017, when PowerShell in Azure Cloud Shell (Preview) was made publicly available.

Currently, the development for PowerShell Core 6.1 and the official release for Azure Cloud Shell is ongoing, while very little work is now put into Windows PowerShell. Therefore, it is very unlikely that we will see new versions of Windows PowerShell, though the PowerShell Team has announced that security fixes will continue to be delivered. This brings us to the topic of the technical background and the roadmap and aims of PowerShell in the future.

To provide the best overview, we will focus on the most valuable information. First, you need to know about the two different versions and the differences between them.

There are two editions of PowerShell:

• Desktop Edition: This version uses the full .NET CLR. It is primarily used in Windows Desktop and Core Server environments.
• Core Edition: This version uses .NET Core. It is primarily used in Windows IoT and Nano Server environments.

The $PSVersionTable variable holds the information for the currently used PSVersion and PSEdition.

The same terminology can be observed with Windows PowerShell versus PowerShell Core:

• Windows PowerShell is built on top of the .NET Framework:
  • Versions 1 to 5.1
  • Available on Windows and Windows Server only
  • Delivered as a built-in component and via WMF
  • Built on top of the .NET Framework (also known as FullCLR)
  • $PSVersionTable.PSEdition is set to Desktop
• PowerShell Core is built on top of .NET Core:
  • Version 6++ (and Nano Server/Windows 10 IoT)
  • Available on Windows, macOS, and Linux
  • Delivered via MSI, ZIP, or PKG (macOS)
  • Built on top of the current .NET Core version (also known as CoreCLR)
  • $PSVersionTable.PSEdition is set to Core

PowerShell Core is available in Windows Server 2016 Nano Server and Windows 10 IoT, but also in PowerShell Core 6 and newer versions.

This information brings us to the following overview:

Windows PowerShell 5.1 is the latest, and probably last, version of Windows PowerShell, and is therefore of special interest in Windows environments. All operating systems with Windows 10 or Windows Server 2016 and higher come with the latest PowerShell version integrated. But, as you know, in many enterprise environments, you will always find machines with legacy operating systems, which may come with completely different versions.

One of the most important recommendations is to always use the most recent versions. PowerShell is backward-compatible, and therefore you should install Windows PowerShell 5.1 on all your machines, barring those known to be incompatible. This can be achieved with the previously described Windows Management Framework.

Because Windows PowerShell is built on top of the .NET Framework, you will need to have .NET version 4.5.2 installed on all computers before applying WMF 5.1 to them. There have been some issues with previous Windows Management Framework versions, which needed the consecutive installation of all of them, but these have been fixed in the latest version (5.1). So, having .NET Framework 4.5.2 installed on the computers is the only dependency you must fulfill.

Supported Operating Systems:

• Windows Server 2012 R2
• Windows Server 2012
• Windows Server 2008 R2 SP1
• Windows 8.1
• Windows 7 SP1

Windows Management Framework 5.1 includes updates to Windows PowerShell, Windows PowerShell Desired State Configuration (DSC), Windows Remote Management (WinRM), and Windows Management Instrumentation (WMI).

There are different WMF 5.1 packages available for different operating systems:

If you have a distribution system in place, such as System Center Configuration Manager, you can easily deploy WMF 5.1 to all your machines. Alternatively, you can also accomplish this task through PowerShell remoting and command-line execution.

Before PowerShell and PowerShell Core 6 were made open source, we had the big PowerShell monolith in place, which was developed and maintained by the PowerShell Team. But there had been a lot of problems with this situation:

• Lack of agility/velocity: There was a legacy control in place, and it was a painful and manual release process with nightly builds tied to Windows having long-running test suites.
• Lack of visibility: The code reviews were done via email, and the issues and working items were stored in many different places.
• Difficult manual feedback process: The Connect/UserVoice items had to be manually triaged into internal work items, and the engineers were completely disconnected from feedback loops.

Therefore, the idea was to set up better engineering processes with rapid, independent builds and fast, transparent tests with automated packing for every platform. In addition, the collaboration needed to be improved in terms of the visibility of the work for all interested parties (first and third parties). A clear project management and release process was needed to provide visibility into current and future releases, as well as a governance system for approving changes and additions to PowerShell.

This all led to PowerShell being made open source, which additionally brought the following benefits with it:

• Enabled the community to directly help in finding and fixing bugs
• Enabled more direct and powerful feedback from the community
• Improved visibility into team priorities
• Increased credibility from the Linux community

PowerShell was completely restructured and published on GitHub; it can be found at https://github.com/PowerShell/PowerShell:

And new documentation was added at https://docs.microsoft.com/en-us/powershell/:

You can just clone the repository with the following Git command:

git clone --recursive https://github.com/PowerShell/PowerShell.git

There is also a contribution guideline available, which can be found at https://github.com/PowerShell/PowerShell/blob/master/.github/CONTRIBUTING.md. It contains some information about working with Git and how to create pull requests.

To be even more connected with the community, the PowerShell Team has set up regular open PowerShell Core Community Calls. In these calls, RFCs, feature requests, and contentious bugs are discussed. The team will also provide a quick update about the status of the project and the direction it is headed in. At the following link, you will also find the previously recorded community calls and an ICS file for your calendar application: https://github.com/PowerShell/PowerShell-RFC/tree/master/CommunityCall.

There have been three primary goals for PowerShell Core 6:

When we examine each of these goals, it becomes clear how PowerShell Core came into being and why it is a great management tool for any infrastructure:

• Ubiquity describes the platform-independency to work with PowerShell on Windows, Linux, and macOS operating systems. This is necessary because heterogenous environments are today's norm, and they are important to developers and IT professionals.
• Cloud refers to the intention of being built for cloud scenarios, because IT is moving towards Azure, REST APIs (Swagger/OpenAPI), and other public clouds. For this, major improvements have been made to the Invoke-WebRequest, Invoke-RestMethod, and ConvertFrom-Json cmdlets. There is a collaboration with the Azure PowerShell team to support PowerShell Core. Third-party vendors, such as VMware and AWS, are also working to support PowerShell Core.
• Community refers to being open source, contributing directly to the product, and allowing the retrieval of customer feedback directly to the engineering team. The current Request for Comments (RFCs)—asking for feedback for the current roadmap/new features or breaking changes, milestones, projects, and issues—should always be transparent and publicly available. This means that we have pull requests against code, tests, and documentation. In addition, issues from the community are dynamically reprioritized, which can also be discussed in the PowerShell Core Community Call. These calls are free to join for everybody, and you can just raise your voice and discuss your feedback directly with the engineers.

As you know, PowerShell Core 6 and all following PowerShell versions depend on .NET Core. The first version of .NET Core was released in 2016:

On August 14, 2017, .NET Core 2 was released, on which PowerShell Core 6.0 is based. It implements .NET Standard 2.0 with the following conditions (https://github.com/dotnet/standard):

• .NET Standard defines a set of APIs that have to be implemented by all .NET platforms, as shown in the following diagram
• .NET Standard 2.0 is implemented by .NET Core
• .NET Standard 2.0 includes a compatibility shim for .NET Framework binaries
• .NET Standard will replace Portable Class Libraries (PCLs)

You can see the .NET Standard API definition in the .NET/standard repository on GitHub.

In the following diagram, you can see this implementation for all .NET platforms:

Though there were no substantial changes made to the language itself in the .NET Standard 2.0 Release, the increase in API size—and hence, the tools available—more than justified the increased footprint:

.NET Standard 2.0 includes the most important APIs and brings almost all .NET Framework 4.6.1 APIs to .NET Core 2.0:

PowerShell Core will be supported by Microsoft's Modern Lifecycle Policy.

The Modern Lifecycle Policy covers products and services that are serviced and supported continuously. Under this policy, the product or service remains in support if the following criteria are met:

• Customers must stay current as per the servicing and system requirements published for the product or service
• Customers must be licensed to use the product or service
• Microsoft must currently offer support for the product or service

Because of the changed underlying .NET Framework, compatibility may also have changed. One big benefit here is that .NET Standard 2.0 is implemented with .NET Core, which provides a binary compatibility with existing .NET assemblies. Because many PowerShell cmdlets and modules depend on them, these continue to work with .NET Core.

Many modules shipped as part of Windows haven't been explicitly ported to .NET Core, but may also continue working with the underlying .NET Standard and the implementations of CDXML. The CDXML files define the mappings between PowerShell cmdlets, and CIM class operations, or methods. Everything that is implemented with a CDXML should keep working.

But there are also some known exceptions:

• Workflows
• Snap-ins
• DSC resources (for now, moves to DSC Core)
• WMI v1 cmdlets (Get-WmiObject, Invoke-WmiMethod, and so on)
• A handful of other missing cmdlets

After the first public release of PowerShell Core, we are currently seeing the community and the product groups port their modules and cmdlets to PowerShell Core. It will take some time before most of the existing cmdlets continue to work on PowerShell Core.

Due to some naming collisions in Linux environments, the executable of PowerShell Core has been renamed from PowerShell.exe to pwsh.exe.

With the focus of being platform-independent, some changes to the remoting techniques had to be made. As you can see in the following diagram, PowerShell Core supports PowerShell Remoting (PSRP) over WSMan with Basic authentication on macOS and Linux, and with NTLM-based authentication on Linux. Kerberos-based authentication is not yet supported.

PowerShell Core also supports PSRP over SSH on all platforms (Windows, macOS, and Linux). Since this feature is still actively being developed, it is not recommended to use it in production. We will look at how to establish remote connections in Chapter 3, Basic Coding Techniques, and Chapter 4, Advanced Coding Techniques:

OpenSSH can be installed on Windows 10 1709 and later via the optional features:

Azure Cloud Shell can be found in the Azure Portal, as shown in the following screenshot:

Afterwards, the Shell will open either in Bash or PowerShell. The connection will look like this and opens in the Azure drive (Azure:):

The PowerShell version that is used for PowerShell in Azure Cloud Shell currently is version 5.1 in the Desktop Edition, which is hosted in a Docker container. We will elaborate on that in Chapter 14, Working with Azure which is dedicated to PowerShell and Azure:

The PowerShell experience builds upon the benefits of Azure Cloud Shell, such as the following:

• Secure automatic authentication from virtually anywhere
• Choice of shell experience that best suits the way you work
• Common tools and programming languages included that are updated and maintained by Microsoft
• Azure File Storage, which allows access to an Azure file share in a storage account for a small monthly fee associated with data storage. File Storage is mapped as the cloud drive and can be used to exchange data.

The PowerShell experience adds the following:

• The new PSDrive for Azure (Azure:)—this provides easier searching capabilities within Azure resources
• Dedicated and built-in commands
• Data persistence via cloud drive
• Custom modules
• User profile
• Rich tools support
• Azure PowerShell
• Nano and VIM (with PS IntelliSense)
• Git and sqlcmd

For more information on PowerShell features, refer to https://aka.ms/cloudshell/PowerShell-Docs.

The first big achievement here is the new Azure drive. Here, you can just work directly on Azure and retrieve your Azure resources, as shown in this screenshot:

Feedback on Azure Cloud Shell is tracked on UserVoice via issues and feature requests: https://feedback.azure.com/forums/598699-azure-cloud-shell.

The future of PowerShell lies in PowerShell Core 6 and newer, with the focus to work platform-independently and together with the community on the new versions. We will see a transitioning phase in the upcoming years, where most of the existing modules are ported from Windows PowerShell to PowerShell Core.

In addition, we will see a lot of work being done within Azure Cloud Shell, providing more automation to work with Azure resources from anywhere. Windows PowerShell, though, will not gain additional features, but will keep being a built-in, supported component of Windows 10 and Windows Server 2016.

In this chapter, you learned about the different PowerShell versions, what the differences are, and how PowerShell is evolving. With this knowledge, you know which PowerShell versions you should use for different scenarios, such as Windows PowerShell 5.1, PowerShell Core 6 and newer, or PowerShell in Azure Cloud Shell.

In the next chapter, we will look at the tools that the different PowerShell versions can be used with and compare the features of both Visual Studio Code, as well as the Integrated Scripting Environment.

1. What is the latest PowerShell version in Windows environments?
2. How can you retrieve the version number and the PSEdition?
3. What is the difference between the Core edition and Desktop edition?
4. How can you deploy the newest Windows PowerShell version to your systems?
5. How can you install OpenSSH on a Windows Desktop?

6. What is the main difference between Windows PowerShell 5.1 and PowerShell Core 6?
7. What are the main goals of PowerShell Core 6?
8. How can you use PowerShell in Azure Cloud Shell?

Please see the following for further reading relating to this chapter:

• Install and Configure WMF 5.1: https://docs.microsoft.com/en-us/powershell/wmf/5.1/install-configure
• Azure Cloud Shell: https://azure.microsoft.com/en-us/features/cloud-shell/