PowerShell 3.0 Advanced Administration Handbook

Because objects play such an important role in Windows PowerShell, there are several native commands designed to work with arbitrary object types. The most important one is the Get-Member command.

The simplest technique for analyzing the objects that a command returns is to pipe the output of the command to the Get-Member cmdlet. The Get-Member cmdlet shows the formal name of the object type and a complete listing of its members. Sometimes the number of returned elements can be overwhelming. For example, a service object can have over 100 members.

To see all the members of a service object and page the output, please type the following:

PS > Get-Service | Get-Member | Out-Host -Paging

The output from this command will look something like this:

The Get-Member command lets you list only members that are properties. There are several forms of properties. The resulting list is still very long, but a bit more methodical, as shown in the following screenshot:

If you need to look at the content outside of Windows PowerShell's default display format, you can do so through the use of the format cmdlets, which can format the output data.

Windows PowerShell's set of cmdlets allows users to control which attributes are displayed for a specific object. All cmdlet names begin with a verb form. The format cmdlets are Format-Wide, Format-List, Format-Table, and Format-Custom.

Each format cmdlet has default properties. These properties will be used if you do not specify a particular attribute to display. Each cmdlet also uses the same parameter name and attribute, but you need to specify which attribute has to appear. As the Format-Wide cmdlet reveals a single attribute display only, its property parameters require only a single value, but the characteristic parameters of Format-List and Format-Table will accept an attribute name list.

With the Format-Wide cmdlet, you can format the output as a table listing one property only. This makes it useful for displaying simple lists that show only one element per line.

The Format-List cmdlet is used for formatting the output as a list of properties, each on a new line. The Format-Table cmdlet is used for tabular output.

Windows PowerShell provides several cmdlets that let you control the data's output directly. These cmdlets share two important characteristics that we will discuss in this section.

By default, Windows PowerShell sends data to the host window, which is just what the Out-Host cmdlet does. The Out-Host cmdlet is primarily used for paging data. For example, the following command uses Out-Host to page the output:

The Out-Null cmdlet is designed to immediately discard any input it receives. This is useful for discarding unnecessary data that you get as a side effect of running a command. When typing the following command, you will not get anything back from the command:

Get-Command | Out-Null

The Out-Null cmdlet does not discard an error output. For example, if you enter Get-Command Is-NotACommand | Out-Null, a message is displayed informing you that Windows PowerShell does not recognize Is-NotACommand. This is shown in the following screenshot:

You can send the output to a file instead of the console window by using the Out-File cmdlet. The following command line sends a list of processes to the C:\tmp\processlist.txt file:

PS > Get-Process | Out-File -FilePath C:\tmp\processlist.txt

You can store the output of a pipeline or a command in a variable for later use, or to work with it in more detail. Variables in PowerShell allow users to store the output of something that may be used later. A variable's name starts with a dollar sign ($) and can be followed by any alphanumeric character or the underscore in its name. You can create a variable and assign it a value in the same step. Windows PowerShell only creates the variable if it does not exist, otherwise it assigns the specified value to the existing variable, as shown in the following screenshot:

You can store any pipeline or command result in a variable to use it later. If that result is simple data, such as a number or a string, then the variable contains simple data. If the command generates rich text data, such as the objects that stand for system services from the Get-Service cmdlet, then the variable contains the list of rich data. If the command, such as a former executable, generates plain text, then the variable contains plain text.

Variables are stored in the memory; if you no longer need the variables that store a large amount of data, you should assign the $null value to those variables, and then PowerShell can release the memory for you.

PowerShell offers several ways to access environment variables. To list all the environment variables you can list the children of the env drive, as shown in the following screenshot:

To get an environment variable, prefix its name with $env (such as $env: variablename). An example is shown in the following screenshot:

PowerShell provides access to the environment variable through its environment provider. The provider lets you work with data storage, such as registration, environment variables, alias, and certificate, as you will visit the filesystem. Get environment variables to use their provider path; supply env: or environment:: by using the Get-ChildItem cmdlet.

Windows Management Instrumentation (WMI) is a core technology for Windows system administration because it exposes a wide range of information in a uniform manner. As we all know, WMI is an infrastructure that supports the CIM model and Microsoft-specific extensions of CIM.

