So, who do I think is right? That is easy - they both are!

First I want to say thank you to both of these guys for getting a discussion going. If I can paraphrase Brandon's side of the argument it would be "Why do I need Workflow Studio? I have Windows PowerShell." This is a question I have gotten a lot and I want to take some time to address it here.

Workflow Studio is designed to run on top of PowerShell. PowerShell 1.0 is a pre-requisite and many of our activities are written in PowerShell. Like Brandon, I think that PowerShell is an excellent scripting language and I personally can't wait for the day when everything is in PowerShell and there is no more need for VBScript. I believe every Windows administrator should learn PowerShell and use it regularly. I am doing what I can to drive all Citrix products to expose an SDK in PowerShell.

So wait a minute then... if the Product Manager for Workflow Studio is saying to use PowerShell then what is Workflow Studio for?

There is no reason that you should have to decide between the two technologies. If you are a Citrix customer then you have Workflow Studio at no additional cost. Workflow Studio has a great SDK for consuming PowerShell libraries, so you can leverage your existing PowerShell libraries with Workflow Studio. Here are some other things you can do with Workflow Studio:

1. Workflows are stored centrally in a SQL database making sharing and re-use across your team much easier
2. Workflows are automatically versioned when stored in the database. If you update a workflow that has been deployed, a copy is automatically created so you can continue to reference and use the previous version.
3. Workflow Studio is integrated with a task scheduling interface to automate the execution of your workflows based on schedule.
4. Workflow Studio has a simple, graphical, drag and drop interface. Most likely not everyone on your team is a PowerShell expert. Workflow Studio provides a simple interface that lets those not familiar with PowerShell be productive with it as well.
5. Workflow Studio can easily integrate with things that aren't PowerShell (native libraries support VBScript, WMI, and running batch files. You can also use 'off-the-shelf' activity libraries for Workflow Foundation as well.)
6. Workflow Studio is designed to support persistence. For simple, quick jobs, someone who is familiar with PowerShell and the cmdlets necessary to complete a given task will be more effective using the PowerShell command line interface. If the task requires several levels of approvals over hours, days, or even months then Workflow Studio and its underlying persistence and tracking engine from Workflow Foundation is a better tool for the job.

And remember, everything in Workflow Studio is exposed via PowerShell, so you can build your own interfaces to your workflows in PowerShell.

I would love to get more feedback on this topic in the comments. Let me know if you agree or disagree. Ultimately these are both just tools and if they don't help you do your job then they are meaningless. Let us know how we can make both technologies work better for your organization.

Just in case you haven't seen the posts by Ed York and Michael Bogobowicz on Workflow Studio recently I wanted to call them out. In addition to providing some excellent activities and workflows for you, there are posts that explain the process of creating activities and workflows around XenApp, Provisioning Server, and SQL.

Michael wrote a workflow that automates the update of vDisks in Provisioning Server using the CLI tools:
http://community.citrix.com/display/wf/PVS+Automatic+vDisk+Update+Script

Ed has written up two excellent blog series on Workflow Studio:

• Workflow Studio SDK - This first series of posts detail Ed's experiences using the Workflow Studio SDK to build and debug custom activities and are an excellent place to start if you want to build your own activities:
  http://community.citrix.com/x/YIUJB
  Ed followed this series up with a post on building an activity to get a list of applications from XenApp using the MFCOM SDK and this activity and source code are available for download:
  http://community.citrix.com/x/KgE-B
  Ed also wrote a couple of activities that work with SQL Server:
  http://community.citrix.com/x/2IJiB

• Automating Workflow Studio - The second series of posts is on automating workflows. Ed has posts that explain how to use the PowerShell interface to start a workflow and pass parameters to it. He then goes on to explain how to build your own front-end for starting these workflows:
  http://community.citrix.com/x/ToNiB

As a reminder, all community posts on activity libraries and workflows will show up right in the Workflow Studio product under the Community tab so you don't even have to go out to the site to look. RSS feeds are also available on the Community site if you want to get notified in your favorite RSS reader.

During the Tech Preview of Workflow Studio, the most popular posts I had were around using Workflow Studio to create a green data center:

• Green Data Center - Support for Wake On LANhttp://community.citrix.com/x/RQUgAg

• Green Data Center - Getting the power back on
  http://community.citrix.com/x/AQUgAg

• Green Data Center - Shutting Down a Windows Server
  http://community.citrix.com/x/9IUNAg

• Green Data Center - Shutting Down a XenServer Host
  http://community.citrix.com/x/1IAVAg

I wanted to review these very popular posts and talk about how the most recent versions of Workflow Studio can be leveraged for these tasks.

Wake On LAN
Support for WakeOnLAN was included in the activity library pack made available in April with version 1.1. The WakeOnLAN activity is in the 'Networking' library and in the 'Networking' folder in the Designer once installed:

Shutting Down a Windows Server
In the Tech Preview post, I talked about two methods of shutting down a computer. One of those two methods - LaunchProcess - is available as part of the library pack that was released in April (under Windows), but also in that pack is a Shutdown activity that manages this for you. The Shutdown Windows activity is in the Networking library with Wake On LAN.

Shutting Down a XenServer host
In the Tech Preview post, I talked about several activities for interfacing with XenServer VMs and the XenServer host. These activities are all part of the library pack from April. These activities are in the 'Citrix XenServer' library and in the 'Citrix XenServer' folder in the Designer once installed:

The host activities Disable-Host and Shutdown-Host that were in the Tech Preview post are not available yet, but will be in the next update to this library.

If you are using Workflow Studio to manage power in your environment, drop me a line and let me know how it is going. If you aren't using it, let me know what we can do to make it easier for you.

