Administrators new to System Center Configuration Manager (and SMS) are often befuddled by return/error codes from programs delivered using an advertisement. The common question is typically something like “Where can I find a list of error codes?” The answer to this question is that you can’t find a list. Program return/error codes are completely dependent on the program; a developer is free to return any code that they wish using one of many different functions or APIs.
Having said all of this, Windows does define a well-known list or error codes that many developers do in fact use to return simple error information to the user. The easiest way to query what each error code translates into is to drop into a command prompt and enter the following:
net helpmsg <errorcode>
That’s it. As long as the developer chose to use the windows error codes, which most do, you now have an easy way to get to the description of the error code which is usually at least half the battle.
Also note that in general, an error code of 0 means success, everything else is an error. This is a convention traditionally used by all operating systems and developers. ConfigMgr also uses this convention to determine the success or failure status of an advertised program. Every now and then, you will, however, find someone that doesn’t follow this convention and it will throw ConfigMgr off. Be aware of this.
ConfigMgr and OpsMgr also use error codes extensively in their logging and alerting facilities, however, the following two caveats often apply.
- Sometimes error codes are HRESULTS; e.g, 0x80040005. HRESULTS are extended error codes that attempt to provide more information than just a reason for failure. For a lot more details see Deciphering an HRESULT by Heath Stewart and Tricks for deciphering HRESULTs not listed in my previous 1935 error article by Aaron Stebner.
- Sometimes HRESULTS are displayed as a negative number; e.g., –2147024891. This happens because the application displaying the HRESULT does not know to display it as a hex number and converts it to a signed 32-bit decimal. With signed 32-bit decimals, if the first bit is a one, the number is negative, thus the negative number. These simply need to be converted to a hex value to be properly interpreted. Aaron talks about this in the post referenced above.
Another way to get back information about advertisement status in ConfigMgr/SMS is to use Status Management Information Format (MIF) files. MIF files are based on a format defined by the Desktop Management Task Force (DMTF): the same folks responsible for SNMP and WBEM. When used with advertisements, these files contain extended error information, not just error codes. ConfigMgr/SMS uses these files for various things already; e.g., hardware and software inventory status. Creating one of these files is not difficult and Microsoft has previously published a stand-alone tool to help you with this. There is also a COM object that you can use to create these file. To tell ConfigMgr to look for status MIF files, you must also fill in the Reporting tab on the package.
The easiest way, however, to create status MIF files is to use an MSI. The Windows Installer executable, msiexec, has a specific switch to create a status MIF file: /m. Most documentation on msiexec does not include this switch, but it’s there. If you create a package in ConfigMgr using the Package from Definition option and choose an MSI, ConfigMgr will automatically create the programs with the /m switch and fill in the Reporting tab for you. Good on ya ConfigMgr team!
There is also a way to produce status MIF files from legacy InstallShield installers, but I don’t honestly know what it is and don’t feel like looking it up right now.