The WMI infrastructure ships in Windows 2000, which was difficult to write and use. In PowerShell 3.0, Microsoft introduced several new cmdlets, which are used for operating CIM. With these cmdlets, not only can we manage servers, but we can also manipulate all the heterogeneous devices necessary to make these servers together into a comprehensive and coherent computing platform. In today's world, cloud computing is a very important technology. Generalized cloud computing requires standard-based management. This is the reason why Microsoft paid so much attention to standard-based management in Windows Server 2012, which is expected to be a Cloud OS. We are going to discuss how to use Get-CimClass to access CIM objects and then how to use CIM objects to do specific things.

Listing CIM classes

The first problem of using CIM is trying to find out what can be done with CIM. CIM classes describe the resources that can be managed. There are dozens of CIM classes, some of which contain several properties.

Get-CimClass resolves this problem by making CIM discoverable. You can get a list of the CIM classes available on the local computer using the –ClassName parameter with a keyword and a wildcard character. An example is shown in the following screenshot:

Get-CimClass uses the root/cimv2 namespace by default. If you want to specify another WMI namespace, use the Namespace parameter and specify the namespace's path, as shown in the following screenshot:

Displaying details of the CIM classes

If you are familiar with WMI cmdlets from PowerShell 2.0, you will find learning new CIM cmdlets easy. If you already know the ClassName value of a WMI class, you can use it to get information. For example, one of the WMI classes commonly used for searching for information about a process is Win32_Process. The WMI cmdlet needs to work with ClassName and NameSpace, and the CIM cmdlet follows the same pattern. Refer to the following screenshot:

Although we are showing all of the parameters, the command can be expressed in a more succinct way. The ComputerName parameter is not necessary when connecting to the local system. We display it to demonstrate the most general case and remind you about the parameter. The Namespace parameter defaults to root/cimv2, and can be ignored as well. Finally, most cmdlets allow you to ignore the name of common parameters. With Get-WmiObject, if no name is specified for the first parameter, Windows PowerShell treats it as the Class parameter.

You will also notice that in some places, the script using the WMI cmdlet can't be simply changed to the CIM cmdlet by changing the cmdlet name. This is shown in the following example:

We can see that the parameters of the two cmdlets are completely different, and the result displayed is not the same.

There are software components with .NET Framework and COM interfaces that enable users to perform many system administration tasks. Windows PowerShell lets you use these components, so you are not limited to the tasks that can be performed by using cmdlets.

We can create an instance of an object using its default constructor. This can be done using the New-Object cmdlet with the classname as its only parameter:

Many cmdlets (such as Get-Process and Get-ChildItem) generate live .NET objects that represent tangible processes, files, and directories. However, PowerShell supports much more of the .NET Framework than just the objects that its cmdlets produce.

PowerShell allows the user to contrast data, and then make decisions with the comparison operators. It allows making decisions based on the result of logical operators to contrast data blocks.

Examples for comparison operators are -eq, -ne, -ge, -gt, -lt, -le, -like, -notlike, -match, -notmatch, -contains, -notcontains, -is, -isnot, -in, -notin, and so on.

Examples for logical operators are -and, -or, -xor, -not, -shl, -shr, and so on.

By default, the PowerShell comparison operator is not case sensitive. For all operators that are case sensitive, the -i prefix makes the comparison case insensitive, and the -c prefix executes case-sensitive comparisons.

In PowerShell you can change the flow of execution of the script by using the conditional statements. The following code snippet shows us an example:

if (condition)
{
statement block
}
elseif (condition)
{
statement block
}
else
{
statement block
}

If the condition calculates to $true, PowerShell implements the block you supply. Then, it continues with the rest of the if/else statement list. PowerShell needs matching parentheses in the block even if the block contains only one statement.

If the condition calculates to $false, PowerShell implements the statements under elseif until a condition matches. If there is a match, PowerShell executes the block-related conditions, and then continues to implement the rest of the if/else statement list. For example:

$textForMatch = Read-Host "Input some text"
$matchType = Read-Host "Supply Simple or Regex matching?"
$pattern = Read-Host "Match pattern"
if ($matchType -eq "Simple")
{
$textForMatch -like $pattern
}
elseif($matchType -eq "Regex")
{
$textForMatch -match $pattern
}
else
{
Write-Host "Match type must be Simple or Regex"
}

If none of the conditions calculate to $true, PowerShell executes the statement block related to the else clauses, and then continues to implement till the end of the if/else statement list.

