At this stage, there will still be a few permissions here and there that aren't quite right for SCOM, so I wanted to sort these out next. Firstly, the SCOM server will need access to the Reporting web service on the SQL server, and the firewall config won't currently allow this.
To ensure I can lock down the rule reasonably well I wanted to see what process was listening on port 80 so ran a netstat -ano | findstr ":80" from the command prompt.
Next, I noticed I was seeing the error "Logon failed for user (OM Action Account) Reason: Failed to open the explicitly specified database. [CLIENT: Local IP]" occur 8 times every 15 Minutes in the applicaton log of the SQL server. (Whoever puts together the code for these errors, actually mentioning the name of the "explicitly specified" database might make them a little more useful :).
SQLServerMPGuide.doc available with the Management Pack Download. The problem with this is it only covers configuration for low-privilege environments, which doesn't support clustering or mirroring, and requires setting up three different service accounts, and using run-as profiles in SCOM. That's fairly overkill for this lab environment, and the amount of granular permissions I've now been configuring, is making me consider the possibility that, even in a production environment having three separate accounts with 10 different permissions each (and therefore 10 opportunities for misconfiguration) is probably less secure than having a single account with more access that has credentials accessible or changeable only to a select few, and is closely monitored for unexpected behaviour... Anyway, I digress. I decided to use the above document as a template to base the permissions I would assign the SCOMAA account, translating the requirements of the many accounts into requirements for one account and subtracting permissions I knew would already be assigned due to (primarily) the SCOMAA user already being a local admin.
In SQL Server Management Studio, I right-clicked the SQL server at the root, went into properties then permissions. Here, I granted the SCOMAA account View any definition, and View server state.
Next, seeing as I was working on the SQL server I decided to check SCOM for any other potential issues. It looks like the SPN has been switching between good and bad a few times.