In the last part of Choosing an Automated Deployment Strategy for XenApp I will discuss installing XenApp via images.

A few people have emailed me recently asking where to find XenServer Express Edition, our free single server virtualization platform with the XenCenter management GUI.   The downloads site recently moved behind the "my citrite" front page, which means that you have to have a login to get it.  This makes sense for resellers dealing with Citrix, but someone must have inadvertently moved Express at the same time.  While we fix this, here is a direct link you can use to download this killer free virtualization platform.  We still rely on your feedback, so feel free to post follow ups!

Download XenServer Express Here!

This is the first episode of the Citrix Delivery Center podcast. Vishal Ganeriwala and I interviewed Daniel Feller of Worldwide Consulting Solutions on the topic of deploying XenApp on XenServer. In part 1 of this topic, Dan talks about where, why and how XenServer and XenApp integration makes sense to deploy in your environment. Scalability will be covered in part 2.

Thanks to Jim West in Citrix Technical Support for voicing the Citrix Countdown and Steve Greenberg of Thinclient.net for the CTP Minute. A special thanks also goes out to Doug Brown for his podcasting advice and help.

MP3 File Download

Subscribe to the Citrix Delivery Center Podcast Feed

Here are the documents Dan created regarding XenApp on XenServer -

Reference Architecture: Explains why a 100% physical architecture was reconfigured to include both physical and virtual systems and deciding factors of why XenServer is the best server virtualization solution for XenApp servers.

Implementation Guide: A step-by-step guide showing how to incorporate a XenApp Farm into a XenServer Platinum environment. Demonstrates how to create a golden XenApp image to be provisioned to any number of virtual machines.

Design Considerations: To meet the needs of the business, a solution like XenServer for XenApp must allow for design decisions. This article focuses on a few of the major considerations when integrating these solutions together.

Part 3 of Choosing an Automated Deployment Strategy for XenApp gives an overview of deploying XenApp via Active Directory.

Welcome to the third installment of the Dynamic Delivery Center.  This time I will be showing you the Proof of Concept (PoC) we built to validate the DDC is possible.  If you haven't done so already, I encourage you to review the first two blogs so you understand our business and requirements.

• Part I - The Need
• Part II - The Analysis

Now, the PoC.  First, let me show you the architecture diagram we've used.  (Visio Stencils for this diagram are located here).

As you can see, it is fairly straightforward. I'm the type of person who prefers things simple. The whole purpose of the PoC is to see if we can use a web front end to dynamically deliver any number of "Test" environments to the users.  Now, as many of you reading this are techies, let's get to the good stuff...

• External Access: Every user will be remote. Even if you are sitting in the office next to the lab, you are considered a remote user (Ever hear of de-perimiterization?).   All users will connect through an HA Pair of NetScaler 7000s with the SSL-VPN functionality enabled in full VPN mode.  We are doing more than ICA so we need a full VPN connection.
• Web Front End: Users will be able to connect to the Web Frontend when they connect with Access Gateway Enterprise .  The Web Frontend will allow the user to request any number of systems from the lab. 
  
  
• XenServer Resource Pool: Currently, the XenServer Resource Pool contains a set of templates that users can request from the environment. Those templates are reflected in the Web Front End, allowing the user to customize their environment.
• XenServer Template Library: For the PoC, the library only includes Windows 2003 R2 servers, XenApp 4.5 servers, Windows Vista SP1 workstations and Windows XP SP2 workstations.  New virtual machines are created based on the templates, which should only take a few seconds.  The library will grow as new requests come in and new systems are required. The longer the DDC is running, the more complete the library will become.
• NetScaler: The NetScaler devices are setup to allow for either a one-arm or two-arm deployment (hence the reason for the two separate VLANs).  If the user only requires a one-arm setup, they just ignore the second connection.
• WANScaler: The WANScaler devices are setup to allow the user to test any number of backend optimizations across any simulated WAN connection with the Apposite WAN Emulator.  The backend contains another XenServer Resource Pool allowing the user to test WAN optimization against any number of resources including file servers, web servers, media servers and XenApp servers, just to name a few.
  

We have the architecture, but how does it work?  How does the Web Frontend do it all?  In the PoC, we chose not to look into Workflow Studio (Sorry WFS Team) as we want to wait for the next beta release. But the lessons learned in the PoC will help us properly develop our workflows in the design phase.  In the PoC, we used the SDKs extensively to do the following:

