Appendix

Applies To: Windows 8 Release Preview, Windows Server 2012

[This topic is pre-release documentation and is subject to change in future releases. Blank topics are included as placeholders.]

In this Appendix

The following supplementary information can help you author and run workflows in Windows PowerShell.

Reserved parameter names

The following are reserved parameter names that cannot be inside either Windows PowerShell script-based workflows, or workflow XAML files.

<Transport>://<ComputerName>:<Port>/<ApplicationName>

List of non-supported Windows Workflow Foundation activities

Windows PowerShell Workflow supports most of the built-in Windows Workflow Foundation activities. For a complete list of built-in Windows Workflow Foundation activities, see the .NET Framework 4 Built-In Activity Library (https://go.microsoft.com/fwlink/?LinkId=251933).

The following is the small subset of Windows Workflow Foundation activities that Windows PowerShell workflows do not support. These activities are excluded because they typically require host level support such as WCF messaging or transactions that are not supported by the Windows PowerShell Workflow runtime.

List of cmdlets that can only run locally

Windows PowerShell Workflow inherently supports running cmdlet actions remotely, however, there is a set of utility and object manipulation cmdlets that is always invoked locally. This is done to improve performance. These cmdlets can be remotely run using the InlineScript activity. For more information, see Running isolated blocks of Windows PowerShell script.

Cmdlets that do not implement activities

Windows PowerShell workflows include corresponding activities for most of the default cmdlets however there is a small set of cmdlets for which it does not make sense. These cmdlets are listed in the following table. To invoke the following cmdlets in a workflow, you have to wrap them in InlineScript. For more information, see Running isolated blocks of Windows PowerShell script.

Windows PowerShell workflow endpoint

Apart from the default remoting endpoint (Microsoft.PowerShell), Windows PowerShell ships with a workflow endpoint: Microsoft.PowerShell.Workflow. Unlike the default Windows PowerShell remoting endpoint, the Windows PowerShell Workflow endpoint runs with -UseSharedProcess set to true. This setting allows the user to connect to the Windows PowerShell Workflow endpoint from different PSSessions and still connect to the same process running on the server machine.

Creating a session to the workflow endpoint ensures that the Windows PowerShell Workflow functionality is loaded.

Get-PSSessionConfiguration –Name *Workflow

Additionally, the Windows PowerShell Workflow endpoint has a very limited set of commands that are necessary for running and managing the workflow.

Invoke-Command -ComputerName . –ConfigurationName Microsoft.PowerShell.Workflow -ScriptBlock {get-command}

Creating a session to the default workflow endpoint

Creating a connection to the Windows PowerShell Workflow endpoint is as easy as calling New-PSWorkflowSession. This command has all the remoting related parameters that allows you to connect to remote Windows PowerShell Workflow sessions. Alternatively, one can use the full configuration name –Microsoft.PowerShell.Workflow with the New-PSSession cmdlet as well.

$wfsession = New-PSWorkflowSession 
$wfsession2 = New-PSSession -ConfigurationName Microsoft.PowerShell.Workflow

Creating a custom workflow endpoint

Creating a custom Windows PowerShell Workflow endpoint is the same as creating a new Windows PowerShell remoting endpoint: you can still use the Register/Set-PSSessionConfiguration cmdlets for this purpose. You will notice that among other new parameters, these cmdlets have -SessionType and -SessionTypeOption parameters. The SessionType parameter lets you specify the type of endpoint you want to create. The SessionTypeOption parameter takes an object for specifying additional options for the endpoint. For workflow-type endpoints, you can specify the various workflow related quotas (such as number of running workflows, allowed workflow activities, and list of activities that run in-process.) via the object produced by the New-PSWorkflowExecutionOption cmdlet.