Basic troubleshooting of SCOM discovery scripts

Do you ever get script errors from a discovery scripts?  Or you aren’t discovering something that you feel should be discovered?

 

There are many ways to troubleshoot this discovery process, this will cover the “basics”.

First thing I like to do – is start with the console.

 

1.  Find out what class your discovered object is missing from.  I will use SQL 2005 DB Engine as an example.

2.  Find out what discovery “discovers” this object.  Fairly easily – we can see that this discovery is “Discover SQL 2005 Database Engines (Windows Server)”

3.  Find out what class this discovery targets.  From looking at the discovery – we can see that this discovery targets the “Windows Server” class.

 

Start there!  So – now go to the console, Monitoring, Discovered Inventory, and change to the “Windows Server” target.  MAKE SURE that the agent or virtual cluster you are expecting this SQL engine to be discovered on – is present, and healthy.  If not – there is no need to troubleshoot the discovery further… you need to fix what’s busted on the actual agent.

 

Ok – we have a good present and healthy target class instance.

So now – we could continue with the discovery troubleshooting.  One of the easiest things to do – to find out the script that is discovering this object, is to search for something like *sql*.vbs on the agent’s health service state folder.  You might get lucky and find that sucker.  If not… then you can export the SQL 2005 discovery MP, and search the XML for your discovery name, then locate the discovery script in the XML, to find the script name, and get a copy of it for testing.

I find the script using a quick search, and it is named DiscoverSQL2005DBEngineDiscovery.vbs

 

So what we want to do at this point – is to run the script manually from the command line, and see what it is returning.  Best thing to do at this point is to copy the script to a local folder to make this easier when working with the paths.  I will use C:\temp as my examples.

So I copy the script to C:\temp\DiscoverSQL2005DBEngineDiscovery.vbs

 

Next up – we need to figure out the correct command line to get the script to run with success.  Pretty much most discovery scripts will look like this:

C:\temp\cscript /nologo scriptname.vbs {GUID} {GUID} param3 param4 etc….

I will explain:

“C:\temp\cscript /nologo scriptname.vbs” is just calling which script to run

After we call the script – we have to pass the required script parameters that SCOM would pass to each discovery script – otherwise the script will just bomb out.  To know which params, or how many, to pass – you should open the script and look for the arguments.  In this example – its easy – because the script comments at the beginning tell us:

‘ Discover instances of SQL Server 2005 DB Engines 
‘ Targeted at Windows Server class – takes 4 or 5 arguments 
‘ Works agentlessly and against Virtaul servers (Wolfpack cluster) 
‘ Arg 0 : SourceID 
‘ Arg 1 : MP Element ID 
‘ Arg 2 : Computer ID 
‘ Arg 3 : FQDN 
‘ Arg 4 : NETBIOS Name (required for clustered SQL discovery) 
‘ Arg 5 : Exlcuded instance list (prefixed with Exclude:) 
‘ Arg 6 : Optional Boolean – true indicates this is a virtual Windows server (Wolfpack)

So we need to pass:

• SourceID – simply a GUID
• MP Element ID – another GUID
• Computer ID – a FQDN
• FQDN – a FQDN
• NETBIOS name – the netbios name of the agent or virtual cluster name
• Excluded instances – something specific to this script
• Optional Boolean – something specific to this script

Now – that’s all complicated… let me show a working example:

C:\temp>cscript /nologo DiscoverSQL2005DBEngineDiscovery.vbs {00000000-0000-0000-0000-000000000000} {00000000-0000-0000-0000-000000000000} sql1v1.opsmgr.net sql1v1.opsmgr.net SQL1V1 Exclude: true

So – for the GUID’s I just pass dummy guids of {00000000-0000-0000-0000-000000000000} because since we aren’t handing these off to the management server – we don’t have to know the real id’s involved.  We are just trying to get the discovery to run and output what it WOULD have sent up as discovery data.

sq1v1.opsmgr.net is the name (FQDN) of my virtual cluster SQL server.

“Exclude:” and “true” are just required parameters in this case.

 

The goal here is to get the script to run manually – and see if it throws an error, or returns the expected data.  For instance – when I run this manually on my SQL cluster, and provide the correct parameters, I get to see how long this discovery script actually takes to run, and then get to see the output:

 

