You 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