The Best Damn Windows Server 2003 Book Period- P65 ppsx

Windows Installer Packages (.msi)
In the early days of Windows computing, you could use a third-party installation and packaging tool
to simplify software deployment (including Microsoft’s SMS). Beginning with Windows 2000, the
new Windows Installer technology became available, this provides a native packaging and distribu-
tion tool for Windows operating systems, and Group Policy provides a way to distribute software
without buying a distribution product.
The Installer technology is made up of the following components:
■
The Installer service, which is an operating system service that uses Windows Installer
packages to perform software installation, modification, and uninstallation.
■
The .msi file, which is a group of files compressed together along with the appropriate
scripting to install and configure the software. It is essentially a relational database con-
taining a number of tables that holds information about the application.The package can
be configured to handle upgrades as well as new installations.
■
The application programming interface (API) by which applications interface with the
Installer service.
A big advantage of Windows Installer is its ability to “roll back” to the former state if problems
occur during an installation.The Installer service can also monitor the state of installed “self-
repairing” applications, and detect missing or corrupt program files.The service can then automati-
cally restore the damaged or missing components so that the application will work properly again.
The database design of the Installer package makes it fast to query and provides for smaller file
sizes.The information in the tables includes data that will allow for different installation scenarios, so
that there is a set of information about how to install the application clean for the first time, how to
install it over a previous version, and so forth. Because the Installer service tracks the installation of
the application’s features and components, it makes it easier to remove the application completely,
without leaving remnants that can cause problems later.
Transforms (.mst)
Packages provided by vendors with their applications are configured and ready to install.This means
there isn’t much room for flexibility if, for example, you want different installation options for com-

puters in different departments.This is where transforms come into play.Transforms are also called
modifications. That’s because a transform is a record of changes to the original package file that allows
you to customize the installation by including or excluding particular features. A transform is appli-
cable to a specific Windows Installer package.
Transforms are especially important when you are doing silent or unattended installations.The
ability to add or remove certain features or make Registry changes in applying your package makes
configuration easier for the administrator. Installing and configuring applications via Group Policy
cuts down on the time spent by the administrator in setting up, configuring, and troubleshooting
applications for users.
606 Chapter 18 • Deploying Software via Group Policy
301_BD_W2k3_18.qxd 5/12/04 2:19 PM Page 606
Transforms customize the installation features at the time you assign or publish the application.
You can create transforms using the authoring and repackaging utilities we discussed earlier, or the
utilities included with applications themselves. Office 2000 included a Custom Installation Wizard
to create transforms for making modifications to the application’s package when deploying it in
your organization. It is often easier to apply a transform rather than repackage an application to
make changes.
You associate your transforms with the application when you configure software installation for
the application. In the new package that you add via the GPO Editor, you need to select Advanced
published or assigned in the Deploy software dialog box that begins the software deployment
process.
Patches and Updates (.msp)
There are times when an application has to be updated because of fixes or new features that are
available through a service pack, patch, or other update software.An .msp file is a special type of
modification that is used to update an existing Windows Installer package with new information.
This allows for easy updates of users’ workstations and application of important security patches and
other fixes.
With an .msp file, only the updated information needs to be distributed to users.This cuts back
on the time and effort required to deploy updates and patches, and cuts down on the amount of
network traffic generated by application updates.