A switch statement is usually used to control several conditions that have a clear value. It requires the value of the conditions to be an integer or a character. The conditions used in a switch statement are called cases. Using the value of case, the control program will jump to the matching case, and will keep running till the statement exits or meets the break statement. Usually, we can use the default clause to include other exceptions. If the conditions of the switch statement are all false, the control program will jump to execute the default clause. If the default clause is omitted, it will execute the next statement directly.

The following code snippet shows a switch statement:

switch options expression
{
comparison value { statement block }
-or
{ comparison expression } { statement block }
(…)
default { statement block }
}

When PowerShell evaluates a switch statement, it calculates the expression for the statement in the switch body. If the expression is a list of values, PowerShell calculates each entry against the statement in the switch body.

The {comparison expression} statement for you deals with the current input items, which are stored in the $_ variable, in any one of the script blocks. When it is dealing with a {comparison expression} statement, PowerShell executes a related statement block only when the {comparison expression} value is $true.

When dealing with a switch statement, PowerShell tries matching the current input object for each statement in the switch body even if there are already one or more matches. PowerShell exits a switch statement after it finds a match or if it encounters a break statement, which is the final statement of the block of statements.

A PowerShell loop statement lets you execute a group of statements several times.

:loop_label for(initialization; condition; increment)
{
statement block
}

for($counter = 0; $counter -lt 10; $counter++)
{
Write-Host "Processing item $counter"
}

:loop_label foreach(variable in expression)
{
statement block
}

$handleSum = 0;
foreach($process in Get-Process |
Where-Object {$_.Handles -gt 600})
{
$handleSum += $process.Handles
}
$handleSum

Nested loops

Sometimes, loops may be nested within each other. However, if you are working with nested loops, how do you break and continue to work? They will always affect the inner loop, which is the loop that they were called from. However, you can also label loops and then submit the label to continue or break if you want to exit or skip the outer loops.

The next example nests two foreach loops. The first (outer) loop cycles through a field with three WMI classnames. The second (inner) loop runs through all instances of the respective WMI classes. This allows you to output all instances of all the three WMI classes. The inner loop checks whether the name of the current instance begins with "a"; if not, the inner loop will then invoke continue to skip all instances not beginning with "a". The result is a list of all services, user accounts, and running processes that begin with "a":

As expected, the continue statement in the inner loop has had an effect on the inner loop where the statement was contained. But how would you change the code if you'd like to see only the first element of all services, user accounts, and processes that begin with "a"? Actually, you would do almost the exact same thing, except that now continue would need to have an effect on the outer loop. Once an element was found that begins with "a", the outer loop would continue with the next WMI class:

Defining a script piece for writing is very simple; it is just surrounding several program statements within curly brackets. This statement will not be executed immediately; on the contrary, a new script block object will be created and returned. In order to facilitate calling the script block after that, we may allocate a script block to a variable. The following screenshot shows a sample script block:

We can call a script block using the invoke operator (&). The following screenshot shows how we can use this operator with a variable when this variable contains a block:

Block compile objects can be passed in and executed multiple times. They are reference objects and we can assign a variable to a block just to make the variable point to the block quoted in memory.

As we have seen so far, none of the blocks have executed an action or an interaction with the outside world in complex ways. Now that I have already mentioned the expression, we can see the operation from the point of view of the block, which can be used in an expression. The operation parameters evaluate the return value. This return value from the script block simply asks you to output an object that will neither be a cmdlet nor another expression. The following is an example of a return value:

As you can see from the last command in the previous example, the return number cannot be used directly in a conditional expression; you must make use of parentheses. If you don't, the plus (+) operator will be mistaken as the right-hand operand and an error, as shown in the following screenshot, will be raised:

Note that the output of an object does not terminate the execution of the block, and the rest of the statement outputs after the object are still implemented. For example, you can print a string to the console window to return a value, and the retuning value does not contain other output statements, as shown in the following screenshot:

The $numberPrint block returns a value and writes a string to the console. Looking at the anonymous block invocation, you may think that the block returns or prints two variables, but this in fact is not the case. Look at the assignment operation in the following screenshot. The $result variable is assigned number 5; this will return the real value and the string will be printed to the console.

We can use a return statement to end the execution and exit the script block. It terminates the execution and gives the return value. Changing the block before using return will prevent the Write-Host command from executing:

