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.

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.

Taking the Answer File Approach with UnattendedInstall.exe

XenApp ships with a tool called UnattendedInstall.exe that allows you to perform a silent install with an answer file. You can find this tool on the XenApp server CD under Support\Install. I won’t go into the details of running the tool, but you can find more about it on pg. 368 of the Admin Guide.

This tool mitigates the problem of trying to key in all those crazy MSI install options on command-line, but you’ll still need a third-party automation tool if you want a completely automated solution.

I’ve always been a firm supporter of IT automation since I joined this industry. Maybe I’m a bit biased because by day and night I’m all about automation, but I think it should be a requirement in all IT departments. This is one of the most effective ways a company can cut costs and it allows engineers to focus on the tasks that really matter.  There’s absolutely no reason why some of the most common, repetitive, and mundane tasks we face in the IT world should not be automated in every organization… especially installing software!

One of the projects I’ve led at Citrix was the development of an automated test to validate the XenApp installer. My experience from this project and past jobs has given me a good amount of knowledge in automated software deployment strategies that can be applied to XenApp.

In this blog, I’ll outline four of the options you can choose from when determining an automated deployment strategy for XenApp (specifically mps.msi). I’ll publish one option each day, which means the last one will come online Wednesday… perfect because on Thursday I’ll be on vacation in the Caribbean sipping on a pina colada!

If there is significant interest in this series, I’ll consider writing a follow-up entry to cover the other XenApp components. Please note that I will not go into the nitty gritty details of how to implement each solution, I’ll leave that to the Admin Guide. However, I will give an overview of each approach and some of the cool perks they offer. Before you install XenApp via these methods, you should ensure your system has the necessary prerequisites installed, which you can find on pg. 48 of the Admin Guide.

So, let’s talk about our options:

Script-based Installs with MsiExec

Running MsiExec on mps.msi in silent mode is one of the most primitive yet powerful ways to install XenApp. This method gives you direct access to the MSI and is the basis for the other options we’ll be discussing later. The main disadvantage here is that you have to specify your install options on command-line. This can get complicated very quickly for an installer like XenApp that allows a lot of customization (not to mention casing and spelling has to be spot-on for some of the MSI parameters). Pg. 369 of the Admin Guide talks about the details in case you’re interested in learning more.

In order to develop a strategy with this method, you will need to use some type of third-party automation tool such as Altiris or SMS. For example, by leveraging Altiris you could create a job, select your base OS image, key in your MsiExec script, and be on your way to automatically provision your servers with XenApp.

The majority of the automation I work on at Citrix take this approach (minus Altiris, we have our own automation framework) since the tests are typically interested in validating the installer itself and not some third-party components. I should also note this automation is used to test our daily builds against small farms and is in no way, shape, or form run in a production environment. With that said, most XenApp environments can still be successfully rolled out by pairing this method with third-party tools like Altiris, as it gives you the most flexibility and control. However, if you’re looking for something that’s simple or have special environment considerations you need to deal with, some of the other options I’ll be talking about may suit you better.

Stay tuned for Part 2!