New Tolly report shows that NetScaler 9.1 with nCore technology significantly outperforms F5's latest software release, BIG-IP v10. The results were astounding. Tolly conducted a battery of standard load balancing and acceleration tests and found that F5 introduces at least 3X more latency than NetScaler across all test scenarios. The report details the impressive performance NetScaler's nCore technology and highlights a significant deficiency with F5's architecture, namely latency. For example, it takes F5 2533.4 milliseconds to deliver an 8KB object versus 1.5 milliseconds for NetScaler. That's a significant negative impact to the end user experience and productivity, which can directly affect a company's bottom line.

To view the full Tolly report, click here

Tap into the power of AppExpert!

View Online | Add Comment

The Citrix C3 Lab with Amazon AWS now hosts XenApp Fundamentals on Windows 2003 Server with no installation required. The C3 Blueprint describes how to set up the environment so you can be testing or demoing apps delivered from the Cloud in minutes. XenApp Fundamentals is the new name for Access Essentials which is an ideal solution for SMB's looking for a simple way to administer and deliver Windows apps to office PC's , Thin Clients, Desktop Appliances, home PC's, Mac's, Laptops or mobile devices. Only a Receiver client is required on the endpoint, the applications get installed on a single XenApp server and are simply published to the users you want to access the app. The Admin console is wizard driven and easy to use, with the option for advanced features only if required.
Putting XenApp Fundamentals in EC2 makes everything even easier, no servers to buy or configure, the image is pre-built and ready to run. The Amazon plus Windows cost is only 12.5 cents per hour while you are using it. Even if you leave it on 24 hours a day all month that only $93 /mo ( plus storage and bandwidth, which is nominal for testing ). We have also included 2 User XenApp evaluation Licenses, so there are no other downloads or registrations required. Once you set up an Amazon account and start the server you only need to install your own apps in the image and click to publish to any user with any device.

This video walks you through every step to get started in 15 minutes.

( thanks to Simon Waterhouse for building the image )

Let us know of any questions or idea's on your use case in the comments below.

http://twitter.com/chrisfleck

View Online | Add Comment

If you have been following some of the recent blog posts about Nirvana Devices and Nirvana Phones, you can get a better idea of what we are talking about in this video clip. Conceptually the Nirvana Phone takes the Smartphone to the next level by solving the existing limitations of small screens and keyboards. There are now some new devices that are close to making this possible, especially in combination with a Virtualized Desktops and applications like XenDesktop and XenApp.
See all the Nirvana Phone blog posts

View Online | Add Comment

How can you win 2 Grandstand Tickets to the Singapore Formula One Grand Prix!
Attend Citrix iForum Singapore 2009, stay for the closing drinks and prize drawing, and you could win our major prize of two 3-day passes and access to the Pit Grandstand at the Singapore Formula One Grand Prix!

Click below to learn more and register for the event:
http://www.citrixiforumsingapore.com/

View Online | Add Comment

Announcing Asia's inaugural Citrix iForum! Citrix is pleased to announce that iForum is coming direct to the hub of Asia for the first time ever! On July 28th 2009 iForum will be launched at the Suntec Conference Centre in Singapore.

Date: 7/28/2009
Location: Singapore
Hosted by: Citrix Systems
Venue: Suntec Convention Centre

Citrix iForum Singapore is full-day must attend event that offers unparalleled access to the vision and technology direction of the industry's application delivery and virtualization thought leaders and delivers technical breakout sessions, powerful demos, tips and tricks, architectural insights, best implementation practices and much, much more.

Click below to learn more and register for this event:
http://www.citrixiforumsingapore.com/

View Online | Add Comment

One of the most common questions I've heard on Workflow Studio is how you can initiate the execution of workflows from an ASP.NET web page.  The web is a great platform for delivering applications to end-users, and more and more applications are being delivered by a web browser each day.  How cool would it be to kick off a workflow within Workflow Studio based on a user-action performed inside a web application?  In this blog I'm going to show you how to do it and I'll give you the tools to customize this further to meet the needs of your application.

