Alexandros

1806 and still persists? I didn’t test myself as I am also on 1806. We need to somehow report this to the devs. Anyone here has any contacts ? Alex

I am glad to report that this is resolved on 1806 of SCCM. There was no action needed on my side. Alex

I am glad to report that this is resolved on 1806 of SCCM. There was no action needed on my side. Alex

I have worked with MS Intune support and this has now been verified as an SCCM bug. The case has been assigned to the SCCM team.

Thanks a lot Oktay for looking into this! I have sent the forum thread to Microsoft Intune support as they have a dedicated topic for Comanagement. Let's hope they help me out here. I am also seeing a weird issue when I do gpupdate: "Windows failed to apply the MDM policy settings" Have you noticed any similar issue? Thanks a lot. Alex

I am facing a very weird issue with SCCM CoManagement where Windows 10 machines registered to AzureAD in Hybrid Azure AD Join, are shown as Azure AD Joined. I will be focusing on one machine so we see the issue in depth. Configuration details SCCM Current Branch 1802 with all three hotfixes installed Windows 10 Enterprise 1803 with latest updates Co-Management Enabled for All Devices (no pilot group) No workloads have yet been migrated to Intune Group Policies for Automatic Enrollment to MDM and Automatic Registration with AzureAD enabled SCCM Client Cloud option for Automatic Registration enabled Intune set as Standalone Intune Enrollment set as MDM only (MAM disabled) ADFS Federated Domain 3.0 (2012R2) with AAD Connect Federation Facts SSO et. all are working as expected on the client Client detects client as Hybrid Azure AD Joined Intune detects client as Hybrid Azure AD Joined Issue SCCM detects client as Azure AD Joined I will now provide all relevant screenshots from Intune, SCCM and Client. SCCM As seen below, SCCM thinks the device is Azure AD Join and not Hybrid Azure AD Join. I also used the following SCCM query: select SMS_R_System.NetbiosName, SMS_Client_ComanagementState.Authority, SMS_Client_ComanagementState.AADDeviceID, SMS_Client_ComanagementState.ComgmtPolicyPresent, SMS_Client_ComanagementState.EnrollmentErrorDetail, SMS_Client_ComanagementState.EnrollmentFailed, SMS_Client_ComanagementState.EnrollmentStatusCode, SMS_Client_ComanagementState.HybridAADJoined, SMS_Client_ComanagementState.MDMEnrolled, SMS_Client_ComanagementState.MDMWorkloads, SMS_Client_ComanagementState.AADJoined from SMS_R_System inner join SMS_Client_ComanagementState on SMS_Client_ComanagementState.ResourceID = SMS_R_System.ResourceId where SMS_Client_ComanagementState.ComgmtPolicyPresent = 1 and SMS_Client_ComanagementState.MDMEnrolled = 1 And had the following results, same probem. Azure AD Joined = Yes, Hybrid Azure AD Joined = No AzureAD As seen on the Devices > Azure AD Devices, the machine is properly detected as Hybrid Azure AD Joined As seen below, DeviceTrustType = Domain Joined and DeviceTrustLevel = Managed should be correct (see here). Get-MsolDevice -Name hp-eb-g3 Enabled : True ObjectId : cxxxxxxxxxxxxxxxxxxxxxxxx0 DeviceId : 2xxxxxxxxxxxxxxxxxxxxxxxxxxxxx2 DisplayName : HP-EB-G3 DeviceObjectVersion : 2 DeviceOsType : Windows 10 Enterprise DeviceOsVersion : 10.0 (17134) DeviceTrustType : Domain Joined DeviceTrustLevel : Managed DevicePhysicalIds : {[USER-GID]:2xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx2, [GID]:g:6xxxxxxxxxxxxxxxx2, [USER-HWID]:2xxxxxxxxxxxxxxxxxxxxxxxxxxxxx2, [HWID]:h:6xxxxxxxxxxxxxxxxxx2} ApproximateLastLogonTimestamp : 27/07/2018 15:00:56 AlternativeSecurityIds : {X509:<SHA1-TP-PUBKEY>0xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx} DirSyncEnabled : True LastDirSyncTime : 03/08/2018 02:31:16 RegisteredOwners : {} GraphDeviceObject : Microsoft.Azure.ActiveDirectory.GraphClient.Device Intune This is how the device shows up in Intune Client DeviceManagement Log event 75 properly happened Client properly seeing management from Intune dsregcmd properly recognizes machine as AAD and MDM enrolled and AD Domain Joined dsregcmd /status +----------------------------------------------------------------------+ | Device State | +----------------------------------------------------------------------+ AzureAdJoined : YES EnterpriseJoined : NO DeviceId : 2xxxxxxxxxxxxxxxxxxxxxxxxx2 Thumbprint : 0xxxxxxxxxxxxxxxxxxxxxxA KeyContainerId : cxxxxxxxxxxxxxxxxxxxxxx7 KeyProvider : Microsoft Platform Crypto Provider TpmProtected : YES KeySignTest: : PASSED Idp : login.windows.net TenantId : 9xxxxxxxxxxxxxxxxxxx2 TenantName : Axxxxxxxxxxxxxs AuthCodeUrl : https://login.microsoftonline.com/9xxxxxxxxxxxxxxxxxxxx2/oauth2/authorize AccessTokenUrl : https://login.microsoftonline.com/9xxxxxxxxxxxxxxxxxxxxxxxxx2/oauth2/token MdmUrl : https://enrollment.manage.microsoft.com/enrollmentserver/discovery.svc MdmTouUrl : https://portal.manage.microsoft.com/TermsofUse.aspx MdmComplianceUrl : https://portal.manage.microsoft.com/?portalAction=Compliance SettingsUrl : JoinSrvVersion : 1.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/9xxxxxxxxxxxxxxxxxxxxxxxxxxxx2/ WebAuthNSrvId : urn:ms-drs:enterpriseregistration.windows.net DeviceManagementSrvVersion : 1.0 DeviceManagementSrvUrl : https://enterpriseregistration.windows.net/manage/9xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx2/ DeviceManagementSrvId : urn:ms-drs:enterpriseregistration.windows.net DomainJoined : YES DomainName : XXXXXXXXXX +----------------------------------------------------------------------+ | User State | +----------------------------------------------------------------------+ NgcSet : NO WorkplaceJoined : NO WamDefaultSet : YES WamDefaultAuthority : organizations WamDefaultId : https://login.microsoft.com WamDefaultGUID : {Bxxxxxxxxxxxxxxxxxxxxxxxxxxxxx0} (AzureAd) AzureAdPrt : YES AzureAdPrtAuthority : https://login.microsoftonline.com/9xxxxxxxxxxxxxxxxxxxxxxxxxx2 EnterprisePrt : NO EnterprisePrtAuthority : +----------------------------------------------------------------------+ | Ngc Prerequisite Check | +----------------------------------------------------------------------+ IsUserAzureAD : YES PolicyEnabled : NO PostLogonEnabled : YES DeviceEligible : YES SessionIsNotRemote : NO CertEnrollment : none AadRecoveryNeeded : NO PreReqResult : WillNotProvision Can anyone having a similar configuration crosscheck and let me know what difference there is? References: https://www.imab.dk/flipping-the-switch-how-to-enable-co-management-in-configuration-manager-current-branch/ https://allthingscloud.blog/automatically-mdm-enroll-windows-10-device-using-group-policy/ -- Alex

