Microsoft SCCM 2012 SP1 Installation – Local Administrator, DNS and SPN Woes

I came across an interesting problem the other day when installing SCCM 2012 SP1 for a client.  A brand new Windows Server 2012 domain had been created and SCCM was being installed on Windows Server 2008 R2 SP1.  All was going fine until I got to the SMS Provider Settings screen in the wizard, where you type the FQDN of the SMS Provider.

sccm_sms_provider

I filled this in and got the following error ‘You must have local administrator privileges to install SMS Provider on machine <FQDN>’:

sccm_local_admin

Wait, what? I went and checked the local admins group and it was all correct as per the prerequisites, so I rebooted the box and the same thing happened.  I then checked the ConfigMgrSetupWizard.log file that automatically gets created on the root of the system drive and it had an error:

Failed to open SCM on machine <FQDN>. Error code: 5

Not very helpful either.  I was beginning to run out of ideas, when I decided to check the server’s SPNs.  Running ‘setspn -L <HOSTNAME>’ returned entries that were missing the FQDN values!  How odd.

I created the FQDN equivalent of each entry manually (you can either do this in AD Users and Computers console or by command line), rebooted the SCCM site server, ran through the installation wizard again and it then got past that stage in the wizard.

Not convinced about why this happened, I did some more digging and when looking in Control Panel > System, I saw that the entry for ‘Full computer name’ was missing the domain name, even though it had the correct domain listed further down.  This is a similar picture to what I saw:

sccm_system_fqdn_missing

…where it should have been (notice the difference in the ‘Full computer name’ value):

sccm_system_fqdn_present

It turns out the servers had been provisioned from an old template and, while I don’t know the exact reason, something was stopping these joining the domain correctly.  Deploying the servers from a new vanilla ISO worked as expected.

Not a local administrators issue after all and several ‘red herrings’ from SCCM.