Finally, XenApp server farms are going to be easier to manage. Am I the only one jumping for joy? As many of you have heard by now, XenApp Platinum is going to include Provisioning Services. This is an announcement I’ve been waiting for, for quite a long time. Provisioning Services is a great secret weapon for maintaining any system, but I’m going to focus on is XenApp. If you want a great overview of what Provisioning Services will do for you, take a look at Vinny Sosa’s blog. What I want to focus on are the best practices for integrating Provisioning Services for XenApp.
The first best practice, is one you need to decide very early on in your build-out… What type of vDisk should you use? Private, Standard or Differential. Take a look at the three options below:
|Standard Image||Private Image||Differential Image|
|Description||Each target devices stores vDisk writes in a unique change file that is destroyed upon each target device reboot.||Each target device has a dedicate vDisk image configured in a read/write fashion. All changes are part of the vDisk.||Each target device stores vDisk writes in a unique file that is kept upon subsequent reboots, allowing the server to keep configuration changes, until the base vDisk is modified.|
||Complete personalization of the environment because all changes are stored, but at a cost of storage and support.||Allows for greater levels of system personalization by not discarding system-level changes upon subsequent reboots.|
|Recommendations|| Standard images are a recommended best practice for XenApp servers. XenApp servers delivering the same applications should be:
||There is little need for Private Images in a XenApp environment because of the differences each image will take. This will go against the core best practice of consistency.|| Differential images are appropriate for a small subset of use cases where users have the need to install their own applications. In a XenApp environment, this is not recommended.
Once the base vDisk is modified, the differential image is destroyed and the user must rebuild their personality into the target device.
Standard Image is the way to go. The benefits are great. They align completely with the best practices for XenApp servers… Consistency. The standard image is the key to consistency. But how can a single image be used for multiple XenApp servers? If I install the operating system and XenApp onto a base image and then use the same, exact image to hundreds of servers, aren’t there issues with farm membership, especially as each server has the same name?
This is the really cool thing about Provisioning Services. Within the console, you define each target device with a name and a MAC address. The MAC address links the defined target device within the Provisioning Services console to the actual physical/virtual server. Whatever name you enter will become the actual computer name of the streamed server. The Provisioning Services streaming service inserts this identification information into the stream. So, Provisioning Services takes care of the computer name, but we still have to deal with XenApp farm membership.
Included in the base image, along with the operating system and XenApp, is the XenApp Prep Tool. Immediately before you create your base image, you run the prep tool. This tool does exactly what you think it should do, it prepares the XenApp server for streaming by removing items (local host cache, Resource Manager local database), stopping services (IMA Service, Citrix SMA service) and a whole slew of other things. The XenApp Prep tool also creates a new service so when the base image is streamed to any target, the XenApp Prep service starts and begins the personalization and integration into the XenApp farm. It does a whole bunch of things, but of importance is the changing of the STA ID (they have to be different), updates certain registry keys to force the XenApp server to request updates to the local host cache, recreates local XenApp databases, and restarts XenApp services. I’ve left off a few items, but essentially what happens is when the XenApp services start, they will try to communicate with the XenApp farm. If the server does not have a presence in the farm yet, it will automatically be added. If the server has a presence, it will simply receive its local host cache from the data store automatically. If you want to get more information and the XenAppPrep tool, get it from here:
If you want to see it in action, take a look at this video
Please comment if there is another best practice you are wondering about. Stay tuned for more upcoming best practice blogs specifically focused on Provisioning Services and XenApp:
- vDisk Cache
- Active Directory
- Application Integration
- Application Streaming Cache
- System-level settings: Page file, drive remapping and multiple drives
- Plus more if we get some good ideas on other areas of focus.
Follow Daniel’s Blog: http://community.citrix.com/blogs/citrite/danielf
Follow Daniel on Twitter: http://www.twitter.com/djfeller