This is the second part of a four-part series on automating the execution of workflows within Citrix Workflow Studio.  In the first blog of the series, I discussed the basics for using Powershell to automate the execution of workflows.  In this blog, we will expand on that topic to discuss how we can pass parameters into the workflow, making our workflows much more dynamic and flexible for supporting different types of situations.

Understanding Global Properties
The key to passing parameters into a workflow is to use the global properties of the workflow.  You access the global properties within the Citrix Workflow Studio Designer by navigating to Workflow->Manage Global Properties from the file menu (shown below).

The Manage Global Properties dialog allows you to specify the global properties of the workflow.  Essentially, all you need to do here is to define the names of the global properties and their property type (String, Boolean, Integer, etc.).  I personally like to pre-fix my global properties with the letter "g" to make them easily identifiable when assigning them to activities.  You can also optionally define a default value for a global property if you want to.

Then within your workflow, you bind the global properties to the activities within the workflow.  When you edit a bindable property for an activity, you'll get an editor such as is shown below.  On the left-hand side, select Global Properties within the drop-down.  The global properties should all be listed and easily identifiable by the letter "g" in front of the name (if you named them this way).  Just select a global property and add it to the text editor to use it. 

When global properties are defined for a workflow, you define the values of the global properties when scheduling a job within the Workflow Studio Console. 

Creating a Powershell Script that passes parameters into the workflow
If you want to automate the execution of the workflow with Powershell, the Powershell script can also set the values of the global properties to pass into the workflow being executed. 

To pass parameters into the workflow, the Powershell script will have a structure similar to below.  This sample script shows how to pass two parameters into the workflow.  What we are doing here is creating a hash table that represents the name/value pairs of the global properties.  This hash table is then provided as a parameter into the schedule-workflow cmdlet.  Please note that the schedule-workflow cmdlet should be all on one line (it was split on two lines here for better readability).

#Set variables for the workflow
$strWorkflowName = "Workflow1"
$strParam1Name = "Name1"
$strParam1Value = "Value1"
$strParam2Name = "Name2"
$strParam2Value = "Value2"

#Add the Workflow Studio snap-ins to the current Powershell session
Get-PSSnapin -registered | Add-PSSnapin

#Get reference to the Workflow Studio runtime
$rt = Get-WorkflowRuntime

#Get reference to the deployed workflow
$workflow = get-deployedworkflow -workflowruntime $rt -workflowname $strWorkflowName -includeschedule

#Create hash table of parameter values to pass into workflow
$params = @{$strParam1Name = $strParam1Value; $strParam2Name = $strParam2Value}

#Schedule the workflow to run immediately
schedule-workflow -workflowruntime $rt -workflowstrongname $workflow.WorkflowStrongName
-workflowparameters $params -runimmediately

Example:
To illustrate how the passing of parameters works, let's use the SQL Server Activity Library within our workflow. This is an activity library that you can download and leverage yourself for communicating with a SQL Server database.  The beginning point of our workflow is shown below. 


In this workflow, we are using the SQLExecute activity for executing an UPDATE command on a SQL Server database.  The initial SQL UPDATE command is shown below.  Since we are hardcoding the Employee ID and Phone Number into the SQL statement here, the initial usability of this workflow is pretty limited.  It would be much better if we could make this SQL statement adaptable for different employee IDs and phone numbers.


To make this SQL statement more dynamic, we need to create global properties to represent the Employee ID and Phone Number.  Notice the prefix "g" we are using to denote the global properties.  This will make them easy to find when applying them to an activity.


Once the global properties are defined, we can use them within the SQLExecute activity.  In the screen shot below, the SQL Command is updated to reference the global Employee ID and Phone Number properties created above.


Our workflow is pretty dynamic now.  We can pass the Employee ID and Phone Number as parameters into the workflow.  When the workflow is executed, it will use the passed in values as part of this SQL statement.

The Powershell Script to automate the execution of this workflow is shown below.  Please note that the schedule-workflow cmdlet should be all on one line (it was split on two lines here for better readability).

#Set variables for the workflow
$strWorkflowName = "Workflow1"
$strParam1Name = "gEmployeeID"
$strParam1Value = "101"
$strParam2Name = "gPhoneNumber"
$strParam2Value = "555-123-4567"

#Add the Workflow Studio snap-ins to the current Powershell session
Get-PSSnapin -registered | Add-PSSnapin

#Get reference to the Workflow Studio runtime
$rt = Get-WorkflowRuntime

#Get reference to the deployed workflow
$workflow = get-deployedworkflow -workflowruntime $rt -workflowname $strWorkflowName -includeschedule

#Create hash table of parameter values to pass into workflow
$params = @{$strParam1Name = $strParam1Value; $strParam2Name = $strParam2Value}

#Schedule the workflow to run immediately
schedule-workflow -workflowruntime $rt -workflowstrongname $workflow.WorkflowStrongName
-workflowparameters $params -runimmediately

Final thoughts:
If you want to try out these Powershell scripts yourself, you'll need to follow the setup instructions as outlined in the first blog of this series. 
In the final two blogs of this series, we are going to take these Powershell scripts to the next level by converting them to an actual C# program. As you'll soon see, you'll use the information contained in these first few blogs to understand how the C# programs actually work.  Stay tuned!

Blogs in this series:
Using Powershell to automate workflow execution within Citrix Workflow Studio
Passing parameters into a workflow within Citrix Workflow Studio (this one)
Automating workflow execution for Citrix Workflow Studio using a .NET windows application
Automating workflow execution for Citrix Workflow Studio using an ASP.NET web application

When you begin learning Workflow Studio, you quickly learn that the Workflow Studio Designer can execute workflows for initial testing purposes and the Workflow Studio Console can execute workflows as a scheduled job.  A lot of people have been asking about how you can automate the execution of a workflow from an external system, such as Powershell, a Windows application, and an ASP.NET web application.  The real power of Workflow Studio is being able to execute a workflow when you want it to run, either manually, on a schedule, or on-demand when needed by external systems. 

