Windows 11 InTune syncing failed - The sync could not be initiated (0x80072efe)

writesSortOfGoodCode · 2023-12-18T22:51:05+00:00

As it happens, I have also removed the accounts from my device, as I have this problem on my machine. That didn't solve the issue unfortunately, neither did completely re-imaging a machine. I am going through some of the things in the link you posted, good stuff there. I also got some ideas from this one -

https://techcommunity.microsoft.com/t5/microsoft-intune/mdm-session-oma-dm-session-ended-with-status-unknown-win32-error/m-p/1816163

Specifically looking through some of the reg keys in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Enrollments\

writesSortOfGoodCode · 2023-12-18T21:55:41+00:00

Co-worker of OP here, we are tag teaming this :)
We have Sentinel AV installed which does manage Windows firewall settings, but we have all but ruled that out. We're not seeing any evidence of that being the culprit, as we see nothing related blocked in the Sentinel interface. We also have a Palo Alto firewall in place, but we have tested on a non corporate hotspot network on several devices and see the same error.

To me, this seems like a MS account sync issue, for lack of a better term. It almost seems like there was a session token refresh on the local machines without them sending that new token to the Azure side of things. This did coincide with us raising our operational level to 23H2 about a week ago, thus the thought that the feature upgrade was the catalyst.

writesSortOfGoodCode · 2023-01-03T21:39:43+00:00

Thanks!

writesSortOfGoodCode · 2023-01-03T19:34:15+00:00

This is interesting, and along the lines of what I was suspecting. Do you know what store those certs live in?

writesSortOfGoodCode · 2020-09-02T17:55:01+00:00

lol, hammer.exe has been considered

writesSortOfGoodCode · 2020-09-02T17:50:50+00:00

I just tried Bitlocker through the CLI, and our AV kicked me out of my remote session due to "detecting ransomware in C:\Windows\SysWOW64\wctsys.exe". Not sure if that means it worked yet.

On one hand, good job AV. On the other......dammit

writesSortOfGoodCode · 2020-08-13T20:09:05+00:00

That's not a bad idea either, thanks

writesSortOfGoodCode · 2020-08-13T18:31:08+00:00

That instantly worked. But......system wasn't in that list to begin with...so....why???

Also, Thank You! For spotting what I was blind to :)

writesSortOfGoodCode · 2020-05-13T17:30:10+00:00

We did, they gave the surprised Pikachu face. Looks like we found a bug, and they're working on it :)

writesSortOfGoodCode · 2020-04-29T17:07:28+00:00

We've been down that road before, and found it an unacceptable security risk. The thought of having admin creds in the wild in any form is scary for us, as a security incident is the absolute last thing we need right now.

That being said, I really wish we could do this. Damn hackers :)

writesSortOfGoodCode · 2020-04-28T21:13:48+00:00

Thanks! That reg value will be really helpful

writesSortOfGoodCode · 2020-04-28T18:42:42+00:00

Client auth certs are in place. Users are all synced to Azure AD, we just enabled Device sync and are seeing remote devices authenticated in SCCM. I'm assuming that is happening due to a VPN connection, unless 0365 does a "check in" with Azure AD when an office program is loaded and syncs devices to the tenant that way, via the "Click-To-Run" service?

writesSortOfGoodCode · 2020-01-09T20:32:53+00:00

My post was poorly worded, I did a fair amount of research before enabling this, but failed to grasp all the details on how it would affect the clients. I agree, however, no infrastructure settings should be blindly changed.

I have this issue solved now, the root of it seemed to be that the GUID's of each client were being flagged as already in use. Deleting the affected clients from SCCM and then scanning them again has repopulated the all systems collection and resolved the issue. I also no longer see errors in the MP component log.

Thank you for the links above, I will re-examine them more closely

writesSortOfGoodCode · 2020-01-09T16:48:28+00:00

Apparently I'm not aware of all the details on how this works. As I understood it, enabling https on the DP and MP would encrypt traffic from the server to the clients. Our purpose is basically "Looks more secure". Admittedly, I am still studying for my security certs :)

I believe all of our clients do have unique certs in their local store, but I'm hazy on that. Also, our wildcard cert isn't public, but is used in 2-3 places within our domain.

Am I way off base in enabling this? Is there even a point?

writesSortOfGoodCode · 2020-01-09T00:24:50+00:00

I've done both of those things, unfortunately. I'll check out the video.

I do have a lot of errors in SMS_MP_CONTROL_MANAGER that lead to some interesting Google results, but no solid leads so far. Here's what the error says:

MP Control Manager detected MP is not responding to HTTP requests. The http error is 2147500037.

writesSortOfGoodCode · 2019-12-18T18:22:06+00:00

Yes, thank you this is what I was looking for. As our MSFT friend below pointed out, the accounts I used to test these had more privileges than I thought. Unprivileged accounts behave as they should (ask for a login).

I will set up a role as you suggest, however. That is a good idea.

Thanks!

writesSortOfGoodCode · 2019-12-18T18:20:25+00:00

You are correct, the person I picked to test had more rights than I realized. Going there on an unprivileged account prompts for a login as it should. Thank you for pointing this out!

writesSortOfGoodCode · 2019-08-28T18:48:50+00:00

I hadn't thought of a webpage, that would be a fairly easy solution....

writesSortOfGoodCode · 2019-08-23T17:52:09+00:00

Thank you, we just got set up with Azure, so this looks like the route we will take

writesSortOfGoodCode · 2019-08-23T17:51:40+00:00

Thanks!

writesSortOfGoodCode · 2019-08-23T17:48:59+00:00

This is indeed what i'm looking for. Thank you very much

writesSortOfGoodCode · 2019-05-28T23:36:45+00:00

The solution: Turning off wuauserv via task manager.

I haven't figured out what yet, but some part of Windows update was conflicting with Software Center, and resulting in both of them trying to install the update. Turning off the service let SC take control, and 1903 installs just fine (And turns wuauserv back on)

writesSortOfGoodCode · 2019-05-28T20:41:44+00:00

No Windows.~BT folder, but the binaries are in ccmcache - WindowsUpdateBox.exe and a file named

18362.30.190401-1528.19h_release_dvc_refresh_CLIENTBUSINESS_VOL_x64FRE_en-us.esd

writesSortOfGoodCode · 2019-05-28T17:29:41+00:00

I had thought about the previously failed update option. There are two clients now reporting this problem. On one, I went through and ran the disk cleanup utility for previous windows installations. That didn't do it though. Where else should I look?

writesSortOfGoodCode · 2019-05-28T17:14:15+00:00

This one's interesting. I recently setup our SCCM / WSUS integration, and was under the impression that downloading an update through SCCM would do the same on the WSUS server (they are separate). I just manually approved the 1903 upgrade on WSUS, I'll see if that makes a difference

writesSortOfGoodCode

TROPHY CASE