During the migration from Configuration Manager 2007 to Configuration Manager 2012, I experienced a problem with clients in a Secondary site wouldn’t get assigned to the Primary Site Management Point. Looking at the LocationServices.log in C:\Windows\CCM\Logs showed me that the client was able to locate the correct proxy Management Point of the Secondary Site, through the downloaded list of MP’s. It would then try re-assign itself and logged the following:
Group Policy Site Assignment key HKLM\Software\Microsoft\SMS\Mobile Client has changed, will attempt to re-assign the client.
After some seconds the client would spit out some more log entries and then restart the CcmExec.exe process (itself).
Security settings update detected, restarting CcmExec.
This would go on and on and some other problems related to this was that when you try to PXE boot an OSD, it would fail to find any advertisements (deployments) in the database. After some re-installations of the Management Point on the Secondary site with the help and advice of a tech from Advance Systems, I also tried to re-install the whole Secondary site, to see if I forgot something during the process. After re-installing the whole site, on a completely new virtual machine, the same problem occurred. Clients would not get assigned.
A support call was then placed to Microsoft Pro Platform Support and I got in contact with Alberto, really nice and helpful technician. He searched through Microsoft’s database of reported problems with Configuration Manager 2012 and secondary sites. He pointed me towards a customer who almost had the same kind of problem I was experiencing. A tip from Alberto led me to investigate SPN of the user account running the Primary site SQL Server. It appeared that when running:
setspn -L DOMAIN\useraccount
that the result was empty. Searching through internet led me to this blog post https://scug.be/sccm/2012/05/21/system-center-2012-and-making-sure-your-sql-spn-s-are-correctly-auto-registering/ where it states how to automatically create SPN’s on the user account. I gave it a try and after restarting the SQL Server service, the LocationServices.log stopped telling it was restarting itself, and finally assigned itself. The short explanation was that I had to give the user account the SELF permission, and under the Properties tab check servicePrincipalName for both Read and Write. It should also only be applied to This object only.
As to that, PXE booting started to work again. Downloading and installing applications from the Application Catalog worked too. I was a happy camper, since I had been troubleshooting the problems for 3 days (and nights).
Great article. we about to install a secondary site in the DMZ, which will present additional challenges I’m sure. But Reading this one will give me something to look for at the get go.