This is the first blog of a new series I'm starting on how you can automate the execution of workflows from external systems, beginning with Powershell.  One thing I didn't realize when I started using Workflow Studio was how much this product was connected to Powershell.  Essentially, any action you can perform within the Workflow Studio Console has an equivalent Powershell cmdlet for it.  Using these cmdlets allows us to automate the various tasks within the Workflow Studio Console, such as executing the workflows themselves.

Workflow Setup:
If you want to execute a workflow with Powershell, the workflow needs to be in the Ready state within the Workflow Studio Console.  One thing that I prefer to do to keep the Powershell script fairly short is to pre-deploy the workflow to the Jobs section in the Workflow Studio Console.  When you pre-deploy a workflow, you are just making it available to execute as a Job without actually executing it yet.  By doing this simple step ahead of time, we can actually cut our Powershell script in half.  Please note that this is just a one time step - once you deploy it to the Jobs section you really don't have to open the Workflow Studio Console again (unless you want to make changes to your workflow itself).  The two screen shots below demonstrate how to pre-deploy the workflow to the Jobs section.

Registration of Xceed DLLs:
The Workflow Studio cmdlets leverage a few Xceed DLLs on the system.  These Xceed DLLs are part of the Workflow Studio installation and need to be present within the global assembly cache (GAC) in order for several of the Workflow Studio cmdlets to run properly.  Workflow Studio 1.1 does not actually place these DLLs into the GAC so you need to do that manually for this release.  I was told in future releases that this step will already be done for us.

There are three Xceed DLLs you need to place into the GAC:  Xceed.Compression.dll, Xceed.FileSystem.dll, and Xceed.ZIP.dll

Drag these DLLs from the C:\Program Files\Citrix\Workflow Studio folder to the C:\Windows\Assembly folder.  This process adds them to the GAC.  The end result is shown below.

Powershell Setup:
An interesting thing to note about Powershell is that scripting is turned off by default.  You can't execute a Powershell script until you enable scripting at a desired level.  I'm not exactly sure why Microsoft chose to do that since Powershell is supposed to be a scripting language, but it is fairly easy to enable scripting.

Launch Powershell (Start->Programs->Windows Powershell 1.0->Windows Powershell) and type the following command to get the current execution setting:

Get-ExecutionPolicy

If the execution policy is set to Restricted, you need to enable script execution by typing the following command:

Set-ExecutionPolicy RemoteSigned

Powershell Script:
The table below is a sample Powershell script for executing a workflow on your Workflow Studio machine.  I've tested the Workflow Studio cmdlets pretty extensively and this seems to be the simplest script I was able to create to execute a workflow. 

To use this script in your environment, just copy and paste this script into Notepad, and rename the file as a .PS1 file.  Then update the value of the $strWorkflowName variable to be the name of the workflow you want to execute.  In my next blog, I'll explain how you can tweak this script to pass parameters into the workflow.  The script below will work for any workflow that does not require parameters.

#Set variables for the workflow
$strWorkflowName = "Workflow1"
 
#Add the Workflow Studio snap-ins to the current Powershell session 
Get-PSSnapin -registered | Add-PSSnapin
 
#Get reference to the Workflow Studio runtime
$rt = Get-WorkflowRuntime
 
#Get reference to the deployed workflow
$workflow = get-deployedworkflow -workflowruntime $rt -workflowname $strWorkflowName -includeschedule
 
#Schedule the workflow to run immediately
schedule-workflow -workflowruntime $rt -workflowstrongname $workflow.WorkflowStrongName -runimmediately

Executing the Powershell script:
After the PS1 file is created, place it within an accessible place on your Workflow Studio machine.  For example, I've placed my scripts within C:\Citrix\PowershellScripts.  One thing I found out is that you want the path to the script to have no spaces, so keep that in mind as you place your PS1 file into a directory.

Next, open the Run window and type the statement below to execute your Powershell script (my script was called ExecuteWorkflow.ps1)
           powershell.exe -noexit C:\Citrix\PowershellScripts\ExecuteWorkflow.ps1

The -noexit switch above keeps the Powershell window open after the script is executed.  If the script execution was successful, you should see a Job ID as noted below.  This tells you that the workflow was successfully executed.

Troubleshooting the Powershell script:
If you are having issues with your Powershell script, the approach I typically take for troubleshooting is to launch Powershell and execute each line of the script manually until you come across the error.  Powershell can be launched from the Start Menu (Start->Programs->Windows Powershell 1.0->Windows Powershell) or by typing Powershell.exe in the Run window.

If you receive Access Denied errors, there is a good chance that the account you are running Powershell under is not a Workflow Studio admin, or does not have permissions within Workflow Studio to execute various workflow actions.  Check that your logged on user account is either a Workflow Studio admin or has these permissions.  These permissions are set inside the Workflow Studio Console within the Security section.

Most of the commands in the script above use variables.  To see the value of a variable, use the echo statement. For example:

echo $strWorkflowName

echo $workflow.WorkflowStrongName

Get-Command -PSSnapin citrix*

The output of the above statement is shown below:

If you want more information on how to use a specific Workflow Studio cmdlet, use a statement such as this:

Get-Help schedule-workflow

Blogs in this series:

• Using Powershell to automate workflow execution within Citrix Workflow Studio (this one)
• Passing parameters into a workflow within Citrix Workflow Studio
• Automating workflow execution for Citrix Workflow Studio using a .NET windows application
• Automating workflow execution for Citrix Workflow Studio using an ASP.NET web application

I just recently posted a SQL Server activity library to the Citrix Developer Network (CDN).  The SQL Server activity library allows you to execute SQL statements (SELECT, INSERT, UPDATE, DELETE, etc.) on a Microsoft SQL Server database as part of a workflow within Citrix Workflow Studio.  The activity library, setup instructions, and full source code can be downloaded here.

