After enabling co-management users get prompt

Occasional Contributor

Hi,

 I Enabled co-management, computers registers in AAD, enrolls in Intune, it seems that everything works - intune status - co-managed. But users get prompt that there is a problem with work or school account and they have to login.

jaky_0-1665772152263.png

Until user logins there is also an mdm sync error under info button in work or school account. Then user logins sync error disappears.

 

Why there is such prompt? I thought that sccm would enroll devices with device credentials and that would be enough? MS documentation states that co-management supports: "Ability to enroll devices without user interaction".

 

2fa isn’t used.


What I am missing here?

10 Replies
You would expect that message indeed to occur if you are requiring mfa... but as you are mentioning you are not using it... could you check out the Applications and Services Logs > Microsoft > Windows > AAD > Operational log to determine which error it is giving you
Thank you for taking interest.
I wasn't able to find a solution by these logs.

event ID 1097 warning : Error: 0x4AA50081 An application specific account is loading in cloud joined session. Logged at ClientCache.cpp, line: 376, method: ClientCache::LoadPrimaryAccount.

event id 1098 error : Error: 0xCAA9001A No endpoint information in discovery response.
Exception of type 'class Exception' at UserRealm.cpp, line: 292, method: UserRealm::ParseResponse.
Log: 0xcaa1007d Failed to acquire token by integrated Windows authentication.
Logged at AggregatedTokenRequest.cpp, line: 182, method: AggregatedTokenRequest::UseWindowsIntegratedAuth.

event id 1098 error: Error: 0xCAA9001A No endpoint information in discovery response.
Exception of type 'class Exception' at UserRealm.cpp, line: 292, method: UserRealm::ParseResponse.
Log: 0xcaa10082 Failed to acquire new token.
Logged at AuthorizationClient.cpp, line: 304, method: ADALRT::AuthorizationClient::AcquireNewToken.

event id 1097 warning: Error: 0x8AA5007C A suspending event for the AAD plugin was received.
Logged at WebUIControllerWebView.cpp, line: 682, method: WebUIControllerWebView::WebViewSuspensionEvents::OnSuspending.
Just wondering but at the point in time when the devices get that policy , how does the dsregcmd /status /verbose looks like
Output of C:\WINDOWS\system32>dsregcmd /status /verbose command. Some info was replaced with word hidden.

+----------------------------------------------------------------------+
| Device State |
+----------------------------------------------------------------------+

AzureAdJoined : YES
EnterpriseJoined : NO
DomainJoined : YES
DomainName : hidden
Device Name : hidden

+----------------------------------------------------------------------+
| Device Details |
+----------------------------------------------------------------------+

DeviceId : hidden
Thumbprint : hidden
DeviceCertificateValidity : [ 2022-08-22 07:20:55.000 UTC -- 2032-08-22 07:50:55.000 UTC ]
KeyContainerId : hidden
KeyProvider : Microsoft Platform Crypto Provider
TpmProtected : YES
DeviceAuthStatus : SUCCESS

+----------------------------------------------------------------------+
| Tenant Details |
+----------------------------------------------------------------------+

TenantName :
TenantId : hidden
Idp : login.windows.net
AuthCodeUrl : https://login.microsoftonline.com/hidden/oauth2/authorize
AccessTokenUrl : https://login.microsoftonline.com/hidden/oauth2/token
MdmUrl : https://enrollment.manage.microsoft.com/EnrollmentServer/Discovery.svc
MdmTouUrl :
MdmComplianceUrl :
SettingsUrl :
JoinSrvVersion : 2.0
JoinSrvUrl : https://enterpriseregistration.windows.net/EnrollmentServer/device/
JoinSrvId : urn:ms-drs:enterpriseregistration.windows.net
KeySrvVersion : 1.0
KeySrvUrl : https://enterpriseregistration.windows.net/EnrollmentServer/key/
KeySrvId : urn:ms-drs:enterpriseregistration.windows.net
WebAuthNSrvVersion : 1.0
WebAuthNSrvUrl : https://enterpriseregistration.windows.net/webauthn/hidden/
WebAuthNSrvId : urn:ms-drs:enterpriseregistration.windows.net
DeviceManagementSrvVer : 1.0
DeviceManagementSrvUrl : https://enterpriseregistration.windows.net/manage/hidden/
DeviceManagementSrvId : urn:ms-drs:enterpriseregistration.windows.net

+----------------------------------------------------------------------+
| User State |
+----------------------------------------------------------------------+

NgcSet : NO
WorkplaceJoined : NO
WamDefaultSet : ERROR

+----------------------------------------------------------------------+
| SSO State |
+----------------------------------------------------------------------+

AzureAdPrt : NO
AzureAdPrtAuthority :
EnterprisePrt : NO
EnterprisePrtAuthority :

+----------------------------------------------------------------------+
| Diagnostic Data |
+----------------------------------------------------------------------+

AadRecoveryEnabled : NO
Executing Account Name : hidden\hidden, hidden@hidden
KeySignTest : PASSED

+----------------------------------------------------------------------+
| IE Proxy Config for Current User |
+----------------------------------------------------------------------+

Auto Detect Settings : YES
Auto-Configuration URL :
Proxy Server List :
Proxy Bypass List :

+----------------------------------------------------------------------+
| WinHttp Default Proxy Config |
+----------------------------------------------------------------------+

Access Type : DIRECT

+----------------------------------------------------------------------+
| Ngc Prerequisite Check |
+----------------------------------------------------------------------+

IsDeviceJoined : YES
IsUserAzureAD : NO
PolicyEnabled : NO
PostLogonEnabled : YES
DeviceEligible : NO
SessionIsNotRemote : NO
CertEnrollment : none
PreReqResult : WillNotProvision
MdmTouUrl :
MdmComplianceUrl :

Are those url configured in the mdm scope configuration in Intune?.. are those filled in on working/enrolled devices
When user logins and policy is applied in dsregcmd output one line is changed
+----------------------------------------------------------------------+
| Ngc Prerequisite Check |
+----------------------------------------------------------------------+
DeviceEligible : YES

Also looking at the error you posted earlier:

MDM enrollment error 0xcaa9001f for co-managed Windows devices - Intune | Microsoft Learn

It almost looks like the one above

I think this error doesn't apply here, because all requirements are met. The Cloud Management Azure service is configured in Configuration Manager. Both AD User Discovery and Azure AD User Discovery methods are enabled.

These two MdmTouUrl : and MdmComplianceUrl : are configured, but they are not filled on working/enrolled devices.

Maybe this is the problem: currently we use intune for testing only, because of this MDM user scope is set to Some with specified one group. Co-managed pc are not in this group.
"When Configuration Manager is set to enroll devices to Intune, you don't need to change the MDM user scope for device token enrollment. Configuration Manager uses the MDM URLs that it stores in the site database."

https://learn.microsoft.com/en-us/mem/configmgr/comanage/tutorial-co-manage-clients

@Rudy_Ooms_MVP 

 

I know this tutorial, but I don't know how to interpret it for my situation. Our mdm page looks like this

 

jaky_0-1666012163277.png