Add support for Status MIF reporting with Application Model
Packages/Programs in ConfigMgr support use of Status MIF reporting while the Application Model does not. Status MIFs can provide for more accurate and detailed status reporting, particularly for deployment execution failures. For this reason, some customers have been reluctant to transition to the Application Model.
The Application Model relies on exit codes for determine success/failure of deployments.
Disadvantages of depending on exit codes:
Success exit codes (0, 3010, etc.) do not always indicate successful installation; failure exit codes do not always indicate failure
Exit code 0 does not always indicate that the installation succeeded, but rather only that the installer routine itself encountered no errors; which is particularly problematic when leveraging installation wrapper scripts. So it doesn’t mean anything actually was installed. Conversely, sometimes a non-zero exit code doesn’t indicate failure, as with the Microsoft Malicious Software Removal Tool, for example, which will generate a range of exit codes from 0 to 13; each indicating various results as to whether or not malicious software was detected, cleaned, and a reboot required.
Exit codes do not provide insight into reason for failure. For example, we’ve all seen exit codes like -27648472020 – what does that mean? Sometimes we can look those up, sometimes not, and it is time-consuming – especially when we have to sift through thousands of status messages for a large deployment. Another case in point are Windows Installer packages, which will nearly always generate exit code 1603 when they encounter problems – giving us no real clue as to why the installation failed.
Exit codes are often generic and are really only the client’s “best guess” as to the success or failure of a deployment.
- Status message ID 10008 = Success w/o MIF
- Status message ID 10006 = Failure w/o MIF
Advantages using MIFs:
1) Great insight into any issues with Program execution:
For example, if I am deploying a Windows Installer package without specifying a MIF, and it fails, it will more than likely generate exit code 1603; which will be recorded in the client’s status message – which isn’t particularly helpful in identifying why the package failed to install. Exit code 1603, as previously mentioned, is generic and can indicate a whole host of problems. One of the things I might do to troubleshoot in this case is to walk over to a system in which the installation failed and attempt to install the MSI interactively. Why might I do this? Because I want to see the error message dialog that was generated by the installation routine – which will very likely be very clear about why it cannot install. For example, let’s say the error was “This application requires the .NET Framework 2.0 which was not detected”. Well, if I deploy this same package again using a MIF, I will capture, in the status message that is returned from the client, the error that is generated by interactive installation – likely word-for-word. So you can think of MIFs as capturing any messages a user would see on the final dialog when installing something manually. You might also think of them as log summarizers giving you a summary of the final result – really the next best thing to actually being there watching the installation occur.
2) Improve accuracy of deployment success status:
If status message ID 10008 (which success w/o a MIF) is being reported for a deployment for which I specified to dump and collect a MIF, and yet I get success without the MIF (exit code), I will be dubious of that success (something’s not quite right, I was expecting a MIF).
If status message ID 10006 (failure w/o a MIF) is being reported for a deployment that I have specified to use MIFs, then I know that the error occurred very early on, likely before the launch of the command line” – often indicating a problem with the command-line syntax – it all really depends on the installer (Windows Installer, .EXE, VBS, etc.)
• Can be used to provide details on various conditions
One of the other benefits MIFs provide is that they return different MIF status and text based on conditions of the program execution. Going back to our Microsoft Malicious Software Removal Tool example, and it’s use of custom exit codes, I could use a MIF to translate those exit codes to intelligible text explaining the outcome of the execution (in plain English).
• Validates success/failure of an installation.
The installer support MIFs, then generally the installer will have logic built-in that will validate that a program installed successfully and generate a MIF reflecting that status. But I can also use MIFs for programs that don’t support MIFs. For example, say I have an .EXE-based installer that does not generate MIFs, using a wrapper script, I could launch the .EXE, wait for it to complete, and have the wrapper script and write out MIF status accordingly.
- Status message ID 10009 = Success with MIF
- Status message ID 10007 = Failure with MIF
Ben Rampe commented
@Vincent: Yes, that is actually "normal" in that it is up to the author of the installer (.EXE, script, etc.) that generates the status MIF to specify the status text. Often, for success, they will only indicate "OK" or otherwise not specify anything other than a success status. Most installers will generate fairly helpful details for failures however (e.g. "Access denied writing to HKLM\SOFTWARE\Microsoft...). I know with the tools I use to generate MIFs, I always try to provide confirmation that the installation succeeded, but again, it is up to the author of the installer to do so.
is it normal that using MIF for success (10009 code) doesn't return the Last Execution Result (description) ? using the failed error it works perfecty but not success :-(