I actually needed this type of library for a Workflow Studio project I'm currently on.  I coded the activity library to be general enough for anyone to use within their own environments.  The environment I've been using with this activity consists of Workflow Studio 1.1 and SQL Server 2005.  I haven't tested with other versions of SQL Server, but I am providing the full source code to this library in case you need to tweak anything.

There are two activities within the SQL Server activity library:

• SQLSelect activity - used to run SELECT queries on a database.  The output of this activity is a collection containing the query results.  Since the output is a "collection" type object, you can loop through this collection within Workflow Studio using the For Each Object activity and dump the collection contents to an XML file via the ExportToXML activity.
• SQLExecute activity - used to run INSERT, UPDATE, and DELETE queries on a database.  The output of this activity is a string containing the number of records affected by the SQL statement.

There are five properties that need to be set on the SQLSelect/SQLExecute activities:

• Database Server - SQL Server machine hosting the database
• Database Name - Name of the database to connect to 
• SQL Command - SQL statement to execute on the database 
• SQL Username - SQL Server username for connecting to the database 
• SQL Password - SQL Server password for connecting to the database 

The SQL Command property will be set differently based on which SQL activity you are using.  The SQLSelect activity will expect a SELECT statement here.  The SQLExecute activity will expect an INSERT, UPDATE, or DELETE statement here (essentially any non-SELECT query).

The SQL Server activity library was developed using the Workflow Studio SDK:
If you need to review the code and make changes, I highly recommend reviewing my previous blog series on using the Workflow Studio SDK.  This blog series will help you get your Visual Studio development environment up and running so you can make changes to the code. 

For the programmers out there, the activities themselves leverage the standard ADO.NET objects for connecting to a SQL Server database and executing a command.  If you are familiar with ADO.NET, then the code should be fairly straightforward to walk through.

Finally:

When you check out the CDN you'll see the full setup and usage instructions so I didn't restate them here.  The SQL queries you execute can be static (using hard-coded values) or dynamic (based on the bindable properties of other activities within the workflow).  This makes this activity pretty flexible to use in any kind of situation or query you may encounter.  Have fun and I hope this helps you out as well!

Cloud Networking is secure and robust

You can create a complete end-to-end network from one cloud network, running on XenServer, through a VPN to another network in a different cloud. All servers and hosts communicate securely over SSL VPN. Amazon Machine Images are secured by the Amazon infrastructure using security groups.

The proof of concept speaks for itself. Between the Softlayer cloud and the Amazon EC2 cloud is running a site-to-site SSL VPN using Vyatta. All of the images in this architecture are running on XenServer. This proof of concept gives rise to many networking architectures for cloud computing.

The reason for using Vyatta site-to-site SSL VPN between the Softlayer and Amazon EC2 clouds is there needs to be a secure network between the two for the transfer of data. The Vyatta AMI (Amazon Machine Image) can also function as a complete router, firewall and DNS cache. The Vyatta SSL VPN router provides security with scalability. Suppose I wanted to separate the Vyatta SSL VPN from a Vyatta OSPF router, I would just launch another instance of the Vyatta AMI.

As you can see from the network diagram and video, complete routing from the Softlayer cloud to the Amazon cloud network is seamless, without having to buy any proprietary hardware. In fact, it is very low cost compared to traditional network solutions. Virtualized networking is here, it is fast, secure and cheap.

A CloudBurst happens when Citrix Workflow Studio determines that one of the devices in the Softlayer Cloud has reached a high watermark. WFS then instructs the NetScaler VPX to start sending traffic to the Cloud - CloudBurst.

To get your own cloud, go here

Configurations used

Vyatta SSL VPN (V1) - Datacenter Configuration
Vyatta SSL VPN (V2) - Cloud Configuration
XenApp VPN Client - Cloud Configuration

Links for this solution

Vyatta for XenServer - go here
Amazon EC2 - go here
XenServer is Free! - go here
XenApp - go here
Workflow Studio - go here
XenApp VPN Client - go here
Dell Server - go here
IP Addresses - go here

Watch This

Read more news like this.

Its powerful AppExpert!

Microsoft, Intel & Citrix: Dynamics of Enterprise Virtualization

An interactive discussion led by Doug Brown

--------------------------------------------------------------------------------------

Attend this lively discussion with virtualization experts David Greschler, Iddo Kadim & Simon Crosby on the dynamics of enterprise virtualization. Register here.

You can register here. I hope to see you and the Citrix Angels there.

Follow me on Twitter.

Provisioning Services (PVS) solves many of the existing problems of datacenter and desktop administrators by reducing the number of unique images that need to be managed. Rather than dealing with application installs, conflicts, patches and errors on hundreds of different servers and/or desktops, they can deal with a single streamed golden image that remains pristine regardless of the changes made by users. 

However, even though this new approach solves many of the issues that have been plaguing IT administrators for years, a new concern comes up. In my role on the Consulting Solutions team, I've been asked the same question by clients and coworkers alike: "If I have a pristine, unchangeable image, how do I deal with antivirus updates and patching?"

The admin guide (page 109) gives detailed instructions on how to do exactly that. It goes, on a high level, something like this:

• Load a machine with a copy of the production vDisk in private mode
• Make your updates
• Shut it down and put it into standard mode
• Finally, increment the version number

It's simple, and the process is easy to do manually - if you only have to add updates to a single vDisk every once in a while, then there's no problem. However, Microsoft comes up with security updates on an almost weekly basis, and new anti-virus definitions come out nightly - most companies aren't comfortable leaving machines unprotected for extended periods of time, and IT administrators don't want to spend time doing a manual, repetitive task on a daily basis. Add in a few different vDisks for different workloads, and this can quickly grow into a time consuming process. How do we reduce the time-cost of keeping vDisks fully updated?

