Chapter 1
Setting Up a PowerShell 7 Environment

The first versions of Windows PowerShell were provided via a user-installed download, initially for Windows XP and Windows Server 2008. Today, both Windows Server and Windows 10 come with Windows PowerShell version 5.1-which in this book I'll call simply Windows PowerShell to distinguish it from PowerShell 7 (and the Windows PowerShell Integrated Scripting Environment) installed and available by default. Windows PowerShell comes with a range of commands available for basic administration of Windows.

PowerShell 7 itself does not ship as part of Windows at the time of writing. At some point, the PowerShell team may ship PowerShell 7 as a Windows component, but until that time, you need to download and install it yourself.

The Windows PowerShell Integrated Scripting Environment (ISE) does not support PowerShell 7. IT pros who want a good interactive development environment for PowerShell can use Visual Studio Code (VS Code), a free tool you can also easily download and install. VS Code comes with an array of extensions that provide a much-improved development experience for IT pros (and others).

With earlier versions of PowerShell, the vast majority of commands came bundled into Windows or were added as part of installing an application (such as Exchange Server) or adding a Windows feature to your system. With PowerShell 7, the PowerShell Gallery has become a core source of modules/commands that you can use to perform various administrative tasks. To ensure that you can take advantage of the PowerShell Gallery, you need to be sure that the PowerShellGet module is up to date.

What Is New in PowerShell 7

PowerShell 7 is the latest version of PowerShell. The PowerShell development team released PowerShell 7.0 in March 2020. By the time you read this, the development team is certain to have released newer minor updates. PowerShell 7 has a number of key new features that IT pros can leverage.

If you are familiar with and can use Windows PowerShell to manage your Windows systems, almost all your knowledge is directly transferable to the new environment. Need to get help on a command? Just type Get-Help at the PowerShell command line. The basic architecture of PowerShell remains the same, with many internal changes, significant improvements, and a few breaking issues.

From the perspective of an IT professional with a working knowledge of managing Windows using Windows PowerShell, here are the key changes you can find:

• Redeveloped cmdlets, based on .NET Core and open sourced via GitHub: You can now read and even help to extend any cmdlet in PowerShell 7. This also means that the cmdlets were written to use .NET Core-which has created a few small compatibility issues.
• A robust compatibility layer: You use this to access Windows PowerShell modules that do not directly work on PowerShell 7. This means that all but a small number of Windows PowerShell 5.1 modules are available with and work under PowerShell 7. Chapter 2, "PowerShell 7 Compatibility with Windows PowerShell," describes this compatibility layer in more detail and notes how it works and its limitations as well as providing work-around solutions.
• Significant performance enhancements: In porting the Windows PowerShell modules to PowerShell 7, the development team was able to review the code and deliver performance enhancements. Processing large collections, for example using Foreach, is now a lot faster. The Foreach-Object cmdlet now has a -Parallel switch that allows you to run script blocks in parallel, which can provide substantially shorter run times, especially on larger multiprocessor and multicore servers.
• New PowerShell language operators: There are three new operator sets in PowerShell: the Ternary operator ( a ? b : c), the Pipeline chain operators ( || and &&), and the Null coalescing operators ( ?? and ??=). These operators were implemented in other shells such as Bash or Zsh, and you can now use them in PowerShell 7.
• Simplified error views: Windows PowerShell error messages were excellent and contained a lot of information. But in most cases the rich output was more than you normally need. Error messages in PowerShell 7 are now much more succinct. And when you do need that additional information, you can use Get-Error to retrieve the full details of any error. You can set the $ErrorView variable to NormalView to view the older Windows PowerShell-style error messages or CategoryView to see just the error category.
• Experimental features: The PowerShell team has implemented a raft of new features that are at an experimental stage. You can opt in (or not) to these features. This gives you the opportunity to try new things and provide feedback.
• Automatic new version notification: At the time of writing, there is no support for PowerShell 7 within the Windows Store or via Windows Update. That means you need to manage the updates yourself, and these messages provide timely notification that a newer version of PowerShell exists for you to download.
• Set-Locationnow supports a path of - and +: When you use Set-Location to reset your current working directory, you can use -Path "-" to instruct Set-Location to move to the last folder. Having moved back, you can set location using + to move forward.
• Ability to invoke a DSC resource directly: PowerShell 7 does not support desired state configuration, so no pull/report servers, local configuration manager, and so on. You can, however, manually invoke DSC resources on a given host, which provides a partial solution.

The PowerShell 7 snippets in this book use and demonstrate most of these new features. For more information on any of these features, including use cases and examples, use your favorite search engine as the PowerShell community has produced a significant amount of content that describes the features. You can find numerous higher-level posts, such as the article at https://www.thomasmaurer.ch/2020/03/whats-new-in-powershell-7-check-it-out. There are also more detailed articles that cover specific new features such as tfl09.blogspot.com/2020/03/introduction-and-background-welcome-to.html, for example, which provides details on the new Pipeline Chain and Ternary operators.

Systems Used in This Book and Chapter

This book examines how you can use PowerShell 7 to carry out a wide range of tasks, including setting permissions on a file share, collecting and reporting on performance data, and installing and configuring Active Directory. To demonstrate these and many other tasks, this book uses a set of hosts and two domains: Reskit.Org and Kapoho.Com. You have options as to how you provision these systems.

Server VM Build Scripts

The scripts in this book assume you have a set of servers ready to configure. You could, if you choose, build each computer used in this book based on physical hardware. A simpler alternative is to build the necessary server VMs using Hyper-V using the build scripts you can find at github.com/doctordns/ReskitBuildScripts. This GitHub repository contains a README.MD file (github.com/doctordns/ReskitBuildScripts/blob/master/README.md) that explains how you can use these scripts to build your VM farm.

By way of background, these scripts are used to create VMs for a variety of training courses and other books. You do not need to create all the VMs. In the introduction to each chapter, you discover the specific VMs that the chapter uses.

These build scripts build VMs, but you need to take some care in terms of the order in which you build the VMs, where you store VMs and virtual hard disks, and so on.

The build scripts build VMs with basic networking (one NIC) although you can always add more should you wish. The scripts build the VMs you need for this book using a specific set of network addresses. The document github.com/doctordns/ReskitBuildScripts/blob/master/ReskitNetwork.md shows the details of the network hosts and IP addresses.

VM Internet Access

The VMs (or hosts if you choose to use physical computers) require Internet access. The VMs are all on the 10.10.10.0/24 IPv4 network implemented as an internal Hyper-V network, using an internal Hyper-V virtual switch. There are two broad mechanisms you can use to provide this.

First, you can configure each VM to have a second virtual NIC. You configure this NIC to use an external switch that you bind to your VM host's external NIC. This is a simple solution and can be set up quickly.

Another alternative is to set up a Windows Server VM running Routing and Remote Access. You configure the VM with two NICs (one internal, the other external) and configure routing between the 10.10.10.0/24 subnet used by the VMs in this book and the internet.

Systems in Use for This Chapter

In this chapter, you use PowerShell 7 to manage various networking aspects. The scripts in this chapter make use of one.

• DC1: For the purposes of this chapter, DC1 is just a Windows Server 2019...