SCCM (current branch) offline upgrade adventures (1511 to 1606)

*UPDATE 1/30/2018*
The “dummy” site idea listed at the bottom of this post doesn’t actually work. It turns out that each ConfigMgr installation has a unique ID, so telemetry generated from one cannot be used to import updates to another. This was personally verified and confirmed via a Microsoft Support case. So, for those of us that are air-gapped, in-console upgrades are not an option. But, it looks like M$ is now releasing standalone updates at a frequency that one can upgrade before support for the prior version ends.

Those who have read my blog for some time now, know that our system is a high security, air-gapped network. This can sometimes make administration of the system…. interesting, to say the least. Most frustrating is when applications take Internet connectivity for granted (which unfortunately, is becoming more and more common).

Our latest adventure is working on upgrading System Center Configuration Manager from 2007 R2 (!) to SCCM (current branch). We are in the middle of an install into our test system, where we perform all tasks as if the network has no external connectivity, just like the real thing. Now I have a total love/hate relationship with SCCM… in that I love it when it works, but it’s a total POS when it doesn’t. And right now… I HATE YOU MICROSOFT.

Now, prior to the release of version 1606 as a standalone installer in October 2016, the only way to install SCCM 1606 was to first install 1511 and perform the upgrade within the SCCM console.

We configured the Service Connection Point to operate in offline mode, in order to simulate the real-world environment. Next, one has to wait SEVEN DAYS before any telemetry* is made available. Once you have waited the requisite time, one must then use the Service Connection Tool to export the telemetry and import the updates. Now, this is where the fun really starts….

Fail one: the online documentation for the Service Connection Tool is only for version 1606; there doesn’t appear to be any way to view historical documentation. This is a problem because one of there features described doesn’t even exist in the 1511 version of the tool: the ability to set a proxy connection. WHAT?!? We get stuck trying to connect, only to find out that the only way to get the data was to send one of the engineers home to pull it from their personal network…. after an hour spent wondering why the command wouldn’t take… So now I’m asking if there is actually a company out there, that uses SCCM, and DOESN’T have a proxy? Ya, I couldn’t think of one either. Supposedly, this was fixed in 1606… we’ll see….

Fail two: once we actually had the data, the Service Connection Tool is used to upload the data to the site server, which it did without complaint. The only problem is, the updates never appeared in the Updates and Servicing tab of the console. This was much harder to resolve. Looking in the dmpdownloader.log file, we noticed this:


Hmmm…. interesting. Drilling into the directory, both the file and the other CABs where there, just ONE LEVEL DEEPER than where SCCM expected them to be. C’MON GUYS… did you actually test your tools before releasing them? Anyway, moving the CABs up one level to where SCCM expected them to be fixed the issue.

Hopefully, this will help one of the other 0.5% of SCCM users out there who aren’t actually connected to the Internet (and Microsoft doesn’t give a crap about)…. you’re welcome.

* Fail three: we’re also not allowed to pull data down from the air-gapped system and move it to the Internet… ever. This presented a real problem with SCCM, since it now requires telemetry to be sent back in order to receive updates. Microsoft has been less than helpful with this issue, assuring us that the data (some of which is processed via a one-way hash) contains no sensitive information… which I find highly amusing, since there is no way to independently verify the hashed data. We’re supposed to just trust them…. riiiight….. We worked around this by creating a “dummy” site, which is configured in a similar fashion to provide fake telemetry data, which is then used as a surrogate for the real site. Time will tell if this is genius or blows up in our face!



  1. Eric
    Posted July 31, 2017 at 3:15 pm | Permalink | Reply

    Can you expand on what characteristics of the “dummy” site need to match the production site? I have the air gap problem myself.

    • Posted January 30, 2018 at 5:50 pm | Permalink | Reply

      It turns out that this process will not work. Each installation is “tattooed” with a unique ID (i.e., telemetry from one server cannot be used to provide updates to another).

  2. C
    Posted November 17, 2017 at 1:31 am | Permalink | Reply

    Did you ever have issues with SCCM for using fake telemetry data? Did SCCM let you install the offline package you received from the service connection tool?

    • Posted January 30, 2018 at 5:51 pm | Permalink | Reply

      So, unfortunately this idea doesn’t work. ConfigMgr installations have unique IDs which make it impossible for one installation to send telemetry as a surrogate for another.

  3. Rich
    Posted February 7, 2018 at 4:16 pm | Permalink | Reply

    Same issue here – air-gapped, secure network from which we CANNOT upload telemetry data. SCCM was installed from the 1511 baseline media and (unless I’m mistaken) we’re now stuck with 1511 because we can’t do in-console updates and we can’t upgrade it using the later baseline media for 1606 or 1702……..

    • Posted February 12, 2018 at 5:14 pm | Permalink | Reply

      That’s interesting… I was told by M$ support that we could upgrade via baseline media (though I haven’t tested this to see if what they said was true). I’m gonna have to take a look at this. Thanks for the heads-up! Please let me know if you are able to successfully perform the upgrade via baseline media.

  4. bestknownmethod
    Posted March 9, 2018 at 11:41 pm | Permalink | Reply

    You can. You need to open a support case to get your telemetry data generated for your air gapped environment. Work with your TAM or reach out to Microsoft Support. When you get your offline file generated, you can use the service connection tool in offline mode to download the UpdatePacks. Then you will need to transfer the data to the air gapped environment, and use your SCT to import into your environment. From there it will show up as an In Console update. Warning, it’s going to be probably 30-35GB’s of data you have to transfer :(. No way around that, but starting with 1706 it does get easier.

    IMPORTANT: You have to use the same version of the SCT as the environment you are updating. SCT is updated each version of SCCM which is located in the cd.latest folder.

    Hope this helps.

    • Posted March 10, 2018 at 1:43 am | Permalink | Reply

      Wow, thanks. Way more help than we received from our last M$ support case :/ Now that we know what to ask for….

      • bestknownmethod
        Posted March 10, 2018 at 3:53 am | Permalink

        No problem. Just ask them what you need to provide and they will give you the instructions.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: