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.
From page 90 of the Citrix client Administrator's
Guide:
"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:

Getting Started
Tools Needed:
- 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.
Quote from Citrix:
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:
From
Active Directory® for Microsoft® Windows® Server 2003 Technical Reference:
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.
Conclusion
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.