If you ever created an update that uses MSI rules you are bound to see a warning message letting you know that the scan agent cannot detect an MSI if it was installed per-user and that you should use different rules to help detect if the update is applicable or installed.   There is another similar warning when you select a MSI update that allows per-user installation when inside the Create Update Wizard.

So what are these warnings about?  The purpose of the warnings is to inform you that we do not support detection of per-user installed MSI updates using MSI rules.  The reason behind this is that if you have installed a MSI under the “User A” account and then scan for the update it will not be detected by the scan engine (running under a different account) and thus cannot be patched.  The scan engine runs under the local system account and therefore can only detect MSI’s that are installed system wide.

So what should you do if you must deploy an update for a per-user installed MSI?  Don’t rely solely on MSI based rules to detect if your update is applicable or installed.  You should use file or registry rules since these will not be user based.

If you don’t know if your update is per-user enabled or not we can help you find out.  During the creation of the update in the Create Update Wizard’s “Select Package” page when you browse to your MSI/MSP we will check to see if it has per-user installation enabled.  If we detect that it is enable we will display the warning message described above.

In both System Center Updates Publisher (SCUP) and Custom Updates Publishing Tool (CUPT) there are three different types (or sections) of detection rules in the Create/Modify Update Wizard.  These rules types are prerequisite, applicability and installed rules.  The definitions are as follows:

Prerequisite Rule: High level detection rules for checking operating system version, processor architecture, operating system language and other similar checks.  These rules are executed first (in CUPT only) to determine if an update is applicable (or installable) on a system.  For SCUP the prerequisite rules are combined with the applicability rules (with AND logic).

Applicability Rule: More specific detection rules used to verify that the specific update is applicable to the system.  Examples of these types of rules would be file exists, file version, file created date, registry key and other similar rules.

Installed Rule: Rules which are used to validate that the update was successfully applied to the system.  These are also specific detection rules such as file exists, file version, file created date, etc.

How these rules are interpreted and used are slightly different, especially between SCUP and CUPT.  The first thing to note is that only in CUPT are prerequisite rules executed first when scanned on a system.  This is due to using the Inventory Tool for Custom Updates (ITCU) scanner to execute the checks.  The ITCU scanner was designed to first execute the prerequisite rules first (then installed followed by applicability rules), which helps with scanning performance since all updates that aren’t associated with that type of machine are quickly discovered and skipped before executing the rest of the checks.  This is not the case with SCUP.  In SCUP we publish updates to a Windows Server Updates Service (WSUS) server which then moves the prerequisite rules into the applicability rules.  The reason for this is that CUPT and SCUP store updates in Software Distribution Package (SDP) schema xml, while WSUS updates are stored in Software Update Services (SUS) schema xml.  In SUS xml prerequisites are not defined in the same way therefore they most move our SDP prerequisites to SUS applicability rules.

Another difference between the rules is how they act when not defined.  If no prerequisite rules are defined in an update it will evaluate to true (or prerequisite rules passed) when scanned.  However, if you do not define an applicability rule it will evaluate to false, meaning the update will never be applicable (this is bad as no warning is given in the UI).   If an installed rule is not defined then the update cannot be published (the UI will not allow you to flag an update for publish with no installed rules defined).

To summarize, always use prerequisite rules when defining an update even if you don’t get the performance gain from ITCU.   Also keep your prerequisite rules general as in OS or CPU checks.  You should not be doing detailed file checking in your prerequisite rules.  Lastly always define applicability and installed rules; otherwise you will not have a useable update.