Example Usage
Before I go into the details about how the sample web application works, I want to quickly provide an example of why you may want kick off workflow execution from a web page.  As you think about your business, ask yourself what it takes to get a new hire set up with new credentials across all of the systems in your environment.  You need an Active Directory account, application accounts, HR accounts, credentials supplied to your single sign-on solution, etc. 

To accommodate this scenario, you can build a web page that presents a form to an admin to gather details about a new user, what groups they should belong to, and what applications/resources they need to access.  This web page can call a workflow within Workflow Studio passing in the details about the user, and the workflow can automate the provisioning of the Active Directory account and application accounts across various systems.  That's a pretty powerful system and would greatly simplify a lot of the complexities for performing those actions manually.  Building that type of workflow might take some custom development effort, but Workflow Studio 1.1 already provides activities for provisioning user accounts in Active Directory to help get you started.

ASP.NET Web Application Overview
The sample web application that I'm providing here is functionally equivalent to the sample Windows application that I provided in the last blog.  To compare and contrast the differences between automating workflows with a Windows and Web application, I wanted to keep the functionality and UI mainly the same.  The web version of the application is shown below.

I describe my adventures for coding this application in the bottom of this article.  To sum up, this application really has two parts.  You have the ASP.NET application that contains the ASPX page and code-behind page.  You also have a COM object that you need to install inside Component Services. (I have steps for doing all this below). 

When you click the Execute Workflow button inside the web page, the ASPX page gathers what workflow you are executing and what runtime it is deployed on.  It then calls the COM object to actually execute the workflow.  The COM object uses the Workflow Studio Powershell cmdlets for communicating with Workflow Studio.  I was getting security issues when I tried to run those functions within the context of IIS.  By creating a COM object and placing that object within Component Services, I was able to overcome the issues I was having. 

For more information on how this application works, feel free to check out the previous article of this blog series.  I described in great detail how the Windows version of this application functions, so I'll refer you to that article for the extra details.  For more information on why I needed to build the COM object, refer to the Lessons Learned section at the bottom of this article.

Downloads:
Download the ASP.NET web application IIS files
Download the ASP.NET web application source code

Prereqs for using the ASP.NET application:
Before you set up this web application on your Workflow Studio machine, you will need to have the following installed and/or configured beforehand:

• Workflow Studio 1.1
• Powershell 1.0
• IIS installed with ASP.NET enabled
• IIS configured with the ASP.NET v2.0.50727 web service extension set to Allowed
• Determine or specify an account within the Workflow Studio Console for executing the workflows.  This is done within the Security section.
• Pre-deploy the Workflow you want to execute within the Workflow Studio Console.  See Part 1 of this blog series for more information.

Setting up the ASP.NET application:
To set up this sample web application, follow the steps in the sections below.

Application Setup

• Copy the IIS files from the ZIP above to C:\Citrix (or any accessible location on your Workflow Studio machine)
• Update the web.config file with the appropriate impersonation account.  This account should have permissions to execute workflows within Workflow Studio and should be the same account that is added to Component Services later in these steps.  

IIS Setup

• Open IIS and create a virtual directory for the application.  Point the virtual directory to the folder specified above.  Enable script execution on the directory.
• View the properties of the virtual directory in IIS. In the ASP.NET tab, set the ASP.NET version to 2.0.50727.

Component Services Setup

• Launch Component Services by navigating to Start->All Programs->Administrative Tools->Component Services
• Within Component Services, navigate to Computers->My Computer->COM+ Applications.  Right-click COM+ Applications and select New->Application
• The wizard now starts.  Create an empty application
• Specify a name such as "WFSCOM" and select Server Application
• Set the application identity to a Workflow Studio admin account
• Create a new role called "Access"
• Add the Workflow Studio admin account to the Access role
• Complete the wizard
• After the COM+ application is created, add a new component to the COM+ application.  Navigate to Computers->My Computer->COM+ Applications->WFSCOM->Components.  Right-click Components and select New->Component.
• The wixard now starts.  Choose to install a new component
• Browse to the WFSCOM.dll file (C:\Citrix\WFSWebClient\bin\WFSCOM.dll).
• Complete the wizard
  

