Remotely Run a PowerShell Workflow


Summary: Microsoft Scripting Guy, Ed Wilson, talks about running a Windows PowerShell workflow on a remote computer.

Microsoft Scripting Guy, Ed Wilson, is here. This morning it is beautiful outside. I am sitting on the porch sipping a cup of English Breakfast tea. I made a pot this morning, and I added some orange peel, Meyer lemon, and a bit of hibiscus flower to give it a nice tangy flavor.

The Scripting Wife is still at the MVP Summit in Seattle, so I had to head to a local bakery to score some scones for breakfast. I found some really nice cinnamon scones, but they also had cinnamon sugar drizzled over the top—so I had to scratch that junk off. But after I had groomed the scone, it went well with the tea.

Speaking of grooming stuff…

One of the cool things about running a Windows PowerShell workflow through a remote server is that I can access modules that may not be available to my client machine. I can also employ alternate credentials.

In my example today, there are actually four computers. The client machine is C1 and it is the computer from where I run the workflow. I target the domain controller, DC1, to be my workflow server. I do this by creating a PS Workflow Session on the target machine. This is really easy. Because I want to specify alternate credentials when I create the workflow session, I use the –Credential parameter in my command. I store the resultant session in a variable that I call $wfs. Here is the line of script:

$wfs = New-PSWorkflowSession -ComputerName DC1 -Credential Nwtraders\administrator

The domain controller, DC1, is the workflow server. It is the server that uses Windows PowerShell workflow to run commands on remote servers.

I use the Invoke-Command cmdlet, and I specify the session I just created. In my script block, I import two modules. I created the first one yesterday (Workflow-Install-Uninstall.psm1 module). It resides on a server as a shared resource, and therefore, it is easily accessible. When I call Import-Module, I specify the full path to the module.

The second module is ActiveDirectory, and I do not need to import because it will automatically load when I call Get-ADComputer. But because I am loading modules, I may as well load this one. Here is the script:

Invoke-Command -Session $wfs -ScriptBlock {

  Import-Module \\dc1\Share\PoshModules\Workflow-Install-Uninstall-ISE.psm1 -verbose

  Import-module ActiveDirectory}

The two target servers are S1 and S2, but I do not specify the computer names directly. Instead, I find the computer names by using the Get-ADComputer cmdlet from the ActiveDirectory module. It is more efficient to obtain computer names from Active Directory, because the list is always up-to-date, and it avoids a lot of typing.

Because the servers begin with the letter “S” and are followed by a number, I use a regular expression for a pattern filter. I do this by piping all returned computer objects to the Where-Object command, and as shown here, I store the resultant matches in the $cn variable:

$cn = Get-ADComputer -Filter * |

          Where Name -match 'S[0-9]'

The last thing I need to do is to call the specific workflow from the module I loaded earlier. That script is shown here:

Invoke-Command -Session $wfs {UnInstall-ISE -pscomputername $using:cn.name -AsJob}

For the computer names, I need to select the Name property from the computer objects I stored in the $cn variable. The –pscomputername parameter is an automatic parameter that appears in workflow commands.

Because I retrieve the computer names from the DC1 computer, they are local objects. To bring the local objects into the work flow, I need to use the $using directive. The –AsJob parameter means that I will create a Windows PowerShell job, and therefore, I can manage the process with the Job cmdlets.

Here is the basic drawing for my example today:

Here is he complete script for today’s example:

$wfs = New-PSWorkflowSession -ComputerName DC1 -Credential Nwtraders\administrator

Invoke-Command -Session $wfs -ScriptBlock {

  Import-Module \\dc1\Share\PoshModules\Workflow-Install-Uninstall-ISE.psm1 -verbose

  Import-module ActiveDirectory}

    $cn = Get-ADComputer -Filter * |

          Where Name -match 'S[0-9]'

Invoke-Command -Session $wfs {UnInstall-ISE -pscomputername $using:cn.name -AsJob}

That is all there is to using Windows PowerShell to remotely run a workflow. Workflow Week will continue tomorrow when I will talk about more cool stuff.

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy 

Comments (2)

  1. public key infrastructure says:

    public key infrastructure
    I’ve learned some good stuff here. I do appreciate your efforts to create one of these magnificent informative websites.
    http://www.arx.com/resources/white-papers/pki-solution-for-electronic-signatures.htm

  2. Chris says:

    This is a timely and helpful article, as I was just trying to do a complex uninstall then install type procedure for several dozen computers. Thank you.

Skip to main content