You can use the return statement to simply quit a block and stop execution. It doesn't ask you to provide a value. If you omit the value, the script block will only exit and not return a value. In this case, the block returns a value to the caller only if there is an output before the return statement.

A useful scripting block will need a way to get parameters from the outside world so that it can be executed with different data. The parameters can be passed and retrieved according to their position. A piece of scripting block will always have a predefined $args variable through automatic settings, and it will contain a group of provided parameters. We can use it to create and output a custom message to the user giving a first name and a family name as shown in the following screenshot:

Though the indexed access to parameters is a good technology, which can be used in many programming languages, unfortunately, it's too easy to make a mistake once the parameters grow in quantity. It is best to be used in a very simple scene where you cannot go wrong. In an advanced scenario, when you don't know the number of parameters while defining your script block, a mistake is likely to occur. We did not talk much about simple and advanced scenarios and in most cases we make use of named parameters. These are announced in the script block using the param keyword. Here is how the previous example switches to named parameters:

Note that usually the first letter of a parameter name will suffice. In cases where multiple parameter names start with the same character sequence, you will have to provide the initial characters that uniquely identify the parameter.

We can set default parameter values, which can contain any expression. We can exploit this fact to implement mandatory parameters. Mandatory parameters are parameters that absolutely have to be provided when calling the script block. To do that, we add an expression that throws an exception when evaluated. In that way, the exception will be thrown if the caller fails to provide the parameter. Based on this consideration in the $greeting block, the $firstName parameter is essential:

Now, you can follow the $(throw "wrong information") model to realize forced parameters.

The typical PowerShell script is a text file, which can be created using all kinds of tools. By default, these documents carry the .ps1 file extension. You can create them using Notepad, but it is best if you use a more powerful tool such as a programmer's text editor with syntax highlighting and intelligent word completion, for example Notepad++, ISE, and PowerGUI.

Notepad++ is a free source code editor and is a Notepad replacement that supports several languages. With a plugin that supports PowerShell, it gives you full syntax highlighting for PowerShell.

The Windows PowerShell Integrated Scripting Environment (ISE) is a host application for Windows PowerShell. Powershell v3 comes with a pretty good ISE built-in. In Windows PowerShell ISE, you can run commands and write, test, and debug scripts in a single Windows-based graphic user interface with multiline editing, tab completion, syntax coloring, selective execution, context-sensitive help, and support for right-to-left languages.

PowerGUI is a graphical user interface and script editor for Microsoft Windows PowerShell. You can find it at www.PowerGUI.org. It is the freeware tool that the administrators need for speeding up PowerShell adoption, and harnessing the power of PowerShell to efficiently manage their entire Windows environment. PowerGUI simplifies management with an intuitive user console.

You can even create scripts from the PowerShell console using the string and the Set-Content cmdlet. The following screenshot shows how you can create your first script:

As you can see, the hello-world.ps1 file is a pure text file; we can check its contents using the Get-Content cmdlet.

Passing parameters

The PowerShell script files also allow users to pass parameters for initialization. Script files have the $args variable set up with the parameters passed at the time of their invocation. The following is example code for using $args to get parameters:

$firstName = $args[0]
$lastName = $args[1]
Write-Host "Hello, $firstName $lastName"

We can save the code as Get-HelloArgs.ps1, and then execute it as follows:

Of course, we also can use the param keyword for accepting a parameter. The following is the example code:

param ($firstName, $lastName)
Write-Host "Hello, $firstName $lastName"

We can save the code as Get-HelloParam.ps1 and execute it as follows:

Return values

A parameter is, most of the time, a one-way communication mechanism, and will only transfer data from the environment of the script. We need to be able to return values from our script. PowerShell provides a good way to output the return value from a script and we should make use of this method.

An object can be bound to a variable or outputted to a pipeline for the next command. We can use it to generate a pile of objects from our script and output them. The following screenshot gives us a script that gives an output of three temporary filenames:

As you can see, this value can be assigned to a variable or can be passed down the line as a foreach command. A return statement will output an object and terminate execution.

Sooner or later, you will be responsible for creating a bigger, more complex solution using PowerShell as its implementation language. Earlier when you wrote your own code, there were cases where each piece of code was stuck in a separate file and you could not find a way through the code. This was not a pleasant situation as you must be aware that your options are separated from the script code into several files to make things easier to manage. In addition to this, fast navigation to the correct location of the correct file with less code makes it more reusable. This is a very common and useful function that lets you move out of the first client code to another file, and is then included in many documents. In practice, I usually use a folder in my system path that contains useful scripts so that I can easily include useful features in any of the scripts and start working on the production code in no time.

