I recently had an issue where a site seemed to suddenly stop communicating with it’s management point and the SUP. Whilst I never got to the bottom why it actually happened (given that all was working fine a day or two before) I did eventually get to the bottom of how to fix it but it took a good day out of a very busy schedule.
Anyway, the symptoms were an MP and SUP which could no longer communicate with the SQL DB. The logs would have errors similar to ‘Call to HttpSendRequestSync failed for port 80 with status code 500’.

mpcontrol.log:

WSUSCtrl.log

As you can see, what a mess. This was working fine previously!
The MP in question was on the same domain and used the computer account to communicate with the database which was on the primary site server. I had also configured an account to connect to another forest on the SCCM site but this wasn’t used in conjunction with this MP. After banging my head against a wall for an hour or two I nonetheless decided to remove the forest connection account from ConfigMgr but still the same error. I then came across this post which I applied. This caused the mpcontrol.log and the WSUSCtrl.log to both calm down somewhat:

mpcontrol.log

WSUSCtrl.log

OK both logs looked better but we’re still stuck with errors. I decided to take a look back at the SPNs for SQL. I opened ADSIEDIT, found the SQL account in question and looked at the Service Principal Names registered. Sure enough they seemed to be registered with the NETBIOS and FQDNs all as expected.

Balls. I was running out of ideas.

I had a chat to my SQL guy and he suggested running Kerberos Configuration Manager just in case. This utility will check if the SPNs are registered correctly, and if not register them all correctly for you. Basically, it takes the messing about out of the command line. I wish I’d known about this utility years ago. Sure enough, it said one of the registrations was incorrect for some reason and it ‘corrected’ it. These worked fine the day before so why had one stopped working?? Doesn’t matter, just need to fix…

After that everything started working again. I was happy. Hopefully this will help someone else frustrated with bugs they didn’t know of in SCCM and SPNs that look, for all intents and purposes, like they are otherwise registered.