Whew – not only has it been quite a while since I wrote something, but this issue even took a Microsoft Premier Support case to solve. If you’re following me on Twitter or reddit you might’ve seen this post already. So if you want to read up how this all started, I suggest you begin there. I will link this blog post as the last answer to the thread there as well. Still, lets recap for a moment:
- A Cloud Management Gateway with E-HTTP didn’t work for AAD joined devices
- However, Co-Management worked for known on-premises hybrid-joined devices
- At first glance errors erroneously pointed to an Intune issue and unconfigured MDM
Error analysis
We checked all settings once more and arrived at the conclusion that the setup on-premises. At first I assumed it was related to our common enemies: DNS or Firewall. Make sure these are properly done, so that the CMG is reachable internally on all required ports. We gathered logs multiple times, to do this we prepared both the single-machine Primary Site (PS/MP/DP/CMG Connector) and our test client to gather more verbose logs for us.
#To enable Verbose Logging, add or change the following dwords
#More Info here https://docs.microsoft.com/en-us/troubleshoot/mem/configmgr/advanced-troubleshooting-tips
#On both Client and Management Point:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\CCM\Logging\@Global
LogLevel = 0
LogMaxHistory = 1
LogMaxSize = 250000 (or higher, this would equal 250kb)
#Restart SMS Agent Host
#On CMG Connection point
HKLM\SOFTWARE\MICROSOFT\SMS\SMS_CLOUD_PROXYCONNECTOR
DumpAllTraffic = 1
VerboseLogging = 1
HKLM\SOFTWARE\MICROSOFT\SMS\COMPONENTS\SMS_CLOUD_SERVICES_MANAGER
VerboseLogging = 1
#Restart the SMS_EXECUTIVE service
ADALOperationProvider.log
First the CCM will try to use the device token, this is especially important when no user is logged in yet. Get the device ID using “dsregcmd /status” to verify against your AAD information.
However, we had an error in some of the logs, that we couldn’t really pinpoint Failed to get AAD token. Error 0x87d00215additionally Failed to get CCM access token and client doesn't have PKI issued cert to use SSL. Error 0x87d00215. which of course led to a CCM_E_NO_TOKEN_AUTH error. We ended up reinstalling that machine. We also cleared it from the autopilot devices as well – no issues after so this was a dead end.
ClientIDManagerStartup.log
If you found this article by using a search engine, you’ve most likely looked at this log already and found the ominous RegTask: Failed to refresh site code. Error: 0x8000ffff. At first glance this seemed to be related to an authentication issue. Messages didn’t reach the Management Point, however, the CMG was contacted successfully (see CcmMessaging.log) with the token. The messages never arrived at the MP, so we started looking into that issue further.
ClientLocation.log
Interesting – for some reason we receive an ERROR_WINHTTP_NAME_NOT_RESOLVED error. This however is unrelated to our issue completely. Somehow the CCM Agent already knew about the internal MP, but obviously can’t resolve the name since the machine is outside of company premises.
LocationServices.log
This “Failed to send site information Location Request Message to <CMG-Address>/CCM_Proxy_MutualAuth” could have been a hint to the issue, however another provided the clue in the end.
CcmMessaging.log
Each CCM message is sent to the CMG as the relay for the MP. The CMG authenticates the device or user by AAD Token and then relays message to the CMG connector. Every registration try from the ClientIDManagerStartup.log is successfully transmitted (StatusCode=0)
Other logs and settings that where verified:
- Client Settings need to have Cloud Services enabled: “Enable clients to use a cloud management gateway” was enabled in the default settings
- Client approval should be set to “Automatically approve computers in trusted domains (recommended)”
- IIS on the MP that is used for CMG traffic should have anonymous authentication enabled – which it was.
The solution – CertificateMaintenance.log
Thankfully the engineer spotted this. So, the internal Management Point didn’t accept the connection type. Interesting, as anonymous connections were allowed on the IIS.
At this point it seemed we wouldn’t get any further. With messages arriving at the CMG, being authenticated successfully, but not visible on the MP, the air was getting thinner. The solution dawned on me, when the engineer asked for these two SQL queries:select * from vSysResList where InternetEnabled = 1
select * from vSysResList where RoleName = N'SMS Management Point'
Which returned the following result:
Why does the result only show the CMG is “InternetEnabled”? Let’s check again in the console – we need to look for “Allow Configuration Manager cloud management gateway traffic”. However…
Ok, so lets disable, wait five minutes and enable that option again. Run the SQL query again and…
TL;DR
If you didn’t want to read the explanation, visit the configuration of your Management Point that has the “Allow Configuration Manager cloud management gateway traffic” setting. Disable that, wait a few minutes and enable the setting again. Unfortunately this is not a known issue or “bug”, so don’t expect a fix from Microsoft. But at least this might help you avoid huge support costs and an even bigger headache.
By the way, this took nearly three months to solve and we were already preparing to move to using certificates. I hope I could help someone out there!