Managing .msi Packages and the Windows Installer

Users might occasionally want to install their own .msi packages, which can be on CDs from vendors, such as Office XP and GPMC.msi (from Microsoft), other vendors , or applications that you create using WinINSTALL LE, for example. To manually install a .msi application on a workstation, you can either double-click the application from the CD or shared folder or use a command-line tool called MSIEXEC to kick off (or repair) the installation.

This section explores the options when manually installing existing .msi packages that you've deployed via Group Policy. As we've explored in the previous section, most of the things we need to do can be performed using the GUI. However, some functions are available only in the command-line tool.

Inside the MSIEXEC Tool

MSIEXEC is a command-line tool, which helps you get applications installed. There are three versions of MSIEXEC , but you're likely to encounter only two versions.

If your machine is Windows XP (pre-SP2), simply typing MSIEXEC /? on the command line is no help at all. In this case, to get the full syntax of MSIEXEC , you'll need to use the Windows help file and search for MSIEXEC .

However, if your machine is Windows XP/SP2, MSIEXEC has been upgraded to version 3.0. Now, if you type MSIEXEC /? , you'll get some useful feedback about how to use it.

For the purposes of this book, MSIEXEC for Windows XP/SP2 (that is, MSIEXEC version 3.0) and the non-Windows XP/SP2 versions of MSIEXEC (that is, MSIEXEC versions prior to 3.0) will act functionally equivalent. However, you might be interested in precisely what MSIEXEC 3.0 has to offer. And, if you like what you see, you'll be happy to know that MSIEXEC 3.0 is redistributable via to your Windows XP (non-SP2) and Windows 2000 clients ! Specifically , you can load Windows Installer 3.0 on Windows 2000 Service Pack 3, Windows 2000 Service Pack 4, Windows Server 2003, Windows XP, and Windows XP Service Pack 1. Note, however, you'll need to find some non-Group Policy way to deploy the update because you can't update the MSI engine while in use. (Very clear chicken-and-egg problem.) You should be able to update these systems with Microsoft SUS or WSUS.

You can find out about what MSIEXEC 3.0 is all about at MS KB 884016 with the plucky little title "Windows Installer 3.0 is Available."

You can use MSIEXEC in several ways, but here we're going to look at how to use it to manage existing .msi packages. Indeed, you can use MSIEXEC to script an installation of a .msi package at a workstation, but why bother? You're already using the power of Group Policy. However, you might need to check out how an installation works by hand or enable additional logging for deeper troubleshooting. Or you could trigger a preemptive repair of an application at specific times. You can even use MSIEXEC to remove a specific application.

You can also use MSIEXEC as a maintenance tool for existing packages on distribution points. We'll explore a bit of both uses.

Instead of diving into every MSIEXEC command here, I'll simply highlight some of the most frequently used. Indeed, you may never find yourself using MSIEXEC unless specifically directed to do so by an application vendor's Install program.

Using MSIEXEC to Install an Application

The first function of MSIEXEC is to initiate an installation from a source point. This is essentially the same as double-clicking the .msi file, using the /I switch (for Install). The syntax for your application might be as follows :

 Msiexec /I \WinDC01\apps\yourapp.msi

Using MSIEXEC to Repair an Application

You can script the repair of applications by using MSIEXEC with the /f switch and an additional helper-switch, as indicated in the Windows help file. For instance, you might want to ensure that ProPlus.msi (Office XP) is not corrupted on the client. You can do so by forcing all files from inside the Office XP .msi to be reinstalled on the client. Use the following command (which overwrites older or equally versioned files):

 Msiexec /fe \WinDC01\apps\officexpdistro\proplus.msi

If you simply want to ensure that no older version is installed, you can execute the following command:

 Msiexec /fo \WinDC01\apps\officexpdistro\proplus.msi

Again, be sure to consult the Windows help file for the complete syntax of MSIEXEC in conjunction with adhering to your specific application vendor's directions

Using MSIEXEC to Patch a Distribution Point

You can also use MSIEXEC to patch ; that is to incorporate vendor-supplied bug fixes and the like to the code base of an existing package. The vendor supplies the patches by using a .msp file, or Microsoft Patch file. Office XP's service packs , for instance, come with several .msp files that update the original .msi files.

Office XP has multiple service packs. You can download the first one from www.microsoft.com/office/ork/xp/journ/Oxpspl.htm . It contains MAINSP1_Admin.msp and OWC10SP1_Admin.msp . And you can download the second from www.microsoft.com/office/ork/xp/journ/Oxpsp2a.htm . It contains Mainsp2ff.msp and Owc10sp2ff.msp . Service Pack 3 is here: http://tinyurl.com/b3wlv . It contains Mainsp3ff.msp and Owc10sp3ff.msp .

