Deploying a Pre-Configured Citrix Client using Active Directory
This article will show you how to create a pre-configured Citrix Client and leverage Active Directory to deploy the client as well as overcome some of the idiosyncrasies found in the Citrix Client packager.
This article will show you how to create a pre-configured Citrix Client and leverage Active Directory to deploy the client. You may ask, "Why would I want to use Active Directory to deploy the client. Doesn't Citrix offer the Auto Client Update?" The answer is yes, Citrix does provide an auto client update feature, but there are limitations such as:
If a workstation already has a Citrix client that was installed from an .msi package, then you cannot use the Auto Client Update feature.
"Important You cannot automatically update previous versions of the client installed with Windows Installer (.msi) packages. You must redeploy a client installer package when a new version of the client is released."
Also, refer to Citrix Article CTX108584.
The Auto Client Update feature also adds steps to the logon process since it has to check to see if the workstation has an up-to-date client. This can cause longer login times and user frustration. In fact, I recommend you turn off the Auto Client Update feature via a Citrix policy:
- Citrix Presentation Server Client Packager
- ORCA to modify the MSI file (today’s trivia, ORCA stands for One Really Cool Application)
- Citrix Transform File to enable Single Sign On in the MSI file (optional)
The first thing you will need to do is get the Citrix Presentation Server Client Packager. You can download the latest Citrix Client Packager at http://www.citrix.com/download. The Citrix Client Packager contains the Citrix Program Neighborhood client, the Citrix Web client, and the Citrix Program Neighborhood Agent client.
You can customize the client packager to deploy and maintain any number and combination of clients network-wide. Based on Windows Installer technology (msi), the client packager lets you install, uninstall, modify, and repair clients as well as perform controlled client upgrades. An easy-to-use wizard guides you through the configuration step by step.
Create an Admin Install of the Citrix Client Packager
This is the part where you pre-configure the client(s).
Run msiexec /a Ica32Pkg.msi to create an administrative install of the package.
Note: this doesn't actually install the client; it just creates the customized client installation files.
Select the "Uncompressed" option if you want to make modifications to the files (such as branding the client).
For this exercise, I have chosen not to install the full Program Neighborhood Client.
Important: If you elect to use the Local Name and Password, you will need to modify the MSI file using a transform (MST) file in order for this to work. More on this later.
In this example, I removed all the dialog boxes. It is not necessary to show any dialogs since we are going to push this client via Active Directory.
Making Post Setup Modifications
There are a couple of common post setup modifications that need to be made for the options I chose in this exercise. The first modification involves a bug in the client packager. If you specify not to install the Program Neighborhood client (as I chose not to in this exercise), it will still be installed to the workstation anyway as "Install on Demand" (see Citrix Article CTX105642).
So, to get around this, you will need to modify the MSI file by following these steps:
- Launch ORCA.
- Open the admin install MSI file (Ica32Pkg.msi) created earlier.
- Select the Condition table.
- Change the condition to "Not Installed" for the Program Neighborhood client.
There is another "feature" in the client packager that puts an icon for Program Neighborhood on the workstation desktop even if you chose not to install Program Neighborhood (see Citrix Article CTX108212)
So, once again, it's ORCA to the rescue:
- Launch ORCA.
- Open the admin install MSI file (Ica32Pkg.msi) created earlier.
- Select the Shortcut table.
- Right click the row with "DesktopFolder..." in the Directory column and select Drop Row.
Enable Single Sign On for Active Directory Deployment
There is yet another "feature" in the client that disables single sign on in the client when deploying via Active Directory (see Citrix article CTX103439). As the article states, you will need to apply a transform (MST) in order for Single Sign On to work.
- Download slfregfix.mst from http://support.citrix.com/article/entry.jspa?entryID=3936
- Launch ORCA
- Open the Ica32Pkg.msi file created above.
- Select Transform -> Apply Transform...
- Browse to slfregfix.mst.
- Click on File -> Save Transformed As... and save the package as a different name (such as mod_Ica32Pkg.msi).
Deploy the Package with Active Directory
Finally, after all the blood sweat and tears to create the admin install client package, you can deploy the package with Active Directory. The question you must answer here is do you want to assign or publish this package? Also, if you assign the package, do you want to assign it to computer or user objects? In this exercise, I assigned the package to computer objects. (For more information about assigning and publishing packages via a GPO with Active Directory, check out Active Directory® for Microsoft® Windows® Server 2003 Technical Reference)
<disclaimer> I strongly suggest you toughly test this in a separate test environment if you have one. If you do not have a separate test environment, at least create a test OU in your Active Directory to try this out.</disclaimer>
- Open up Active Directory Users and Computers.
- Right click on the OU you want to use to host the GPO to deploy the package and select Properties
- Select the Group Policy tab.
- Click edit to edit an existing Group Policy or New to create a new Group Policy. (Again, I suggest creating a new GPO for testing purposes).
- Browse to Computer Configuration -> Software Settings -> Software installation.
- Right click Software installation and select New -> Package.
- Browse to the package created above.
- Select Assigned on the Deploy Software Dialog.
Now, any computer object you move into this OU will automatically have the pre-configured Citrix ICA client installed upon logon (I suggest you only try moving a few computer objects into the OU for testing purposes).
Be careful about placement of the Citrix client install files and network bandwidth. You may want to have different GPO's specifying different install points based on location. Here’s what Microsoft has to say:
One of the most difficult aspects of managing software distribution using group policies is network utilization management. If you assign a large multi-megabyte application to a large group of users and all of those users install the application at the same time, the installation might take hours because of the significant increase in the volume of network traffic. There are a number of options for managing the network bandwidth. One option is to assign applications to computers and ask users to reboot the computers at the end of the day. You can also force a reboot of the workstation by using the GPUpdate command. If you apply this command to only a few workstations at a time, the impact on the network can be minimized.
Another option is to assign applications to small groups of users at one time. In most cases, you might also want to avoid assigning applications that will be completely installed when the user logs on. If you advertise an application but allow the user to initiate the installation, you will be able to at least spread out the software installation over some time. Although none of these options is ideal, you can use them to at least manage the bandwidth to some extent. Another way to manage network utilization if you have multiple sites is to use the Distributed File System (DFS). With DFS, you can create a logical directory structure that is independent of where the files are actually stored on the network. For example, you might create a DFS root named \\server1\softinst and then create subdirectories for all applications underneath that share point. With DFS, you can locate the subdirectories on multiple servers and configure multiple physical links to the same logical directories. If you use Active Directory-integrated DFS, you can even configure automatic replication of the folder contents between copies of the same directory. DFS is a site-aware application, which means that if you have multiple sites, the client computers will always connect to a copy of a DFS folder in their own site rather than cross a wide area network (WAN) link to access the folder on another site.
It is difficult to predict exactly what the effect of a network installation will be. One of the advantages of using group policies to install software is that you can easily perform a test to see what the effect is likely to be. For example, you can configure a GPO that includes the software package but make sure that GPO is not linked to any OU. You can then create a temporary OU, add a few user or computer accounts to the OU, and link the GPO to the OU. This configuration can be used to test how long it takes to install the applications to a small group of users. You can also pilot the software distribution by linking the GPO to a production OU but using group filtering to limit which users or computers will apply the GPO.
Regardless of the efforts you take to minimize the effect on the network, deploying a large application to a large number of users will always have some impact on the network. Since this is this case, you will probably have to plan on completing the installation over several days.
This article showed you how to make a pre-configured admin install of the Citrix ICA Client and the idiosyncrasies involved to make certain functionalities work. Also, we used Active Directory and Group Policy Objects to deploy this customized package. Note: you can use any deployment method you like to deliver the final MSI (such as SMS), but if you do not have SMS (or another deployment device) available in your environment, this method works well.