You should now see the WFSCOM.WFSAction COM object listed within the Components section.  In the Interfaces section, there is an inteface called IWFSAction that contains the methods of our COM object.  The ASP.NET code calls the COM object to execute these methods.  Since this object resides inside Component Services, these methods run outside the context of IIS under the Workflow Studio admin account that we specified above. 

Lessons learned from developing this application
Developing an ASP.NET web application that executes workflows actually turned out to be a little more difficult than building the equivalent Windows application.  With a Windows application, the application runs under the context of the logged-on user account. If that logged on user had permissions to execute workflows inside Workflow Studio, that user would be able to use the custom Windows application without issues.  With a Web application, the application runs under the context of IIS.  You can modify the account that runs a web application in a few places.  (1) Editing the properties of the virtual directory or (2) Including a <identity impersonate="true"> tag inside the web.config file of the ASP.NET application. 

Armed with that knowledge I set out to build the ASP.NET application.  The approach I initially took was to take all of the code I had inside the Windows application and paste it into the ASPX page and code-behind page.  The only thing I changed was I replaced all of the Windows controls with Web controls and I changed how I sent messages back to the user.  When debugging this application inside Visual Studio, my application actually ran fine.  However when I deployed it to IIS and ran it, that was a different story.  I kept on getting Access Denied messages whenever I wanted to retrieve the workflow list or execute a workflow.  Something inside those functions was causing me issues...

After much debugging, I deduced that the code that was causing the Access Denied messages was when I was trying to get a reference to the deployed workflow inside my PowerShell SDK code.  For whatever reason, IIS just did not have the permissions to execute the Workflow Studio Powershell cmdlet called get-deployedworkflow.  I put this section of code below so you are aware of which section I was having issues with.

//Get reference to the deployed workflow. We are executing the Powershell command below: //$workflow = get-deployedworkflow -workflowruntime $runtime -workflowname $strWorkflowName -includeschedule l_objPipeLine = l_objRunspace.CreatePipeline(); l_objCommand = new Command("get-deployedworkflow"); l_objCommand.Parameters.Add("workflowruntime", l_objRuntime); l_objCommand.Parameters.Add("workflowname", l_strWorkflowName); l_objCommand.Parameters.Add("includeschedule"); l_objPipeLine.Commands.Add(l_objCommand); l_objCommandResults = l_objPipeLine.Invoke(); //Get Access Denied here when running this code in IIS PSObject l_objWorkflow = l_objCommandResults[0]; l_objPipeLine = null    

After playing with the Virtual Directory account settings and web.config impersonation settings for a while, I still was not able to get past the Access Denied message.  I would have thought that setting the web.config <identity> tag to the Workflow Studio admin account would have done the trick, but I still received that error message.  So I then I went to Plan B and thought of a different approach.  What if I take that particular code outside of IIS and put it into a more controlled environment where I can run it under whatever account I want and not have to worry about IIS getting in the way? 

That solution was Component Services.  I'm not an everyday developer (probably have one development project a year), but I remembered using Component Services many years back with a MFCOM application I wrote.  (MFCOM is the XenApp API).  With that application, I wanted to be sure that my MFCOM code would run under the context of a XenApp admin account and not the logged on user account.  So creating a COM object and placing that object within Component Services allowed me to run it under whatever account I needed.  With Component Services, you also have the choice of running the COM object in-process as a library application or out-of-process as a server application.  When you run it out of process, it is executed within a different memory space than the calling application.  Creating a COM object and executing it as a server application under the context of a Workflow Studio admin account was the missing ingredient for the Web Application that I was building.  Since it runs out-of-process, IIS can't get in the way and mess with those security permissions any more!

Although most of the Workflow Studio cmdlets functioned fine when running within IIS, I decided to move the entire Powershell SDK functions themselves to the COM object that I would run within Component Services.  Although this sounds really complicated, the good news is that I've done all the work for you.  The COM object that I am providing within this article has all the functions you need for executing a workflow.  If you want to create your own ASP.NET application that executes workflows, you just need to add my COM object to Component Services on your Workflow Studio machine, and then call the methods of the COM object inside your ASPX page.  If you are reading this article, I would venture to guess that you might have quite a bit of experience in working with ASP.NET so you should have the tools you need to proceed from here. 

