Ugh: CCMSETUP Error Codes

Ugh: CCMSETUP Error Codes

One of the things I’ve lamented and heaped scorn onto in the past is the use of non-standard error codes for processes and installers in particular. Why? Well, if a process or installer returns a standard error code, it’s pretty easy to figure out what that error code means using one of the techniques I described in one of my older posts appropriately titled Error Codes. If, however, a non-standard error code is returned, how is anyone supposed to know what it means especially if the codes aren’t documented by the vendor.

What does this have to do with ccmsetup? If you’ve installed Current Branch version 1602, you may have noticed that the .NET Framework 4.5.2 is now a prerequisite for the client agent and thus ccmsetup will install it if a system doesn’t already have it installed. You may have also noticed that installing this version of the .NET Framework requires a reboot in some circumstances. ccmsetup handles this gracefully (and doesn’t force a reboot) but does exit without finishing the installation, returns error code 7, and writes “CcmSetup is exiting with return code 7” as the final line of ccmsetup.log.

While troubleshooting this issue for a customer using my client startup script, I did what everyone should do when troubleshooting: figure out what error code 7 means. The standard meaning for error code 7, “The storage control blocks were destroyed”, makes no sense for this scenario though so I proceeded to review the other logs in the ccmsetup\logs folder. This lead me to the .NET Framework installer log (named dotNetFx452_Setup.log-MSI_netfx_Full_GDR_x86.msi) which clearly indicated that the .NET Framework installer was requesting a reboot. Others participating in a forum thread I was following also came to this same conclusion at right about the same time. Boo custom error codes.

In response to a query about this from Mr. Finland (aka Enterprise Mobility MVP Panu Saukko), guess what the beloved product team for our most favorite product “admitted”? Yep, they used non-standard error codes for ccmsetup — this almost brought me to tears btw. Oh the humanity! Also in the response to Panu, Brain Huneycutt provided the following short-list of error codes returned by ccmsetup for general public knowledge:

Error Code Meaning
0 Success
6 Error
7 Reboot Required
8 Setup already running
9 Prerequisite evaluation failure
10 Setup manifest hash validation failure

As with most deviations, I’m sure that there was a well thought-out reason for this and it wasn’t just an intern making an uninformed choice; now that the codes are documented though, we can all take a few deep breaths, wipe away the tears, and carry on.

5 Comments

Cancel

  1. Code 6 is awesome, so much detail.

    • Sometimes, there’s simply no way to know what wrong when making a call to something external and it doesn’t return what you are expecting. Like calling the wife from the bar and she starts screaming at you — something’s wrong for sure, but there’s really no way to know for sure what 🙂 j/k

  2. Thanks. I know this is an old post but I have found myself coming back to ConfigMgr once again after about almost a year of VMM/SCOM/Azure and other fun stuff. I was beating my head over all the return code 7’s I was getting…..

  3. Hey,
    So I am currently migrating one hierarchy to another – and reboot windows are tight at best – and only once per month.

    With that in mind, does anyone know the actual impact of the dreaded return code 7?
    i.e. the client still registers with the MP and seems to be generally available. Has anyone investigated what functions do and don’t work while it is in this “requires reboot” state ?

    • I’m sure that depends on what’s requesting the reboot. IME, the .NET framework is the main component that typically requests a reboot when upgrading it. There’s no telling what won’t work if that’s not been upgraded though.