This best practice was requested by a comment on a previous blog posting. With Provisioning Services, we are able to use a single image for hundreds of XenApp target servers. Making a change to the image is a big deal because every XenApp server will use the new image after a reboot (of course this is also a huge benefit). How do we keep control over these images and make sure you don’t break your entire environment with a new update?
Truthfully, it is a fairly straight forward process, but just like all processes, you need to follow them if you want things to go smoothly. High-level process overview is in the following figure:
These are all logical systems, meaning that they could be virtual servers, physical servers, different volumes on the same storage infrastructure. The recommended process is as follows:
- When you have a valid vDisk on your production Provisioning Services server, make a copy of it and store it in your library. The library is just that, a location where you keep the current and old revisions of vDisk images.
- When you need to make an update, copy the vDisk from your library to your test environment Provisioning Services server.
- Make your changes in the test environment. When the changes are done, update the revision number and filename of the vDisk. Copy the vDisk back into your library and to the production Provisioning Services server.
- Tell the production Provisioning Services server to auto-update vDisks. This is actually a really cool feature. The auto-update process will automatically update the vDisk file of all affected target devices upon next reboot. How can you tell which target device will be updated? By the Class information. Each target device and vDisk file has a Class field. The class fields are the link for auto-updates. Provisioning Services will look to see if there are any vDisks with a higher revision number (which there is as we just updated the vDisk and incremented the revision number). Provisioning Services then checks the Class of the vDisk. Any target device with the same Class will receive the new vDisk upon next reboot. This is a great way to simplify the management of your XenApp farms.
Ok, so we updated our XenApp servers with a new vDisk, but what happens if there is a problem with the vDisk updates? Have you ever installed a hotfix to find out it broke other things? I bet so. If you followed the process outlined above, you have a build in rollback feature by doing the following:
- You make a copy of the previous vDisk image from your library to the Production Provisioning Services server.
- You increment the revision number on the old vDisk image to a number that is higher than the updated vDisk image.
- You implement the auto-update feature of Provisioning Services
- Reboot the XenApp servers
As you can see, the processes for updates and rollbacks are very similar and it works great. Stay tuned for more best practices regarding Provisioning Services and XenApp.
- vDisk Type
- vDisk Cache
- Active Directory
- Application Integration
- Application Streaming Cache
- System-level settings: Page file, drive remapping and multiple drives
- Image Management
- Local Database Storage (event viewer, EdgeSight, AntiVirus updates)
- Plus more if we get some good ideas on other areas of focus.
By the way, if you haven’t done so already, take a look at the Provisioning Services for XenApp TechTalk presented by yours truly. I’m a little biased, but I think it is a good one.
Daniel – Sr. Architect – Worldwide Consulting Solutions
Follow me on Twitter: http://www.twitter.com/djfeller
Follow me in the Blogs: http://community.citrix.com/blogs/citrite/danielf