About the source code:
The source code above includes both the ASP.NET web application and the COM object for executing the workflows.  Your development machine will need Visual Studio 2008, Workflow Studio, Powershell 1.0, Powershell SDK, and IIS. 

If you want to step through the code within Visual Studio, you'll need to place the COM object within Component Services on your development machine.  You can follow the manual steps above for doing this or use the regsvcs utility.  To use regsvcs.exe, open the Visual Studio command prompt and type a command such as this:

regsvcs /c "C:\Documents and Settings\Administrator\My Documents\Visual Studio 2008\Projects\WFSWebClient\WFSCOM\bin\Debug\WFSCOM.dll"    

I tried to code the COM object so that you wouldn't need to make any changes to it if you just wanted to execute workflows on Workflow Studio.  If you do need to make changes to the COM object for any reason, remove the COM object from Component Services.  If you placed the COM object within the global assembly cache (GAC), remove it from the GAC as well.  (The GAC resides in C:\Windows\Assembly.  Just right-click on the WFSCOM assembly to un-install it).  Then open the Visual Studio solution and make changes to the WFSCOM project as you need to.  Re-compile the project.  When you are ready to re-deploy the COM object, add WFSCOM.dll to the global assembly cache (GAC) to get a new type library (.tlb file).  To add it to the GAC, just execute a command such as below.  Then re-add WFSCOM.dll back to Component Services using the regsvcs command above.  If you open Component Services, you should now see the WFSCOM COM+ application listed.

gacutil.exe /i "C:\Documents and Settings\Administrator\My Documents\Visual Studio 2008\Projects\WFSWebClient\WFSCOM\bin\Debug\WFSCOM.dll"    

I hope this blog series on automating Workflow Studio will help you out with your projects.  Happy coding!

Blogs in this series:
Using Powershell to automate workflow execution within Citrix Workflow Studio
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 (this one)

View Online | Add Comment

In episode 85, Douglas Brown interviews Paul Ardoin, Director of Marketing and Chuck Fritz, CEO at visionapp. Doug, Paul, and Chuck discuss visionapp?s application / server deployment / automation solution for Citrix, Terminal Services, and all around Windows environments, gives us an introduction to their new OpsQuick solution, plus much more....

This is the third part of a four-part series on automating workflow execution within Citrix Workflow Studio. In the first two parts of the series, I discussed how you can create Powershell scripts to execute workflows. ...

I’ve been writing about remote display protocols for over six years now. In that time I’ve written about performance, user experience, bandwidth, and latency. I’ve written about the importance of the display protocol in a desktop replacement...(read more)

Introduction:

Multiple monitor support for Remote Desktop Services allows users to open a Remote Desktop connection expanded across all the monitors on the client computer regardless of the client monitor configuration. With this feature, the user can fully utilize all the monitors connected to the client computer for the Remote Desktop connection thereby providing extra desktop space and an almost seamless experience with the client desktop that is much improved over “Span mode”.

This feature will be part of Windows 7/Windows Server 2008 R2 release and works for connections to another client machine (physical or VM), or a Remote Desktop Session Host.

How to use Remote Desktop Multimon feature:

To use this feature, you must:

1. Connect using the Remote Desktop Client 7.0 (mstsc.exe) available initially on Windows 7/Windows Server 2008 R2.
2. Enable Multimon using one of the three methods described below:
   a. Click “Use all monitors for the remote session” in the client (mstsc.exe) window.
   b. Use the “/multimon” switch on the mstsc.exe command line.
   c. Add “Use Multimon:i:1” to the RDP file.
    
3. Connect to a computer running Windows 7 or Windows Server 2008 R2.

How does it look?

Currently this feature displays the remote desktop on all the monitors available on the client computer. It can handle any client monitor configuration supported by Windows.

The following images show the Remote Desktop Multimon feature in various configurations:

Display Settings UI inside a Remote Desktop session showing multiple monitors

Remote Desktop Multimon Session with 5 monitors

