We considered the work from home being an issue since a lot of people are working via VPN. But they have had issues with devices that aren't work from home, as well as those VPN connected.
I appreciate the answer on how to remove them from co-management. One question just to be clear, when you say unenroll device from Intune, you're talking about from the Intune Console (or PowerShell) or are you talking something else?
No they don't have a CMG. I lost the battle for that one, and they pushed it out to the future. But that's an excellent point I hadn't considered. It very well may explain a bunch of things. They have been relying on that most of their remote people are connecting daily by VPN. But that loss of connection could cause some confusion.
Thank you for that though.
Additional info
In the DeviceManagement-Enterprise-Diagnostics-Provider event log. Two entries show up:
Warning 209 - MDM Session: Failed to get AAD Token for snync session User Token" (Unkown Win32 Error code: 0xcaa9014) Device Token: (Incorrect function.).
Error 201 - MDM Session: OMA-DM message failed to be sent Result: (Unknown Win32 Error code" 0x80072f8f).
DSREGCMD /status returns
- AzureAdJoined: Yes
- DomainJoined: Yes
- AzureAdPRT: NO
Looking in Azure AD at the device it does not show a user registered to the device. The logged on user is in Azure AD and the account is synced with AD.
We have devices in AAD but the PRT isn't set. The ones I've looked at show up as not having a signed in user in AAD. As I dug into one of the devices there was a warning about the TPM needing a firmware update. That might be part of the problem as well. TPM is enabled but it appears Windows 10 isn't using it. If the firmware update would fix it that might solve the problem, but that could be a fair amount of work just figuring out what needs updated.
We did the steps and it worked successfully.
I think we may have identified the problem though. The machine was last logged on using a technicians account that isn't in AAD. When we did the command steps we had him elevate his normal user account to local admin and then run the commands. One note we had to enable the task in the task scheduler, otherwise the DSREGCMD /Join did not work.
Thank you for your help.
I considered doing that but couldn't get anyone to try it. We'll give it a shot. Hopefully we'll only have a few, if we end up with hundreds doing this this solution isn't practical since someone would have to touch each computer.
Quick question, is there a way we can cancel the co-management enrollment? I've been looking for the scripts that are being run but haven't found them yet. There are a few things I've found about creating the Co-management policies, but there only appears to be a PowerShell New command, nothing to list, remove, etc. I also looked in WMI but didn't see anything. The documentation for Co-management is really lacking unfortunately.
For some reason this crappy forum interface didn't post this response, so typing it in again.
AzureAdJoined : YES
EnterpriseJoined : NO
DomainJoined : YES
DomainName : NNG
AzureAdPrt : NO
I'm not sure why PRT is NO, the only thing I've come up with is the computer isn't used often and when the Co-Management occurred it didn't have a logged on user, and may not have in several months. The customer has some of these computers in place to handle specific emergency conditions, they are only used at those times.
The rest of the log file
This device is enrolled to an unexpected vendor, it will be set in co-existence mode. CoManagementHandler
This device is enrolled to an unexpected vendor, it will be set in co-existence mode. CoManagementHandler
Device is not provisioned CoManagementHandler
State ID and report detail hash are not changed. No need to resend. CoManagementHandler
Here is the CoManagementHandler.log info. As I said, it looks like its waiting for co-management to finish since the vendor isn't set.
This device is enrolled to an unexpected vendor, it will be set in co-existence mode. CoManagementHandler
Workload settings is different with CCM registry. Current value is 4294967295, expected value is 1 CoManagementHandler
Workloads rules are not compliant. CoManagementHandler
Setting workload info: Allowed = 1, Flags = 1 CoManagementHandler
Updating comanagement registry key to 0x1 CoManagementHandler
CoManagement flags registry key updated. CoManagementHandler
Setting co-management RS3 flags CoManagementHandler
This device is enrolled to an unexpected vendor, it will be set in co-existence mode. CoManagementHandler
Machine is already enrolled with MDM CoManagementHandler
Incompatible enrollment type CoManagementHandler
I should have mentioned that, it is AD and Hybrid AAD joined, and the SCCM agent communicates. Its been Hybrid AAD for about two months.
I'll get the CoManagementHandler.log when the customer is responsive. But I expect what its going to show is that its waiting for co-management to complete.
Also, we verified the computer is able to access all of the enrollment URLs.
Moving off of SCCM to Intune was never the intention. The customer is likely years away from that kind of move for a lot of reasons, Intune simply isn't ready to do the things they need to do. Part of that is the maturity level of the customer.
I don't have any information on your scenario. While Co-management sounds like a nice idea, I'm getting to the point where I think its not quite ready for prime time yet. Oddly more because of issues with Hybrid AD.