Rerun of failed advertisements does not work as expected when you use status MIF files generated by Windows Installer

Rerun of failed advertisements does not work as expected when you use status MIF files generated by Windows Installer

  • Comments 1
  • Likes

imageYou may want to use status MIF files for extended or custom reporting of the advertisement status by configuring the reporting properties of a mandatory advertisement to "Use these fields for status MIF matching", but if the resulting MIF file is generated by Windows Installer (using Windows Installer command line parameter "/M", for example "/M MIF" in the packages command line), the client might set the execution status to FailureNonRetry even if the exit code is within the list of Failure Retry Error Codes.

The list of Failure Retry Error Codes causing the Configuration Manager Client to retry the installation as well as the according client policies can be found:

1. In the Site Control File:

PROPERTY <Execution Failure Retry Count><REG_DWORD><><1008>

PROPERTY <Execution Failure Retry Interval><REG_DWORD><><600>

PROPERTY <Execution Failure Retry Error Codes><REG_SZ><{4,5,8,13,14,39,51,53,54,55,59,64,65,67,70,71,85,86,87,112,128,170,267,999,1003,1203,1219,1220,1222,1231,1232,1238,1265,1311,1323,1326,1330,1618,1622,2250}><0>

or

2. In Configuration Manager 2007 Clients in WMI Namespace "root\ccm\policy\machine\actualconfig", instance of class "CCM_SoftwareDistributionClientConfig".

In the following example, the client never re-tries to install the program even if the Windows Installer return code is in this list:

1. You configure the Schedule in Advertisement to "Rerun if failed previous attempt" (see TechNet (Configuration Manager): Advertisement Name Properties: Schedule Tab).

2. The Reporting properties of the package are configured to use a "MIF file name:" of MIF.mif.

3. The command line in package's program is something like "msiexec.exe /I "msipackage.msi" /QN /M MIF /L*v.

On a client, Windows Installer exits with return code 1618 which means "Another installation is already in progress. Complete that installation before proceeding with this install".  The return code 1618 is in the list of Failure Retry Error Codes but the client never re-tries to install the program.

In execmgr.log you will find:

"Execution is complete for program Install-Basic-with-MIF. The exit code is 1618, the execution status is FailureNonRetry"

The behavior is based on current design of SMS 2003 and Configuration Manager 2007.  In the case where a MIF file is used for status reporting, only the value of attribute "Status" within the MIF file is considered to determine the installation result.  In case that the value of attribute "Status" is "Failed", CCMEXEC sets the final execution status to "EXECUTION_FAILURE_NORETRY" (i.e. "FailureNonRetry").

In the example above, the MIF file created by Windows Installer does not contain the return code but the status is defined as "Failed".

Excerpt of the MIF file:

START COMPONENT
NAME = "WORKSTATION"
… … …
START GROUP
NAME = "InstallStatus"
ID = 2
CLASS = "MICROSOFT|JOBSTATUS|1.0"
START ATTRIBUTE
NAME = "Status"
ID = 1
ACCESS = READ-ONLY
STORAGE = SPECIFIC
TYPE = STRING(32)
VALUE = "Failed"
END ATTRIBUTE
START ATTRIBUTE
NAME = "Description"
ID = 2
ACCESS = READ-ONLY
STORAGE = SPECIFIC
TYPE = STRING(128)
VALUE = "Another installation is already in progress. Complete that installation before proceeding with this install."
END ATTRIBUTE
END GROUP
END COMPONENT

Comparison of the results of status message query "All Status Messages for a Specific Advertisement …" for identical MSI advertisements with/without a status MIF file shows that there is no additional information (beside the description of the return code) when using a MIF created by Windows Installer.

There are two configuration options to solve this issue:

1) Add a "Recurrence Pattern" to the Mandatory Assignment.

- This causes package/advertisement to re-run only on clients where it previously failed.

- On clients where a previous installation succeeded, installation will not be re-run and you will find the following in execmgr.log:

"CreateMandatoryRequestRecursively policy Install basic-msi no need to re-run"

2) For Windows Installer based installations, do not use MIF reporting.

- Change advertisement properties to "Use package properties for status MIF matching" (instead of "Use these fields for status MIF matching")

As the 1st option causes an unnecessary increase of incoming client status messages (each client regularly checks the recurring advertisement and sends a status message) and as there is no gain of additional information when using status MIF reporting in conjunction with Windows Installer based installations, the 2nd option is typically more feasible.

Armin Denzler | Senior Support Escalation Engineer

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • We're getting this issue all over our site as we get a lot of rebuilt machines and they all install a large number of msi's once they've been rebuilt (based on security group membership), and it seems they like to install all the msi's at the same time...leading to a lot of failures. So I went through all my adverts changing them to rerun if previously failed, and now I've found your article telling me this won't work.

    Many of our packages have been added to our SCCM without full (or correct) info in the package information, meaning without MIF matching we probably still won't get info about the software not being installed - or at least SCCM will never think the software has been installed.

    So that leaves me with setting a recurring install schedule for every advert...and I have hundreds of adverts for different rooms and packages!

    Have you got any simple way of setting a recurring schedule on all the adverts? Say a simple SQL update or something. I've not idea how to do this, other than go through each advert again, and my mouse finger is already hurting from doing it the first time. Plus our SCCM system is dog slow (we can't afford to scale it up or out).

    Please! Pretty please! With a cherry...

    Nick.

    University of the West of England, Bristol UK.