Choosing an Automated Deployment Strategy for XenApp (Part 3/4)
Part 3 of Choosing an Automated Deployment Strategy for XenApp gives an overview of deploying XenApp via Active Directory.
Deploying MSIs via Active Directory with Group Policy
I’m a big fan of deploying MSIs via Active Directory. This probably remains one of the most affordable ways to automatically deploy software today… not to mention it’s pretty cool to see it work. One of the significant feats I had at a past job back in 2003 was using this method in conjunction with the Remote Installation Service (RIS) to automatically deploy operating systems and 100+ apps to the entire company. I still have some of the painful memories from repackaging the apps that weren’t MSI based (90% of them) and getting them to play nice (aka not blowing up) in a LUA environment. Streaming Server (now part of XenApp), Softricity, and all of those other application virtualization tools are truly a blessing. With that said, I’d hope most application developers know better than to write user data to HKLM and Program Files!
I wasn’t able to find a section in the Admin Guide that covers installing XenApp via Active Directory, so I’ll give an overview of it. To deploy XenApp via Active Directory, the first thing you need to do is create an administrative install. This will basically copy all of the files to a network location, so all of your servers can reach it. You can find the details about this on pg. 370 of the Admin Guide.
Next you’ll need to create a transform (MST file). The transform will capture all of the install options, similar to an answer file except it’s based on Microsoft’s own proprietary format. Back in the day I used InstallShield’s AdminStudio to do this… you just point AdminStudio to the MSI, it will let you walk through the GUI portion of the install and choose your options, then when you click Finish it captures all of your settings into a .MST file. Now days, I wouldn’t be surprised if there are some free tools that allow you to do this. If you know of any, I’d be interested in checking them out so feel free to post them as a comment.
The last step is to create a Group Policy object (GPO). In this GPO, you will need to create a new Software Installation object and reference the network location of mps.msi and your transform. When you apply this GPO to an OU, by default it will install XenApp on all computers under the OU. The easiest way to restrict this is by applying a filter to the GPO that specifies a group with all of your XenApp servers.
Now the cool perk about deploying apps via Active Directory is that you just need to add the desired computer to the group and reboot it. Well… you may need to run gpupdate too, but I think you get the point.
For an install as complex and large as XenApp, this approach does have some downfalls:
- Compared to a script-based approach, it’s harder to detect and troubleshoot problems that occur at install time. For example, a machine may fail to install, but there’s no good indication of how or why there was a problem.
- Controlling and staging XenApp roll-outs can be difficult due to all of the new IMA and file sharing traffic occurring at the same time.