we monitor SQL Server Instances in a DMZ environment which has its own Active Directory – let’s call it web.local.
We monitor sql.web.local.
Our monitoring system is located in our production AD – let’s call it prod.local.
Our monitoring system is called monitoring.prod.local
There is no trust between these forests.
When we try to gather metrics via WMI FOR sql.web.local FROM monitoring.prod.local using a proper configured AD account in web.local (firstname.lastname@example.org ) this attempt fails.
We can exclude the firewall being the culprit of this behavior since we can successfully start a PS get-wmiobject call from the monitoring server using the –credential switch.
From the server monitoring.prod.local we call get-wmiobject –class win32_operatingsystem –credential web\svc_idera – this attempt succeeds.
Thus we know that the systems required for AAA work.
We observe that the failed attempts to gather WMI metrics on sql.web.local from monitoring.prod.local leave an entry in the Security Eventlog which says that the authentication failed for the service user we run the SQLdm Services (Collection, Management, Rest, Predicitive Analytics) under. We leave the checkbox “Connect using the SQLDM Collection Service Account” blank. Why does the SQLdm Collection Service try to connect using the prod.local service account when we explicitly provide web.local credentials for this particular task.
We also observe the when we start the get-wmiobject CMDlet the WMI metric collection with the SQLdm Collection Service works for some time.
Why does the SQLdm Collection Service discard the credentials provided to gather WMI metrics and uses the local Service account in a cross forest setup without an AD trust in place?
Any help is highly appreciated.
I've not seen this happen before, where you've specified a unique account to gather WMI statistics but SQLDM continues or later reverts to using the SQLDM Collection Service account. Are you sure that SQLDM is failing to connect to WMI due to the wrong account being used? I would suggest opening up a support case to investigate this issue further.
Powered by IDERA