To deploy an .msp update, you generally should advertise the package again to those to whom
the original application was assigned or published. Sometimes, the software vendor will provide an
entire new .msi package if changes are extensive. In this case, you should just replace the old .msi
file with the new one. Otherwise, use the .msp file to make the changes to the original .msi file, and
then redeploy the application.This will automatically install the new version for those users and
computers where the original was installed, and make it available instead of the old version for those
users to whom the original was published, who haven’t yet installed the application.
Note that .msp files are not able to make certain changes. For example, they cannot be used to
remove Registry keys, or remove or change the names of shortcuts and files.They cannot be used to
change product codes, and you can’t use them to remove features.These tasks require the use of an
.mst transform or a new .msi package.
Application Assignment Scripts (.aas)
When you set up Group Policy Software Installation and publish or assign applications, an
Application Assignment Script (with the file extension .aas) is generated automatically.The
Application Assignment Script is stored in the GPO in Active Directory.The script contains infor-
mation regarding the configuration of the Software Installation.Advertisement information is also
stored within the assignment script.
Deploying Software to Users
GPOs can be linked to a site, domain, or OU (or to a local computer). With that in mind, we will
now discuss deployment of software to user objects in Active Directory. Because software installation
Deploying Software via Group Policy • Chapter 18 607
301_BD_W2k3_18.qxd 5/12/04 2:19 PM Page 607
cannot be done through local group policies, we will be concerned with deploying software at the
site, domain, or OU level.The easiest way to deploy software to a specific group of users is to use
the OU that contains the user objects. A link can be made to an existing GPO, or you can create a
new GPO for this purpose.
Remember that when you deploy software to users, it might be installed soon after they log on.
This is determined by whether you assign the software or publish it. If the software is assigned, the
software will be installed when the user attempts to run the application from the shortcut or clicks on
an associated file. Large installations might make users think that the workstation is locked or froze up,

so you have to be careful about whether you assign, publish, or deploy to the workstation instead.
If the application is published, the user can install the application from Add/Remove
Programs in Control Panel.This makes it more likely that the user will know what’s going on,
since he or she will have chosen to install the application. However, the published application will
be installed via document invocation if file associations were set up within the package, which can
result in the same problem of a user not realizing an installation is taking place and thinking there is
a problem with the computer.
Deploying Software to Computers
Most of the same rules discussed in regard to deploying software to users also apply to deploying
software to computer objects in Active Directory. However, you need to remember that you can
only assign software to computers; there is no publishing to computer objects. Software installation
policies can be applied like any group policy to sites, domains, or OUs. In Active Directory, by
default each computer object is added to the Computers container in the root domain.You will
most likely want to set up software deployment to computers by creating an OU, but this depends
on your Active Directory design.
When software is deployed to computer objects, the installation generally takes place when the
computer boots, prior to the appearance of the Ctrl + Alt + Del screen.This means the user
cannot log on until all of the software has been installed.This must be considered prior to designing
or assigning software installation packages. Assigning too many applications at the same time can
cause the workstation to take a long time to start up.
Using Group Policy Software
Installation to Deploy Applications
Now that you know the basics of software installation, let’s look at the details and step-by-step pro-
cedures involved in completing the process. We will look at the interface used to add software
installation packages: the GPO Editor MMC snap-in.
In this section, we will review the Microsoft Windows Installer technology and packages, in the
context of how they are used in the process of software deployment. We will also look at how to
create your own Windows Installer packages using Veritas WinINSTALL LE. Because the configura-
tion of legacy applications is often an issue in real-world deployment scenarios, we will show you
how to deploy software when you don’t have a Windows Installer package and do not want to

create one. Finally, we will discuss how to set up distribution points.
608 Chapter 18 • Deploying Software via Group Policy
301_BD_W2k3_18.qxd 5/12/04 2:19 PM Page 608
Preparing for Group Policy Software Installation
Determining which applications you plan to distribute with Group Policy Software Installation is an
important first step in the deployment process. Because the GPOs used to deploy software can be
linked to a site, domain, or OU, some planning is required.You must take into consideration your
Active Directory design and the application needs of your organization.
Some departments will require a particular application, whereas there is no need for that appli-
cation in other departments. For example, the Financial department may need accounting software
that is not used elsewhere. In other cases, an application is required for all those in a particular job
function. For example, all project managers may need a particular project management application,
regardless of department.There are also times when an application must be distributed throughout
the entire enterprise. For example, the software that is used to open and read personnel policies or
security policies that apply to all employees will be needed by everyone, regardless of department or
job function.Your Active Directory design and organizational needs will ultimately determine your
plans for where you will configure Software Installation within Group Policy.
Creating Windows Installer Packages
Although Microsoft provides Installer packages with most of their software programs, the situation is
not quite as simple when you have third-party software to install.Then, you may not have the con-
venience of having a Windows Installer package available, but when this happens, you can use a
utility to create an Installer package. One such tool that has been available since Windows 2000 is
WinINSTALL.The original version of WinINSTALL LE (Limited Edition) was included on the
Windows 2000 Server installation CD-ROM.The software is no longer included on the Windows
Server 2003 CD-ROM, but a free MSI repackager, WinINSTALL LE 2003, can be downloaded at
no cost at the OnDemand Software Web site at www.ondemandsoftware.com/FREELE2003/.
Alternatively, you can download a trial version of the full WinINSTALL product.The full product
can be used in environments where deployment needs are more complex, and provides features such
as hardware and software inventory, conflict assessment, MSI validation, and multicast replication—
many of the same features offered by Microsoft’s SMS.

Figure 18.2 shows the WinINSTALL LE interface.
Deploying Software via Group Policy • Chapter 18 609
Figure 18.2 WinINSTALL LE 2003 Console
301_BD_W2k3_18.qxd 5/12/04 2:19 PM Page 609
Before you begin to create your own packages, you should configure a freshly installed worksta-
tion to use for this purpose.This will ensure that you have a clean Registry and standard configura-
tion of the operating system. Using a workstation that has had software installed and removed and
other changes made to it can cause problems with package deployment.
If you cannot dedicate a workstation for creating .msi packages, you must use a computer that is
as close as possible to the configuration of the workstations that will receive the package.The work-
station on which you create the packages should be running the same version of the operating
system as the computers on which the packages will be deployed.As simple as package creation
seems, if configuration steps are not followed closely, you might spend more time troubleshooting
problems than successfully deploying software.
Using .zap Setup Files
It is possible to publish applications that don’t have .msi packages by using the application’s Setup
program. If you want to deploy software via Group Policy, do not have an .msi file, and do not want
to create one, you can instead create a .zap file for the program.The key point to remember in
using .zap files is that they can only be published to users; you cannot assign software to users or to
computers by this method.This type of software deployment also has some additional limitations
when compared to Windows Installer packages, including the following:
■
These installations cannot take advantage of elevated user privileges.This means that if the
application requires an account with administrative privileges to be used to install it, users
who don’t have administrative privileges won’t be able to install it even though it is pub-
lished to them.
■
The programs cannot be installed on first use by double-clicking a shortcut, as with
Windows Installer packages.
■

The system does not automatically repair or remove an application, and you cannot roll
back a failed deployment.
■
You cannot install features upon first use of the feature, as you can with .msi packages.
If these limitations don’t present a problem with the application you want to deploy, the first
step is to create a .zap file for the application being deployed.To create a .zap file, you must follow
the format prescribed by Microsoft.The .zap file is a text file and can be created in any text editor
(for example, Notepad).A sample is available to use as a guide in the Microsoft Knowledge Base
article Q231747.
Only two items are required to be completed for a working .zap file.As long as FriendlyName
and SetupCommand are filled in with a Program Name and a string for executing the Setup pro-
gram, the .zap file will work.The [Application] section is required, and you can also include an
[Ext] section; the latter is the file extension section where the application is associated with a file
extension in Active Directory.The [Ext] section is optional.
The .zap file is created in a text editor such as Notepad.
610 Chapter 18 • Deploying Software via Group Policy
301_BD_W2k3_18.qxd 5/12/04 2:19 PM Page 610
After you create the .zap file, you have to add it to your Software Installation configuration
within Group Policy.The following example walks you through the steps of publishing an applica-
tion with a .zap file.
Publish Software Using a .ZAP File
When publishing software with a .zap file, you first need to determine which GPO you want to
edit. After you determine whether to use a GPO that is applicable to a site, a domain, or an OU,
open the appropriate GPO (see the section titled Working with the GPO Editor later in this chapter)
and make the appropriate addition by following these steps:
1. In the GPO Editor’s left console pane, expand User Configuration, and then expand
Software Settings.
2. Right-click Software Installation, select New, and then select Package.
3. Change the Files of type field to ZAW Down-level applications package (*.zap).
4. In the Open dialog box, navigate to the location of your .zap file or type the path in the

