When you build a workflow using some of the PowerShell tasks you may come across a need for the special variable "$_". This variable represents the current pipeline object in PowerShell and is used in workflow tasks to refer to the passed in 'Input' object. One case where this comes up often is with the "Where-Object" task. When using this object your "Filter Script" property will typically contain something that looks like this:

$_.Status -eq "Running"

The above means to return all items from the Input object where the Status field is "Running"

I found this site that does a great job of explaining the special variables in PowerShell if you want to explore further:

http://www.computerperformance.co.uk/powershell/powershell_variables.htm

That site has a lot of tutorial pages on PowerShell covering the escape character I talked about in my previous post as well as a good summary of PowerShell syntax. I find myself on that site often from searching for PowerShell topics and often find answers there.

There was a question on the forums about calling the XenApp task Connect To Farm when using a domain user name. Since we are using PowerShell heavily under the covers the string passed in to this task for the username needs to use the PowerShell escape character whenever a reserved character for PowerShell is in the string. I searched Microsoft's site, but couldn't find much detail out there on this so I wanted to clarify here:

The escape character for PowerShell is the grave-accent character "`" (which on US keyboards should be in the upper-left of the keyboard to the left of the number 1.

I haven't been able to find much posted on reserved characters on Microsoft's site, but here is a good article that highlights what is in the PowerShell help documentation:

http://www.microsoft.com/technet/scriptcenter/resources/qanda/jan08/hey0117.mspx

Here is the list of characters from that article:

$
( )
*
+
.
[ ]
?
\
/
^
{ }
|

 If you need to use any of those characters in a string then you will need to escape it with the ` character. For example, to pass in a domain username to Connect to Farm in XenApp then you will need to pass in "domain`/user" instead of just typing "domain/user".

In a previous post I covered how to integrate Wake On LAN into your workflow, but how many people are currently using Wake On LAN or at least know that the majority of their servers support it?

Do the servers in your Data Center support Wake On LAN technology?	Choose
Yes, and I currently use it
Yes, I believe so but I am not using it
No, they only support the hardware vendor's proprietary technology
No, they do not support any form of remote power management
I have no Idea

In a previous postI explained how to leverage the PowerShell Script task (and PowerShell code) to generate your own custom user interfaces in Workflow Studio. I ran across this script and wanted to share in case anyone wanted to get a date from a user:

http://www.microsoft.com/technet/scriptcenter/resources/pstips/mar08/pstip0314.mspx

In previous posts I have explored using Workflow Studio to Shut down a Windows host and also how to Shut down a XenServer host. Getting the power off is a big step in being greener, but if you could just turn off machines and leave them off permanently then you wouldn't need Workflow Studio Next we have to look at how to get those hosts powered back on.

There are a lot of different options out there for power management, but the one thing that is fairly consistently avaiable is Wake On LAN (WOL). In this post I am going to look at how WOL technology can be leveraged by Workflow Studio. Most modern server NICs have some form of WOL support (though you may have to turn it on in the BIOS.) This allows you to start up any machine that you know the MAC address for. Heare are some details on WOL from Intel and the Wikipedia WOL page has a good overview and a lot of links to free utilities and sample code.

Now that we have an understanding of how we want to start our server we can add it in as a task in Workflow Studio. There isn't a native WOL task in Workflow Studio (not yet anyway), but it is pretty easy to call one of the tools mentioned in the Wikipedia article with a "Launch Process" task. I started with that, but didn't like having to require one of these to be installed, so I went looking at the code samples. I finally found a great implementation of WOL in PowerShell by /\/\o\/\/ The PowerShell Guy. Paste that code in a PowerShell Script task and you have an embedded Wake On LAN task.

The next step is to put all this together into a single workflow with some business logic about when you want to start and stop your servers. I want to hear from you - what metrics would you want to use to drive a "Green" workflow? Is Wake On LAN supported in your data center? What issues do you have that this kind of a workflow could help with?

If you haven't read my post on whether we should have more customizable dialogs in Workflow Studio please check it out (here) and respond to the poll so I know what you think. In that post I mentioned that you could get custom dialogs today in Workflow Studio by leveraging PowerShell. Building Custom dialogs in PowerShell is not easy right now, but there are some projects out there to automate the process using the Visual Studio designer so it is getting easier. I'm not going to cover the specifics of how to create dialogs with PowerShell, but have a look at this Microsoft article for an introduction and then I will show you how to use this concept in Workflow Studio:

http://www.microsoft.com/technet/scriptcenter/resources/pstips/feb08/pstip0208.mspx

As I said, the process of building the dialog in PowerShell is tedious, but fortunately getting it into Workflow Studio is not so hard. Workflow Studio has a task called "PowerShell script" that can execute PowerShell script directly:

 
Just drag this task onto your workflow and paste the code from the above article into the "PowerShell Script" property. Now when you run your workflow you will get the dialog to appear. Pretty cool...
 
If you left all the defaults on your PowerShell Command task then you will also have the results of $x (the input string) in your $Output variable and you can use that in subsequent tasks.
 
In future articles I will look at how you can use this concept to create more complex dialogs and pass more complex objects out, but try it out and let me know what you think.

Many people have asked me how to build custom dialogs in Workflow Studio. Enough people have asked that I have built custom dialogs as native tasks in Workflow Studio and I have also built them in PowerShell (something you could do right now with the tech preview.) Before I post more information on how to do this though I want to better understand why people want to have custom dialogs.

An example that I often hear is that someone wants to modify one of our samples to prompt the user for their username and password in the same dialog instead of using two dialogs. Another example I hear is that people would like a multi-column display tool (like a grid) to display the contents of objects output from other tasks. When people ask me for this I begin to wonder how they plan to use the workflow once they get beyond testing it. When we created those samples we included the user input to ensure that the user is aware of what the workflow is doing and to provide a way for them to input the settings specific to their environment. We expect that most people will deploy workflows with these settings pre-configured in the tasks directly or by using the "Set Variable Value" task and that any output would be to XML files or other tasks.

I wrote a post on IT Process Automation with Workflow Studio that looks at some of the use cases we expect Workflow Studio to be used for. Read through that earlier post for a little deeper look at how I think workflows will be used.  [And if you think I am wrong please leave me a comment or send me an email...]

With that post in mind, I believe that the people requesting richer interaction from a workflow are either looking to do a lot of "On-Demand Automation" or they are looking for Workflow Studio to offer a richer set of debugging tools for desiging and debugging workflows. If you have read this far then take my poll and tell me which you think it is for you?

Why do you want a richer set of Input/Ouput tasks in Workflow Studio?	Choose
To make designing and debugging workflows easier - I would delete them before deploying.
Because I expect to use "On-Demand Automation" type tasks heavily and not schedule workflows to run automatically
I don't need richer user interface options

I want to use this blog to post answers to common and/or complex questions I get asked about Workflow Studio. One that has been asked fairly often is how to access the MAC address of a VM running in XenServer. The MAC address for a VM is located in the following object path:

VMList.VM.VirtualInterfaces.MAC

When you call Get-VM you get back a list that represents multiple VMs. Whenever you are dealing with something that returns more than one item in Workflow Studio you are going to need to access the individual items with the "For Each Object" task. As you iterate over this list of VMs you will have a new object that represents an individual VM. This typically has properties on it that you want to access, but in this case there is another list of things named "VirtualInterfaces". Because a given VM can be assigned multiple network cards we have an object that represents each of them, so we need to go down one more level using the "For Each Object Task" to get an individual Virtual Interface so we can access the MAC property. I hope that is clear, but since pictures speak more clearly here is an example:

At the top of the workflow you would call Get-VM and then use For Each Object to iterate over each one returned:

 

 You will notice that the For Each task has the little (s) icon representing it has sub-tasks, so if you double-click on that task you will be able to specify the sub-tasks where you will iterate again on the Virtual Interfaces:

And  then you can access the individual MAC address:

Hopefully that clears up how to get to the MAC address of a VM.

In a previous post (Shutting Down a Windows Server) I looked at how you can shutdown Windows Servers in a workflow to save power. If you have already moved your workloads to a XenServer environment this task becomes a lot easier to manage. Shutting down a XenServer host is a three-step process:

1. Suspend or Shutdown any VMs that you have running on the host (with either Suspend-VM or Shutdown-VM)
2. Disable the host so new VMs cannot be started (with Disable-Host)
3. Shutdown the host (with Shutdown-Host)

To turn this process into a complete workflow we need to define the logic that determines which hosts to shutdown and what to do with the VMs running on it. For simplicity sake I have chosen to shutdown all the hosts on my server (or in my Pool if a master server is specified) and to first suspend all the VMs currently running on the host(s). Here is what the workflow looks like:

I added in the prompts so that if you download this workflow and run it you are reminded to specify your own XenServer host name, user, and password, but in reality these items would most likely be hard-coded or specified at run time dynamically. Next we are going to have to look into starting Windows Servers and XenServer hosts back up as my server room is a long walk for me.

If you want to download the workflow to try in your environment I posted it to the Script Exchange where you can also post workflows you have built. Click here to download the workflow file.

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?

The first question that most people ask me after seeing Workflow Studio in action is:

"Wow! That's cool, but what can I do with that?

I would like to use this post to try to explain why I think you should be doing automation in your data center today and then look at some different processes that are good candidates for automation with Workflow Studio.

Why should you automate?
The IT data center of today often includes products from many different vendors and consists of both hardware devices and software. Often, the SDKs that are available for all of these devices and software are quite inconsistent and some of your processes may have been developed by a consultant who is no longer around. Stop and ask yourself this question:

Are all of my processes consistently repeatable by anyone on the team?

If you can't answer 'yes' to that question then you should be looking into IT Process Automation. And if you want an easy way to automate tasks across multiple products/components without the need for complex scripting, then take a look at Workflow Studio.

Here are some broad categories for types of automation you might want to have in your data center:

1. On-Demand Automation - Being able to launch a process that combines several tasks, possibly with some simple user input, in response to something that has happened in your environment (e.g. A call or email comes in that a new user needs to be setup, a new application installed, or permissions modified for a user.)
2. Schedule-Based Automation - Schedule a task to be performed at a set time each day (e.g. Restart your servers every night at midnight.)
3. Event-Driven Automation - Automate a set of tasks based on system events (e.g. When load is increasing bring more servers online and when load decreases take servers offline)

If you download the Tech Preview of Workflow Studio (free download here) you can look at some of the sample templates we include with the product and get a look at some On-Demand Automation out of the box. The Tech Preview doesn't really provide any help with scheduling or event management, but this type of functionality is being added to the product.

Next, let's look at what I think are the 3 key categories of use cases for Workflow Studio and some examples that you could put in action today:

1. Server Resource Management = Dynamic Delivery Center - Transform your data center into a delivery center by creating workflows that tie together your server provisioning process (both physical and virtual) with your web, desktop, and application delivery processes.
2. Power Management = Green Data Center - Being able to power on/off both physical and virtual servers automatically provides the ability to better manage your resources and, ultimately, save $$ by having your power-hungry servers off when they are not needed.
3. User Management = Automated User Provisioning - Every organization has a process for provisioning and de-provisioning user accounts, but often these processes involve multiple manual steps. Automating the process end-to-end ensures that best practices are followed in exactly the same way each time.

I hope this encourages everyone to think about what kinds of tasks you could automate in your environment. Let me know in the comments what kinds of things you would like to automate or you can find my email address in my profile if you want to email me directly.

The PowerScripting podcast including the interview with myself on Workflow Studio and PowerShell has been posted:

 http://powerscripting.wordpress.com/2008/07/07/episode-32-citrix-does-powershell/

The interview with me starts at 15:30 in.

Enjoy!

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.
 

I met Hal Rottenberg at TechEd this year and found out about his podcast on PowerShell (among the many other things he works on.) He mentioned Workflow Studio on episode 30 (at about 22:50 in):

http://powerscripting.wordpress.com/2008/06/22/episode-30-teched-report/

I am going to do an interview with Hal on Workflow Studio for an upcoming show so stay tuned...

In my last post I walked you through creating a workflow based on a template (the included "Start Stopped Services" workflow.) In that post I mentioned that you might want to modify the workflow to only show services that are not in the disabled state and suggested you try to figure out how to do that on your own: Previous Post

 Let's take a look at the previous workflow we created to see how it is structured:
 

 This workflow has 5 basic steps:

1. Get all the installed services (Get-Service)
2. Filter out all the stopped services (Where-Object)
3. Sort the list of services in alphabetical order for display to the user (Sort-Object)
4. Display the sorted list to the user and allow them to choose a subset of services to start (User Option)
5. Start the services that were selected by the user (For Each Object)

 It should be obvious that if we modify the "Where-Object" task to also filter out services that are Disabled in addition to the Stopped ones we can achieve the desired result. Unfortunately, the Status property only returns two different values - "Running" and "Stopped". We need to take a look at what other properties there are on the Get-Service task that we could use. The easiest way to do this is to just output the entire object to a file and take a look at what is there. We include two tasks with Workflow Studio that allow you to send objects to a file - "Export To CSV" and Export To XML". Both of these tasks also include a property to auto-generate an HTML wrapper for the data so you can quickly view the data as well.

 To use this debugging technique, just add the additional task from the Input/Output folder (either CSV or XML) and connect it to the "Get-Service" task:

 There is no need to delete the other tasks as Workflow Studio will only run the tasks that are connected in the workflow. On the newly added task you will have to set the "Input Variable" property to "$Services" and the "Output XML File" property to a valid local path and pick a filename. I also set the "Save As HTML" and "Show HTML" properties to TRUE so that I get an immediate, readable HTML report of the object like this:
 

 If you have followed along this far I hope that this helps you understand how you can output objects to a file for debugging purposes (or you may need to do it to provide files to other processes.) When you look at the properties that are available from the Get-Service task you will find that there is not a property available that will allow you to determine if a service is Disabled. The Get-Service task is based directly on the Get-Service PowerShell cmdlet and this is a limitation of that cmdlet. So we went through this whole process and have hit a dead end with our goal of filtering out disabled services. Next time I will provide the solution to this problem, but in the mean time here is a good hint:
http://msdn.microsoft.com/en-us/library/aa394418(VS.85).aspx

Building your first workflow with Citrix Workflow Studio is incredibly easy. We include many templates with the Tech Preview that allow you to see how the product works quickly and easily.

First go download the product - http://www.citrix.com/wfsinsider (MyCitrix login required, but it is painless to get one.)

Once you download and install the product you will see the following the first time you launch it:

Just click the box where it says "Create a new workflow based on a Workflow Template" and you will see the following:

Provide a name for your new workflow and select one of the workflow templates that we included with the product. The easiest one to set up and understand for your first time is the one under "Windows Management" called "Start Stopped Services". Select that one from the list and click "OK". You should see the Workflow Studio Designer interface with the template loaded like this:

 You now have built your first workflow. Click "Start" to run the workflow and you should be presented with a list of the services that are currently in a stopped state on your machine. Much like the following:

If you select one or more services and click "OK" Workflow Studio will attempt to start those services.

Note: If the service is disabled Workflow Studio will not be able to start it and will return an error. Take a look at the workflow and see if you can modify it to exclude the services that are in a disabled state.

I would love to see comments on what people think about Workflow Studio and what they would like to use it for in their environment. I plan to post some more advanced workflow samples in coming weeks, so let me know what you would like to see.

In May I took an internal transfer to the Workflow Studio team as Technical Product Manager. I am really excited about this new product. If you haven't downloaded it yet you can get more information here. Look for more information and some tips and tricks coming here on the blog in the coming weeks.

Hi, I am Peter Schulz and I am a Senior Manager in the Technical Marketing team. I hope to start a dialog with the community around leveraging the SDKs that we provide to extend applications in interesting ways. I wrote some samples that Kurt and I demonstrated at both iForum and Summit and I want to share the first of those here. With the release of Presentation Server 4.5 we now have a powerful new feature available - Application Streaming to the desktop. The MFCOM SDK will be updated to support application streaming. If you haven already watched the webinar on the new features coming in the CPS 4.5 MFCOM SDK I highly recommend it:
http://citrixcommunity.com/blogs/cdn/archive/2007/03/20/Dr-SDK-PS-4.5-Webinar-Recording-Available.aspx

Even though the SDK is not out yet, can write code against the newly exposed objects. sample with SMS and automates the pre-deployment of the application cache for streamed applications and has been posted to the Developer Center at http://support.citrix.com/article/CTX113229

If this is useful or you have any questions about it leave me a comment here or on the support site.

Thanks!
Pete