Let me start by saying I have a Microsoft ticket open on this issue that has
been open for a while now and was escalated to Tier 3 and we have been actively
working but no resolution. I wanted to see if anyone else had input that we
have not tried.
Original Build:
2 MGMT servers (Server 2012 R2) VM's
1 SQL Server (standalone with reporting, Server 2012 R2 with SQL 2012) VM's
Everything was working good then I lost the SQL VM, came in after we lost power
and everything went down hard to a screen that said no OS found. So at this
time we decided that this was a good time to move the DB's to the SQL cluster.
So now all the SCOM DB's reside on a 4 node cluster.
Existing Build:
2 MGMT servers (Server 2012 R2) VM's
4 Node SQL Cluster (SQL 2012/instance)
Db's were restored and MGMT servers were honed to the sqlserver\instance, and
everything is working like it should with the exception of installing the SCOM
agent. Now the fun part trying to explain this. This is reproducible, so
hopefully I can explain this without confusing.
Scenario:
Our 2012 R2 servers are locked down by STIG and we use restricted groups to
allow admins on the servers via GPO's. This has been working up till the SQL
crash.
Example:
Security Group "SCOM Servers"
Members: "myself and SCAA" (SCOM Action Account)
My account and SCAA can log into the servers so I know they are locked down and
Admin access is successful.
SCOM Agent install:
If "SCOM Servers" security Group exists the agent will install
or I can use any other existing SG
If the "SCOM Servers" security group is newly created, SCOM agent will fail
with Access denied, now the funny part about this is that about after a week or
two the agent will install without any changes being made.
While working with Microsoft we have tested and collected logs from all of the
machines involved but have not been able to resolve yet. I am hoping this
reaches someone with the ah ha you need to check or do this. Any
recommendations would greatly be appreciated. It seems to be related to the
SCAA account and newly created security groups. AD is healthy and replication
is not an issue. Didn't know if there is something in SCOM I need to check or
the DB's or a script I need to run.
Thanks
Chris