In a previous post about use cases for IT Process Automation and Workflow Studio I mentioned building a workflow to facilitate a "Green Data Center". Workflow Studio can help with this by managing the workloads on your servers and turning servers off when they are not needed. In this post I will show you 2 ways that you can shutdown a windows server from a workflow (these are native to Windows, if you are using 3rd party tools let me know in the comments.)

1. "Launch Process" Task - Windows has a built-in utility (shutdown.exe) that can shutdown computers on your network remotely. Using the Workflow Studio "Launch Process" task allows you to call the shutdown command and pass it the arguments you want for your needs. You can see all the arguments by typing "shutdown /?" at your command line and there are several detailed write-ups on Microsoft's site (here and here for example).
2. "PowerShell Script" Task - WMI has a class (Win32_OperatingSystem) that can be used to shutdown computers as well. Workflow Studio has a task called "Get WMI Info" that is designed to query WMI classes, but unfortunately it cannot call methods on the WMI classes. We will need to leverage a scripting environment like PowerShell to be able to call the method (or you could use VBScript.) Fortunately, in PowerShell we only need one line of code to achieve this:

(Get-WmiObject -Class Win32_OperatingSystem -ComputerName <computer name>).shutdown()

Add that line of code to your "PowerShell Script" task and replace the <computer name> with the name of the computer you would like to shutdown.

In this post I looked at shutting down a Windows Server, but in future posts I will expand this and look at how to use Wake On LAN to power machines back on, how you can manage power on a XenServer host machine, and how you can integrate this with logic to monitor when to shut down and start up your servers.
 
Power management is an area that we are working diligently on internally to build out a robust set of tasks for you. Have you tried automating server shutdown processes in your data center? What issues do you face? What kinds of inputs do you want to be able to leverage to determine when to shutdown a server?

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.