Configuration Manager with Jason Lewis : CUPT

What are those “Per User” MSI warning messages about?

Jason Lewis — Mon, 06 Aug 2007 19:55:00 GMT

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.

What’s the difference between Prerequisite, Applicability and Installed Rules?

Jason Lewis — Thu, 02 Aug 2007 21:26:00 GMT

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.

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.

What is Catalog Updates and why should I use it…

Jason Lewis — Fri, 29 Jun 2007 03:16:00 GMT

Catalog Updates is a feature in Custom Updates Publishing Tool (CUPT) and System Center Updates Publisher (SCUP) that allows you to maintain a list of catalogs. This list of catalog gains you two things, first the ability to detect when a catalog is updated by the vendor and secondly the ability to bulk import all of your catalogs in one single import session.

To use this feature you will need to add catalogs to your Catalog Updates list, there are two ways to do this. The first is to manually add them (Click on “Settings -> Add” on Import List tab). This will bring up a form where you can enter the catalog information. The second option is to automatically add them with the “Discover and Add External Catalogs” feature (Click on “Settings -> Find” on the Import List tab). This option will find all the partner catalogs that are included in the Microsoft catalog (http://www.microsoft.com/smserver/partners/itcucat.mspx).

After adding the catalogs to your Catalog Updates list you can now detect when they are updated. To do this you hit the refresh button on the “Catalog Updates” control in the center pain. You can also configure CUPT/SCUP to automatically check for new catalogs every time you start the program (Click on “Settings -> Automatically check for updates to my catalogs on startup” on the Import List tab).

Lastly, now that you have catalogs in your Catalog Updates list you can bulk import them by simply clicking on the “Import” action. You will see on the first page “Bulk Catalog Import” option is now enabled.

What is the difference between the different export options?

Jason Lewis — Tue, 19 Jun 2007 19:17:00 GMT

In Custom Updates Publishing Tool (CUPT) there were two export options, now with System Center Updates Publisher (SCUP) you have three. Today I’m here to tell you what the difference is between all of them.

Export Option 1

First is the option “Export selected updates to a cabinet file that can be imported by other publishers” in SCUP. This is the exact same option as “Export a cabinet file that can be imported by other publishing tools” in CUPT. This option was designed to be used to export your selected updates to a cab file. This cab file then can be imported into any other publishing tool. This is a great option if you have more than one user who authors a single update. For example you might have a marketing team start creating the update and entering information such as title, description, vendor and product. Once the marketing team is done they can export the update and hand off to the developer of the update to import into their SCUP/CUPT and fill out the detection rules.

One thing to note here is what I mean by selected updates. There are only a few ways to select an update, below is a list.

Select the root node, which selects all updates
Select a single vendor node, which selects all updates under that vendor
Select a single product node, which selects all updates under that product
Select one or more updates under a single product node

As you see there is no way to pick and choose across different vendors or products without selecting them all, that is where option 3 comes in.

Export Option 2

The second option is called “Export selected updates to a test catalog XML file and supporting scan file for testing” in SCUP. The corresponding option in CUPT is called “Export a test catalog XML file and supporting scan files for testing”. This is the “Export for Test” option when you want to test your selected update’s Software Distribution Package (SDP) before releasing to the public or your corporate environment. This option will create SDP XML without CAB’ing. Specifically this option exports the raw SDP XML into a user specified folder along with RunScan.cmd and executable to test your updates. All you have to do at that point is double click on “RunScan.cmd” which will then run the test scan engine and report your results in the form of “TestResults.xml”. This results file along with the scan engine log can be used to verify or troubleshoot your update SDP.

Export Option 3 (SCUP only)

The third export option is called “Export all updates in the update publisher database that have the publish flag set” and can only be found in SCUP. This option was originally inside the Publish Wizard in CUPT but was moved to the Export Wizard in the new release. The primarily difference versus the first two options is that it exports only those updates which are flagged (Publish Flag set). This can span across multiple vendor and product nodes unlike the two above selecting options. The other main difference is that this option also produces a signature file (XML) that is used in conjunction with the CAB when publishing online. This signature file stores when the catalog was created and can be consumed by SCUP/CUPT subscribed catalogs feature. The subscribed catalogs feature is used to keep a list of catalogs you want to be alerted to when they are updated. Independent Software Vendors and Line of Business developers should use this option when they want to create a final catalog that is to be consumed by their customers.