Note

Microsoft seems to have changed their tune mid-way with this technology. In some instances, you needed to apply each successive service pack's MSP files to be sufficiently protected. However, Office XP's service pack 3, for instance, expressly states that it contains all the fixes contained within all previous service packs. So, be sure to read your manufacture's instructions on whether or not to install every MSP file from every update, or if you can make due with just the most recent.

Throughout this chapter, we've leveraged our Office XP administration point. We'll continue with that trend. In the following example, the Office XP distribution, located at \\WinDC01\apps\officexpdistro , is to be patched with the MAINSP1_Admin.msp patch that comes with Office XP Service Pack 1. The resulting log file will be called logfi1e.txt .

Note	Because each vendor may have a different way of patching, be sure to check out the Readme file that comes with the patch files.

The following command line is written as directed from the Office XP Service Pack SR-1 Readme file:

 msiexec /p MAINSP1_Admin.msp /a \WinDC01\apps\officexpdistro\proplus.msi SHORTFILENAMES=TRUE /qb /L* logfile.txt

Note

Again, you'll have to run the command for each and every patch file in all the service packs. This means you'll have to run the command four times to update an Office XP distribution point to SR-2. You'll only be able to use Office SR-2 updates if you've applied the SR-1 .msp patches to the distribution point.

This next step is a point of order that I left out of the last edition of this book. That is, once the .msi is patched, all your users (or computers) need to reinstall the application. The underlying application has changed, and the client system doesn't know about the change until you tell it.

Users also need to do this because of what is termed the "client-source- out-of-sync " problem. Until the client reaches and reinstalls from the updated administrative image, it won't be able to use the administrative image for repairs or on-demand installations. This is because a source location is validated by the Windows Installer before use. The criteria for validation are the name of the package file and the package code (seen as a GUID) of the package. When you patch the administrative image, you change the underlying package code GUID. Thus, the client needs the recache and reinstall in order to pick up the updated package code information.

So, specifically, after you patch a distribution point (or otherwise change the underlying .msi package in a distribution point), you need to right-click the offer and choose All Tasks ˜ Redeploy Application, as shown in Figure 10.24.

Figure 10.24: Once you patch a .msi source, be sure to select "Redeploy Application."

Affecting Windows Installer with Group Policy

You can use several policy settings to tweak the behavior of the Windows Installer. Most tweaks do not involve how software is managed or deployed via GPSI because there's not much to it. You deploy the application, and users (or computers) do your bidding. Rather, these settings tweak the access the user has when software is not being Assigned or Published.

There are two collections of policy settings for the Windows Installer; one is under Computer Configuration, and the other is under User Configuration. As usual, to utilize these policy settings, just create a new GPO, Enable the policy settings you like, then ensure that the corresponding user or computer account is in the scope of management of the GPO.

Computer Side Policy Settings for Windows Installer

To display the settings in Computer Configuration, as shown in Figure 10.25, choose Computer Configuration ˜ Administrative Templates ˜ Windows Components ˜ Windows Installer.

Figure 10.25: Use Group Policy to affect the Windows Installer settings.

Note that Windows Installer 3.0 has four specific Computer side policy settings. That is, for these four settings to work, your machine needs to be running Windows Installer 3.0. As stated, Windows XP/SP2 and Windows 2003/SP1 both have Windows Installer 3.0 already have Windows Installer 3.0 loaded. And, as stated, the Windows Installer 3.0 redistributable is available for Windows XP (no Service Pack), Windows 2003, and Windows 2000 (SP3 and later.) Again, check out MS KB 884016. Once your client has Windows Installer 3.0, it will respond to the newest settings. These are specifically called out and listed last here.

Disable Windows Installer

Once enabled, this setting lets you specify one of four options:

Not Configured Uses the settings at a higher level.
Enabled/Never Always keeps the Windows Installer active.
Enabled/For Non-Managed Apps Only Turns off the Windows Installer when users try to manually install their own applications. This is useful if you want to guarantee no foreign .msi packages are making it through the doors. This option permits users to install only those programs that a system administrator Assigns or Publishes.
Enabled/Always Essentially turns off all methods (managed and unmanaged) for loading .msi packages.

These settings specify only settings for .msi packagesnot other programs that users can install, such as those from SETUP.EXEs and the like.

Always Install with Elevated Privileges

Deploying applications with GPSI is awesome : we do all the work with .msi files, and we don't have to worry about users having administrative privileges. As we've already seen, we can deploy applications to users, and have the system take care of the installation in the system context (not the user context).