Safely ignore this one. It is by design until accounts are added.

Dear all, I am trying to figure out what is the difference between the two below options. 1. The first is Capture User State that has an option for Offline USMT 2. The second is a script call under Offline USMT node. Can anyone please help me understand the difference? Thank you!

I found the following that happens on 1610 and seems like a bug which Microsoft acknowledged. https://social.technet.microsoft.com/Forums/en-US/7bfdd65e-d81f-447c-a132-3df9f2b296c7/client-fails-to-request-user-state-store-no-local-smp-found?forum=configmanagerosd Removing the Failback boundary group from the Boundary, solves the problem. Just tested it and verified that this bug is still there. -- Alex

And yes, this is now resolved. On the Boundary Group, I had only added the local DP (which carries the SMP role as well) and lives in the same subnet. I hadn't added the main Site System which is over WAN and is holding the Primary Site server role and the MP. I don't know if this is the proper way to set this up, but this has now solved the problem. BUT, if the secondary host (the Primary Site Server) is also a DP and SMP, then the client could possibly choose that one as a DP? Any help here appreciated. Alex

Here is the log from this change. Number of remote SMP's = 1 OSDSMPClient 23/02/2018 05:50:17 3656 (0x0E48) Adding http://server.company.intern.com to Remote SMP list. OSDSMPClient 23/02/2018 05:50:17 3656 (0x0E48) -- Alex

