Bumped into an issue where the installation of OM12x didn’t run ‘smoothly’. The installation of the first Management Server in the new SCOM Management Group ran but that’s where it stopped.
When trying to install the SCOM Reporting component all kinds of errors were thrown. First I suspected the SPN to be at play here, or better the lack of it. But even when the SPN was set for the Management Servers, the same error was thrown, blocking the installation of the SCOM Reporting instance.
Time for some deeper investigation. When opening the SCOM Console on the newly installed SCOM Management Server I noticed that NOTHING of the new SCOM infrastructure was detected. Strange! Even when a new SCOM MG is deployed, SCOM starts collecting information about itself and monitors it.
But this time NOTHING.
Time to check the OpsMgr eventlog on this MS server. And soon the errors popped up: The SCOM service accounts weren’t allowed the required Allow Log on Locally permissions on the SCOM MS server(s), breaking the SCOM environment.
Time to contact the people involved and ascertain that the SCOM service accounts were given the proper permissions as stated in the design and RFCs. When this was fixed, and the related SCOM services restarted, things started looking way much better.
Discoveries run successfully, and soon thereafter the monitoring of those new Objects started. And now the SCOM Reporting component installed without a glitch. More SCOM MS servers were added to the mix and SCOM was just fine.
Never presume, always check. In this case an additional check about the accounts and whether the requirements were met, would have been a good step.
And when a SCOM component fails to install, check the OpsMgr eventlog of the previously installed SCOM MS Server(s). Many times good information is to be found there, helping you to solve the problem at hand.