SOLVED

MECM co-management enrollment not working

Brass Contributor

Hello,

 

We are trying to enroll devices in intune using MECM

Devices are Hybrid azure AD joined.

Devices are member of the pilot collection :

 

Le_Michel_0-1662986794025.png

 

CoManagementHandler.log shows the following records :

 

Auto enrollment agent is initialized. CoManagementHandler 12/09/2022 13:59:57 1712 (0x06B0)
Could not check enrollment url, 0x00000001: CoManagementHandler 12/09/2022 13:59:57 1712 (0x06B0)
Device is not enrolled. CoManagementHandler 12/09/2022 13:59:57 1712 (0x06B0)
AAD-Join Info: type = 1
DeviceId = 'DeviceID'
TenantId = 'TenantID'
JoinUserEmail = 'fooUser@company.com'
TenantName = 'Name'
EnrollmentUrl = 'https://enrollment.manage.microsoft.com/enrollmentserver/discovery.svc'
CoManagementHandler 12/09/2022 13:59:57 1712 (0x06B0)
Set device to not externally managed CoManagementHandler 12/09/2022 13:59:57 1712 (0x06B0)
Could not check enrollment url, 0x00000001: CoManagementHandler 12/09/2022 13:59:57 1712 (0x06B0)
Device is not MDM enrolled yet. All workloads are managed by SCCM. CoManagementHandler 12/09/2022 13:59:57 1712 (0x06B0)
Value of CoManagementFlags retrieved: 0x2001 CoManagementHandler 12/09/2022 13:59:57 1712 (0x06B0)
Checking MDM_ConfigSetting to get Intune Account ID CoManagementHandler 12/09/2022 13:59:57 1712 (0x06B0)
Expected MDM_ConfigSetting instance is missing, can't retrieve Intune SA Account ID. CoManagementHandler 12/09/2022 13:59:57 1712 (0x06B0)
Co-Management is disabled. Expect MDM_ConfigSetting instance to be deleted. CoManagementHandler 12/09/2022 13:59:57 1712 (0x06B0)
Current workload settings is not compliant. Setting enabled = 0, workload = 8193. CoManagementHandler 12/09/2022 13:59:57 1712 (0x06B0)
Checking MDM_ConfigSetting to get Intune Account ID CoManagementHandler 12/09/2022 13:59:57 1712 (0x06B0)
Expected MDM_ConfigSetting instance is missing, can't retrieve Intune SA Account ID. CoManagementHandler 12/09/2022 13:59:57 1712 (0x06B0)
Updating comanagement registry key to 0x2001 CoManagementHandler 12/09/2022 13:59:57 1712 (0x06B0)
CoManagement flags registry key updated. CoManagementHandler 12/09/2022 13:59:57 1712 (0x06B0)
Nothing is changed for RS2, keep executing. CoManagementHandler 12/09/2022 13:59:57 1712 (0x06B0)
Setting co-management RS3 flags CoManagementHandler 12/09/2022 13:59:57 1712 (0x06B0)
Nothing is changed for RS3, ENDOK. CoManagementHandler 12/09/2022 13:59:57 1712 (0x06B0)
Could not check enrollment url, 0x00000001: CoManagementHandler 12/09/2022 13:59:57 1712 (0x06B0)
Device is not MDM enrolled yet. All workloads are managed by SCCM. CoManagementHandler 12/09/2022 13:59:57 1712 (0x06B0)
Value of CoManagementFlags retrieved: 0x2001 CoManagementHandler 12/09/2022 13:59:57 1712 (0x06B0)
Could not check enrollment url, 0x00000001: CoManagementHandler 12/09/2022 13:59:57 1712 (0x06B0)
Device is not provisioned CoManagementHandler 12/09/2022 13:59:57 1712 (0x06B0)
Default CSP is Microsoft Enhanced RSA and AES Cryptographic Provider CoManagementHandler 12/09/2022 13:59:57 1712 (0x06B0)
Default CSP Type is 24 CoManagementHandler 12/09/2022 13:59:57 1712 (0x06B0)
Calculating hash with 32772 algorithm using 'Microsoft Enhanced RSA and AES Cryptographic Provider' CSP. CoManagementHandler 12/09/2022 13:59:57 1712 (0x06B0)
State ID and report detail hash are not changed. No need to resend. CoManagementHandler 12/09/2022 13:59:57 1712 (0x06B0)
User 'S-1-5-21-SID' is logged on. CoManagementHandler 12/09/2022 14:00:03 9244 (0x241C)
Check if it's enrollment pending and if it's already enrolled.... CoManagementHandler 12/09/2022 14:00:03 9244 (0x241C)
UserLogon: enrollment isn't pending. CoManagementHandler 12/09/2022 14:00:03 9244 (0x241C)
Released global agent cache. CoManagementHandler 12/09/2022 14:00:03 9244 (0x241C)

 

There is no scheduled tasks under "EnterpriseMgmt"

 

Baselines are evaluated like this :

 

Le_Michel_1-1662987430646.png

 

Eventlog shows : 

MDM ConfigurationManager: Command failure status. Configuraton Source ID: (SourceID), Enrollment Type: (WMIBridge), CSP Name: (EnrollmentStatusTracking), Command Type: (Clear: first phase of Delete), Result: (./Device/Vendor/MSFT/EnrollmentStatusTracking/DevicePreparation/PolicyProviders/ConfigMgr/LastError).

 

MDM ConfigurationManager: Command failure status. Configuraton Source ID: (SourceID), Enrollment Type: (WMIBridge), CSP Name: (Policy), Command Type: (Clear: first phase of Delete), Result: (./Device/Vendor/MSFT/Policy/Config/Security/AllowAddProvisioningPackage).

 