And, what's more, mere mortals cannot just download an MSI application and necessarily expect it to install correctly. Many .msi applications will fail installation if attempted in the user context. You can, however, bypass the normal security mechanism so that users can install .msi files by Enabling this policy setting. You'll need to do the same with the corresponding policy setting in the User Configuration, as discussed in the "User Side Policy Settings for Windows Installer" section.

Note	If you are deploying .msi applications with Group Policy, you need not use and enable this setting.

Prohibit Rollback

As stated, .msi files can be "rolled back" during the actual installation of the application, after the fact in the Add or Remove Programs applet in Control Panel. If you enable this policy setting, you're effectively telling the system not to maintain "backup files" in the case of an on-the-fly rollback. Since a rollback can be initiated during the actual installation, a "fractured" and, hence, nonworking program could remain on the system.

Personally, I would never use this policy setting.

Remove Browse Dialog Box for New Source

Recall that, at any given point, only the components required to run a .msi application are actually downloaded. For instance, the help files in Word are downloaded the first time it is used from the installation source (usually the server), not necessarily the first time Word runs. But what happens if you move the source?

When you move an application from one shared folder to another, the application can become confused , and users need to specify a different installation point to get to the source. By default, users cannot choose another source; thus they are left in limbo. Enable this setting to allow users to choose another source if the original source becomes unavailable.

Prohibit Patching

If users can install some .msi applications under their own security context, by default, they can also patch their own .msi files with .msp (Microsoft Patch) files by using the MSIEXEC command-line application. Enabling this setting prevents users from patching even their own installed .msi applications.

Disable IE Security Prompt for Windows Installer Scripts

Recall that users can manually install .msi applications from a CD, or a shared folder, or a web page. The default behavior before executing any downloaded application via Internet Explorer is to warn the user about potentially damaging content. Enabling this setting squelches this warning.

This scenario should be rare, because normally you Publish or Assign applications in order to install them to your users' desktops. At times, however, some applications may be best suited for downloading via Internet Explorer, and, hence, a warning message could appear and frighten your users.

Enable User Control Over Installs

When an administrator Publishes or Assigns applications, all the settings specified in the .msi application are forced upon the user. Sometimes this behavior is undesirable. For example, you might want to let the user specify the destination folder or decide which features to download. If you enable this setting, you grant users the ability to change the default .msi application settings.

Note

This policy setting affects all applications installed on the client system. How ever, if you want to let the user set up a specific product in their own way, you can use a transform that sets a special properties inside the .msi . You can use the .mst tool to set the EnableUserControl property to 1 or add specific properties to the SecureCustomProperties list (using a customization transform). If your application doesn't have a way to create .mst files, you can create them with third-party .msi creation tools.

Enable User to Browse for Source While Elevated

When an administrator Publishes or Assigns applications, all the settings specified in the .msi application are forced upon the user from the installation point the administrator specifies. Sometimes this behavior is undesirable because the user knows of a closer source to the application in their branch office. In cases like this, you might want to let the user specify the source to locate a closer source point. If you enable this setting, you grant users the ability to change the default .msi source location.

Warning

Once users are affected by this policy setting, they can basically browse any where they like, including the local system. If you have locked down the Desktop to prevent such behavior, enabling this setting could be a potential security hole during .msi application install times.

Enable User to Use Media Source While Elevated

When users install .msi packages under their own security context, they can choose whatever source they desire for the software. But when you, the administrator, Assign or Publish an application, you are essentially dictating the source of the .msi file. If you enable this setting, you permit the user to choose a nonnetworked source, such as a CD or floppy drive, from which to install a program you specify. Enable this setting only if the Enable the User to Browse for Source While Elevated is enabled.

Enable User to Patch Elevated Products

By default, only the administrator who Assigns or Publishes the application can use a .msp file (in conjunction with MSIEXEC ) to patch a program. If you enable this setting, users can use MSIEXEC to patch their local versions of Published or Assigned applications.

Allow Admin to Install from Terminal Services Session

By default, administrators using the Terminal Services "Remote Administration Mode" on Windows 2000 or Windows 2003 Server are prevented from installing additional Published or Assigned applications.

If you want Administrators to be able to install MSI applications while logged in via Terminal Services session, just Enable this setting so that servers and Domain Controllers download the setting and, hence, reverse this default.

Cache Transforms in Secure Location on Workstation

Recall that you can specifically customize a .mst file to hone a .msi application. Transform files are applied on .msi packages either to filter the number of options available to the end user or to specify certain answers to questions usually raised during the .msi package installation.

