Migrating CCM agents to a new site – 0x8000ffff and SMSSLP

While its not as bad as my last issue with the _same_ error code, the thumbnail picture is still justified here. There’re already some blogs about this error showing up in ClientIDManagerStartup.log and LocationServices.log constantly, for example here and here. However, the issue I was looking at today had an old root cause, really old. Usually I still go for the old adm template when migrating CCM Agents from Site A to Site B. These are located in <ConfigMgrInstallationFolder>\Tools\ConfigMgrADMTemplates. There, configmgrassignment.adm sets GPRequestedSiteAssigmentCode in HKLM\SOFTWARE\Microsoft\SMS\Mobile Client to be the new site code, as Prajwal points out. I wrote the following points to check and verified them with the customer.

Verification and Checklist

1. Make sure your publishing is working properly.
   • See Find site resources – Configuration Manager | Microsoft Docs
   • Check your DNS for _mssms_mp_<sitecode> (see picture above) – you enable this on the MP Component Properties on your site
   • Check your Site Management Container – you enable this in the properties of the site under publishing
2. Make sure, that either your boundaries between the sites don’t overlap or disable the publishing for the retiring site (see 1.). This is not as bad as it sounds, as existing clients already have their information and will happily talk to your existing site. Be aware, that if you need to reinstall a CCM you will need to give it an MP to talk to.
3. Make sure that the boundaries are correct. If you use your AD Site as boundary, make sure it has your IP subnets.
4. Check your Firewall again – yes really! Ports, Firewall(s), Firewall rules. Involve the network them, bribe them with beer if you have to.
5. Check that your MP is resolving from the client(s) in question.
6. Verify that you have set the correct Root CA in your site properties under Communication Security. If your root CA is different from your old site, you might want to use RESETKEYINFORMATION=TRUE. We did this even though we had the same root CA thumbprint.

Solving the root cause

You made it through all points and still see issues? You might want to look at your ccmsetup.log (look for the line starting with “MSI properties:”) or HKLM\SOFTWARE\Microsoft\CCMSetup “InitialCommandLine”. If you see any entries that define SMSSLP you might have found your culprit. This is an installation parameter so old, it even predates SCCM 2012. Back then you had the Server Locator Point. Basically a role that sole purpose that told clients where to look for their ConfigMgr servers. This was great for non domain joined machines or if you couldn’t use AD/DNS publishing. I would compare it to SMSMP most likely. However, these days this role is dead, it doesn’t exist anymore.

To fix this issue, get rid of the SMSSLP entry in HKLM\SOFTWARE\Microsoft\CCM – it will most likely exist already but it should be empty. I’m not sure of how that was filled in the old environment, as the ConfigMgr installation we’re migrating from was never a SCCM 2007. If I had to guess, someone either dug up or knew the old parameter and just used a GPO that was removed along the way. Either way, here’s the code if you want to query this with CMPivot and the PowerShell code to get rid of the key. You can of course also remove the key (or at least empty it) with a GPO.

cmpivot:UmVnaXN0cnkoJ0hLTE06XFxTT0ZUV0FSRVxcTWljcm9zb2Z0XFxDQ00nKSANCnwgd2hlcmUgUHJvcGVydHkgPT0gJ1NNU1NMUCcNCnwgd2hlcmUgVmFsdWUgPT0gJyc=

$Path = "HKLM:\SOFTWARE\Microsoft\CCM\"
if(Test-Path $Path){
    if((Get-ItemProperty $Path -Name SMSSLP).SMSSLP -ne ""){
        Set-ItemProperty $Path -Name SMSSLP -Value "" -Force
        Write-Output "-done-"}
}