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 Nameproperty 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