In previous posts I discussed how to build a new workflow from a template we included in the tech preview (see Building Your First Workflow) and how to output objects to an XML file for debugging so you can understand the workflow (see Debugging Your Workflow). In this post I will answer the question posed in that first post of how you could modify the sample workflow to only show services that are set with a Startup Type of something other than Disabled. The answer to this question takes you into one of the areas where you can extend Workflow Studio to do things that aren’t “built-in” to the product.

There are 3 main ways that Workflow Studio can be extended:

  1. Build templates and share with others - This is the easiest way for you to extend Workflow Studio, all you have to do is build a workflow and choose “File…Save As Template” and then share it with someone else. Citrix has a site set up for you to upload and share the templates you build. Upload Your Workflow Templates
  2. Create new Task Libraries - The left side of Workflow Studio is a set of libraries that we include with the product to integrate with Citrix products, Virtual Machine Manager, and Windows in general. There will be tools available for anyone interested to build their own integration to other products. These tools are not available publically yet, so if anyone is interested in building task libraries on top of Workflow Studio please contact me.
  3. Leverage support for ‘extensible’ tasks - Workflow Studio has native support for you to embed PowerShell scripts, call VBScript, and run WMI queries as tasks as well as run Windows applications and command files.

This last area is the topic for this post. Here is a screenshot with these extensible tasks highlighted:


From top to bottom in the picture we have:

  • Command Script - allows you to run a Windows command (or specify a .bat or .cmd file), optionally specify parameters and get back the text of the command session
  • Get WMI Info - allows you to run WMI queries and get back the results
  • Launch Process - allows you to run a Windows executable (there is also a Start Process that lets you schedule executables to be run)
  • Windows Script - allows you to run VBScript or JScript directly (or call a script file)
  • PowerShell Command - allows you to run a PowerShell cmdlet
  • PowerShell Script  - allows you to run PowerShell script directly (or call a script file)

As you can see there are lots of ways to leverage Workflow Studio to complete tasks beyond the obvious, included ones. This could allow an admin to document existing scripts by turning them into workflows providing a visual record of how the process flow is structured and making complex scripts more easy to update as the process flow changes later.

Alright, back to the original problem – how do we modify our sample workflow to hide services that are set to disabled? After some searching around we find that the WMI query Win32_Service provides us with the same basic object, but with additional info like the Startup Type. By modifying our workflow to replace the “Get-Service” task with a “Get WMI Info” task and setting its “WMI Class” property to “Win32_Service” we now have an object that provides everything we need. One thing to note – the “Status” property that we were using on Get-Service is called “State” on the WMI object so we need to change our “Where-Object” to reflect that. The new Where-Object filter would be:$.State -eq “Stopped” -and $.StartMode -ne “Disabled”

The syntax for this filter follows PowerShell syntax so any PowerShell guide will help you with the syntax. Play around with this – hook up an “Export To XML” task to the WMI result so you can see all the properties and let me know what you think.