PowerPoint inside Remote Desktop session showing multiple monitors

How is this different from “Span” mode?

Span mode, introduced in Vista, allows the remote desktop to span across all monitors on the client as long as the monitors are arranged to form a rectangle. The remote session created when using span mode is still a single-monitor session. With multimon support, each monitor on the client machine is viewed as a distinct monitor in the remote session. Due to this fundamental difference, span mode has some restrictions that true multimon does not:

1. The primary monitor must be leftmost.

2. The set of monitors must form a rectangle (i.e. identical vertical resolution, and lined up in exact straight line).

3. The total of the resolutions must be below 4096x2048 (ex. 1600x1200+1600x1200 = 3200x1200).

For these reasons, all monitor configurations shown below are valid for Remote Desktop multimon, whereas most of them are not valid for span mode:

With true multimon support, the client-side monitors can be arranged in any order and can be of any resolution.

Since a span mode remote session is essentially a single-monitor session, if a window in the remote desktop is maximized, it spans across all the monitors. With true multimon support, a window will only maximize to the extent of the containing monitor.

If an application queries for the number of monitors inside a span-mode session, it will find only one monitor, whereas it will find as many monitors as are actually present on the client system when using true multimon RDP. This difference can change the behavior of applications such as PowerPoint.

Remote Desktop Multimon configuration properties:

There are a few settings associated with the Remote Desktop Multimon feature that can be used to restrict the number of monitors and resolution that clients use to connect.

Restricting the maximum number of monitors:

The Remote Desktop Multimon feature provides an option to restrict the number of monitors a user can use to connect. By default, RDP protocol supports a maximum of 16 monitors. This number can be restricted to any value between 1 and 16 using one of the following three approaches:

1. Using the “Limit maximum number of monitors per session” setting in the Remote Desktop Configuration Tool (tsconfig.msc) as shown below:
   
2. Setting the “Limit maximum number of monitors” machine group policy as shown below:
    
