To follow this recipe, you'll need a Windows machine with at least Windows Server 2008 R2 or Windows 7. If this machine isn't connected to the internet, you'll need a way of transferring the installer to the machine.

Please perform the following steps:

Using the standard MSI installer methods, PowerShell Core will be installed for your system in the 64 bit Program Files directory by default. It won't replace Windows PowerShell but will simply coexist peacefully and include the most recent updates to PowerShell.

If left on the default settings, an event manifest will be registered on the system, enabling an event log for PowerShell Core. The log file will be placed at %SystemRoot%\System32\Winevt\Logs\PowerShellCore%4Operational.evtx and can be found in the Applications and Services Logs.

By default, no remoting configuration will be made. We'll talk about remoting in Chapter 8, Running Remote Commands and Understanding Just Enough Administration, where you'll enable PowerShell remoting for a system.

Besides the installer that you can download and install manually or through any software deployment solution, you can also use Chocolatey. Chocolatey is a NuGet package source for binary packages and can be used to bootstrap software on a system.

The following steps will install Chocolatey and PowerShell Core on a Windows system. These steps require using Windows PowerShell for the initial process:

Set-ExecutionPolicy Bypass -Scope Process -Force
iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))

If you're so inclined, compiling the code from scratch is of course also an option. Simply follow the guidelines laid out in the GitHub repository to do so:

# Clone the repository
git clone https://github.com/powershell/powershell

Set-Location -Path .\powershell
Import-Module ./build.psm1

# Ensure you have the latest version of .NET Core and other necessary components
Start-PSBootStrap

# Start the build process
Start-PSBuild

# Either run PowerShell directly...
& $(Get-PSOutput)

# ...or copy it to your favorite location (here: Program Files on Windows, necessary access rights required)
$source = Split-Path -Path $(Get-PSOutput) -Parent
$target = "$env:ProgramFiles\PowerShell\$(Get-PSVersion)"
Copy-Item -Path $source -Recurse -Destination $target

In order to follow the recipe, you'll need any Linux distribution (even the Windows Subsystem for Linux) that's preferably connected to the internet and can download packages. In the recipe, I'm using CentOS and Ubuntu to show some very different approaches.

At the time of writing, the recipe was correct. However, check whether it still applies on the official installation page for your operating system, for example, https://docs.microsoft.com/en-us/powershell/scripting/setup/installing-powershell-core-on-linux.

On CentOS 7.x, perform the following steps:

curl https://packages.microsoft.com/config/rhel/7/prod.repo | sudo tee /etc/yum.repos.d/microsoft.repo.

On Ubuntu 18.10, perform the following steps:

The steps to install PowerShell on other distributions are fairly similar as long as you can use your distribution's package management system, such as rpm or dpkg.

Usually, the installation instructions for Linux require the registration of a package repository that's maintained by Microsoft and used to publish PowerShell Core. The repository settings include the URL, a reference to the GPG public key, and the status of the repository.

On Linux, binary packages are usually compiled using a makefile on the running OS and then, for example, linked or copied to one of the binary paths. The best example for this is probably Gentoo, where compiling your kernel and all components, libraries, and software is actually required. With RPM and DEB packages, developers can better resolve dependencies and include all necessary instructions to install a binary package or compile a source package.

With binary packages, the component is compiled for a specific architecture with general compilation flags set. While this won't allow the user to fine-tune every part of the installation, it'll provide the benefit of an easier deployment.

PowerShell comes pre-built in, for example, an RPM package for different OS architectures. By using the package management provider of the distribution, you ensure that all necessary dependencies are installed alongside the package itself.

With Ubuntu 18.10, PowerShell is available as a Snap package in the Ubuntu Software store. This allows a more user-friendly installation of PowerShell that doesn't require the command line at all—apart from using PowerShell, of course.

There're many different flavors of Linux—there is macOS, Windows, and probably other platforms to come. Stay up-to-date by having a look at the official installation instructions at https://github.com/powershell/powershell.

In addition to traditional installation methods, you can also build your entire PowerShell from scratch.

In order to follow this recipe, you should have completed the installation of PowerShell Core for your operating system.

Let's perform the following steps:

