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 ConfigMgr.Update.Manifest.cab 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!