File Name field.
5. Click the .zap file you created and click the Open button.
6. Click Published as the deployment method in the Deploy Software dialog box, and
click OK.
Creating Distribution Points
To distribute software, you must ensure that the users are able to access the needed files from the
network.As a network administrator, you must create shared folders on the network known as distri-
bution points, to hold the necessary files for installing the deployed applications.A distribution point
can be part of a Distributed File System (Dfs) hierarchy or any share point that is available to all
users who will need to install the software.
Each share point needs to be configured with the appropriate NTFS permissions to allow access
to those who will install the software.This will allow you to control the software that can be
installed. If a user doesn’t have permissions to access the folder where a package is stored, the soft-
ware cannot be deployed to that user.
In most cases, it is preferable to control who is able to receive the software through their associ-
ation and permissions to the GPO itself, but the NTFS permissions must be at least Read and
Execute for the distribution point and its subfolders.
Working with the GPO Editor
For those who have worked with the Window NT 4.0 System Policy Editor, learning to use the
Active Directory GPO Editor should be relatively easy. However, deploying applications via Group
Policy can be a bit complex.There are many different options to configure when you are setting up
a package for deployment.You can deploy software for fresh installations, manage the upgrade of
previously installed packages, and remove software from workstations by forcibly uninstalling the
software. Every tool is available for managing software within your organization.
Deploying Software via Group Policy • Chapter 18 611
301_BD_W2k3_18.qxd 5/12/04 2:19 PM Page 611
In the following sections, we will show you how to use the GPO Editor to set installation
options, assign and publish applications, upgrade applications, and remove managed applications.
Opening or Creating a GPO for Software Deployment
The first step in deploying software via Group Policy is to create a new GPO or open an existing

GPO that applies to the site, domain, or OU to which you want to deploy the software.You can
open an existing domain policy by following these steps:
1. Click Start | All Programs | Administrative Tools | Active Directory Users and
Computers.
2. In the left console pane of the ADUC tool, right-click the name of the domain and select
Properties.
3. Click the Group Policy tab.
4. Select the policy you want to edit under Group Policy Object Links. Click the Edit
button.This will open the policy in the GPO Editor.
To deploy software at the OU level, follow the same steps except, in step 2, expand the node for
the domain, right-click the name of the OU to which you want to deploy the software, and then
click Properties.
If you want to deploy software at the site level, follow these steps:
1. Click Start | All Programs | Administrative Tools | Active Directory Sites and
Services.
2. In the left console pane, expand the Sites node.
3. In the right details pane, right-click the site to which you want to deploy the software, and
click Properties.
4. Click the Group Policy tab.
5. Select the policy you want to edit under Group Policy Object Links. Click the Edit
button.This will open the policy in the GPO Editor.
Assigning and Publishing Applications
Earlier we discussed the concepts of assigning versus publishing applications. Now we will look at
the GPO Editor console’s interface to become more familiar with the step-by-step process.After
you open the GPO Editor, right-click on Software Installation under either Computer
Configuration or User Configuration (depending on whether you want to assign the software to
computers or assign or publish it to users) and choose New Package from the right context menu
as shown in Figure 18.3.
612 Chapter 18 • Deploying Software via Group Policy
301_BD_W2k3_18.qxd 5/12/04 2:19 PM Page 612

