For over a month, our team had been fighting with an Entra Connect synchronization problem that was preventing 40 workstations from properly enrolling in Microsoft Intune.
Two or three other team members had several hours each over the past few weeks troubleshooting – checking network connectivity, reviewing firewall rules, reinstalling the Entra Connect service, even working with Microsoft support. The machines would show up in Azure AD, but Intune enrollment would consistently fail with vague permission errors. Management was getting frustrated because this was blocking our Intune rollout, a project that had already been delayed for years, and now we had 40 machines in limbo unable to be managed by Intune.
My Involvement
I took a fresh look at the problem on June 16th, focusing specifically on the permission errors in the Intune enrollment logs. The error messages referenced an attribute called msds-ConsistencyGUID, which is used by Azure to maintain consistent identity mapping between on-premises Active Directory and cloud-based Azure AD.
I checked the permissions for our Entra Connect sync service account and discovered the issue: the account had been granted permissions to read Active Directory attributes, but it didn’t have write permissions for the msds-ConsistencyGUID attribute specifically. Without the ability to write this attribute, Entra Connect couldn’t properly establish the identity link needed for Intune enrollment.
Since I identified the root cause, the fix was straightforward or so I thought. But some involved in the project were concerned that it could not possibly be the problem. Their reasoning was that “there very little documentation on that specific AD Attribute in Microsoft’s official documentation.” So they asked me to look into it further.
I dove back in and found as much supporting documentation as I could and enrolled the assistance of Grok from xAI and Microsofts Copilot both in extending thinking and research mode.
I provided it the generalized problems removing any company data or names. Then I asked each of the AI assistants a very detailed prompt that somewhat matched what is shown below:
“Is the msds-ConsistencyGUID the problem that is causing us to have some machines that are not online.”
I also told it to:
“Please provide sources to back up and justify your reasoning, use official Microsoft documentation and other official Microsoft support sources such as forums as much as possible. If there no such sources available from Microsoft, use any credible community sourced data you can find regardless of the source but make sure to give me the source list for that assertation.”
After about 10-15 minutes of each AI doing research, both of the AI assistants came back with roughly the same answer and about 60% of the links matched. They both had significant data, stories, resources, and websites.
I double checked the data to make sure there were no AI hallucinations and to make sure that the sources and the claims matched and made sense and it did.
I as able to show those involved that the attribute may not have a much published as others but here are some legitimate sources that had similar problems.
Resolution
After I calmed those fears I added an explicit write permissions for the msds-ConsistencyGUID attribute to our Entra Connect sync service account. Within the next 1 to 2 days as machines came online, they successfully enrolled in Intune and started receiving policies and applications.
What made this particularly satisfying to solve this problem had stumped:
- Multiple team members
- An Intune expert from our patent company
- Microsoft support (level 1 and I think level 2)
Yet I alone found the cause and fixed it in no time.
One co-worker at the time told me,
“Steve, we were not making any progress until you showed up, no joke. But you just took charge. You dug into the logs and asked all the right questions.
So seriously thanks man.”
Relevant Info:
Entra / Intune uses the msds-ConsistencyGUID to ensure the user and the machine that are accessing an Entra cloud system are actually the same object on-prem and in the cloud. This is also used to some extent for conditional access policies.