Sep 12 2022 06:40 AM
Hello,
We are trying to enroll devices in intune using MECM
Devices are Hybrid azure AD joined.
Devices are member of the pilot collection :
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 :
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 ?
Sep 12 2022 01:01 PM
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!
Sep 20 2022 04:46 AM
Oct 12 2022 11:17 AM
Oct 12 2022 11:39 PM
@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...
Nov 02 2022 12:55 PM - edited Nov 02 2022 12:55 PM
I am seeing very similar errors to this. Did you ever get this solved?
Nov 02 2022 11:54 PM
@dmuels7 Hello. No, not yet solved. MS case is still open.
Nov 18 2022 03:11 AM
Jan 03 2023 03:12 AM
Jan 08 2023 11:44 PM
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.
Mar 28 2023 07:39 AM
Mar 29 2023 05:09 AM
Nov 15 2023 11:08 AM
Nov 15 2023 11:12 AM
Nov 15 2023 12:53 PM
Apr 15 2024 02:26 PM
Where in the SCCM Database were you seeing if the policies were duplicated?
I would like to check to see if this is the same scenario we are facing.
Thanks,
David
Jan 08 2023 11:44 PM
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.