Hello,

I have few servers that the following error appear every 15 minutes in the Operations Manager log :

GetSQL2012SPNState.vbs : Unable to open WMI Namespace 'winmgmts:\\server.company.Corp.xxx.company.Corp\root\Microsoft\SqlServer\ComputerManagement11'. Check to see if the WMI service is enabled and running, and ensure this WMI namespace exists.. The remote server machine does not exist or is unavailable.

The event ID is 4001 and the source of alert is Health Service Script

While xxx is a child domain of the company.corp forest. The server itself is located on the company.corp forest.

Does someone know this error message and can assist me how to solve it ?

Thanks,

Amit

Correct me if I'm wrong, but this looks like the script is trying to query WMI using a wrong server name (server.company.corp.subdomain.company.corp), right? So obviously it can't open it.

I think I've already faced this problem.

If I remember correctly, it is related to the method the script uses to find the server's fqdn : 

First it uses the FQDN discovered by the SCOM Agent (server.company.corp)

Then it does an LDAP query on GC://RootDSE to find the defaultNamingContext

Then it compares both values, and if the defaultNamingContext is not contained in the FQDN, it considers that the FQDN is wrong and append it to the defaultNamingContext.

So, what happens is that the SCOM agent says "FQDN for this server is server.domain.com", but the LDAP request says "defaultNamingContext is xxx.company.corp".
Since xxx.company.corp is not contained in server.company.corp, the script "rebuilds" what it thinks would be the correct FQDN : server.company.corp.xxx.company.corp.

This happens when for some reason, the LDAP query to GC://RootDSE is targeted at a GC that is not in the same domain as the SQL server.

The thing is, I never had time to go further and work with a qualified AD/DNS admin on this, so I don't really know how a server chooses what GC it will target for a GC:// query and therefore I don't have a solution for this issue.

Hope these explanations helped, though!

• Edited by CyrAz Sunday, December 28, 2014 2:31 PM

Correct me if I'm wrong, but this looks like the script is trying to query WMI using a wrong server name (server.company.corp.subdomain.company.corp), right? So obviously it can't open it.

I think I've already faced this problem.

If I remember correctly, it is related to the method the script uses to find the server's fqdn : 

First it uses the FQDN discovered by the SCOM Agent (server.company.corp)

Then it does an LDAP query on GC://RootDSE to find the defaultNamingContext

Then it compares both values, and if the defaultNamingContext is not contained in the FQDN, it considers that the FQDN is wrong and append it to the defaultNamingContext.

So, what happens is that the SCOM agent says "FQDN for this server is server.domain.com", but the LDAP request says "defaultNamingContext is xxx.company.corp".
Since xxx.company.corp is not contained in server.company.corp, the script "rebuilds" what it thinks would be the correct FQDN : server.company.corp.xxx.company.corp.

This happens when for some reason, the LDAP query to GC://RootDSE is targeted at a GC that is not in the same domain as the SQL server.

The thing is, I never had time to go further and work with a qualified AD/DNS admin on this, so I don't really know how a server chooses what GC it will target for a GC:// query and therefore I don't have a solution for this issue.

Hope these explanations helped, though!

• Edited by CyrAz Sunday, December 28, 2014 2:31 PM

Correct me if I'm wrong, but this looks like the script is trying to query WMI using a wrong server name (server.company.corp.subdomain.company.corp), right? So obviously it can't open it.

I think I've already faced this problem.

If I remember correctly, it is related to the method the script uses to find the server's fqdn : 

First it uses the FQDN discovered by the SCOM Agent (server.company.corp)

Then it does an LDAP query on GC://RootDSE to find the defaultNamingContext

Then it compares both values, and if the defaultNamingContext is not contained in the FQDN, it considers that the FQDN is wrong and append it to the defaultNamingContext.

So, what happens is that the SCOM agent says "FQDN for this server is server.domain.com", but the LDAP request says "defaultNamingContext is xxx.company.corp".
Since xxx.company.corp is not contained in server.company.corp, the script "rebuilds" what it thinks would be the correct FQDN : server.company.corp.xxx.company.corp.

This happens when for some reason, the LDAP query to GC://RootDSE is targeted at a GC that is not in the same domain as the SQL server.

The thing is, I never had time to go further and work with a qualified AD/DNS admin on this, so I don't really know how a server chooses what GC it will target for a GC:// query and therefore I don't have a solution for this issue.

Hope these explanations helped, though!

• Edited by CyrAz Sunday, December 28, 2014 2:31 PM

Hi,

Please check out the commonality of the few servers on which you are seeing this error, mostly when you are monitoring a Microsoft SQL Server 2012 computer that has the System Center 2012 Operations Manager agent installed, you notice that event 4001 is logged in the Operations Manager log

Please refer the following link:

http://support.microsoft.com/kb/2962161

Hope this helps...

hi

You can check the following threads

https://social.technet.microsoft.com/Forums/systemcenter/en-US/c61a8a71-421f-4e0a-973c-236345e76747/sql-mp-spn-status-monitor-weird-behaviour?forum=operationsmanagermgmtpacks

Christophe

Funny that this issue was discussed a few weeks ago when I couldn't find anything when I faced it a couple of months ago, even more when you imagine that it has probably been around for a long time!

I see that we reached the same conclusions... but there is still no real answer here, unless we consider that the script should be fixed by MS.

• Edited by CyrAz Sunday, December 28, 2014 11:10 PM

Funny that this issue was discussed a few weeks ago when I couldn't find anything when I faced it a couple of months ago, even more when you imagine that it has probably been around for a long time!

I see that we reached the same conclusions... but there is still no real answer here, unless we consider that the script should be fixed by MS.

• Edited by CyrAz Sunday, December 28, 2014 11:10 PM

Funny that this issue was discussed a few weeks ago when I couldn't find anything when I faced it a couple of months ago, even more when you imagine that it has probably been around for a long time!

I see that we reached the same conclusions... but there is still no real answer here, unless we consider that the script should be fixed by MS.

• Edited by CyrAz Sunday, December 28, 2014 11:10 PM

Hi There,

Please check this link with the same issue

https://social.technet.microsoft.com/Forums/systemcenter/en-US/4fe2354a-ecd4-498c-9490-892ed0b6571d/event-id-4001-source-health-service-script

I vote "yes" to this consideration that MS re-write the script.  I am experienceing it and I would bet that this has been around for a long time.