PowerShell works with commands like any other shell environment. Native PowerShell commands are called cmdlets. Unlike commands from other shells, PowerShell cmdlets should only serve one purpose and fulfill this purpose only. As always, there're exceptions to the rule. In some cases, command-line switches, called switch parameters, can be used to toggle additional functionality.

The first example, Get-Process, returns (Get) a list of running processes (Process). While the formatted output appears similar to that of the Windows command tasklist, PowerShell doesn't merely return text, but .NET objects.

Our second example, Get-Date, returns the current date and time as a .NET object again. In .NET, time is calculated with ticks, which are 100 nanosecond-intervals starting at 0001-01-01 00:00:00. The output is formatted depending on your operating system's culture and can be changed on demand.

The third example has you filter the output with PowerShell, which is extremely easy compared to Windows and Linux alike. Especially the endless possibilities of working with text in Linux make this a striking example. The ps command doesn't allow much filtering, so you need to rely on tools such as awk to process the text that is returned. This simple task without PowerShell requires knowledge of text processing and filtering with different tools.

The last cmdlet, Stop-Computer, demonstrates a very common parameter with many cmdlets called WhatIf. This parameter allows you to simply try a cmdlet before actually doing anything. This is an excellent way to test changes for general correctness, for example, before modifying your 10.000 Active Directory user accounts:

There's plenty more to do and see in PowerShell—part of which will be covered in this book. Try to follow the upcoming recipes as well to find out about cmdlet discovery, the flow between cmdlets in the pipeline, and much more.

In order to follow this recipe, you should have completed the installation of PowerShell Core for your operating system.

Please perform the following steps:

The help system of PowerShell Core can be used to update help files from the internet or from a CIFS share. Without updated help content, the help system always displays the name and syntax of a cmdlet as well as detailed parameter help for all parameters of a cmdlet.

In order to update help for modules on the local system, Update-Help will examine all modules in the PSModulePathenvironmental variable in order to find all modules that have the HelpInfoUriproperty set. It'll try to resolve the URI, which should point to a browsable website where it will then look for an XML file called <ModuleName>_<ModuleGuid>_HelpInfo.xml. Inside this XML file, the location of a cabinet file (*.cab) is stored, which will then be used to download the actual content.

With the new Scope parameter introduced in PowerShell Core, all help content will be placed in the personal user folder, for example, C:\Users\<UserName>\Documents\PowerShell, instead of a system-wide folder that would require administrative privileges, for example, C:\Program Files\PowerShell.

The Update-Helpcmdlet will only download new content once per day if the cmdlet is called. In order to download the content more frequently, you can use the Force parameter.

Help content can also be hosted on-premises by using the Save-Helpcmdlet and distributing the content. On Windows systems, a group policy setting can be found that can control the default path for Update-Help as well. This setting is in Administrative Templates | Windows Components | System | Windows PowerShell. This setting is only valid for Windows PowerShell. Regardless of the edition, the Update-Helpcmdlet supports the SourcePath parameter to specify from where the help content will be downloaded.

In order to provide your own help content properly, have a look at the PowerShell module, PlatyPS. This module makes it very easy to generate help content for your own modules, package it to the correct format, and much more.

PlatyPS supports markdown help, enabling you to write help content in a very easy way that feels more natural than creating large and complex MAML files.

In order to follow this recipe, you should have completed the installation of PowerShell Core for your operating system.

Please perform the following steps:

PowerShell and its incredibly flexible system are easily discovered with the help of Get-Command. Even for a seasoned PowerShell expert, Get-Command is invaluable as it works on any system, doesn't need additional content, and will save you precious time. Additionally, nobody is able to just know all existing cmdlets—sometimes, you just need to have a short look at the syntax.

Aliases are a part of PowerShell as well as cmdlets. Sometimes, an alias is introduced when the name of a cmdlet changes in order maintain backward compatibility to some degree. Other aliases are simply created to make working interactively faster or to ease the migration from another scripting language such as the aliases, dir and ls.

By inspecting module manifests and module definitions, Get-Command is able to discover the exported cmdlets of a module that make up the available cmdlets on a system. Additionally, the PATH environmental variable is used to discover external applications such as executables, libraries, and text files.

