About Help

Choose a topic from the list on the left or search for a specific topic. Choose a topic from the list or search for a specific topic.
Cmdlets  Providers





    Provides a brief introduction to the Windows  
    PowerShell Workflow feature. 


    Windows PowerShell Workflow brings the benefits of 
    Windows Workflow Foundation to Windows PowerShell  
    by enabling you to write and run workflows in Windows 
    Windows PowerShell Workflow is introduced in Windows 
    PowerShell 3.0. 
    For detailed information about Windows PowerShell  
    Workflow, see "Introducing Windows PowerShell Workflow" 
    in the TechNet Library at  
    and "Writing a Windows PowerShell Workflow" in the MSDN 
    Library at http://go.microsoft.com/fwlink/?LinkID=246399.  


    Workflows are commands that consist of an ordered sequence of  
    related activities. Typically, they run for an extended period  
    of time, gathering data from and making changes to hundreds of 
    computers, often in heterogeneous environments. 
    Workflows can be written in XAML, the language used in Windows 
    Workflow Foundation, or in the Windows PowerShell language.  
    Workflows are typically packaged in modules and include help 
    Workflows are critical in an IT environment because they can 
    survive reboots and recover automatically from common failures.  
    You can disconnect and reconnect from sessions and computers 
    running workflows without interrupting workflow processing,  
    and suspend and resume workflows transparently without data  
    loss. Each activity in a workflow can be logged and audited 
    for reference. Workflow can run as jobs and can be scheduled  
    by using the Scheduled Jobs feature of Windows PowerShell. 
    The state and data in a workflow is saved or "persisted" at 
    the beginning and end of the workflow and at points that you 
    specify. Workflow persistence points work like database snapshots 
    or program checkpoints to protect the workflow from  the effects 
    of interruptions and failures. In the case of a failure from 
    which the workflow cannot recover, you can use  the persisted 
    data and resume from the last persistence point, instead of 
    rerunning an extensive workflow from the beginning. 


    A Windows PowerShell Workflow configuration consists of  
    the following elements. 
    -- A client computer, which runs the workflow. 
    -- A workflow session (PSSession) on the client computer or 
       on a remote computer. 
    -- Managed nodes, the target computers that are affected by 
       the workflow activities.  
      The workflow session is not required, but is recommended.  
      PSSessions can take advantage of the robust recovery and 
      Disconnected Sessions features of Windows PowerShell to  
      recover disconnected workflow sessions. 
    Because the client computer and the computer on  which the 
    workflow session runs can be managed nodes, you can run a 
    workflow on a single computer that fulfills all roles.     
    The client computer and the computer on which the workflow  
    session runs must be running Windows PowerShell 3.0. All 
    eligible systems are supported, including the Server Core 
    installation options of Windows Server operating systems. 
    To run workflows that include cmdlets, the managed nodes  
    must have Windows PowerShell 2.0 or later. Managed nodes 
    do not require Windows PowerShell unless the workflow 
    include cmdlets. You can run workflows that include 
    Windows Management Instrumentation (WMI) and Common Information 
    Model (CIM) commands on computers that do not have Windows 
    For more information about system requirements and configuration, 
    see "Introducing Windows PowerShell Workflow" in the TechNet Library 
    at http://go.microsoft.com/fwlink/?LinkID=252592. 


    Workflows are typically packaged in modules. To import the module 
    that includes a workflow, use any command in the module or use the 
    Import-Module cmdlets. Modules are imported automatically on first 
    use of any command in the module. 
    To find the workflows in modules installed on your computer, use the  
    CommandType parameter of the Get-Command cmdlet. 
      PS C:\> Get-Command -CommandType Workflow 


    To run a workflow, use the following procedure. 
       1. On the client computer, start Windows PowerShell with the 
          Run as administrator option. 
            PS C:\> Start-Process PowerShell -Verb RunAs 
          This step is not required when the managed node is 
          the local computer. 
       2. Enable Windows PowerShell remoting on the computer on which  
          the workflow session runs and on managed nodes affected by 
          workflows that include cmdlets.  
          You need to do this step only once on each participating 
          This step is required only when running workflows that  
          include cmdlets. You do not need to enable remoting on 
          the client computer (unless the workflows session runs 
          on the client computer) or on any managed nodes that are 
          running Windows PowerShell 3.0.  
          To enable remoting, use the Enable-PSRemoting cmdlet. 
            PS C:\> Enable-PSRemoting -Force 
          You can also enable remoting by using the "Turn on Script 
          Execution" Group Policy setting. For more information, see 
          (http://go.microsoft.com/fwlink/?LinkID=251696) and 
       3. Create the workflow session. Use the New-PSWorkflowSession  
          or New-PSSession cmdlets.  
          The New-PSWorkflowSession cmdlet starts a session that 
          uses the built-in Microsoft.PowerShell.Workflow session  
          configuration on the destination computer. This session  
          configuration includes scripts, type and formatting files,  
          and options that are designed for workflows. 
          On the local computer:           
            PS C:\> $ws = New-PSWorkflowSession 
          On a remote computer:           
            PS C:\> $ws = New-PSWorkflowSession -ComputerName Server01 ` 
                    -Credential Domain01\Admin01 
          Or, use the New-PSSession cmdlet. Use the ConfigurationName parameter 
          to specify the Microsoft.PowerShell.Workflow session configuration. 
          This command is equivalent to using the New-PSWorkflowSession cmdlet.  
          If you are a member of the Administrators group on the workflow 
          session computer, you can also use the New-PSWorkflowExecutionOption 
          cmdlet to create custom option settings for the workflow session 
          configuration and use the Set-PSSessionConfiguration cmdlet to  
          change the session configuration. 
            PS C:\> $sto = New-PSWorkflowExecutionOption -MaxConnectedSessions 150 
            PS C:\> Invoke-Command -ComputerName Server01 ` 
                     {Set-PSSessionConfiguration Microsoft.PowerShell.Workflow ` 
                      -SessionTypeOption $Using:sto} 
            PS C:\> $ws = New-PSWorkflowSession -ComputerName Server01 ` 
                    -Credential Domain01\Admin01           
       4. Run the workflow in the workflow session. To specify the  
          names of the managed nodes (target computers), use the  
          PSComputerName workflow common parameter. 
          The following commands run the Test-Workflow workflow. 
          Where the managed node is the computer that hosts:           
          the workflow session: 
            PS C:\> Invoke-Command -Session $ws {Test-Workflow} 
          Where the managed nodes are remote computers. 
            PS C:\> Invoke-Command -Session $ws{ 
                       Test-Workflow -PSComputerName Server01, Server02 } 
          The following commands run the Test-Workflow workflow on hundreds 
          of computers. The first command gets the computer names from a text 
          files and saves them in the $Servers variable on the local computer. 
          The second command uses the Using scope modifier to indicate that 
          the $Servers variable is defined in the local session. 
            PS C:\> $Servers = Get-Content Servers.txt 
            PS C:\> Invoke-Command -Session $ws {Test-Workflow -PSComputerName $Using:Servers } 
          For more information about the Using scope modifier, see  
          about_Remote_Variables at http://go.microsoft.com/fwlink/?LinkID=252653 


    The workflow common parameters are a set of parameters that 
    Windows PowerShell adds automatically to all workflows.  
    Windows PowerShell also adds the cmdlet common parameters to 
    all workflows, even if the workflow do not use the CmdletBinding 
    For example, the following very simple workflow defines no 
    parameters. However, when you run the workflow, it has both 
    the CommonParameters and WorkflowCommonParameters. 
      PS C:\> workflow Test-Workflow {Get-Process} 
      PS C:\> Get-Command Test-Workflow -Syntax 
      Test-Workflow [<WorkflowCommonParameters>] [<CommonParameters>] 
    The workflow common parameters include several parameters that 
    are essential to running workflows. For example, the PSComputerName 
    common parameter specifies the managed nodes that the workflow affects. 
      PS C:\> Invoke-Command -Session $ws ` 
               {Test-Workflow -PSComputerName Server01, Server02} 
    The PSPersist workflow common parameter determines when workflow 
    data is persisted. It enables you to add persistence point between 
    activities to workflows that do not define persistence points. 
     PS C:\> Invoke-Command -Session $ws ` 
               {Test-Workflow -PSComputerName Server01, Server02 -PSPersist:$True} 
    Other workflow common parameters let you specify the  
    characteristics of the remote connection to the managed nodes.  
    Their names and functionality are very similar to the parameters 
    of remoting cmdlets, including Invoke-Command. 
      PS C:\> Invoke-Command -Session $ws ` 
               {Test-Workflow -PSComputerName Server01, Server02 -PSPort 443} 
    Take care to distinguish the remoting parameters that define the  
    connection for the workflow session from the PS-prefixed workflow 
    common parameters that define the connection to the managed nodes. 
      PS C:\> $ws = New-PSSession -ComputerName Server01 ` 
              -ConfigurationName Microsoft.PowerShell.Workflow 
      PS C:\> Invoke-Command -Session $ws ` 
               {Test-Workflow -PSComputerName Server01, Server02 ` 
              -PSConfigurationName Microsoft.PowerShell.Workflow} 
    Some workflow common parameters are unique to workflows, such  
    as the PSParameterCollection parameter that lets you specify 
    different workflow common parameter values for different remote 
    For a list and description of the workflow common parameters, 
    see about_WorkflowCommonParameters at   


"Getting Started with Windows PowerShell Workflow"
"Writing a Windows PowerShell Workflow"