C:\temp>cscript /nologo DiscoverSQL2005DBEngineDiscovery.vbs {00000000-0000-0000-0000-000000000000} {00000000-0000-0000-0000-000000000000} sql1v1.opsmgr.net sql1v1.opsmgr.net SQL1V1 Exclude: true 
<DataItem type=”System.DiscoveryData” time=”2010-03-09T10:02:06.1500082-06:00″ sourceHealthServiceId=”E174B0FE-5FDF-1A8A-332D-DAED449F3B40″><DiscoveryType>0</DiscoveryType><DiscoverySourceType>0</DiscoverySourceType><DiscoverySourceObjectId>{00000000-0000-0000-0000-000000000000}</DiscoverySourceObjectId><DiscoverySourceManagedEntity>{00000000-0000-0000-0000-000000000000}</DiscoverySourceManagedEntity><ClassInstances><ClassInstance TypeId=”{8B0E4E41-3B39-8589-C7FE-2DA7EE6BAB39}”><Settings><Setting><Name>{5C324096-D928-76DB-E9E7-E629DCC261B1}</Name><Value>sql1v1.opsmgr.net</Value></Setting><Setting><Name>{0F700489-D513-FC14-2FE1-B514BC789F42}</Name><Value>I01</Value></Setting><Setting><Name>{AE29AF8B-F227-E771-5D19-DCCC19F010D1}</Name><Value>9.3.4035.00</Value></Setting><Setting><Name>{7F98B94E-8BC2-68C1-7382-C0EA6C799B66}</Name><Value>Enterprise Edition (64-bit)</Value></Setting><Setting><Name>{8C5D6C49-5D3A-CBB2-9511-B4499B8852DD}</Name><Value>Windows Authentication Mode</Value></Setting><Setting><Name>{3BBDDDF9-1F49-4334-8759-B0D9461B9A1A}</Name><Value>K:\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\master.mdf</Value></Setting><Setting><Name>{661E621B-14AE-6B08-C446-2DAD28E0A137}</Name><Value>K:\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\mastlog.ldf</Value></Setting><Setting><Name>{EFEADD8E-94E6-D58A-6BEF-39FD68095A77}</Name><Value>K:\Microsoft SQL Server\MSSQL.1\MSSQL\LOG\ERRORLOG</Value></Setting><Setting><Name>{D260D148-9F4F-ADDD-BC1F-E358E6D1B7E8}</Name><Value>1033</Value></Setting><Setting><Name>{202341AA-8ABE-0427-96D3-B91D612CF6C8}</Name><Value>3</Value></Setting><Setting><Name>{F3100DCA-9AE3-8CD1-1E3C-E957133E04A6}</Name><Value>Failure</Value></Setting><Setting><Name>{F9B147D1-052E-5488-219F-A5B9F2227526}</Name><Value>c:\ProgramFiles\Microsoft SQL Server\MSSQL.1\MSSQL</Value></Setting><Setting><Name>{FD638451-D610-E995-3B2C-FB74B84A98A9}</Name><Value>c:\Program Files\Microsoft SQL Server\90\Tools</Value></Setting><Setting><Name>{A7B48BC8-AA75-3455-6826-CC19E91D2595}</Name><Value>False</Value></Setting><Setting><Name>{D18EE4A4-4328-FDEC-5B7A-3F4469C66E2B}</Name><Value>K:\Microsoft SQL Server\MSSQL.1\MSSQL\REPLDATA</Value></Setting><Setting><Name>{DE27A276-075D-4222-733D-02C6B8E5DB3F}</Name><Value>N/A</Value></Setting><Setting><Name>{FA2BAA42-B88C-CAFE-280A-D5999ADC3904}</Name><Value>SQL1V1\I01</Value></Setting><Setting><Name>{19A96D5F-2D87-E1A5-38F3-A09A42830D07}</Name><Value>MSSQL$I01</Value></Setting><Setting><Name>{197D70B5-0429-5C8F-E11E-50B1CE5BBE30}</Name><Value>MSSQL$I01</Value></Setting><Setting><Name>{21CC0652-0CF6-84DB-2245-0CAA483EE2D9}</Name><Value>SQL SERVER (I01)</Value></Setting><Setting><Name>{4DDAC64C-C6E2-362A-2BC1-C1CB98AA95FF}</Name><Value>MSFTESQL$I01</Value></Setting><Setting><Name>{BCC39E48-D267-5E38-A7BE-1584612B72EF}</Name><Value>SQL SERVER FULLTEXT (I01)</Value></Setting><Setting><Name>{C58E9D6A-79BB-BB78-E716-005784E4333D}</Name><Value>SQLAgent$I01</Value></Setting><Setting><Name>{98A83214-A0BF-C211-D8F1-B66666AED2BA}</Name><Value>SQL SERVER AGENT (I01)</Value></Setting><Setting><Name>{078C975B-6B4B-7ED1-678F-ECB81FAA00CC}</Name><Value>True</Value></Setting><Setting><Name>{61D68FF0-7029-1654-CF30-1474F87E9221}</Name><Value>OPSMGR\sqlsvc</Value></Setting></Settings></ClassInstance></ClassInstances></DataItem>

 

Now – this was a complicated example – but it showed the use of lots of parameters.  There are much simpler discovery scripts… and if we are using this process to troubleshoot script errors – you can use the script error alert to help here:

For instance – If you are getting a repeating script error alert for a specific instance or script – you can use this method to troubleshoot why it is failing, or confirm the output on the command line.  You could also now modify this copied script with statements to stop on errors, and output the data to the command line.

 

Like I said – this was a basic approach.  There are much deeper levels of troubleshooting to take with this – you can see Stefan Stranger’s post on this for some more ideas and steps:

http://blogs.technet.com/stefan_stranger/archive/2010/03/10/basic-troubleshooting-discovery-script-follow-up-on-kevin-s-post.aspx