The output of Get-Command can simply be filtered with wildcards in order to discover cmdlets that have a certain purpose, for example, *Process will list all cmdlets that have something to do with processes.

One parameter that you should always use is the Syntax parameter. Reading the cmdlet syntax is one of the easiest ways to determine how the cmdlet can be used, what its mandatory parameters are, and what its parameter values should look like.

Even if you're an advanced PowerShell user, Get-Command can help you. Just have a look at the amount of data you can access for each command by using Format-List. We'll later learn about Get-Member as well:

# Discover more about a cmdlet with Format-List
Get-Command New-Item | Format-List -Property *

# Examine additional properties that might be helpful
$cmd = Get-Command New-Item

# Where does the cmdlet's help content come from?
$cmd.HelpUri

# Quickly jump to the location of a cmdlet's module
Set-Location -Path $cmd.Module.ModuleBase

# How many parameters does a cmdlet have including the common parameters?
$cmd.Parameters.Count

# Discovering the data of a parameter, in this case realizing that
# New-Item allows empty strings or $null to be passed to the Name parameter
$cmd.Parameters.Name

Look at the following screenshot of how the output looks:

In order to follow this recipe, you should have completed the installation of PowerShell Core for your operating system.

Please perform the following steps:

Native PowerShell cmdlets should all follow the exact same syntax: verb-noun. The verb indicates the action and the noun indicates the recipient of that action. Whether it is a cmdlet such as New-Item or Get-Process, the syntax always follows the same principle.

With all of its different parameters used, a full cmdlet call might look like the following example:

Get-ChildItem $home -Filter *.txt -File

Get-ChildItem is the name of the cmdlet. $home is the value of a so-called positional parameter, Path. -Filter uses the parameter name, and *.txt is the value provided for that parameter. -File is something called a switch parameter, which resembles a command-line switch.

In order to follow this recipe, you should have completed the installation of PowerShell Core for your operating system. Some cmdlets are Windows-specific and require a Windows operating system.

Please perform the following steps:

PowerShell provides access to several different data sources by means of the Get cmdlets. After retrieving the data, PowerShell wraps it into an object model to allow you to store, display, filter, and process the data.

The data sources can be anything from services, event logs, and files to functions and variables. Every item that's retrieved is called an object and will have different properties and methods, which we will see later on.

Just explore Get-Command -Verb Get to find all read-only cmdlets and simply have a look at what the return values are. There's no harm in trying!

On your way to building a perpetuum mobile? Make PowerShell execute all Get cmdlets for some fun:

$ErrorActionPreference = 'SilentlyContinue'
Get-Command -Verb Get | ForEach-Object { & $_ }

The ampersand operator will invoke an expression. By iterating over each Get cmdlet that is returned by Get-Command, we try to read everything we can get our hands on. Please be aware that this will take some time.

In order to follow this recipe, you should have completed the installation of PowerShell Core for your operating system. You should prepare a virtual machine for testing purposes since the cmdlets used in this recipe will inadvertently change your system configuration. 

Please perform the following steps:

There're many verbs in PowerShell that indicate changes such as New, Set, and Remove. Many of those cmdlets also return objects for the data that's altered or created. If one of those parameters doesn't provide output such as Stop-Process, you can try using the PassThru parameter if it is available. It usually means that objects will be returned.

In the recipe, you can see the usual flow between different cmdlets. The file can be created, modified, and removed using the pipeline and cmdlets related to each other. In Chapter 2, Reading and Writing Output, we'll see how pipeline input is usually processed.

With the new parameter, &, you can start a background job, much like the forking parameter on Linux. The job results can be collected later as well.

There're countless cmdlets that change a running system, some of which we will see in this book. Be sure to have a look at the PowerShell repository on GitHub and the documentation on https://docs.microsoft.com/en-us/ to get all available information before ruining your weekend or your colleague's on-call shift.

In order to follow this recipe, you should have completed the installation of PowerShell Core for your operating system.

Please perform the following steps:

Each time a new PowerShell session is started, a bunch of variables is registered and filled. You can always rely on those variables to exist and be present in your scripts. Many of those variables contain preferences for cmdlets, formatting, and output.

In the following chapters, there'll be more. We'll continue using the built-in variables for different purposes.