Folks, I dug deeper in the issue. My Client is on a subnet that is properly in the boundary group of the server below. So, Client : 192.168.51.150 SMP: 192.168.51.50 These are properly bordered in the SMP role, but still the smsts.log fails with: Number of local SMP's = 0 OSDSMPClient 23/02/2018 03:39:40 2080 (0x0820) SMP Location Info = <SMPLocationInfo> <Sites> <Site> <SMPSite SiteCode="XX1" MasterSiteCode="XX1" SiteLocality="REMOTE"> <LocationRecords> <LocationRecord> <ADSite Name="SITE1"/> <IPSubnets> <IPSubnet Address="192.168.51.0"/> <IPSubnet Address=""/> </IPSubnets> <ServerName>http://server.company.intern.com</ServerName> </LocationRecord> </LocationRecords> </SMPSite> </Site> </Sites> </SMPLocationInfo> So, I changed the Task Sequence to be allowed to fallback on a Remote DP and that worked so this is the root of the problem. Possible causes: a. The client is in two Boundary Groups, one via the AD Site and one via the IP Subnet b. Dual network interfaces exist on the client so it gets confused I will look into both issues. -- Alex

Folks, I have the same question. Anyone? Alex

On a SCCM 1606 fresh install, I see that Accounts tab is empty. Is this normal? -- Alex

Although it worked once, now it fails with below error. Administration > Add System Site Role Wizard > Add a Reporting Point. When I try to provide the user account and click Existing Accounts I get the following error. Invalid parameter ------------------------------- Microsoft.ConfigurationManagement.ManagementProvider.WqlQueryEngine.WqlQueryException The SMS Provider reported an error. Stack Trace: at Microsoft.ConfigurationManagement.ManagementProvider.WqlQueryEngine.WqlQueryResultsObject.<GetEnumerator>d__74.MoveNext() at Microsoft.ConfigurationManagement.ManagementProvider.QueryProcessorBase.ProcessQuery(Object sender, DoWorkEventArgs e) at System.ComponentModel.BackgroundWorker.OnDoWork(DoWorkEventArgs e) at System.ComponentModel.BackgroundWorker.WorkerThreadStart(Object argument) ------------------------------- System.Management.ManagementException Invalid parameter Stack Trace: at Microsoft.ConfigurationManagement.ManagementProvider.WqlQueryEngine.WqlQueryResultsObject.<GetEnumerator>d__74.MoveNext() at Microsoft.ConfigurationManagement.ManagementProvider.QueryProcessorBase.ProcessQuery(Object sender, DoWorkEventArgs e) at System.ComponentModel.BackgroundWorker.OnDoWork(DoWorkEventArgs e) at System.ComponentModel.BackgroundWorker.WorkerThreadStart(Object argument) ------------------------------- If I try to add an account on the spot, I can complete the User and Password fields but when I hit OK, it doesn't show up -and can't continue- ! Any ideas? Has the DB been broken? -- Alex