This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(300.8, 48%, 39%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EN%3C/text%3E%3C/svg%3E)
MEMCM 2103
I have set up Desktop Analytics which is partially working. Clients are sending telemetry to the DA workspace, however MEMCM is still showing the 300 or so devices as Awaiting Enrollment in the Connection Health node. The M365AUploadWorker log shows GET and POST successes but the final log entry (i.e. the failure point) reports BAD REQUEST 400. It appears that the MEMCM sync is not working but everything else is. I have confirmed I have the correct permissions, accounts etc set up on App Registration and DA Workspace
Happy to fill in another blanks. This isn't my first set up for DA, and I've not encountered this issue before. It's always been pretty seamless. it just seems like the final sync isn't working.
Type the URL that is giving you the bad request into a web browser on the Site Server and check if the site is trusted. You may be missing a public root cert on your server.
Hi - thanks for the suggestion. That's something I tried first and I get a download prompt for AccountOnboardingInfo. Any other suggestions gratefully received.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(284.8, 81%, 37%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EJ%3C/text%3E%3C/svg%3E)
Have you had any luck with this? I'm seeing the same behavior in my environment. Rebuilding our desktop analytics hasn't fixed it either. Kinda stumped.
Are you going through a proxy? If so, check that there is no SSL interception going on.
https://learn.microsoft.com/en-us/mem/configmgr/desktop-analytics/enable-data-sharing
For privacy and data integrity, Windows checks for a Microsoft SSL certificate (certificate pinning) when communicating with the diagnostic data endpoints. SSL interception and inspection aren't possible. To use Desktop Analytics, exclude these endpoints from SSL inspection.
I will add that the URL list includes https://login.live.com, and the documentation doesn't call it out but some orgs need to use SSL interception on this URL in order to block Microsoft consumer apps as per https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/tenant-restrictions.
Additionally, the tenant restrictions feature now supports blocking the use of all Microsoft consumer applications (MSA apps) such as OneDrive, Hotmail, and Xbox.com. This uses a separate header to the login.live.com endpoint, and is detailed at the end of the document.
I have implemented Desktop Analytics and kept SSL interception on this particular URL and it still works for me.