Script libraries are normal files that contain useful functions. They are ordinary PowerShell scripts that do not execute an action—they just define several functions and let the library client code call them to do the real job.

Including or importing a script library in a script file is similar to executing it. It is a good programming practice to ensure that the scripting library should contain any executable code function definition.

The Windows PowerShell Web Access gateway is the name of the server where PowerShell Web Access is installed and configured. This gateway is the bridge between the end user and the managed servers, so once you connect to the web interface of the PowerShell Web Access for writing your cmdlets and scripts, the gateway will be responsible for executing them on the right server. In the real world, the PSWA gateway is placed in the DMZ (demilitarized zone) and the web interface is published to the Internet so that you can easily connect to your server anytime and anywhere.

This part will show how to install and configure Windows PowerShell Web Access easily in a few steps.

IntelliSense is the name of Microsoft's implementation for the autocomplete technique. Autocomplete is one of the most famous features in today's applications, and everyone using a computer is using autocomplete. Simply, autocomplete is a feature embedded in most of the search engines that gives you a list of suggestions once you start typing on your keyboard. IntelliSense in PowerShell not only shows you a suggestion for words but also for commands, parameters, variables, and even UNC paths on your computer. The following screenshot shows us an example:

Code snippet is the name used to describe a piece of reusable code, and it is usually used to speed up the process of writing code especially when using a repetitive code and syntax. PowerShell 3.0 ISE introduced the snippets feature to make the script-writing process easier. By using snippets you do not have to know the syntax for each command and function. For example, the ForEach code snippet inserts the syntax of the ForEach loop and you just have to modify your variables. The following screenshot shows us a similar example:

New-IseSnippet -Title RestartSQLServerServices -Description "Restart all SQL Server Services" -Text "Restart-Service -Name *SQL*"  

Join-Path (Split-Path $profile.CurrentUserCurrentHost) "Snippets"

Add-on tools are Windows Presentation Foundation (WPF) controls that can be added to PowerShell ISE to add extra features and functionalities to the ISE, such as spelling checker and script-printing features. One of the most popular add-ons is Microsoft Script Explorer. The Microsoft Script Explorer enables you to find scripts, snippets, and modules in the script repositories such as TechNet Script Center and other community repositories such as PoshCode, and also it can search for scripts in local and network filesystems.

PowerShell ISE 3.0 automatically saves any runspace and script file that is open , so in case a failure happens in your ISE or your operating system restarts suddenly, ISE will restore all your runspaces once you open it again. It is similar to "restore session" in Internet Explorer.

PowerShell remoting is now similar to a remote desktop session; you can disconnect your session without interrupting any running process, application, or script, and you can connect later to this session again from the same or a different computer to continue your work.

Remoting in PowerShell 3.0 can be enabled on public networks on the client operating systems such as Windows 7 and Windows 8. In simple terms, we use the SkipNetworkProfileCheck switch with the Enable-PSRemoting or Set-WSMANQuickConfig cmdlets.

The custom session configuration file is a predefined session configuration that includes information about which cmdlets, snippets, modules, and other PowerShell components should be loaded in this session and the configuration that can be used by the user, which gives another edge of security for PowerShell in general and PowerShell remoting specifically.

Writing a PowerShell Workflow is similar to writing a PowerShell function with a little difference. The first difference is using the word "workflow" instead of "function". Also, as in functions, the same definition of parameters using param() can be used with CmdletBinding to add some advanced workflow features. CmdletBinding allows you to add advanced capabilities to your function and workflows, such as adding the –Verbose, –Debug, –whatif, and –confirm parameters to your workflow without implementing them manually. It also defines HelpUri that will be used by the Get-Help cmdlets to get the online help for the workflow or function. The following code snippet shows how we write a PowerShell Workflow:

Workflow Test-Workflow
{
 [CmdletBinding(ConfirmImpact=<String>,DefaultParameterSetName=<String>,
   HelpURI=<URI>,PositionalBinding=<Boolean>)]
  Param([string] <Parameter_Name>)
}