Enter Workflow Studio. Workflow Studio (WFS) is designed to reduce repetitive tasks into easy-to-manage workflows that can be run either on-demand or on a scheduled basis. Using Workflow Studio and PVS's built-in CLI, we're able to create a script that automates the entire process of updating vDisks, allowing for easy nightly or weekly scheduling with less chance for human error.

In order to be device/hypervisor agnostic, the script utilizes an always-on machine designated as an "update" machine, which allows PVS to use its own functionally to restart the machine when necessary. Updates can come in and automatically be implemented during the course of the day or week, and applications can be added or removed by any vDisk admin. Then, at the scheduled point or on a manual call, the script shuts down the server, makes a copy for future updates, and switches out the disks using the Auto-Update feature. After the next reboot, desktops will switch to the newest disk, no additional manual intervention required.

Additionally, the "update" machine can be given a "personality" that then executes scripts inside the image that aren't run on other machines - such as perhaps automatically copying files from a share, or enabling Microsoft's Auto-Update, or any number of other actions. Workflow Studio is a component of making the script function appropriately, and it has the added benefit of allowing role-based access to the Workflow, as well as built-in scheduling. However, if Workflow Studio cannot be deployed, then the components of the script can be broken apart and used solely with Windows Scheduler.

Grab the script at the Citrix Developer Network. If you have questions, comments, or ideas for improvement, leave me a comment or ping me on Twitter @mcbogo.

Best,
Michael Bogobowicz
Senior Consultant @ Citrix Consulting Solutions

If there are other Citrix accounts or Citrix employees you follow on Twitter, please post them in the comments.

A great way to learn how to use the Workflow Studio SDK is to look at code examples that you can try and implement yourself.  The Activity Developer's Guide provides a few simple activities to help get you started.  If you are looking for a more robust activity sample to set up and review, I just recently posted a sample activity called AppList to the CDN site for you to download.  The AppList activity, setup instructions, and full source code can be downloaded here.

What is the AppList activity?
The AppList activity is a sample activity based on MFCOM that retrieves the list of applications that are published within a XenApp 4.5 farm.  This activity communicates with a XenApp 4.5 server, so you'll need a XenApp 4.5 farm in order to run and test this activity.  Even if you do not have a XenApp server handy, you can at least review the source code to get more details of how to code your activities.

The output of this activity is a collection of application objects, where each application object contains details about a published application in the farm.  By returning a collection of objects, you can use the other activities within Workflow Studio to loop through this collection or output the entire collection contents to an XML file (see picture below).   

Sample workflow
In the workflow pictured above, the "AppList" activity retrieves the list of published applications.  The output of this activity is then tied to the "ExportToXML" activity to export the contents to an XML file.  The XML file will contain a list of the applications published within the XenApp farm along with their various attributes (executable path, description, window size, audio setting, etc). 

The screen shot below shows a sample XML file that is generated. The first application listed here is "Notepad", along with various attributes for how Notepad was published.  If you want a quick way of archiving how all of your applications are published, this is a nice and simple way of doing so without having to visit the properties of each published application within the Access Management Console. 

How is this sample useful?
I've spent most of this blog explaining what this activity does.  But the real reason for posting this activity is the source code.  Feel free to open the source code inside Visual Studio to get an idea of how this type of activity is coded.  Take a look at the MFCOM code for pulling back the list of published applications.  MFCOM is a pretty robust API and I only tapped into a few objects to make this activity happen.  You can do so much more with it to perform other actions on XenApp.  In the near future I hope to provide more blogs about this particular example and explain the various sections of the code.  In the mean time, feel free to try to get it up and running, step through the code, and experiment (test environments only please!). 

What is MFCOM?
For those of you not familiar with MFCOM, MFCOM is the name of the API provided by XenApp for performing various administrative actions on a XenApp farm via code.  MFCOM (MetaFrame Component Object Model) has been around for quite some time across several different releases (XenApp, Presentation Server, and MetaFrame).  When you use MFCOM, you'll quickly realize that a lot of the actions that you can normally do within the Access Management Console you can also do with MFCOM API calls.

MFCOM has a client/server architecture where the MFCOM client is the client machine running your MFCOM program and the MFCOM server is the XenApp Server itself.  In the case of our Workflow Studio activity discussed here, the Workflow Studio machine is considered the MFCOM client.  MFCOM clients communicate with MFCOM servers via DCOM calls.  When you install MFCOM on your Workflow Studio machine, the installation will have you specify the XenApp server you want to communicate with via DCOM.  You do not need to make any updates or changes to your XenApp server as the server-side MFCOM components are already implemented by the XenApp installation.

Additional Resources:
If you want more information on the Workflow Studio SDK, feel free to check out my SDK blog series.

If you want to step through the AppList source code while running the activity within Workflow Studio, you should check out this post on how to set this up.

It's now time to wrap up this series on the Workflow Studio SDK and talk about a pretty handy topic for debugging the activities that you create within Visual Studio.  If you have developed code in the past, you know that one of the most handy ways to debug your code is to step through your code in real-time as the program is running.  As you step through your code, you can check the programming logic and make sure it is executing as expected.  You can also "watch" variables as they are declared and populated with values.  Watching variables is especially important if they are being filled from backend database calls or APIs. 

In this article, I'm going to show you how you can step through your Visual Studio code in real-time as your activity is being executed within the Workflow Studio Designer.  As always, I'll keep the process simple and break it down into the following steps:
• Step 1 - Initial setup
• Step 2 - Place break points in the Visual Studio project
• Step 3 - Verify the project build settings
• Step 4 - Attach Visual Studio to the WorkflowExpressRuntime.exe process
• Step 5 - Start the workflow within the Workflow Studio Designer
• Step 6 - Step through your code in Visual Studio when your break points are hit
 

