Deploying Software via Group Policy
Since the basics of this topic were looked at in previous articles, so
my intention is to look at some of the more advanced options here. For
the purpose of review, the basics of group policy are outlined below.
In an AD environment, group policy allows us to distribute software to
users and computers using a repackaged file format, .msi. When software
is deployed using group policy, the user needs no special privileges,
since the software is installed using the elevated privileges of policy.
If a vendor does not provide an msi file for their software, you can use
a repackaging program, such as WinInstall LE (found on the Windows 2000
CD) to create one.
The two basic options when deploying software via
group policy are to either Assign or Publish it. Software can be either
published or assigned to users. If assigned, the software appears to
follow the user, regardless of where they log on. Shortcuts appear
on the start menu, but the software isnt actually installed until
they click on the shortcut. When assigned to a computer, the software is
installed on that computer the next time it reboots, and is available to
all users of the system. When software is published (which can only be
done to users, not computers), the software is available to install from
Add/Remove programs, and can also be installed by document invocation
(when a user click on a file type associated with that application).
Publishing software makes it available to users, but doesnt create
the illusion that it is actually installed. An application can also be
published using a .zap file, if an msi does not exist or if one cannot
be created. Note that if a .zap file is used, the user will require a
level of privilege suitable to install the application. Also note that
software deployment options are only applicable for Windows 2000-based
systems, and would not be applied if a user logged on to Windows 98, for
example.
The Software Settings area of group policy is where the publishing or
assigning options are set, as shown below:
When an application is deployed by
group policy, the first option that must be chosen is whether the
application will be published or assigned, as shown below:
You should use filtering of GPOs
sparingly, as they can complicate GPO troubleshooting. The advanced
elements of software deployment can be set up when you originally choose
to deploy the software (by choosing Advanced published or assigned as
shown above), or later by accessing the properties of the deployed
software. The advanced properties allow you to control a number of
elements with respect to the deployment, including the addition of
upgrades or patches, modifications, as well as uninstalling packages.
There are 6 property sheets associated with advanced application
deployment, and you should be familiar with them. The general tab lists
basic information about the package (such as the version number), while
the security tab contains the ACL for the object. The deployment tab,
shown below, controls whether the application is published or assigned
(which can be changed). If published, you can control whether or not the
application will be installed by document invocation (this option is
grayed out when you choose to assign an application).
Note the option to uninstall the
application when it falls out of the scope of management. If this is
chosen, and the GPO that deployed the software no longer applies (for
example if a user or computer object was moved), then the software would
be automatically uninstalled. The installation user interface options
allow you to control how much interaction the user will have during the
installation process.
The upgrades tab (shown below) allows you to automate the deployment of
patches and upgrades (such as newer versions) to applications that have
already been deployed via group policy. If the upgrade is made mandatory
(the required option is selected) then the upgrade will be applied, and
the user will only be able to use the updated version. If it were not
made mandatory, then the user would be able to use both the old and new
versions of the software. This is potentially useful when a new
application is not backwards compatible.
The categories tab allows you to
create and control the way that applications are presented in Add/Remove
programs. For example, you could create categories for each type of
software, such as graphics applications, word processors, and so forth.
This section would allow you to group the newly published application
into one of those categories in order to make it easier for a user to
install the correct application.
Finally, the modifications tab (shown below) allows to further customize
a package for users with special needs. For example if you wanted to
deploy a language-specific dictionary for users in different offices,
you could apply a modification to the package. Modifications are made in
the form of .mst files (also known as transform files). For those who
are interested, there is a utility provided with the Office 2000
resource kit to create .mst files.