Not quite Steve - here is how it works: FIRST - we must discover Windows Computer objects for each Named Resource in the cluster.
I have a simple two-node failover cluster. [cid:[email protected]] Nodes are NODE1 and NODE2. The Cluster name is CLUS1 Then - I have a Resource Group listed under "Services and applications" which a network name object which equals SQLCLUS01 [cid:[email protected]] So the first step in troubleshooting - before I even BOTHER looking at the SQL MP - is "Do I have 4 Windows Computer objects" one for each of these? I check the Windows Computer view, and see that Yes, I can continue because all 4 of these Windows Computers were discovered either by having agents on each node with proxy enabled, or by the cluster discovery that ran. The next step is to check the Microsoft.SQLServer.2008.SeedDiscovery which targets the "Windows Server" class, and determine if the seed discovery is finding all 4 computers as well: [cid:[email protected]] Once this is verified - the next discovery that runs is the DBengine discovery. This is the script based discovery you were running. You can extract this from the management pack by using MPViewer, and saving the MP as XML, then opening it with Notepad++, and copying out the script. You then need to convert the XML based scipt back into a VBscript using http://blogs.technet.com/b/kevinholman/archive/2014/10/31/troubleshooting-scom-discovery-scripts-and-those-annoying-xml-special-characters.aspx Now you have the script - you can run it manually using http://blogs.technet.com/b/kevinholman/archive/2010/03/09/basic-troubleshooting-of-discovery-scripts.aspx The script will be run 4 times.... once for every seed class. This is BY DESIGN. However, it will only return DISOVERY DATA which is an XML blob returned at the command line for ONE of the attemps, which actually contains a SQL server. Had you waited long enough in your capture you would have seen this, or you jumped way too far ahead in your troubleshooting process, and you didn't check to see if the cluster objects and resources were discovered first. cscript /nologo DiscoverSQL2008DBEngineDiscovery.vbs {00000000-0000-0000-0000-000000000000} {00000000-0000-0000-0000-000000000000} node1.opsmgr.net node1.opsmgr.net NODE1 Exclude: false cscript /nologo DiscoverSQL2008DBEngineDiscovery.vbs {00000000-0000-0000-0000-000000000000} {00000000-0000-0000-0000-000000000000} node2.opsmgr.net node2.opsmgr.net NODE2 Exclude: false cscript /nologo DiscoverSQL2008DBEngineDiscovery.vbs {00000000-0000-0000-0000-000000000000} {00000000-0000-0000-0000-000000000000} clus1.opsmgr.net clus1.opsmgr.net CLUS1 Exclude: true cscript /nologo DiscoverSQL2008DBEngineDiscovery.vbs {00000000-0000-0000-0000-000000000000} {00000000-0000-0000-0000-000000000000} sqlclus01.opsmgr.net sqlclus01.opsmgr.net SQLCLUS01 Exclude: true "true" or "false" at the end is provided by the Windows Server class property "IsVirtualNode" which you can look up in the console under discovered inventory. Notice the first two return nothing. Then the cluster object returns an empty discovery data packet. Then the actual SQL cluster name object returns a real SQL instance. C:\>cscript /nologo DiscoverSQL2008DBEngineDiscovery.vbs {00000000-0000-0000-0000-000000000000} {00000000-0000-0000-0000-000000000000} node1.opsmgr.net node1.opsmgr.net NODE1 Exclude: false C:\>cscript /nologo DiscoverSQL2008DBEngineDiscovery.vbs {00000000-0000-0000-0000-000000000000} {00000000-0000-0000-0000-000000000000} node2.opsmgr.net node2.opsmgr.net NODE2 Exclude: false C:\>cscript /nologo DiscoverSQL2008DBEngineDiscovery.vbs {00000000-0000-0000-0000-000000000000} {00000000-0000-0000-0000-000000000000} clus1.opsmgr.net clus1.opsmgr.net CLUS1 Exclude: true <DataItem type="System.DiscoveryData" time="2015-07-07T08:23:17.9759516-05:00" sourceHealthServiceId="FAF81DA7-614F-ABC5-1533-628C17CD7954"><DiscoveryType>0</DiscoveryType><DiscoverySourceType>0</DiscoverySourceType><DiscoverySourceObjectId>{00000000-0000-0000-0000-000000000000}</DiscoverySourceObjectId><DiscoverySourceManagedEntity>{00000000-0000-0000-0000-000000000000}</DiscoverySourceManagedEntity></DataItem> C:\>cscript /nologo DiscoverSQL2008DBEngineDiscovery.vbs {00000000-0000-0000-0000-000000000000} {00000000-0000-0000-0000-000000000000} sqlclus01.opsmgr.net sqlclus01.opsmgr.net SQLCLUS01 Exclude: true <DataItem type="System.DiscoveryData" time="2015-07-07T08:23:36.0227111-05:00" s ourceHealthServiceId="FAF81DA7-614F-ABC5-1533-628C17CD7954"><DiscoveryType>0</Di scoveryType><DiscoverySourceType>0</DiscoverySourceType><DiscoverySourceObjectId >{00000000-0000-0000-0000-000000000000}</DiscoverySourceObjectId><DiscoverySourc eManagedEntity>{00000000-0000-0000-0000-000000000000}</DiscoverySourceManagedEnt ity><ClassInstances><ClassInstance TypeId="{994BDF28-10B8-52E4-3334-D65A63D9FE52 }"><Settings><Setting><Name>{078C975B-6B4B-7ED1-678F-ECB81FAA00CC}</Name><Value> True</Value></Setting><Setting><Name>{0F700489-D513-FC14-2FE1-B514BC789F42}</Nam e><Value>I01</Value></Setting><Setting><Name>{197D70B5-0429-5C8F-E11E-50B1CE5BBE 30}</Name><Value>MSSQL$I01</Value></Setting><Setting><Name>{19A96D5F-2D87-E1A5-3 8F3-A09A42830D07}</Name><Value>MSSQL$I01</Value></Setting><Setting><Name>{202341 AA-8ABE-0427-96D3-B91D612CF6C8}</Name><Value>2</Value></Setting><Setting><Name>{ 21CC0652-0CF6-84DB-2245-0CAA483EE2D9}</Name><Value>SQL SERVER (I01)</Value></Set ting><Setting><Name>{3BBDDDF9-1F49-4334-8759-B0D9461B9A1A}</Name><Value>R:\MSSQL 10_50.I01\MSSQL\DATA\master.mdf</Value></Setting><Setting><Name>{4DDAC64C-C6E2-3 62A-2BC1-C1CB98AA95FF}</Name><Value>MSSQLFDLauncher$I01</Value></Setting><Settin g><Name>{5C324096-D928-76DB-E9E7-E629DCC261B1}</Name><Value>sqlclus01.opsmgr.net </Value></Setting><Setting><Name>{61D68FF0-7029-1654-CF30-1474F87E9221}</Name><V alue>OPSMGR\sqlsvc</Value></Setting><Setting><Name>{661E621B-14AE-6B08-C446-2DAD 28E0A137}</Name><Value>R:\MSSQL10_50.I01\MSSQL\DATA\mastlog.ldf</Value></Setting ><Setting><Name>{7F98B94E-8BC2-68C1-7382-C0EA6C799B66}</Name><Value>Enterprise E dition</Value></Setting><Setting><Name>{8C5D6C49-5D3A-CBB2-9511-B4499B8852DD}</N ame><Value>Windows Authentication Mode</Value></Setting><Setting><Name>{98A83214 -A0BF-C211-D8F1-B66666AED2BA}</Name><Value>SQL SERVER AGENT (I01)</Value></Setti ng><Setting><Name>{A7B48BC8-AA75-3455-6826-CC19E91D2595}</Name><Value>False</Val ue></Setting><Setting><Name>{AE29AF8B-F227-E771-5D19-DCCC19F010D1}</Name><Value> 10.52.4033.0</Value></Setting><Setting><Name>{BCC39E48-D267-5E38-A7BE-1584612B72 EF}</Name><Value>SQL Full-text Filter Daemon Launcher (I01)</Value></Setting><Se tting><Name>{C58E9D6A-79BB-BB78-E716-005784E4333D}</Name><Value>SQLAgent$I01</Va lue></Setting><Setting><Name>{C6565411-D577-58AA-3106-248668ECF9D7}</Name><Value >MSSQL10_50.I01</Value></Setting><Setting><Name>{D18EE4A4-4328-FDEC-5B7A-3F4469C 66E2B}</Name><Value>R:\MSSQL10_50.I01\MSSQL\repldata</Value></Setting><Setting>< Name>{D260D148-9F4F-ADDD-BC1F-E358E6D1B7E8}</Name><Value>1033</Value></Setting>< Setting><Name>{DE27A276-075D-4222-733D-02C6B8E5DB3F}</Name><Value>N/A</Value></S etting><Setting><Name>{EFEADD8E-94E6-D58A-6BEF-39FD68095A77}</Name><Value>R:\MSS QL10_50.I01\MSSQL\Log\ERRORLOG</Value></Setting><Setting><Name>{F3100DCA-9AE3-8C D1-1E3C-E957133E04A6}</Name><Value>Failure</Value></Setting><Setting><Name>{F9B1 47D1-052E-5488-219F-A5B9F2227526}</Name><Value>c:\Program Files\Microsoft SQL Se rver\MSSQL10_50.I01\MSSQL</Value></Setting><Setting><Name>{FA2BAA42-B88C-CAFE-28 0A-D5999ADC3904}</Name><Value>SQLCLUS01\I01</Value></Setting><Setting><Name>{FD6 38451-D610-E995-3B2C-FB74B84A98A9}</Name><Value>c:\Program Files\Microsoft SQL S erver\100\Tools</Value></Setting></Settings></ClassInstance></ClassInstances></DataItem> Now - go back and start at the beginning. :) From: [email protected] [mailto:[email protected]] On Behalf Of Steve Wouden Sent: Tuesday, July 7, 2015 7:57 AM To: [email protected] Subject: [msmom] DiscoverSQL2008DBEngineDiscovery.vbs running against SQL Management node instead of SQL Resource name SCOM 2012 R2. Wk2R2 SQL Cluster. I use the quick and dirty solution. Action Account has SA rights. No Runas Accounts. Few days ago I noticed the instance/DB on the SQL cluster are not discovered. Took me almost a day to get this right http://blogs.technet.com/b/kevinholman/archive/2010/03/09/basic-troubleshooting-of-discovery-scripts.aspx Did not know which part of the XML file to copy, but with help I succeeded. I then manually ran the script. Everything looks fine. No errors. I found this article to use process monitor to check Run As Account permission https://sqlmate.wordpress.com/2012/09/15/database-engine-and-databases-not-discovered-by-scom-2012/ What I did found with this nice troubleshooting tip, was that the DiscoverSQL2008DBEngineDiscovery.vbs script was running against the Management node instead of the SQL Networkname [cid:[email protected]] I don't know if this is a cluster or script related issue. Thanks. Steve Wouden T +31 20 546 0243 M +31 6 531 750 78 F +31 20 546 07 05 [email protected]<mailto:[email protected]> [http://www.stibbe.com/~/media/6%20stibbe%20logo%20email%20disclaimer/stibbe%20disclaimer%20logo]<http://www.stibbe.com/> Amsterdam - Brussels - Luxembourg - Dubai - Hong Kong - London - New York Visitors address: Strawinskylaan 2001 - 1077 ZZ Amsterdam - The Netherlands Postal address: P.O. Box 75640 - 1070 AP Amsterdam - The Netherlands This e-mail may contain privileged or confidential information. If you have received this e-mail in error, please notify us immediately. Stibbe N.V. is a Dutch law firm registered with the Dutch Chamber of Commerce under number 34198700. Any services performed are carried out pursuant to an agreement for services ('overeenkomst van opdracht') with Stibbe N.V. This agreement is governed exclusively by Dutch law, with the exception of rules of Dutch private international law. All disputes shall be decided exclusively by the competent court in Amsterdam, The Netherlands, without prejudice to the right to appeal. The general conditions of Stibbe N.V., which include a limitation of liability, apply and are available on www.stibbe.com/generalconditions<http://www.stibbe.com/generalconditions> or upon request. Stibbe N.V. is part of an international network of Stibbe offices in Amsterdam, Brussels, Dubai, Hong Kong, London, Luxembourg and New York. More information about us and our services can be found on www.stibbe.com/importantinformation<http://www.stibbe.com/importantinformation>. Before printing this e-mail, please consider the impact on the environment.
