Logbook of the Captain – sidereal time: 2017.06.07
From now I’ve installed so many servers with System Center Configuration Manager site in different constellations. It seems to be about 150 different servers in different domains, on different platform versions, productive and non-productive, on my own environment or on the customers environment. But last week I ran into an error I don’t understand until now.
I’ve installed an standalone primary site with Current Branch 1702 of Microsoft’s ConfigMgr and everything seems to be ok. We’ve migrated the content from an old ConfigMgr Standalone Primary Site and went to be sure that everything works like expected. One of the last things on my checklist: install the Reporting Services Point.
For understanding the environment:
- Domain Level: 2008 R2
- Server 2016 (with actual patches)
- SQL Server 2016 SP1 locally installed
- SCCM Current Branch 1702
As known I’ve installed SQL Server including Reporting Services. Microsoft recommends to install the SQL Server with Domain Accounts for running services. In this case you must register service principal names (SPN) for this services. Every time I’ve installed the services with different Users.One user for the Engine and one for reporting. Because of time issues I’ve only got one user for all services from the customer.
Reporting Services (native) installed correctly by SQL server setup and SQL server services running as expected. SPNs would registred correctly by following the Microsoft Guideline: https://docs.microsoft.com/en-us/sql/database-engine/configure-windows/register-a-service-principal-name-for-kerberos-connections
Register SPNs for SQL Engine:
- setspn.exe -a MSSQLSrv/NetBIOSName:1433 Domain\Serviceusername
- setspn.exe -a MSSQLSrv/FQDN:1433 Domain\Serviceusername
Register SPNs for SQL Reporting Services:
- setspn.exe -a http/NetBIOSName:80 Domain\Serviceusername
- setspn.exe -a http/FQDN:80 Domain\Serviceusername
Later on (after installing reporting services point) I’ve want to test a report from ConfigMgr Console and ran into the error described in the title of this blog post. The Report crashed not because the reporting services could not reached the files on IIS, they crashed caused trough authentication error after connecting to the SMSDB.
After searching some hours on the internet and testing the connection and the issues I’ve decided to
- delete the reporting databases
- delete SPNs for reporting services
- reinstall MS SQL reporting services with an second user (completely new user in AD)
- and reinstall SCCM Role (reporting services point
After the reinstallation of described components everything worked fine.
BUT WHAT WENT WRONG?
I’ve installed the system as I did the other 149 times. This is the point in the life of a consultant who you are at the edge of madness. I hope I can adjust the error again and find the cause of the error. For an immediate solution, a reinstallation is sufficient, but does not satisfy the consultants brain.
Captain over and out…