We have recently implemented SCOM 2012 with the SQL Management Pack. On our SQL Clusters (SQL 2008), we have added a low level privilege account to the local administrators group on both nodes and have given read permissions to the databases in SQL (as recommended by Microsoft). The servers are Windows Server 2008 R2 SP1.
The issue is, we were receiving a script error on a getSQL2008DBFilesFreeSpace.vbs that the script was terminated because it was running over the 300 second timeout. Upon further investigation, we have found the real issue.
The low-level privilege account did not have the ability to browse WMI using the Cluster Name. We were receiving an access denied. If you logged in as the low-level privilege account locally on one of the SQL Cluster nodes and run wbemtest and then connected to \\<clustername>\root\cimv2, we received an access denied error. If you connect to \\<clusternodename>\root\cimv2, it would connect successfully.
The low level privilege account is a local administrator of the server and is in the local administrators group. If you look a the WMI permissions, the local administrators group has full permissions on both the node name and the SQL Cluster name.
To resolve this issue, we had to edit DCOM permissions for the "My Computer" object for Launch and Activation Permissions/Edit Limits and then add the low level priviledge account explicitly with Remote Activation permissions.
My question.....why do you have to add EXPLICIT permissions for an account in DCOM when the account is already a member of local administrators group that HAS the remote activation permission defined????
I appreciate it if any one can tell me if there is a patch or something that I am missing that corrects this condition. I think it is silly that I have to add this account explicitly if it is already a member of a group that has the permissions defined?
Thanks!