Identifying Administrative Installation Patches
Windows Installer has the ability to create administrative installations,
which is a copy of the .msi database and files that have been expanded into a source
directory structure. These administrative installations can easily be deployed
using Active Directory group policy deployment among other things, such as
creating patches since PatchWiz.dll requires that patch sources are not compressed. You can
create administrative installations using the /a command-line switch, which corresponds to
ACTION=ADMIN if specified in the
You can also patch an administrative installation using both the /a and /p command-line switches. This results in the patch transforms persisting changes to the database; however, the non-administrative transform that begins with a # symbol is not persisted and is used only to resolve the patched files to the correct Media table entry, which describes in what cabinet the patch files can be found.
Because Microsoft Developer Division uses an external UI handler, it writes it’s own registry keys using the Registry table to display entries in the Add/Remove Programs (ARP) control
panel. This means that
ARPSYSTEMCOMPONENT=1 is set,
which I’ve discussed
before as causing several problems. This means, too, that patches must write
their own registry keys for ARP.
Since patches applied to administrative installations loose their identity as
patches since the non-administrative transform isn’t persisted, these patches
cannot be removed. This means when installing a patched administrative
DWORD registry value NoRemove must be added to the appropriate
registry key for each patch applied to the administrative installation. This
prevents the Remove button from displaying in ARP for that patch, which
would – if clicked – display the message “The patch is not applied to this
product.” Frankly, that’s misleading.
There are several ways of solving this problem and hiding that button that
all lead to writing the
DWORD registry value NoRemove. We need a component that
will install only when installing or patching an installation for patches
applied to the administrative installation.
Since non-transitive component conditions are evaluated only when the
components are first installed, one could use the
IsAdminPackage property to determine if the component – which contains the registry value to be written
– should be installed. Windows Installer sets this property automatically when
installing or reinstalling an administrative installation onto a client machine.
Because of problems introduced by setting
had to implement a custom supersedence strategy using transitive components. That
means the conditions are evaluated every time the components are reinstalled,
which is when their containing feature or features are reinstalled. Clearly the
IsAdminPackage property won’t work in this case.
Another way might be to use the
AdminProperties property, which lists property values to save when the
administrative installation is created into a sub-stream named AdminProperties that – if the
AdminProperties property exists in the Property table – is read
for property values to override property values stored in the Property table
when the administrative installation is installed. The problem here is that the AdminProperties sub-stream – which is written during the InstallAdminPackage
standard action – is only written when the administrative installation is
created, not when it is patched. So, patches can’t use this feature to persist
an override to a property to indicate that the patch was applied to an
Recall that the non-administrative transform is only applied when the patch is installed on a client machine to patch an installed product. Another solution is to write a property into the non-administrative transform that we could check. In your .pcp file as input to PatchWiz.dll, there must exist an UpgradedImages table. This table lists the upgrade .msi files that PatchWiz.dll uses to create patches. The PatchMsiPath column allows you to specify the path of a copy of the upgrade .msi that contains additional entries in tables. These entries are added to the non-administrative transform instead of the regular patch transform that contains the differences between both the target and upgrade .msi files.
So, create a new property with a patch-specific name and a property value,
KB123456.ClientPatch=1, in a copy of the upgrade .msi and add the
source path to that copy in the PatchMsiPath column for your
relevant upgrade .msi entry in the UpgradedImages table. When you create the patch, that
non-administrative transform will contain that property in the Property table.
Next, add the condition
NOT KB123456.ClientPatch, using the example property
name, to the Condition column in the Component table for the relevant component entry that
DWORD registry value NoRemove, or whatever component objects you want
to install only for administrative installation patches. An example WIX fragment
for such a component would look like the following:
<Registry Id=”ARP.KB123456.NoRemove” Action=”write” KeyPath=”yes” Root=”HKLM” Key=”SOFTWAREMicrosoftWindowsCurrentVersionUninstallKB123456″ Name=”NoRemove” Type=”integer” Value=”1″/>
When the administrative installation is patched, the non-administrative
transform isn’t persisted so the
KB123456.ClientPatch property won’t exist when
the administrative installation is actually installed on a client machine. This
means that the component condition that checks that the property doesn’t exist
will evaluate to true and the component gets installed, which writes the
property value and hides the Remove button from ARP.