• Virtual Machines
  1. A user selects one or more templates on the Web Frontend and selects "Provision Servers".
  2. The Web Frontend code will search for a virtual machine resource in the database that has not been marked as in use. Once an open virtual machine is found, the database will be updated and marked as in use by the user for a period of 3 days.
  3. The Web Frontend will establish a session with the XenServer host using root credentials.  The template the user selected will be cloned.  Once the clones are created, they will be sent a start command.
  4. Once the virtual machines are running, the IP address will be obtained. This information is used to generate an automated email to the requester using the SMTP service running on the Web Frontend server.
  5. The user will use the IP address to make a Remote Desktop connection to the console of the server, which is waiting for the user to enter a name for the virtual machine as part of the SID generation process.

• NetScaler
  1. User selects "Provision NetScaler" from the Web Frontend
  2. The Web Frontend checks the database for an available NetScaler. Once one has been found, it is marked as in use by the particular user for a period of 3 days. In the event that all NetScalers are assigned, the user will receive an automated email.
  3. The Web Frontend will establish a session using XML API calls with the NetScaler using the "nsroot" credentials. The reset process involves using the XML API calls to get into the NetScaler shell to remove the ns.config file.  Simply deleting the NS.Conf will completely reset the NS config. That would be bad because that includes the IP Address.  We don't want to go into the lab and connect a serial port and configure the device.  To solve this challenge, we  copy a base ns.config (which includes the NS IP configuration) over the current one.  We also have the code go through and remove any extra files that the previous user might have created (certificates, configuration files, etc).
  4. The Web Frontend will send code that will clear the NetScaler configuration, while keeping the IP address constant, so it is accessible from the network.
  5. The user will receive an automated email from the Web Frontend using the SMTP service.  The email informs the user on the connection information for the NetScaler.

• WANScaler
  1. User selects "Provision WANScaler" from the Web Frontend
  2. The Web Frontend establishes an HTTP session with the WANScaler web console using the "admin" credentials.
  3. The Web Frontend sends a request to reset the WANScaler config back to factory defaults, while still preserving the IP address. Once the WANScaler has been set back to factory defaults, the WANScaler will be rebooted.
  4. The user will receive an automated email from the Web Frontend using the SMTP service.  The email informs the user on the connection information for the NetScaler.
     

Lessons Learned:

• The biggest thing is that it is possible!!  The tricky part of the project was resetting the NetScaler and WANScaler back to factory defaults without losing the IP address. 
• A more complete set of XenServer templates is required to anticipate any number of requests from the field
  

Next Steps:

• Create a more detailed design that identifies the templates required for the initial release
• Create a detailed set of workflows that are required to see how Workflow Studio can be leveraged to make this environment easier to build and maintain.
• Create a way to hide Simpsons "Surprises" within the lab like logging into the lab and receive a warm welcome from Homer saying "D'oh!"
  

Hope you enjoyed this one.

Daniel

Homer Quote for the Blog "Look, the thing about my family is there's five of us. Marge, Bart, Girl Bart, the one who doesn't talk, and the fat guy. How I loathe him."

Simon Crosby has been very popular in the "podosphere" of late. Here are three recent podcast interviews with Simon.

First, Simon did a very interesting interview with Doug Brown of DABCC.com.

Next, Simon participated in a two part interview with Mitchell Ashely of Converging on Microsoft at Network World.

Part 2 of the Network World podcast is entitled "Why Simon Loves Hyper-V".

In Part 2 of the Choosing an Automated Deployment Strategy for XenApp series I will talk about installing XenApp with the UnattendedInstall.exe tool from the server CD.

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

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

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

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

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

If you're like me, you'll like to mentally create pictures to make sense of what you're reading. The underpinnings of Xen networking, as I found out, is not that difficult once you have the correct pictures in mind. Once I'd discovered the secrets, I decided to write a paper explaining it to myself. Hopefully, others will find this useful as well!

"It's important to understand that XenServer networking operates at Layer 2 of the OSI. This means it's independent of any Layer 3 addressing, such as IP. As we'll see, XenServer acts as a Layer 2 virtual switch..." Read more in my Citrix Knowledge Center article.

In the next few days at shannonma.wordpress.com I'll be blogging about the different ways you can install XenApp in an automated fashion. Part 1 is online, Part 2 will be coming tomorrow, and the whole series will be online by Wednesday. Check it out and if you have any questions or feedback don't hesitate to drop me a comment.