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

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
command-line arguments.

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

Media table
entry, which describes in what cabinet the patch files can be

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
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
installation the 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 ARPSYSTEMCOMPONENT=1, I
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
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
administrative installation.

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
, there must exist an

UpgradedImages table
. This table lists the upgrade .msi files that
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,
such as 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
writes the 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:

<Component Id=”KB123456.ARPNoRemove”>
    <Condition>NOT KB123456.ClientPatch</Condition>
    <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.

Heath Stewart

Senior Software Engineer

Follow Heath   


    Leave a comment