Step 1 - Initial setup
Workflow Studio needs to be installed on your Visual Studio development machine.  This allows Visual Studio to attach to the various Workflow Studio processes for stepping through your code (as discussed in a later step).

Next, when you are ready to test your workflow and step through your code, you essentially need two programs running.  First, you need your Visual Studio project opened so you can step through your code.  Second, you need the Workflow Studio Designer opened so you can place your activity in a workflow and initiate the test.  If you do not know how to add your activity to the Workflow Studio Designer, please refer to my last blog (Part 4) on how to test your new Activity DLL within Workflow Studio. 

I'm going to use the same "AdvancedDelay" example that I discussed in the last blog to illustrate the step-through process.  My workflow is shown below.  The activity I'm trying to step-through is the AdvancedDelay activity.  This activity inserts a delay into the workflow for a specified amount of time (about 5000 milliseconds in this example).  When this activity completes, a message box will pop up via the MessageBox activity.

Step 2 - Place break points in the Visual Studio project
Once you have your activity placed in a workflow within the Workflow Studio Designer, you can place break points in your Visual Studio project.  In this example, I placed a breakpoint in the line of code that is actually performing the delay here.  Within the execution section of my activity project, the Sleep() call is actually performing the delay.  I want to step through this code myself to make sure it works while my workflow is running.

Step 3 - Verify the Project Build settings.
Your Visual Studio project needs to be set up in a certain way in order for you to step through your code in real-time.  The following two screen shots show how I have my project set up.  You can access these same screens by going to the Properties of the activity project. 

I actually did not have to make any changes to the project settings as is shown here - my project was already set up correctly based on the project template.  Your project is most likely already set up this same way as well.  I really wanted to give you these screens here for reference in case you were playing with these properties during the development stage.  A few things you'll need to check at the least:
• Your project should be in "Debug" mode instead of "Release" mode. 
• The "Optimize code" setting should be disabled
• In the Advanced dialog, the "Debug Info" setting should be set to "full".

Step 4 - Attach Visual Studio to the WorkflowExpressRuntime.exe process
Next, navigate to Tools-->Attach to Process within Visual Studio.  In the Attach to Process dialog, select "WorkflowExpressRuntime.exe".  This is the process used by the Workflow Studio Designer for executing workflows.  If you do not see this process listed, it means that you do not have the Workflow Studio Designer open.   

If you are curious about what the "WorkflowRuntimeHostService.exe" process is, that is the process used by Workflow Studio for executing regular jobs.  If you want to step through your code when executing a job instead of using the Workflow Studio Designer, you can attach to that process instead and then run a job containing this activity.  It's pretty cool we have some flexibility here for stepping through our code in either situation!

Step 5 - Start the workflow within the Workflow Studio Designer
Once Visual Studio is attached to the correct process, we are ready to begin our test.  Start the workflow within the Workflow Studio Designer.  When our custom activity is executing (AdvancedDelay1), any break points that are hit within our code will automatically bring up Visual Studio at those break points.

Step 6 - Step through your code in Visual Studio when the break points are hit
Our break points are now getting hit and we can begin stepping through our code.  The standard way to step through your code in C# is with the following keys - Step Over (F10), Step Into (F11), Step Out (Shift + F11), and Continue Execution (F5).

In our example below, we set a break point when our Sleep() command actually performs the delay.  If you execute this statement, the sleep will actually occur for the specified amount of time as specified within the activity (which is 5 seconds here). 

Final remarks:
You should now be well on your way for creating custom activities within Visual Studio, testing them, and stepping through your code for advanced debugging.  I hope this series was helpful and stay tuned for more information on using the SDK.  If there are certain topics that you would like us to focus on in the future, please let us know!

Blogs in this series:
• Getting Started
• Setting up your Visual Studio development environment
• Anatomy of a Workflow Studio activity project
• Testing your Workflow Studio activity project
• Stepping through your Visual Studio code (this one)

After attending Citrix Synergy last week, I wanted to come back and complete this 5 part series that I started before the conference began.  In the last article (Part 3), I discussed the anatomy of a Workflow Studio project.  The information in that article should help you get started in coding your activities.  Next on the list is to discuss how to test your activity project within Workflow Studio once you've completed a bulk of the code in Visual Studio.

If you want to follow along with me, you should create the AdvancedDelay activity project as outlined within the Workflow Studio Developers Guide.  The AdvancedDelay activity inserts a delay into your workflows for a specified amount of time.  As discussed in the Developers Guide, the code that you add is pretty straightforward.  You are just adding a property to specify the delay time and a sleep command in the execution section to perform the actual delay.

To make the testing process simple, I'll break it up into the following sections.  Each section is discussed in more detail below.
• Before you begin
• Build your solution in Visual Studio
• Copy the activity DLL to the Workflow Studio activities folder
• Launch Workflow Studio and create a new workflow project
• Add the activity to the workflow project and run/test the workflow

Before you begin
Before you compile your project, you should check out a few settings that are placed at the top of your activity file.  If you are following the AdvancedDelay example, open the AdvancedDelay.cs file and check out the activity settings at the top.
• DisplayNameAttribute - this is the name of the activity as it will appear in the Workflow Studio Designer.
• ActivityTreePath - this is the location that the activity will be placed in within the Workflow Studio Designer activity pane.  In the example below, I'm placing this activity within the General/Custom Activities folder.  You can place this activity anywhere in the activity pane.

Build your solution in Visual Studio
You build the solution like any other Visual Studio project.  Just navigate to Build-->Build Solution in the file menu.  Verify that the build succeeds within the Output window at the bottom of Visual Studio. 

