Clients still report to the old management point after having migrated to the new hierarchy

Clients still report to the old management point after having migrated to the new hierarchy

We carried out SCCM migration from one hierarchy to a new one. However, it is found that some of the clients still report to the management point in the old hierarchy. Checking the client logs, we observed the following –

LocationServices.log:

02-02-2021 15:56:51.269 LocationServices 11500 (0x2cec) LsRefreshManagementPointEx failed with 0x8000ffff

ClientIDManagerStartup.log:

02-02-2021 15:56:51.269 ClientIDManagerStartup 11500 (0x2cec) RegTask: Failed to refresh MP. Error: 0x8000ffff

CcmMessaging.log:

02-02-2021 15:56:51.239 CcmMessaging 11500 (0x2cec) Raising event:
instance of CCM_CcmHttp_Status
{
ClientID = "GUID:DFE3D455-EE19-4EB9-88FD-EEB475E7E20B";
DateTime = "20210202075651.239000+000";
HostName = "oldmgmtpoint.contoso.com";
HRESULT = "0x00000000";
ProcessID = 7532;
StatusCode = 0;
ThreadID = 11500;
};

This was actually caused by the Trusted Root Key.

The Configuration Manager trusted root key provides a mechanism for Configuration Manager clients to verify site systems belong to their hierarchy. Every site server generates a site exchange key to communicate with other sites.

If a client still holds the old trusted root key from the site server of the previous hierarchy, it will considers itself belonged to the previous hierarchy.

We ran the following PowerShell command to get the trusted root key of the problematic clients.

(Get-WmiObject -Namespace root\ccm\locationservices -Class TrustedRootKey).TrustedRootKey

Just as expected the returned trusted root key is different from the one found in the the <Configuration Manager install directory>\bin\i386\mobileclient.tcf file of the current site server in the new hierarchy.

There are two ways to fix the issue –

Option 1 – This is also the suggested way in the official guide. See – Migration operations – Configuration Manager | Microsoft Docs

  • Uninstall sccm client and then reinstall it

Of course, you can alternatively install the client with /forceinstall parameter which uninstall any existing client and re-installs it.

Option 2 –

Add to the RESETKEYINFORMATION=TRUE install command line, eg. ccmsetup.exe /MP:currentmp.contoso.com /UsePKICert /SkipPrereq:Silverlight.exe SMSSITECODE=PS1 FSP=newfsp.contoso.com RESETKEYINFORMATION=TRUE

This parameter is especially important in case of migration.

If a client has the wrong Configuration Manager trusted root key, it can’t contact a trusted management point to receive the new trusted root key. Use this property to remove the old trusted root key. This situation may occur when you move a client from one site hierarchy to another. 

References

Design a site like this with WordPress.com
Get started