Co-Managed Windows 10 Device Doesn't Show Azure Domain in 'Access Work or School' Settings

Question

question

NotSoMagicMike-9180 asked Mar 2, '22 saldana-msft edited 3 days ago

Co-Managed Windows 10 Device Doesn't Show Azure Domain in 'Access Work or School' Settings

We are performing a targeted deployment (formerly controlled validation) to Hybrid Azure AD Join our Windows 10 workstations. We have a federated environment. We're using MECM (formerly SCCM), so the machines will be co-managed once they are Hybrid Joined. The first batch of machines that we successfully hybrid joined (according to 'dsregcmd /status' and a 'Hybrid Join' join type in Azure Active Directory), do not show the Azure AD domain in the 'Access Work or School' settings. However, the on-prem Active Directory domain is there. In MECM, we're using the pilot option for Cloud Attach, so we can gradually switch the workloads over from MECM/Group Policy to Intune. Present, the only workload transferred is Endpoint Security, which should include cloud policy settings directly related to Defender.

I discovered the AAD domain was missing from 'Access work or school' when I attempted to perform a policy sync. The procedure is to go into the 'Access work or school' settings and trigger a policy sync from the AAD domain connection item. Obviously I can't do that if the only connection item is the on-prem domain. Perhaps it won't appear until I switch over one of the other workloads to Intune?

windows-10-general mem-intune-general mem-cm-co-management azure-ad-hybrid-identity

5 |1600 characters needed characters left characters exceeded

Attachments: Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

Answer 1 · 2022-03-02T20:20:35.087Z

Jason-MSFT answered Mar 2, '22 NotSoMagicMike-9180 commented Mar 3, '22

What you are seeing is correct and expected. To sync the MDM policy from Intune on a HAADJ Windows endpoint, you need to select the on-prem AD domain in Access work or school, click the Info button, scroll to the bottom, and click Sync.

Because you only have the Endpoint Security workload switched over, only profiles and settings related to Endpoint security will apply.

Also note that co-management and co-management workloads have nothing to do with group policy and won't in any way arbitrate or prevent group policies from applying. You need to control this using group policy targeting constructs like OUs, security filtering, and WMI filters.

Finally, it was never "SCCM" and has always been (at least since it was SMS) and still is ConfigMgr.

· 3

5 |1600 characters needed characters left characters exceeded

Attachments: Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

NotSoMagicMike-9180 · Mar 03 at 09:29 PM

Hah! Thanks for the reminder there, @Jason-MSFT! "ConfigMgr" indeed! Glad to know this is correct and expected. I'm clear on your point that co-management workloads have nothing to do with group policy, and your recommendation for using targeting constructs makes sense. However, in the event there is a conflict between Group Policy and CSP, I've read we can use MDMWinsOverGP. Have you seen that in practice and can you confirm it's effective?

0 ·

Jason-MSFT NotSoMagicMike-9180 · Mar 03 at 10:04 PM

I strongly recommend avoiding this setting as it is not a ubiquitous setting -- by design it is only meant to dictate behavior of settings within the Policy CSP and not other CSPs and even within the Policy CSP, there are at least a couple of exceptions to this to my knowledge. Policy deployment and enforcement from multiple different sources should be deterministic and not left to a priority scheme.

0 ·

NotSoMagicMike-9180 Jason-MSFT · Mar 03 at 10:23 PM

Very well sir. Thank you for that, and thank you for your contributions throughout the Interwebs over the years. =<8^)

When reading forums, I always hope to see your comments as I know they come from a knowledgeable source.

0 ·

question