Copy the activity DLL to the Workflow Studio activities folder
After you compile the project, a DLL is produced that contains your activity project code.  This DLL is typically found in a sub-directory where your Visual Studio project resides on the system.  In my environment, this DLL was found in my user profile since my Visual Studio projects are all written to my user profile ("C:\Documents and Settings\Administrator\My Documents\Visual Studio 2008\ProjectsAdvancedDelay\AdvancedDelay\bin\Debug").

Copy the activity DLL (AdvancedDelay.dll in this example) and paste into "C:\Program Files\Citrix\Workflow Studio".  Your DLL will need to be here in order for Workflow Studio to use it. 

Note:  If your project happens to reference other 3rd party DLLs that you added manually to the project (for example, mfcom.dll for tying into XenApp), you'll need to add these extra DLLs to the above folder as well.  This allows the Workflow Studio Designer and Runtime to pick up these references to allow you to run the activity.  In our example here, our AdvancedDelay activity project is pretty simple and we didn't add a reference to another 3rd party DLL so we can bypass this action.

Launch Workflow Studio and create a new workflow project
With your activity DLL now in the right location, launch Workflow Studio and create a new workflow project.  I typically like to create new workflow projects for testing activities, but you can also edit existing workflow projects if you desire.

Add the activity to the workflow project and run/test the workflow
The Workflow Studio Designer should now be displayed.  If this is your first time testing the activity, the activity will not yet be displayed within the activity pane.  To add the activity as an available activity within the pane, navigate to Tools-->Choose Activities.  Browse to the activity, verify it is selected, and close the Choose Activities dialog.  Notice the "Toolbox Location" field on this dialog.  This is the location we specified in our code where this activity will be placed within the activity pane.

Verify the activity is now listed within the activity pane.  Drag the activity to the designer surface and configure the properties as needed.  Start the activity and verify that it runs as expected.  

In the example below, I configured the AdvancedDelay activity to run for 5000 milliseconds (5 seconds).  I then placed a message box beneath the delay.  When running the activity, it should take about 5 seconds for the message box to pop up.  If it does, I know this activity is running as expected. 

One final note:

If you find that you need to make code changes to your activity, just open up Visual Studio, update your code, and recompile your project.   You'll then need to place the updated DLL back in the C:\Program Files\Citrix\Workflow Studio folder in order for Workflow Studio to pick it up.  If you get an "Access Denied" type message, this typically means that you'll need to close Workflow Studio (Console and Designer) in order to successfully overwrite the existing DLL that is in that location.  The Workflow Studio executables will have a lock on that DLL if you just used a previous version of that DLL in a workflow.

Once you can copy the updated DLL to that location, re-open Workflow Studio, and edit your workflow project.  When you edit your project, your workflow will automatically be referencing the new DLL.  You don't have to re-browse for the activity and add it to the activity pane.  Make the appropriate property changes and workflow changes and re-execute your workflow. 

In the next blog, I'll explain how you can step through your code in real-time in case you wanted to perform more robust troubleshooting at this stage.  Stay tuned!

Blogs in this series:
• Getting Started
• Setting up your Visual Studio development environment
• Anatomy of a Workflow Studio activity project
• Testing your Workflow Studio activity project (this one)
• Stepping through your Visual Studio code

Citrix XenDesktop is a finalist in the Virtualization category for the "Best of TechEd" award from Windows ITPro magazine.

If you are attending TechED 2009 in Los Angeles, please vote for XenDesktop as the "Best of TechED" at this link -

http://windowsitpro.com/awards/teched_finalists_2009.html

(you must be logged into to MSTechEd.com and attending the event to vote).

Follow the Twitter feed for "Best of TechEd 2009" here.

Follow the official TechEd 2009 Twitter feed here

Everyone who was at Snyergy last week wanted the link to how to do snapshots in XenServer. Here is the link to Shannon's PowerShell snap-in:

http://shannon.neutex.net/2008/11/06/hot-off-the-compiler-powershell-snapin-for-xenserver-snapshots/

I will also post a 'how-to' guide on how to convert this to an activity library.

NetScaler Virtual Machine

Today, Citrix announced a virtual appliance version of their NetScaler Application Delivery Controller - the NetScaler VPX, the first of its kind. All of the functions that traditionally were performed in the datacenter can now be performed in the domain of virtual machines. Load balancing, application acceleration, security and offload functionality are now available as a XenServer virtual appliance.

Industry's first Virtual Load Balancer

No other vendor offers this type of software as a Virtual Appliance. By making advanced web application delivery functionality available as a virtual appliance, NetScaler VPX drives convergence of virtualization and networking. In the continued movement toward simple and affordable convergence, NetScaler VPX makes sophisticated application delivery functionality available to any size organization. This breaks down deployment barriers for all types of organizations.

What used to run on a proprietary piece of hardware now runs on any hardware that supports virtualization. Because there is no physical appliance to ship, install or move VPX can be installed at a moment's notice, on any server running XenServer.

The challenge

• Check out The Great NetScaler VPX challenge and get $10,000.
• The Tech Preview will be downloadable from citrix on May 18th.
• If you are running VMWare, you need to run Xen - and why wouldn't you, Xen is free.
  

NetScaler VPX

It's powerful - AppExpert!

I just posted an article on the components that are pre-requisites for Workflow Studio and how you can extend the ISO image we provided to include all components if you wish:

http://community.citrix.com/display/wf/Workflow+Studio+Pre-Requisites

I find it useful to have a CD image with everything on it that auto-runs, and thought that others might as well.

Now that we have released Workflow Studio 1.1, I wanted to point out that we also have articles with details about what is available in each activity library. There are 8 different libraries listed in the installer - click on the item below to view the activities available with each one:

• Citrix NetScaler
• Citrix XenServer
• Active Directory
• Group Policy
• Networking
• Windows
• WMI
• Workflow Math Functions