3. By setting the MaxMonitors property in the Win32_TSClientSetting WMI class (http://msdn.microsoft.com/en-us/library/aa383778(VS.85).aspx).

Restricting the maximum resolution of each monitor:

By default, RDP restricts the maximum resolution to 4096 X 2048 per monitor. Additionally with multimon, the width and height of each remote monitor can also be restricted in one of two ways:

1. Setting the “Limit maximum display resolution” machine group policy as shown below:
    
2. By setting the MaxXResolution and MaxYResolution properties in the Win32_TSClientSetting WMI class (http://msdn.microsoft.com/en-us/library/aa383778(VS.85).aspx).

Please note that the policies and WMI settings described above apply only to connections with multiple monitors and not when connecting with a single monitor.

I have been re-awarded as an MVP for Remote Desktop Services. I am honoured and thankful and want to thank everyone that made this happen.

Storage thin provisioning can save space on a VMware Virtual Machine Disk File (VMDK), but reclaiming that space requires the use of tools described in this article.

Microsoft last week announced the availability of beta 2 of Microsoft Deployment Toolkit 2010.

The most wanted feature for Windows 2008 Terminal Services is RemoteApp user filtering. You don’t want all users to see all applications on the web portal. This feature will probably be released in Windows Server 2008 R2 but till then, you are out of luck. This article helps.

We have added a new page to the Citrix Communities for you to be able to see all of the highlights that are in the Community Spotlight.

http://community.citrix.com/display/cdn/Community+Spotlight

View Online | Add Comment

We have added a new page to the Citrix Communities for you to be able to see all of the highlights that are in the Featured Communities.

http://community.citrix.com/display/cdn/Community+Featured+Sites

View Online | Add Comment

PinSafe is a form of multi-factor authentication which is easier to deploy and more cost effective than its token based competitors.  It also integrates seamlessly with the NetScaler for both SSL VPN and AAA for Web Applications.

It works by providing the user a customized "one time" image on the login page.  The image employs character rotation and will use a range of fonts and backgrounds to provide resistance to OCR attacks.  Contained within the image, is a security string which can be made up of numbers, characters or even a mixture of the two.   Place holders in the image help the user to extract their one-time image code.  So in the example below, a PIN of 4359 would yield a one-time code of 3125.

 

 

The default image has place holders to help the user extract the one-time code, but other, pattern based images can also be used.  The examples below show the numeric (eg telephone) keypad pattern as well as a more random pattern.  These images can even be branded for individual customers requirements.

 

For more information goto http://www.swivelsecure.com/

View Online | Add Comment

That's the title of the July 9th TechTalk. This session is open to genuine propeller heads and geeks only.

In this session, I'll explain how ICA functions, including why single session application bandwidth testing isn't accurate, the CGP (Common Gateway Protocol) and how it relates to ICA, what virtual channels do, and much more. We'll even dissect some ICA packets!

Then Jason Maynard is going to talk about ICA Acceleration, which is focused on how the Repeater/Branch Repeater devices can make ICA even more efficient. He'll show you how you can squeeze and compress ICA like never before.

As you consume this information, the "aha!" moments will abound. You will have lots of "Did you know that . . . ?" items to discuss at lunch the next day with your fellow Citrix geeks. Go ahead, take it up a notch and invite your fellow network geeks to dine with you. Just be warned that packets of knowledge will be accelerating everywhere and beverage napkins will be full of diagrams!

View Online | Add Comment

Ben Armstrong: In Windows Server 2008 R2 we have made some surgical changes to the way virtual machine snapshots work and how they are exposed in the system in order to address some key customer pain points.  Changes include:

    * You can now export a single snapshot from a virtual machine.  This works by selecting the snapshot in question and then selecting Export… from the Action pane.  We will merge all the snapshot disk data into a single new virtual hard disk – and the resulting exported virtual machine will look like a virtual machine with no snapshots that is identical to the snapshot you selected.  Note that the virtual machine needs to be turned off in order to perform this operation.
    * Snapshot AVHD files are now created in the same directory as their parent VHD files.  Their names have also been updated to include the name of the parent virtual hard disk.  Both of these changes make it easier to identify and group snapshot files.
    * When you open the settings for a virtual machine snapshot and look at the hard disk settings – you will see the name of the AVHD that is associated with that snapshot.  This helps you to map AVHD files to specific snapshots.
    * You can now edit AVHD files in the edit VHD wizard.  This means that if you want to manually merge AVHD files to a new VHD to give to someone else – you can (note: be careful as you can cause problems if you merge back into the parent in this case).
    * You can now directly attach an AVHD file to a virtual machine.  This is very handy if you have lost your virtual machine configuration and need to get data off of a snapshot file.

This is the third part of a four-part series on automating workflow execution within Citrix Workflow Studio.  In the first two parts of the series, I discussed how you can create Powershell scripts to execute workflows.  Part 1 provided a high-level overview of creating Powershell scripts for automating workflow execution and Part 2 expanded on those scripts to discuss how to pass parameters into the workflow.  In this blog, I will discuss how you can automate workflow execution with a custom Windows application.  The sample .NET application I built is shown below.  I am providing both the executable and full source code to allow you to expand upon this solution to meet the needs of your environment.

When would I need to use a custom application for executing workflows?
A lot of you might be asking the question - "If we can use the Workflow Studio Console to execute workflows, why would I need a custom application to do that for me?".  The answer really comes down to how you need to execute certain workflows in your environment.  If you need to execute workflows "on-demand" or "on a schedule", the Workflow Studio Console would meet those needs.  Just open the Workflow Studio Console and schedule a job to run immediately or on a pre-determined schedule.  However, if you need "event-driven" automation where a third-party application kicks off the execution of a workflow based on an event happening, that is where you need to be able to hook into Workflow Studio with a custom solution to perform that type of automation. 

The custom application provided in the Downloads section below provides a sample for how you can tie any .NET windows application to Workflow Studio for executing workflows.  Feel free to try out the sample application on your Workflow Studio machine.  The full source code is also provided to allow you to customize and extend the application further based on what you need to do.

Downloads:
Download the application executable here
Download the application source code here
 

Preparing your Workflow Studio environment to use the custom application:
The custom application needs to run on a machine that contains Workflow Studio since it ties into Powershell and calls the Workflow Studio cmdlets for performing various actions on Workflow Studio.  In your Workflow Studio Console, you will need to pre-deploy the workflow that you want to automate (see Part 1 for more information on pre-deploying workflows).  The workflow that you want to automate can include parameters as well.  Parameters for a workflow are defined in the Workflow Studio Designer under the Global Properties section (see Part 2 for more information on defining workflow parameters).

This custom application functions as any typical Windows application in that it runs under the context of the logged-on user account.  The logged-on account needs to have permissions in Workflow Studio to execute workflows.  These permissions are defined in the Security section of the Workflow Studio Console.  For simplicity, I typically add the user accounts as a "Workflow-Admin", but you can play with the security roles here to determine what roles are actually needed.

Using the custom application:
To use the custom application, log onto your Workflow Studio machine with an account that has permissions to execute workflows within Workflow Studio.  Place WFSWorkflowExecute.exe on your Workflow Studio machine.  When you launch the application, the initial view is shown below.

Click the Get Runtimes button to get the Workflow Studio runtimes that are installed on the local machine.  The runtimes are listed within the combo-box below and the name of the runtime specifies which account the runtime is running under.  

When a runtime is selected, all of the workflows that are deployed on that runtime are listed as well.  To execute a certain workflow, you need to know which runtime you deployed the workflow on.   This sample application also provides the version of the workflow as you may have deployed two different versions of the same workflow to the same runtime.  Using the version numbers helps you keep them straight.

When you want to execute a workflow, you need to know if that workflow requires any parameters.  The workflow parameters are defined in the Workflow Studio Designer in the Global Properties section of the workflow.  As mentioned above, Part 2 of this blog series goes into detail on how to define and use parameters inside a workflow.

When specifying workflow parameters inside the custom application, the parameter name is case sensitive.  (Notice how I kept the parameter name as "gMessage").  If you mistype the parameter name or use the wrong case, you will get an error message when executing the workflow stating that the parameter name is not recognized.  Just keep this in mind as you type the name of the parameters into the application.

Click the Execute Workflow button to execute the workflow.  If the workflow was successfully executed, you'll get a pop-up message indicating success.

To verify the workflow was executed, you can open the Workflow Studio Console and check out the Jobs section. 

Understanding the source code:
A lot of you out there will want to customize this application in your own environment.  I developed this application with C# using Visual Studio 2008 and the Powershell SDK.  Your development machine will also need Powershell 1.0 and Citrix Workflow Studio.  For advice on setting up your Visual Studio environment, check out this article.  If you follow the steps in that article, you'll just need to add the Powershell SDK and you should be all set.

The Powershell SDK is included as part of the Windows Software Development Kit.  You can get information on the Poweshell SDK here.  I downloaded the full ISO and it took me quite a while to get it.  When you are ready to install, you don't need everything in the setup wizard.  The Powershell SDK link provided above actually tells you what you specifically need to install to just get the Powershell SDK.  To use the Powershell SDK inside your Visual Studio project, the project will need to reference System.Management.Automation.dll.  

Once you get your development machine set up, you can open the solution that I provided above inside Visual Studio.  Essentially all this custom application does is use the Powershell SDK APIs to execute cmdlets on Powershell.  Since Workflow Studio provides Powershell cmdlets to automate various tasks, we can use the Powershell SDK to automate many Workflow Studio functions. 

From my personal experience, using the Powershell SDK takes a little time getting used to.  What I found to be helpful is to first write out the Powershell commands in Notepad and test them within Powershell to make sure they are functioning as expected.  If you are working with Powershell variables, use the echo statement frequently to understand the current value of the variable.  Then when you are ready to use the Powershell SDK in your Visual Studio project, you can convert each of your Powershell statements to the equivalent Powershell SDK code.  In the source code that I provided for this custom application, I put comments into the code to explain what Powershell command I was trying to execute within that code block.  Reviewing those comments should help you to get started with understanding how to use the Powershell SDK.  For example, here is the ExecuteWorkflow() function that is used by the custom application.  Stepping through this code inside Visual Studio and watching the variables is another great way to learn this code.
public string ExecuteWorkflow(Hashtable objFunctionParameters, Hashtable objWorkflowParameters) { try { //Declare local variables string l_strReturn = "Executing workflow"; string l_strWorkflowName = objFunctionParameters["WorkflowName"].ToString(); string l_strRuntimeName = objFunctionParameters["RuntimeName"].ToString(); Hashtable l_objWorkflowParameters = objWorkflowParameters; //Create a runspace containing the Workflow Studio snap-ins RunspaceConfiguration l_objRSConfiguration = RunspaceConfiguration.Create(); PSSnapInException l_objSnapInException = null; l_objRSConfiguration.AddPSSnapIn("Citrix.WorkflowStudio.Azman", out l_objSnapInException); l_objRSConfiguration.AddPSSnapIn("Citrix.WorkflowStudio.Core", out l_objSnapInException); l_objRSConfiguration.AddPSSnapIn("Citrix.WorkflowStudio.DataStore", out l_objSnapInException); l_objRSConfiguration.AddPSSnapIn("Citrix.WorkflowStudio.Installer", out l_objSnapInException); Runspace l_objRunspace = RunspaceFactory.CreateRunspace(l_objRSConfiguration); l_objRunspace.Open(); //Get reference to the Workflow Studio runtime that was passed in. //We are executing the Powershell command below: //$rt = Get-WorkflowRuntime -ServiceName $ServiceName Pipeline l_objPipeLine = l_objRunspace.CreatePipeline(); Command l_objCommand = new Command("get-workflowruntime"); l_objCommand.Parameters.Add("ServiceName", l_strRuntimeName); l_objPipeLine.Commands.Add(l_objCommand); Collection<PSObject> l_objCommandResults = l_objPipeLine.Invoke(); PSObject l_objRuntime = l_objCommandResults[0]; l_objPipeLine = null; //Get reference to the deployed workflow that was passed in. //We are executing the Powershell command below: //$workflow = get-deployedworkflow -workflowruntime $rt -workflowname $strWorkflowName -includeschedule l_objPipeLine = l_objRunspace.CreatePipeline(); l_objCommand = new Command("get-deployedworkflow"); l_objCommand.Parameters.Add("workflowruntime", l_objRuntime); l_objCommand.Parameters.Add("workflowname", l_strWorkflowName); l_objCommand.Parameters.Add("includeschedule"); l_objPipeLine.Commands.Add(l_objCommand); l_objCommandResults = l_objPipeLine.Invoke(); PSObject l_objWorkflow = l_objCommandResults[0]; l_objPipeLine = null; //Schedule the workflow to run immediately. //We are executing the Powershell command below: //schedule-workflow -workflowruntime $rt -workflowstrongname $workflow.WorkflowStrongName -workflowparameters $wfparameters -runimmediately l_objPipeLine = l_objRunspace.CreatePipeline(); l_objCommand = new Command("schedule-workflow"); l_objCommand.Parameters.Add("workflowruntime", l_objRuntime); l_objCommand.Parameters.Add("workflowstrongname", l_objWorkflow.Properties["WorkflowStrongName"].Value.ToString()); l_objCommand.Parameters.Add("workflowparameters", l_objWorkflowParameters); l_objCommand.Parameters.Add("runimmediately"); l_objPipeLine.Commands.Add(l_objCommand); l_objCommandResults = l_objPipeLine.Invoke(); l_objPipeLine = null; //Close the runspace l_objRunspace.Close(); //Return success l_strReturn = "Job completed!"; return l_strReturn; } catch (Exception objException) { //Initialize error message string l_strError = ""; l_strError = "An error has occurred. The error is \"" + objException.Message.ToString() + "\". "; return l_strError; } }
Blogs in this series:
Using Powershell to automate workflow execution within Citrix Workflow Studio
Passing parameters into a workflow within Citrix Workflow Studio
Automating workflow execution for Citrix Workflow Studio using a .NET windows application (this one)
Automating workflow execution for Citrix Workflow Studio using an ASP.NET web application

View Online | Add Comment