Can someone help ?

 

14 Replies

@Le_Michel 

 

Intune Enrollment using Group Policy | Automatic Enrollment AVD VMs 

See this article. Check the MDM User Scope and enable the policy "Enable Automatic MDM enrollment using Default azure AD credentials."

 

Troubleshooting Windows device enrollment errors in Intune 

Otherwise see that article for other possible error conditions reported in the log.

 

HOW TO ENABLE CO-MANAGEMENT IN SCCM 1902 

And per this other article, make sure you've followed all needed co-management setup steps.

 

Please like or mark this thread as answered if it's helpful, thanks!

Hello,

We have opened a support case with Microsoft. I'll let you know the findings.
Our intent is to rely on MECM to start the onboarding process.
Hi Le_Michel... any news about this issue, we have the same with any devices (another register and enrolled right)...

<![LOG[Initializing co-management agent...]LOG]!><time="11:19:29.514+300" date="10-12-2022" component="CoManagementHandler" context="" type="1" thread="1644" file="comgmtagent.cpp:194">
<![LOG[Loaded EnrollPending=0, UseRandomization=0, LogonRetriesCount=0, ScheduledTime=0, ErrorCode=0x0, ExpectedWorkloadFlags=12543, LastState=100, EnrollmentRequestType=0]LOG]!><time="11:19:30.233+300" date="10-12-2022" component="CoManagementHandler" context="" type="1" thread="1644" file="comgmtagent.cpp:224">
<![LOG[Auto enrollment agent is initialized.]LOG]!><time="11:19:30.233+300" date="10-12-2022" component="CoManagementHandler" context="" type="1" thread="1644" file="comgmtagent.cpp:280">
<![LOG[Device is enrolled.]LOG]!><time="11:19:30.233+300" date="10-12-2022" component="CoManagementHandler" context="" type="1" thread="1644" file="comgmtagent.cpp:491">
<![LOG[Updating comanagement registry key to 0x30ff]LOG]!><time="11:19:30.498+300" date="10-12-2022" component="CoManagementHandler" context="" type="1" thread="1644" file="ccmcomgmt.cpp:428">
<![LOG[CoManagement flags registry key updated.]LOG]!><time="11:19:30.498+300" date="10-12-2022" component="CoManagementHandler" context="" type="1" thread="1644" file="ccmcomgmt.cpp:433">
<![LOG[Setting co-management RS3 flags]LOG]!><time="11:19:30.498+300" date="10-12-2022" component="CoManagementHandler" context="" type="1" thread="1644" file="ccmcomgmt.cpp:476">
<![LOG[Device is not provisioned]LOG]!><time="11:19:30.530+300" date="10-12-2022" component="CoManagementHandler" context="" type="1" thread="1644" file="mdmreglib.cpp:708">
<![LOG[State ID and report detail hash are not changed. No need to resend.]LOG]!><time="11:19:30.530+300" date="10-12-2022" component="CoManagementHandler" context="" type="1" thread="1644" file="comgmtagent.cpp:1810">

@Sorcia25910 . Hi. No solution till now. Nothing relevant found on the MECM side and waiting for a month for a support engineer from the intune team...

I am seeing very similar errors to this. Did you ever get this solved?

@dmuels7 Hello. No, not yet solved. MS case is still open.

Finally had a meeting with an escalation engineer that found the issue. it seems that all co-management policies are duplicated in the SCCM database. And the client receives the corrupted policies.
The cause is that the first time we tried to activate the cloud attach, the operation did not complete due to lack of permissions on azure. Some uncomplete policies were left in the database.
Next week, we will work with the escalation engineer again to remove the cloud attach, delete policies from the DB and recreate the cloud attach.
Hi,
are you problem resolved? what needed to be done? I've the same problem as you seems to have.

Kind regards
best response confirmed by Le_Michel (Brass Contributor)
Solution

@yannick_sierro Yes, it's solved.

 

All co-management policies were duplicated in the SCCM database. And the client received the corrupted policies.
The cause is that the first time we tried to activate the cloud attach, the operation did not complete due to lack of permissions on azure. Some uncomplete policies were left in the database.
We removed the cloud attach, deleted policies from the DB with help of the escalation engineer and recreated the cloud attach.

Hi,
I am having the same problem.

Can you explain how did you delete the policies from the DB?
Thanks
I recommend opening a MS case to solve this. I would not make changes in the configmgr database without guidance from MS.
Hello @Le Michel can you please help me regarding the below problem please

1. We want to run our infra on Co-Manage (Intune and SCCM) Hybrid model.
2. Currently Microsoft Entra Joined and Microsoft Entra Registered Workgroup devices successfully enrolled in Intune and we can manage the device compliance, Windows updates and remote deployment of Managed Apps successfully.
3. Challenge with On-Prem Active Directory registered devices not enrolled in Intune, but those devices showing in Intune dashboard managed by Config Mgr (SCCM) instead of Co-managed.
4. In ConfigMgr systems --> control panel --> Configuration Manager Properties --> Co-Management option shows Disabled. Below images are for your reference.
we would like to see in client devices which is Co-Management is enabled

please help me on this.

if you want i will send co-management handler logs in CCM setup also i will send to you
I am encountered with the same error... have you overcome this error can you please let me know please
1 best response

Accepted Solutions
best response confirmed by Le_Michel (Brass Contributor)
Solution

@yannick_sierro Yes, it's solved.

 

All co-management policies were duplicated in the SCCM database. And the client received the corrupted policies.
The cause is that the first time we tried to activate the cloud attach, the operation did not complete due to lack of permissions on azure. Some uncomplete policies were left in the database.
We removed the cloud attach, deleted policies from the DB with help of the escalation engineer and recreated the cloud attach.

View solution in original post