Configuring Your Workflow Environment

Artigo
08/31/2016

Applies To: Windows Server 2012, Windows Server 2012 R2

Now that you understand the definition and benefits of workflows in Windows PowerShell, as described in Getting Started with Windows PowerShell Workflow, you are ready to set up your environment to run workflows.

This topic contains the following sections.

Supported operating systems and architectures

Windows PowerShell Workflow runs on any system on which Windows PowerShell 3.0 or Windows PowerShell 4.0 is available. For a complete list of Windows PowerShell requirements, see Windows PowerShell System Requirements.

Download and install Windows Management Framework 3.0 or Windows Management Framework 4.0 on managed nodes if your workflows contain Common Information model (CIM) activities. CIM is an extensible, object-oriented data model that contains information about different parts of an enterprise. For more information about CIM, see Common Information Model on MSDN. You can also install Windows Management Framework (WMF) on managed nodes that are running Windows Server 2008 R2 with Service Pack 1, Windows 7 with Service Pack 1, or Windows Management Framework 3.0 on Windows Server 2008 with Service Pack 2 to run workflows on those computers, but this is not required unless your workflows contain CIM activities.

Workflow configurations

Workflow operations involve the following three nodes. The nodes can all be located on the same computer, or distributed across multiple computers.

The node on which the workflow is running, sometimes called the workflow server.
The node on which an administrator is managing the workflow or viewing workflow status. This is sometimes called the client.
Roles, features, settings, or physical or virtual devices on which the workflow actions are carried out. These are called managed nodes.

Computers that are running any of the supported operating systems and architectures can function as any part of a workflow configuration. The following diagram shows the possible setup configurations for workflows.

Configuration 1: The server, client, and managed nodes are running on separate computers. Note that the command flow is from client, through server, to managed nodes. In this scenario, the client node must be running Windows PowerShell 2.0 to communicate with the computer that is running the workflow, but Windows PowerShell 3.0 or Windows PowerShell 4.0 is not required on the client.
Configuration 2: The workflow server and client nodes are both running on the same computer. The versions of Windows PowerShell and .NET Framework that are running on that computer satisfy the highest requirements, those for the computer that is running the workflow. Managed nodes are running on one or more remote devices.
Configuration 3: The workflow server, client, and managed nodes are running on the same computer or device. The versions of Windows PowerShell and .NET Framework that are running on that computer satisfy the highest requirements, those for the workflow server.

Download locations for .NET Framework and Windows PowerShell

For information about download locations for required versions of .NET Framework and Windows PowerShell, see Windows PowerShell System Requirements.

Prepare computers to run workflows

Procedures for setting up your computers to run workflows are available in this section.

To prepare for remote management

On the computer from which you are running and managing the workflow, start Windows PowerShell with the Run as administrator option as described in Starting Windows PowerShell. Alternatively, you can run a new Windows PowerShell session as administrator by running the following command in a session that is already open.

Start-Process PowerShell -Verb RunAs
Do one of the following to enable Windows PowerShell remote management on participating computers, such as the workflow server and managed nodes.

Note

While Windows PowerShell remote management must be enabled on the server node, you do not need to enable it on managed nodes unless your workflow requires it. Neither Windows PowerShell nor WMF is required on managed nodes, unless your workflow contains CIM activities.
- On a workflow server that is running Windows Server 2012 R2 or Windows Server 2012, Windows PowerShell remote management is enabled by default. Go on to the next step.
- On a workflow server that is running Windows 8.1 or Windows 8, right-click the Windows PowerShell tile, and then in the app bar, click Run as administrator. Type Enable-PSRemoting, and then press Enter. Press Y to confirm that you want to enable remote management.
- On a workflow server that is running Windows Server 2008 R2 or Windows 7, Windows Management Framework 4.0 or Windows Management Framework 3.0 must be installed first. After WMF is installed, click Start, point to All Programs, click Accessories, click Windows PowerShell, right-click the Windows PowerShell shortcut, and then click Run as Administrator. Type Enable-PSRemoting, and then press Enter. Press Y to confirm that you want to enable remote management.
- On a workflow server that is running Windows Server 2008, Windows Management Framework 3.0 must be installed first. After WMF 3.0 is installed, open a Windows PowerShell session with elevated user rights. To do this, click Start, click All Programs, open the Windows PowerShell folder, right-click the Windows PowerShell shortcut, and then click Run as administrator. Type Enable-PSRemoting, and then press Enter. Press Y to confirm that you want to enable remote management.

Workflow session configurations

A session configuration is a group of settings on the local computer that define the access rights and commands that are available for the Windows PowerShell sessions that are created when remote or local users connect to Windows PowerShell on a computer.

The Enable-PSRemoting command that you run on the workflow server in the preceding section creates default session configurations, including the recommended and default session configuration for workflows. We recommend using the default session configuration because it provides the following benefits to your workflows automatically.

Performance optimization. Default settings of the New-PSWorkflowExecutionOption cmdlet, such as activity time-out periods and maximum allowed processes per activity, are designed to help constrain resource usage and improve workflow performance.
SharedHost mode. SharedHost mode allows users to start a workflow on one computer, log off, log on to another computer, and reconnect to the workflow. The workflow session configuration uses the same process for a user across different computers, as long as the user is connecting to the same session configuration, and is logged on to the new computer with the same access rights as the user had on the first computer.
Automatic multi-device support. The workflow session configuration is optimized for running workflows on multiple devices, offering the following benefits.
- Workflow jobs are automatically created for each target device.
- Windows PowerShell Workflow automatically throttles the number of simultaneous workflows and remote operations that can run on a target device.
- Manages lifecycle of remote connections – creation, reuse, and deletion

You can create a custom session configuration for your organization’s needs, which might differ from the workflow session configuration. You can add your workflows to your custom session configuration, so they are available automatically when a user connects to the session configuration.

For more information about session configurations, see about_Session_Configurations.

The following procedure shows how to create a custom session configuration named Microsoft.PowerShell.MySession.

To create custom session configurations

Start a Windows PowerShell session with elevated user rights (Run as Administrator). The procedure To prepare for remote management in this topic describes how to do this.
We recommend increasing the default Windows Remote Management (WinRM) memory quota to 1 GB in sessions that are using the session configuration for workflows. To do this, run the following command to create a session configuration option object, and then save the object in the $MoreMemory variable. The variable is used in the next step.

$MoreMemory = New-PSSessionConfigurationOption -MaxMemoryPerShellMB 1000

Note

The value shown in the preceding command is an example. You can use lower values; the minimum requirement is 400 MB.
To add the new session configuration, run the Register-PSSessionConfiguration cmdlet as shown in the following script sample.
1. Set the value of the SessionConfigurationType parameter to Workflow.
2. Set the value of the ModulePath parameter to the location of the modules that contain your workflows.
3. Set the value of the SessionConfigurationOption parameter to the $MoreMemory variable that you created in the preceding step.
```
Register-PSSessionConfiguration -Name Microsoft.PowerShell.MySession `
-SessionConfigurationType Workflow `
-ModulePath $pshome\modules\MyModule`
-SessionConfigurationOption $MoreMemory
```

Partilhar via