As mentioned earlier, PowerShell Workflows use activities that are similar to cmdlets; the PowerShell team has already implemented all PowerShell core cmdlets as activities, which makes it easier for PowerShell users to use activities and not get confused, except for a set of cmdlets that are excluded from this implementation. Does it mean that the excluded cmdlets cannot be used in a workflow?

No, PowerShell automatically executes them using a special activity called inlineScript. The purpose of this activity is to execute any PowerShell command that is valid in PowerShell but not supported by workflows, such as executing a .ps1 file or calling a dynamic parameter inside a workflow.

PowerShell Workflows can be executed concurrently and sequentially by using the reserved keywords such as Parallel and Sequence. The activities inside the Parallel block will be running concurrently, and activities inside the Sequence block will be running sequentially. ForEach –parallel is a combination of the Sequence and Parallel executions. ForEach –parallel will execute the activities sequentially on the items in the collection concurrently. In other words, if there is a collection of computers where a set of activities such as rename and restart computer are being executed, the activities will be executed in sequence on all computers at the same time. The following script block shows the syntax of using the Parallel and Sequence execution capabilities inside a workflow:

Workflow Test-Workflow
{
  Parallel
{
  <Activity_1>
  <Activity_2>
  <Activity_3>
}

Sequence
{
  <Activity_1>
  <Activity_2>
  <Activity_3>
}

ForEach -parallel ($item in $collection)
{
<Activity_1>
  <Activity_2>
  <Activity_3>
}
}

Parallel execution is useful for running independent activities concurrently, such as starting a process and restarting a service at the same time where each activity is running independently from the other one.

Sequence execution is useful for defining a set of activities to run sequentially inside a Parallel or ForEach –parallel execution.

One of the most interesting features in PowerShell Workflow, and what makes it unique compared to a normal script is the flexibility of controlling the execution; at any point you can interrupt, suspend, or resume the workflow's execution. You can even restart the computer while running the workflow and complete the execution upon startup.

You can suspend the workflow's execution using the Suspend-Workflow activity that will save the execution state, variables, and values in a checkpoint and return the job ID for the suspended workflow, so you can use the job ID as a parameter for the Resume-Job cmdlet to resume the workflow execution again.

In the following example, we will learn how to suspend and resume the workflow execution:

Workflow Test-Workflow
{
  <Activity_1>
  <Activity_2>
Suspend-Workflow
  <Activity_3>
}

You can execute this workflow using the following command:

PS C:\>Test-Workflow

The first two activities will be executed and the workflow will be suspended, and the result of suspend-workflow will be information about the workflow-executed job.

Id  Name  PSJobTypeName  State      HasMoreData  Location  Command  
--  ----  -------------  -----      -----------  --------  -------  
2   Job2  PSWorkflowJob  Suspended  True         localhost  Test-Workflow

In order to resume the workflow again, we will use the Resume-Job cmdlet:

S C:\>Resume-Job –Name Job2

In order to get the results of the activities executed after resuming, in our case Activity 3, we will use the Get-Job and Receive-Job cmdlets:

PS C:\>Get-Job –Name Job2 | Receive-Job

Since PowerShell Workflow is recoverable, you can restart the target computer and smoothly resume the workflow again using the Restart-Computer activity. Simply use the –wait switch with Restart-Computer so that the workflow will wait for the computer to restart and reconnect again before proceeding with the workflow execution.

In the following example, the workflow will restart the targeted computer after executing Activity 1 and Activity 2, and then wait for the computer to boot up again to resume and execute Activity 3. You can also use the -PSConnectionRetryCount and -PSConnectionRetryInterval parameters to specify the connection retries and the interval between each connection retry.

Workflow Test-Workflow
{
  <Activity_1>
  <Activity_2>
  Restart-Computer –Wait –PSConnectionRetryInterval 4 –PSConnectionRetryCount 8
  <Activity_3>
}

In order to maintain these features of PowerShell Workflow, it is a must to implement another feature in workflows, which is "CheckPoint". Checkpoints in PowerShell Workflow take a snapshot of the current state and data, and then save it in the profile of the user who executes this workflow on the hard disk, so on resuming, the workflow will start from the last checkpoint instead of starting from the beginning. PowerShell by default adds checkpoints in the beggining and ending of the workflow. In addition, you can use the -PSPersist switch with any activity to take a checkpoint after completing its execution. Also, you can use the Checkpoint-Workflow activity at any point in your flow to take a checkpoint.