Once a user starts using a .msi application applied with a .msi file, that .mst file follows them in the Roaming Profilespecifically, in the Application Data folder, as described in Chap ter 8. You can change this default behavior by enabling this setting, which takes the .mst file out of the Roaming Profile and puts it in a secure place on the workstation. On the one hand, this closes a small security hole that sophisticated users might hack into their own .mst files in their profiles. On the other hand, users are forced to return to the machine that has their .mst files in order to additionally modify their application.

Avoid using this setting unless specifically directed to do so by your application vendor, a security bulletin, or Microsoft.

Logging

Applications Assigned or Published using Windows Installer do not provide much information to the administrator about the success of their installation. By default, several key tidbits of information are logged about managed applications that fail. The log files are named .msi*.LOG ; the * represents additional characters that make the log file unique for each application downloaded.

Logs for Assigned applications are on the client machine in the system's Temp folder (typically c:\windows\temp). Installs for Published applications (as well as install transactions from shortcut and Document invocations) are in the user's Temp folder (%temp%). Thus, centralized logging and reporting is an arduous, if not impossible , task for anything more than a handful of users who are using Windows Installer. For additional logging and reporting, Microsoft recommends their Systems Management Server, as described in the section titled "Fitting Microsoft SMS into Your Environment," later in the chapter.

To add logging entries, modify the Logging setting. Some settings that might come in handy are Out of Memory and Out of Disktwo common reasons for Windows Installer applications failing to load.

Tip

You can also turn on Application Management debugging logs by manually editing the Registry of the client machine. Simply run regedit or regedt32 and edit the following key: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion . Create a key called "Diagnostics", then and add Reg_DWORD value called AppMgmtDebugLevel and set it to 4b in hexadecimal. You'll then find a log in the local %windir%debug\usermode folder named appmgmt.log , which can also aid in finding out why applications fail to load.

Prohibit User Installs

On occasion an administrator might dictate that a user is Assigned Office XP, and another administrator dictates that a computer gets Office XP (but perhaps without Access). What if the user who is Assigned Office XP sits down at a computer that is Assigned Office XP without Access? Which one "wins"? The application (and settings therein) Assigned to the user takes precedence.

This policy setting has three options (once enabled): Allow User Installs, Hide User Installs, or Prohibit User Installs. Computers that are affected by "Hide User Installs" display only the applications Assigned to the computer. However, the user can still install the applications assigned to them using the Add or Remove Programs applet in Control Panel (hence, overriding the applications assigned to the computer).

If you set Prohibit User Installs , the user won't get the applications Assigned to them on the machines to which this policy setting applies. And the user cannot load Assigned applications to their user account via the Add or Remove Programs folder. If they do so, they'll get an error message. If this policy setting is set somewhere else, you can also return the default behavior by setting "Allow User Installs."

This policy setting can be especially handy in Terminal Services sessions or Kiosk settings (for example, lab machines) where you want all users of the machine to get the applications Assigned only to computers (not to users).

Note	This setting is valid for Windows XP and Windows 2000 machines (with Win dows Installer 2 or later loaded). See the section "The Windows Installer" earlier in this chapter.

Turn Off Creation of System Restore Checkpoints

On a Windows XP machine, a System Restore Checkpoint is created when users load their own .msi files unless there is no user interface. The .msi system creates System Restore Checkpoints on first installation and uninstall. System Restore Checkpoints are not created when deploying (or repairing) applications via GPSI.

Enable this setting if you want to ensure that no System Restore Checkpoints are created when .msi files are loaded.

Note	This setting is only valid on Windows XP machines.

Prohibit Removal of Updates

Windows Installer 3.0 has new technology to help roll back patches once installed. If you enable this policy, no one can remove software updates and patches once installednot even an administrator. You might want to do this if your environment has special security requirements. That is, if, by unloading a patch, you might be putting the system and your company in harm's way, you might want to enable this setting. This will ensure that no one can uninstall installed patches.

If this policy setting is disabled, a user can remove updates from the computer if the user has been granted privileges to remove the update. This all depends on how the patch was deployed. Read the "Explain help" on this policy setting for more information.

Note	This setting is valid only on machines that have Windows Installer 3.0.

Enforce Upgrade of Component Rules

Windows Installer 3.0 can be stricter about how applications allow themselves to be updated, via .msp files, for example. That is, some .msp files can perform some no-no's that could inadvertently render an application to malfunction once updated.

The Explain Text of this policy setting describes two of these no-no's: when an .msp changes the GUID of a function and also when a new component is added in the wrong place of the .msi tree. These have to do with the way, an .msi file is represented internally to the system. If these things are changed, the application could fail to function.