Note: The Group Policy activity library requires the Microsoft Group Policy Management Console (GPMC) to be installed before it can be used. You can get GPMC here:
http://www.microsoft.com/downloads/details.aspx?familyid=0a6d4c24-8cbd-4b35-9272-dd3cbfc81887&displaylang=en

When you create a new Workflow Studio activity project within Visual Studio, the templates provide you with a pretty comprehensive and documented activity class file.  In the screen shot below,  I minimized a lot of the code, but you can see the primary sections of the activity file within the project. 
The primary sections of this file are listed below:

• Using statements
• General activity properties
• Class constructor
• Standard properties
• Dependency properties
• Activity execution section
• Property validation section
  

In this blog, I'll discuss at a high level each of these primary sections.  I won't detail the meaning of all of the attributes and properties that are present as they are pretty well documented within the Activity Developers Guide and within the comments of the class file itself.  This blog is really meant to give you an overview of what is actually in here so you can navigate to the appropriate section as you develop your activity.

1. Using statements:
There is a long list of using statements at the top that define the references for the class.    What you should notice here is that the last five all come from Workflow Studio.  If your activity references a third party DLL, you'll most likely need to add more using statements to make sure your references are all in place.

using Citrix.WorkflowStudio.Common;
using Citrix.WorkflowStudio.CustomActivities.Designers;
using Citrix.WorkflowStudio.CustomActivities.Editors;
using Citrix.WorkflowStudio.CustomActivities.Serializers;
using Citrix.WorkflowStudio.User;

2. General activity properties:
Right beneath the using statements is a section called "Attribute Definitions and Comments".   This section contains a series of general properties for the activity.  The comments provided within this section explain these settings pretty well.  A few of them you should take note of are below.

[DisplayNameAttribute(@"AdvancedDelay")]
This is the name of the activity displayed within the Workflow Studio Designer.

[Description(@"This activity will delay for a specified amount of time")]
This is the description of the activity displayed within the Workflow Studio Designer.  When you select the activity in the Activity pane, the description is shown in the lower-left corner of the Designer.

[ActivityTreePath(@"Windows PowerShell/Utilities")]

This is the folder location for where the activity is placed within the Activity pane of the Workflow Studio Designer.  A forward slash is used to specify a subfolder.

3. Class constructor:
The class constructor is next.   This code gets executed when the activity is placed on the drag-and-drop surface within the Designer.  The most common thing you'll need to do in the constructor is to initialize the values of your properties. 
 

4. Standard properties:
The section for standard properties is listed after the class constructor.   A sample one is provided in the template which is commented out.   This sample is mainly here to give you the syntax for defining a sample property if you would like to use one within your code.

What you really need to know is that there are two types of properties you can define within the class - standard properties and dependency properties.  The primary difference between them is that dependency properties are "bindable" to other activities whereas standard properties cannot be bound.   Dependency properties have much more flexibility than standard properties due to being bindable.   In the Designer, bindable properties allow their values to come from other activities.  Bindable properties can also be used as input to properties of other activities.  Due to this flexibility, dependency properties are much more common to use than standard properties and you should probably define all of your properties as dependency properties first, then fall back to being standard if the bindable behavior is not desired.

5. Dependency properties:
The dependency property section is listed after the standard property section.  As stated in the section above, dependency properties are much more common to use than standard properties since they can be bound to the properties of other activities.  Their flexibility makes them a much better choice in most cases.

The activity template gives you a series of sample dependency properties that are commented out.   I won't go into all of the code for this property here (it's explained pretty well within the Activity Developers Guide).  I'll just highlight a portion of the settings here...

[DefaultValue("0")]
This is the default value of the property.  Default values can also be set within the class constructor.  When using the Workflow Studio Designer, if the property value is ever set to something different than this default value, the value is shown as bold within the Designer to indicate it has changed.

[DisplayName(@"DelayTime")]
This is the name of the property as shown within the Workflow Studio Designer.  This name should be intuitive and easy for admins to understand.

[Description(@"Amount of time to sleep in ms")]
This is the description of the property as shown within the Workflow Studio Designer.  When you select the property in the Designer, this text is shown in the lower-right corner of the Designer.

[Browsable(true)]
This setting defines whether this property is visible within the Workflow Studio Designer.  If set to true, it is displayed within the Designer when the activity is selected.  If you don't want admins to know about this property or see it within the Designer, you can set browsable to false.

[InputAttribute]
A property can either be an input property or output property.  Input properties define some value that is inputted into the activity.  Output properties define something that is returned by the activity after the activity is executed.  The use of the [InputAttribute] or [OutputAttribute] declaratation defines what icons should be used for this property in the Workflow Studio Designer.

6. Activity execution section:
After all of the properties are defined, the next section is the Execute() function.   This function gets called when the activity is executed by Workflow Studio.  All of the execution logic should go into this function.    

The Execute() function provides a try/catch block.  Put all of your execution logic in the try block.  Don't touch the ExpandStringProperties() call at the top as this function will dynamically retrieve the property values set within the Workflow Studio Designer at runtime so that you can use them within the try block.

7. Property validation section:
The last section of the file defines how property validation is performed within the Workflow Studio Designer.  If you have used the out-of-the-box activities within the Designer, you may have noticed that some activities have required properties that need to be set in order for them to be valid.  These properties provide a red X or yellow warning icon to inform admins that they are required or desired to be set.  You can set up the same type of functionality for your properties through the code in this section.  There are a lot of comments within this section to explain how to set up your properties for validation, so I won't go into this here.   I may blog about this in the future as it could be a big discussion on its own.

Blogs in this series:

• Getting Started
• Setting up your Visual Studio development environment
• Anatomy of a Workflow Studio activity project (this one)
• Testing your Workflow Studio activity project
• [Stepping through your Workflow Studio activity project code]