A dialog box will open asking you for the package you want to use. Navigate to a network
location where the .msi file for the software you want to deploy is located. Package files should be
stored in a central location.This central location is your distribution point for your software pack-
ages. Software packages can generally be downloaded from the manufacturer. Some organizations
choose to create their own with other third-party software products.
When you choose a new package, it should be located on a network share. Otherwise, you will
receive a message informing you that clients will not be able to install the package, as shown in
Figure 18.4.
Next, a prompt will ask you if you want to assign or publish the application, or use the
Advanced method. If you choose Advanced, you will be presented with the Properties window for
your new package. We discuss the options that you can configure in this Properties box in the sec-
tion titled Configuring Software Installation Properties later in this chapter.
Assign Software to a Group
This procedure will walk you through the steps of assigning software to an Active Directory group
at the OU level.This gives more granularity to the configuration, and this example will give you
some good hands-on practice in using the interface.
Deploying Software via Group Policy • Chapter 18 613
Figure 18.3 Configuring a New Package
Figure 18.4 Error Message When Selecting Drive Letter
301_BD_W2k3_18.qxd 5/12/04 2:19 PM Page 613
1. Ensure that you have a distribution point (a shared folder containing the .msi package) set
up with the appropriate NTFS permissions assigned.
2. Log on as a Domain Administrator.
3. Open Active Directory Users and Computers from the Administrative Tools menu
and right-click the OU to which you want to deploy the software. Select Properties.
4. Click the Group Policy tab and choose New to create a new GPO.
5. Select the new GPO in the list and type a distinguishing name for it.
6. Click Edit to make changes to the GPO.
7. In the GPO Editor, highlight Software Settings under User Configuration.
8. Right-click, select New, and then select Package.

9. Navigate to the location of your .msi package.This is the distribution point that you
shared earlier. Enter the UNC path so the workstations can find the software.
10. Next, you are prompted to select whether to publish or assign the application or choose
the Advanced option. Select Assigned.
11. Click OK.The software package name should show up in the right details pane of the
GPO Editor.
12. Close the GPO Editor window. In the OU’s Properties dialog box, select the GPO
under Group Policy Object Links and click the Properties button.
13. In the GPO’s Properties dialog box, click the Security tab.
14. Remove Authenticated Users on the Security tab and add the appropriate group that
contains the users to whom you want to assign this application.
15. Click OK and the application should be ready for deployment.
Configuring Software Installation Properties
When you first open the GPO Editor, expand Computer Configuration or User Configuration
(depending on whether you want to deploy the software to computers or users), and then expand
Software Settings. Under Software Settings, right-click Software Installation and choose
Properties.
There are four tabs within the Properties of Software Installation. In the following sections, we
will discuss the configuration options that can be made with each of these tabs.
The General Tab
On the General tab, you can specify the default location of all packages. Under the New Packages
section on that same tab, you can specify the default value for publishing or assigning.The default is
to prompt the user to decide at the time of object creation.The last item to be configured on this
tab is the User Interface options.This setting determines how much of the installation the user sees.
The Basic option only shows minimal screen display during software deployment.The Maximum
option shows all the installation screens as the installation happens.
614 Chapter 18 • Deploying Software via Group Policy
301_BD_W2k3_18.qxd 5/12/04 2:19 PM Page 614
The Advanced Tab
The Advanced tab has options to be configured such as how to handle 64-bit machines as well as

OLE information being published in Active Directory. Figure 18.5 shows the Advanced tab.
The first option in this window is Uninstall applications when they fall out of the scope
of management.This means that if a software program was installed with Group Policy and later
the account was moved to a different OU, the software could be uninstalled automatically.
You can also choose to have Object Linking and Embedding (OLE) information stored in Active
Directory. OLE can be a key part of user interaction and collaboration.
The File Extensions Tab
The File Extensions tab is where you can associate documents and other file types to a specific
application that is configured for deployment as shown in Figure 18.6.
Deploying Software via Group Policy • Chapter 18 615
Figure 18.5 Advanced Tab of Software Installation
Figure 18.6 File Extensions Tab
301_BD_W2k3_18.qxd 5/12/04 2:20 PM Page 615