How Group Policy Software Installation Extension Works
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2
How Group Policy Software Installation Extension Works
In this section
Terms and Definitions
Group Policy Software Installation Extension Architecture
Group Policy Software Installation Extension Components
Group Policy Software Installation Extension Processes and Interactions
The Group Policy Software installation extension allows administrators to use the Group Policy Object Editor to centrally manage the installation of software on all client computers in an organization. This is accomplished either by assigning applications to users or computers, or by publishing applications for users.
Software can be assigned on a per-user or per-computer basis when an organization does not want to give users the choice to install or remove the software. For example, if a user removes a user-assigned application by using Add or Remove Programs in Control Panel, the Group Policy Software installation extension automatically reapplies the advertisement information after the user logs on or the computer restarts, and the software is reinstalled the next time a user selects it or tries to open a file with an associated file name extension. It is not possible for a user to delete a computer-assigned application. In most cases, packages that are assigned to users or computers include applications that are essential but do not create congestion between the clients and the software distribution points.
Group Policy-based software deployment allows administrators to publish software for users only; in other words, published software is not available for computers. Publishing software for users allows them to decide if and when they want to install it. They can install the software from a list of published applications in Add or Remove Programs. For example, not everyone in the organization requires software for project management. Therefore, a software administrator is likely to publish a project management package for only those users who require it. Managers who require the software can then choose to install it.
Users can always see both assigned and published applications in Add or Remove Programs. Add or Remove Programs includes an active Web link for each application, which provides users with the support information they need to install certain applications. However, administrators can overwrite the default link by using the Group Policy Software installation extension. The support link then corresponds to the internal product support resources.
This Web link can also point to a support page that includes information such as an FAQ about a specified application, a help desk article about using the application, or instructions for requesting support.
Group Policy–based Software Installation in the Ideal Environment
The following components are necessary to deploy software using the Group Policy Software installation extension:
Group Policy.
Windows 2000 Server or Windows Server 2003 domain controllers.
A network that uses Active Directory directory service–based domains.
Target computers that run Windows 2000 Server, Windows 2000 Professional, Windows XP Professional, or Windows Server 2003.
The Group Policy Management Console (GPMC) is not required but necessary for simple, powerful, and efficient administration. See the Group Policy topic for more information about GPMC.
Terms and Definitions
The following are terms used in this document to describe aspects of Group Policy–based software deployment.
Advertisement
The process of making an application that supports Windows Installer appear installed on the desktop, by installing the shortcuts for the application on the Start menu or desktop, and by populating the registry with the application information.
Advertisement script
The output of the Group Policy Software installation extension Microsoft Management Console (MMC) snap-in, which advertises an application that supports Windows Installer. The advertisement script is stored in Active Directory.
Assigned
One of the modes of targeting supported by Group Policy-based software deployment. Administrators can assign the software that users require to perform their jobs. Administrators can assign software to users and to computers. User-assigned applications are advertised on the desktop; they appear to be installed on the user’s desktop, but they get installed the first time that the user starts the application, typically from the Start menu. If a user deletes an assigned application, it will be re-advertised. Computer-assigned applications are installed the next time that the computer restarts.
Package
A Windows Installer .msi file. At its core is a database that contains the instructions to manage the software on a computer.
Published
One of the modes of targeting supported by Group Policy-based software deployment. Administrators can publish software to users. Published applications are not advertised on the desktop; there is no physical appearance of published applications on the user’s desktop. Users install published applications from the Add or Remove Programs in Control Panel or by opening a file type associated with an application.
Repackaging
The process of preparing software for distribution by making an image of a correctly configured computer, then installing the software and making a post-installation image of the computer. The repackaging software takes the difference of the two images and creates the necessary installation instructions to reproduce the installation.
Group Policy Software installation extension snap-in
The MMC component of Group Policy Object Editor that an administrator uses to manage software.
Transform
(Verb) The process of modifying or customizing a Windows Installer-based .msi package.
Transform
(Noun) A Windows Installer customized package that, if associated with another Windows Installer-based .msi package at deployment time, results in a customized installation.
Windows Installer
Windows Installer is a Windows operating system–based service that can install, modify, repair, and remove software. Windows Installer includes the operating system–based service, a package format, and an application-programming interface (API) that allows both the operating system and applications to interact with the service to install, modify, or repair the software.
Group Policy Software Installation Extension Architecture
This section details the architecture behind Group Policy–based software distribution. The Group Policy Software installation extension performs two processes: application publishing and application assignment. The following figure shows the server-side perspective of Group Policy–based software deployment.
Server Architecture and Components of the Group Policy Software Installation Extension
.gif "Software Installation Extension Architecture")
Application Publishing
Publishing is simply advertising that a package is available to be installed – it does not mandate that an application be installed. A published package is created by using the Group Policy Software installation extension. The Group Policy Software installation extension extracts advertising information about the package and stores this, in modified form, in both the directory and the Sysvol folder. Advertising information includes the name and installation path of the application; it also includes information about the file associations, Program IDs (ProgID), and Component Object Model (COM) Class IDs (CLSID) that the application supports or implements.
Published applications can be either Windows Installer .msi files or text-based .zap files. Each is treated differently: The Group Policy Software installation extension uses the Windows Installer subsystem to extract advertising information from the .msi package. This information is programmed into the .msi package by the author of the package, normally the application vendor. A .zap package is a simple text wrapper around a setup command. The author of the .zap file can include information such as file name extension and COM support in the .zap file. This information is extracted directly by the Group Policy Software installation extension.
A subset of the advertising information – file name extensions, CLSIDs, and ProgIDs – is used to create an Active Directory package publication object (PackageRegistration) in the ClassStore container. This is located in the GPO GUID\User\Class Store\Packages subcontainer of the Group Policy object (GPO) in which the package is published and given a newly generated globally unique identifier (GUID) for a common name (CN). This published package then becomes available to all recipients of the advertised application.
The Group Policy Software installation client-side extension (CSE) also creates an Application Advertising script in the Sysvol folder that is derived from the same advertising information. This has the same name as the related PackageRegistration object with a file name extension of .aas. In this case, more of the advertising information – such as Start menu shortcuts created by the application, which are omitted from the PackageRegistration object – is used in the creation of the .aas file. This file is stored in GPO GUID\User\Applications.
Published applications do not cause any change on the client computer during normal GPO processing, so no information is downloaded from Active Directory or Sysvol. However, the applications published to the user can be viewed in Add or Remove Programs. The user must perform some action to cause the published application to be installed. The simplest case is that the user chooses to install the application from Add or Remove Programs.
The Group Policy Software installation extension also supports a more sophisticated method for installing applications. If a user attempts to open a document with a file name extension for which there is no application currently installed, or tries to call a COM object for which there is no local definition in the registry, the Group Policy Software installation extension service searches Active Directory for PackageRegistration objects that support the file name extension or COM CLSID and that have been published to the user by using a GPO. If one is found, the .aas script is downloaded to the client computer and runs to create advertisements on the computer. When the user again attempts to open a document or a COM operation is retried, the advertisement triggers the installation of the application (or at least that part of it required to support the document or COM operation attempted). If more than one suitable PackageRegistration object is found, the one in the highest-priority GPO is selected. Where there is more than one in the same GPO, the one with the latest creation date is selected.
The following figure shows the Group Policy–based software publishing architecture.
Group Policy–based Software Deployment Processing Architecture and Components (Published Software)
.gif "Group Policy-based Deployment Processing")
Application Assignment
Assigning is a superset of publishing. The same description for published-application processing applies to assignment except that the application is either fully or partly installed on the client computer during GPO processing.
Assignment differs from publishing in that the Group Policy Software installation extension either advertises the application on the client computer (in the case of a user assignment) or fully installs the application (in the case of a computer assignment). Assigning to a user creates an advertisement of the application on the client computer – this can include application shortcuts on the Start menu and registry entries defining COM and program registrations supported by the application. Unlike publishing, applications can also be assigned to computers. The Group Policy Software installation CSE only processes during startup and logon, never during periodic refresh. By default, it also does not process over a slow link (this behavior can be changed).
The creation of an assigned package is similar to that of a published package. This produces an almost identical PackageRegistration object and .aas file. The only difference is that the PackageFlags property of the PackageRegistration object identifies this as an Assigned rather than a Published application.
Advertising is a function of Windows Installer and works by placing entry points to the application on the client system. Examples of these entry points are Start menu shortcuts, COM Class IDs, Program IDs, and Multipurpose Internet Mail Extensions (MIME) types. These entry points are configured so that, if any of them are called, Windows Installer installs the application. Windows Installer checks to see whether the application or application component that implements the call has been installed. If not, it installs the application. To the user, the advertisements appear to be already installed.
During GPO processing, the Group Policy Software installation CSE queries the directory for available assigned PackageRegistration objects for applied GPOs that have changed or are new. Any packages found are compared to those already downloaded onto the client computer – the client computer records received packages in the registry and caches .aas files. Any new or changed packages are processed. The corresponding .aas file is read from the Sysvol folder and then cached in %systemroot%\appmgmt. This folder also contains AppMgmt.ini, which stores configuration settings.
The following figure shows Group Policy–based software assignment architecture.
Group Policy–based Software Deployment Processing Architecture and Components (Assigned Software)
.gif "GroupPolicy–based software assignment architecture")
Software Distribution Point Servers
Deploying applications is the process of setting up and managing distribution points or server shares where users have access to the packaged software and can install it on their computers. These servers act as file shares for the .msi packages identified in software installation GPOs.
Two methods can be used for deploying and managing software distribution point servers:
Universal naming convention (UNC) path to a server share.
Distributed File System (DFS).
UNC Paths to Server Shares
By using UNC paths, a user or application can specify the physical server and share names to gain access to file information. For example: \\Server\Share\Path\File_name. A UNC path can be used to allow direct access to a shared file by mapping to a network drive, where the drive letter denotes \\Server\Share. Administrators can also perform a net use command to navigate beyond the redirected drive.
However, as networks grow and as organizations begin using existing storage for new purposes, mapping a single drive letter to individual shares becomes inefficient. Also, despite the fact that users and applications can refer to UNC names directly, the increasing number of places users must go to retrieve data can be overwhelming.
DFS and Software Distribution Point Servers
DFS provides fault tolerance for software distribution points by mapping a specific logical name to shared folders on multiple file servers. This way, software remains available for installation, regardless of whether one of the physical servers where the software deployment files reside becomes unavailable. DFS also improves storage scalability because administrators can deploy additional or higher-performance file servers and present the storage on the new computers as new directories in an existing namespace.
When using DFS in combination with Group Policy–based software deployment, organizations benefit from its load-sharing abilities and location-independence. These features simplify management and optimize the installation for users. Instead of allowing all users to install software from a single server, and taxing the server, a DFS namespace can distribute network traffic across multiple servers.
Group Policy Software Installation Extension Components
Group Policy–based software deployment uses the Windows Server 2003 features and technologies described in the following table.
Essential Tools and Components for Group Policy–based Software Deployment
| Component or Tool | General Description | Combined with Group Policy Software Installation Extension |
|---|---|---|
Active Directory |
A hierarchical collection of objects including domains, sites, organization units (OUs), users, computers, and printers that allow an organization to manage these resources. |
Provides the scope of management mechanism to locate users and computers. Stores software deployment information through Group Policy. |
Group Policy |
An administrative tool for defining and controlling the way programs, network resources, and the operating system work for users and computers in an organization. In an Active Directory environment, Group Policy is applied to users or computers on the basis of their membership within sites, domains, or OUs. |
Enables administrators to deploy applications in a GPO associated with one or more Active Directory containers, such as sites, domains, or OUs. Use the Group Policy Software Installation extension snap-in to deploy applications. |
Windows Installer |
A service based on an operating system, which provides software installation services using a standard package format. Administrators can use Windows Installer to manage the installation, modification, upgrade, and removal of software applications. |
Installs, modifies, upgrades, and removes software applications. |
Group Policy Software installation extension |
An extension of the Group Policy Object Editor snap-in that includes a user interface that allows administrators to deploy and manage software. |
Communicates with Active Directory, GPOs, and Windows Installer to assign or publish applications as follows:
|
Appmgmts.dll |
The client-side extension for the software installation component of Group Policy. |
This is the extension file on the client that configures software installation settings. |
Group Policy Management Console (GPMC) |
A new tool that consists of an MMC snap-in and command-line tools. This tool unifies management of all aspects of Group Policy across an enterprise. GPMC allows administrators to manage all GPOs, Windows Management Instrumentation (WMI) filters, and permissions on a network. |
Group Policy Modeling (formerly known as RSoP planning) allows administrators to run hypothetical scenarios to verify software configurations under various sites, domains, and OUs. Provides printable HTML-based reports. Group Policy Results(formerly known as RSoP logging)verifies which software applications are properly installed for a specific group of users or computers. It also pinpoints the causes of unintended removal or damage to software. Provides printable HTML-based reports. |
Add or Remove Programs |
A user interface in Control Panel of Windows XP Professional and Windows 2000 Professional. Add or Remove Programs lets users manage software on their own computers. |
Lists both published and assigned applications so that users can install, modify, and remove software from their desktop computers. |
Command-line and Graphical User Interface (GUI) tools or scripts |
These include GPResult.exe, GPOTool.exe, GPUpdate.exe, ReplMon.exe, NetDiag.exe, InstallShield, and the new Group Policy Management Console (GPMC) MMC snap-in. Some are installed by default; others must be installed manually. |
Helps manage, optimize, or troubleshoot Group Policy–based software deployment. |
How Windows Installer Works
Many software authors develop applications to include native Windows Installer packages. A native Windows Installer package contains a single product, such as Microsoft Office 2000, which can be made up of several features, such as Microsoft Word, Microsoft Excel, and Microsoft PowerPoint. However, software can be configured to install features individually. When the user selects an uninstalled feature, the feature is installed. Each feature (Word, Excel, PowerPoint, and so on) contains components, such as a thesaurus, spelling checker, or an additional user-interface language. When the user selects a feature or component that is not installed, the feature or component is automatically installed. Automatic (or “on-demand”) installation of selected features saves network bandwidth during the initial installation. It also gives users only the features and components that they need to do their jobs. Automatic installation can also save space on users’ local disk drives. However, this type of installation delays the availability of a feature when the user first selects it.
Windows Installer packages ensure that an accidentally deleted file, such as Winword.exe, is reinstalled the next time the user tries to start Word because Windows Installer detects and reinstalls missing files.
Windows Installer technology uses the following two components to help an organization install and manage software:
A Windows Installer package (an .msi file), which is a database containing information that describes the installed state of an application. The Windows Installer package performs the installation, modification, and removal of the software.
An application programming interface (API) that allows applications and management tools to interact with Windows Installer to install or remove additional features of the application after the initial installation is completed.
The managed state of an application includes installation, modification, upgrade, or removal. Windows Installer provides administrators with consistent and reliable methods to customize installations, update and upgrade applications, and resolve configuration problems. The following are some of its advantages:
Helps manage the state of software during and after installation.
Defines a standard format for application setup and tracks components such as groups of files, registry entries, shortcuts, and other aspects of the application that must be managed together.
Detects whether software is installed correctly or whether a program file is missing. It can immediately reinstall the damaged or missing files.
Repairs applications and ensures that they are installed or removed without overwriting or deleting files that are required by another application.
Enables administrators to modify an installation by adding or removing features after the installation.
Enables deployment of 32-bit and 64-bit Windows applications using Windows Installer version 2.0.
Note
- Versions of Windows Installer earlier than version 2.0 can install and manage 32-bit Windows Installer packages only on 32-bit operating systems. Windows Installer version 2.0 supports all of the setup functionality that is available in earlier Windows Installer versions.
Software installed by using the Windows Installer uses the following parameters:
\>msiexec /I \\servername\share\<software.msi> TRANSFORMS = \\servername\share\<software.mst> /qb
In this example, Software.msi is the Windows Installer package, and Software.mst is the transform applied at deployment time.
Transforms for Customizing Windows Installer Packages
A transform (.mst file) is a collection of specified changes that are applied to a base Windows Installer package file at the time of deployment. Windows Installer packages are modular to simplify deployment. When transforms are applied to an .msi file, Windows Installer can dynamically add or modify data in the installation database to customize the installation of the application.
For example, Office 2000 provides the Office 2000 Custom Installation wizard, which can be used to build transforms. Administrators can create a transform for managing the configuration of Office 2000 that is deployed to users in an organization. Other tools in the Windows Installer software development kit (SDK), or other non-Microsoft tools, can also help to create transforms for Windows Installer packages that do not include their own custom installation tools.
Transforms tailor the installation of an application. Although they are optional, transforms can be used for a variety of purposes including customizing and encapsulating.
Customizing
Customizing can involve configuring installations so that a particular set of features from a specified software application, or suite of software applications, is installed locally on the computer.
Transforms can also add new features to an existing application’s package. For example, they can add custom Excel templates for an organization’s Finance group.
Encapsulating
Administrators can encapsulate numerous customizations of a base package that are required by different groups. For example, in organizations where the Finance and Marketing departments require different installations of an application, the base package of the application can be made available to everyone at one software distribution point. Then the appropriate customizations can be distributed separately as transforms to each group of users.
Reauthoring Applications for Windows Installer
When administrators reauthor an application, they create applications that adhere to the Windows Installer format. Reauthoring is essentially redeveloping the setup portion of the application to take full advantage of the advanced capabilities of Windows Installer.
There are some authoring tools available to help developers create new Windows Installer packages, but the procedures can be resource-intensive and costly. If an organization determines that the application will play a key role in its future, it is important to weigh the benefits of reauthoring with the costs.
.Zap Files
Applications that do not use the .msi file format for the Windows Installer Service can be set up for distribution by creating a text file that has a .zap file name extension. When organizations have many applications that do not contain native Windows Installer packages and plan to discontinue these applications, they often create software installation settings (.zap) files for the installation executable files, such as Setup.exe or Install.exe. Additionally, if an organization uses custom applications that do not have Windows Installer support, but plan to use them in the long term, .zap files might be the only choice. Users of .zap files do not benefit from the capabilities of Windows Installer. The Group Policy Software installation extension recognizes .zap files that wrap 32-bit or 64-bit Setup.exe files into a .zap file format. Applications published in this format are available for users to install by using Add or Remove Programs.
Because these applications do not use Windows Installer setup programs, they do not do the following:
Use elevated permissions for installation. While applications that are installed by using .zap files run their original setup programs, they do not run with the elevated permissions that Windows Installer packages have. If installing the application requires administrative permissions, only users who have those permissions can install it.
Install a feature on the first use of the feature.
Roll back an unsuccessful operation, such as install, modify, repair, or removal.
Detect a broken state and automatically repair it.
Implement customized installations (also known as transforms).
64-Bit Application Packaging
In Windows Server 2003, the Group Policy Software installation extension and Windows Installer version 2.0 continue to support and protect the investment that organizations have made in 32-bit applications. Additionally, Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter Edition, introduce support for 64-bit application installation.
Windows Installer version 2.0 can install three types of Windows Installer packages on a computer running a 64-bit operating system:
32-bit packages that contain only 32-bit components
64-bit packages containing some 64-bit components and some 32-bit components
64-bit packages containing only 64-bit components
Note
- 64-bit applications cannot be published or installed on 32-bit operating systems. Group Policy will attempt to install an incorrectly configured 64-bit package for 32-bit clients, but then removes the package during logon. It then installs the package again the next time a user logs on, and so on.
The Group Policy Software installation extension can be configured to allow or disallow installation of 32-bit applications to 64-bit clients. More .zap applications fail on 64-bit clients than on 32-bit clients. Unless the default behavior is changed, 32-bit .zap applications are deployed so that they are not listed in Add or Remove Programs on 64-bit clients.
Repackaging Applications for Windows Installer
Administrators repackage an .msi package for Windows Installer when they cannot reauthor it. Repackaging an application for Windows Installer involves making an image of a fresh computer (including the registry settings, files, and system settings), installing the software, and then taking a post-installation image of the computer. The repackaging software detects the difference between the two images, and then creates the necessary instructions to reproduce the installation. If any registry changes, files changes, or system setting changes occur during the capture process, they are included in the installation. Repackaging is useful when administrators do not have control over dynamic-link library (DLL) files, source code, and registry entries, or for applications about which they do not have in-depth knowledge.
Repackaging requires a thorough knowledge of the application’s installation program and of the Windows Installer configuration on the Windows platform. Success with repackaging is affected by the state of the computer on which an administrator performs the repackaging. The computer should have only the operating system and operating system service packs installed before running the repackaging software. Because of this limitation, and other issues, repackaging is not recommended.
Repackaging is not a function or a feature of Windows Installer. As with reauthoring applications, several vendors provide tools to enable administrators to repackage applications for a variety of needs. The same vendors who provide tools to reauthor applications can also help repackage them.
During repackaging, an application, the existing components, such as DLLs, .ini files, registry settings, and shortcuts, are replaced, and then the administrator creates a path for Windows Installer to find these items at installation time.
For more information about repackaging applications in the .msi format, see the Windows Installer SDK for detailed documentation about the Windows Installer package format.
Group Policy Software Installation Extension Processes and Interactions
Because software can be published for users, assigned to users, or assigned to computers, administrators can establish a workable combination of those three options to meet an organization’s software management goals.
Publishing Software for Users
The benefit of publishing software, instead of assigning it, is that it requires less management when change occurs in the Active Directory structure. Typically, applications that are nonessential for the users are published. When software is published for a user, it does not initially appear to be installed on the computer. There is no Windows Installer advertisement information about the software on the computer in the registry, on the desktop, or on Start menu as a shortcut. On an as-needed basis, the user installs the published software by using Add or Remove Programs in Control Panel. An exception is when an application is published in a new GPO, when the GPO must be simultaneously linked to the users in a site, domain, or OU. If a GPO is linked and the software is deployed at the same time, the GPO must be refreshed by an administrator or by a user logging on before the application appears in Add or Remove Programs.
Users can also install a published application by opening an associated document if the application is deployed to do that (if Auto-Installis selected).
The user can remove published software, and then later choose to reinstall it, by using Add or Remove Programs.
The following figure shows how Group Policy–based software publishing works.
Group Policy–based Software Publishing for Users
.gif "Group Policy-Based Software Publishing for Users")
Assigning Software
There are three methods for assigning software: assign to users on-demand, assign to users, or assign to computers.
Note
- By default, Group Policy allows administrators to configure a user-assigned application that has a staggered, on-demand installation. Windows Server 2003 allows administrators to turn off the default installation and install the entire application at once. This is the same behavior as computer-assigned application installation.
Assigning Software to be Available on Demand
After a software package is assigned to users in a site, domain, or OU, the software is advertised on user desktops. The application becomes available to the user the next time the user logs on (if the application’s GPO applies to that user). The application is fully installed by the user from the Start menu, from Add or Remove Programs, from a desktop shortcut, or by opening a document (on demand) that has a file name extension that is associated with the application.
The user can remove the software, and then later choose to reinstall it as they did previously. Group Policy ensures that assigned applications that are available on-demand are available, regardless of whether users remove them, and that the applications are available again the next time the user logs on or starts the computer.
Assigning Software to Users
After a software package is assigned to users in a site, domain, or OU, administrators can use the Install this application at logon option to install the whole application the next time the computer starts, or after the user logs off and then logs on again. Alternatively, for users of Windows XP Professional, Logon Optimization can delay the installation of software to the second logon to prevent installation during the first logon. The application is also immediately available in Add or Remove Programs.
The user can remove the software, and then later choose to reinstall it.
Note
- Some published applications might not appear in Add or Remove Programsin a domain that has multiple domain controllers until the changes have replicated to all domain controllers in the domain.
The following figure shows the client-side perspective of assigning Group Policy–based software deployment.
Group Policy–based Software Assignment to Users
.gif "Group Policy–based Software Assignment to Users")
Assigning Software to Computers
After assigning a software package to computers in a site, domain, or OU, the software is installed the next time the computer restarts or the user logs on. For users of Windows XP Professional, Logon Optimization can delay the installation of software to the second logon to prevent installation during the first logon.
Only the local or network administrator can remove the software, though a user can repair the software.
The following figure shows the client-side perspective of publishing Group Policy–based software deployment.
Group Policy–based Software Assignment to Computers
.gif "Group Policy-based Software Assignment to CPUs")
Patches for Installed Applications
Installing a patch updates a previously installed application or applications. A patch package (.msp file) is obtained from the software manufacturer or from the internal developers of the original program. Installing patches allows existing applications to be updated without removing the product. This preserves the customizations of the installation and can lower the cost of making the change. The patch might change only a few bytes of a single application file. It is more efficient to distribute those few bytes than to remove and redeploy the whole product.
Note
- A patch might change all of the files and registry keys in a product.
After a patch is applied, it is cached on the user’s computer, this allows the user to:
Perform any installation on demand.
Reinstall the application.
Repair the application.
Remove the application.
A patch package (.msp file) does not include a database as a regular installation package does. Instead, it contains, at a minimum, one database transform that adds patching information to the database of its target Windows Installer .msi package. For an application to perform maintenance operations, such as adding, removing, or repairing the installation, the package codes for both the installed application and the source must match.
Software Upgrades
During an upgrade where the ProductVersion or ProductCode property of the package has changed, Windows Installer searches for upgradeable products by querying the Upgrade table of the upgrade package. The newer version of the product is installed. If Windows Installer finds an older version of the product, it removes the old version. The author of the application’s setup can choose to remove the old version, and then install the new version. The maintenance mode and removal do not trigger these actions because “remove existing versions of an application” is now automatic.
The Windows Installer package for a repackaged application does not have declared upgrade relationships. Administrators must manually create upgrade relationships. The Group Policy Software installation extension can be used to create upgrade relationships between the new package and the packages that the application replaces. This includes making a formal upgrade relationship between two similar products from completely different vendor’s. A vendors application can replace another’s, or an administrator can upgrade a repackaged application.