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 http://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).

(1128)

Nickolaj Andersen

Principal Consultant and Enterprise Mobility MVP since 2016. Nickolaj has been in the IT industry for the past 10 years specializing in Enterprise Mobility and Security, Windows devices and deployments including automation. Currently working for TrueSec as a Principal Consultant. Awarded as PowerShell Hero in 2015 by the community for his script and tools contributions. Creator of ConfigMgr Prerequisites Tool, ConfigMgr OSD FrontEnd, ConfigMgr WebService to name a few. Frequent speaker at conferences and user groups.

comments
  • bob
    Posted at 16:50 July 17, 2015
    bob
    Reply
    Author

    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.

  • Leave a Reply