To that end, Enabling this policy setting forces the .msi engine to ensure that certain safe guards are in place and that the .msp file doesn't actually perform these no-no's.

If you disable this policy setting, Windows Installer is allowed to perform these no-no's.

Note	This setting is valid only on machines that have Windows Installer 3.0.

Prohibit Non-Administrators from Applying Vendor Signed Updates

When a patch comes out from an application vendor, how do you want to handle it? Application vendors could come out with patches that only the administrator can installor conversely, they could also come out with patches that theoretically even the user should be able to install. And these patches are digitally signed, so you can be sure that they're not really coming from EvilSoftware, Inc. You can then just allow the user to just patch their own applications, but this is likely fraught with peril.

However, this policy setting controls just that. If you enable it, you're forcing only administrators to install updates that have been digitally signed by the application vendor.

If you disable this policy setting, mere mortal users can install these non-administrator updates without needed administrative access.

Note	This setting is valid only on machines that have Windows Installer 3.0.

Baseline File Cache Maximum Size

Don't you just hate it when you're asked for the original installation media when an update is available? In theory, this is silly: The application is already installed on my hard drive, why on earth do I need the original media?

Well, with Windows Installer 3.0, this policy setting tries to help fix that. It sets the percentage of disk space available to the Windows Installer "baseline file cache." The idea is that you can have these required files hanging around, ready for whenever an update is ready to do. Then, when the original source is needed, it goes to the baseline file cache and doesn't ask for the original installation source.

If you enable this policy setting, you can then modify the maximum size of the Windows Installer baseline file cache. Note that if the baseline cache size is set to 0, Windows Installer cannot store new files. Previously stored files will stay in place (until the application that uses it is uninstalled ), but new applications (if loaded in the future) cannot store information here. Windows Installer will stop populating the baseline cache for new updates. The existing cached files will remain on disk and will be deleted when the product is removed.

Setting the baseline cache to 100 means "Use as much space as you need!"

By default, 10 percent of the hard drive is used for this purpose. Disabling this policy setting forces the value at 10 percent.

Note	This setting is valid only on machines that have Windows Installer 3.0.

User Side Policy Settings for Windows Installer

To display the Group Policy settings that affect the Windows Installer, as shown in Figure 10.26, choose User Configuration ˜ Administrative Templates ˜ Windows Components ˜ Windows Installer. These settings affect the behavior of the users in the scope.

Figure 10.26: The Windows Installer user settings

One for the Road Leave Windows Installer and Group Policy Software Installation Data

Back in Chapter 8, we discussed a specific problem with regard to GPSI and roaming user profiles. That is, if you chose to enable the Delete Cached Copies of Roaming Profiles policy setting, the machine "cleans up" as a user logs off.

This has an unintended consequence with regard to GPSI.

Specifically, if the roaming profiles data is deleted at logoff time, the information regarding applications deployed via Group Policy Software Installation is also lost (by default). To that end, you should enable a new policy that affects users on Windows XP/SP2 (or Windows 2003/ SP1) called Leave Windows Installer and Group Policy Software Installation Data , which addresses this. Once enabled, the Group Policy Software Installation data remains on the hard drive, so subsequent logins for users is much faster.

Again, enable this setting if you're also choosing to wipe the roaming profile away when the user logs out. Note that it is not a Windows Installer setting, per se, so it's located in a different area. Specifically, you'll find the policy you need at Administrative Templates ˜ System ˜ User Profiles ˜ Leave Windows Installer and Group Policy Software Installation Data .

If you're interested, this problem is specifically discussed in MS KB 828452 "An Assigned Package Is Reinstalled Every Time Clients Log on to the Domain."

Always Install with Elevated Privileges

Enabling this policy setting allows users to manually install their own .msi files and bypass their own insufficient and lowly user rights in order to correctly install applications. Some applications install correctly in the users' context, but many don't.

After you enable this setting, you'll also need to set the corresponding setting in the Computer half, as noted in the previous section.

Search Order

By default, applications that are Published or Assigned using the Windows Installer search their original location for updates or repairs. If that original location is not available, the application tries other locations.

This policy setting allows you to specify any or all of the following locations: Network, removable media, or URL (Web site).

Prohibit Rollback

See the Prohibit Rollback policy setting in the "Computer side policy settings for Windows Installer" section.

This setting is found in both User Configuration and Computer Configuration. Recall that computer settings have precedence over user settings.

Prevent Removable Media Source for Any Install

If you enable this setting, which works only for .msi application, users cannot install applications under their own context. Rather, only administrators can install applications, or applications must be Published or Assigned for users to use them. This prevents users from running down to the computer store, obtaining the latest version of a program, and installing it via CD.