Discovery of MSSQL Database Instances

[syddent]

I am new to discovery. Below looks like a credential issue, but I am wondering if I do not have the right problem.

I have run discovery in my environment. I find the host machine and the software that is running on that host machine. I find MSSQL Server running on the machine. However discovery does not find the instances on the MSSQL Server.

The following message shows up in the ECC queue

<?xml version="1.0" encoding="UTF-8"?><results probe_time="13108" result_code="0"><result><error>Authentication failure with the local MID server service credential.</error><error>Failed to access target system.   Please check credentials and firewall settings on the target system to ensure accessibility: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))</error></result><parameters>

If this is a credential issue, does someone have a hint on what needs to be present besides a Username and password?

Thanks

Sydney Dent

[doug_schulze · Accepted solution]

Sydney,

Have you gone through all the requirements for discovering the SQL instance?

Discovering Microsoft SQL Servers

[syddent]

I have gone through the documentation. I am working in a small company and we are not using Active Directory or have a network domain set up. So my discovery of the Database remains a problem.

I can see the DB instances in the XML. However the tool is not able to parse/read the MS SQL schema tables.

thanks for you answer

[saadit]

doug.schulze I got the SMO library loaded and am able to discovery MSSQL instances. My question is, I was able to discover the instances before loading the SMO library. When comparing the CI before and after loading of the SMO library, I'm not finding anything different. Is there any lower level details on the instances that should be getting discovered like disk space allocated to each instance?

[jeremy_perdue]

This answer is a bit late, but hopefully it is helpful to someone out there.

When you Discovered the Instance before installing the SMO on the MID Server, it was probably just the Instance name without the version or other details.

The way a SQL database is Discovered on a machine is via a Process Classifier (Process Classification). Basically, while ServiceNow is interrogating the Windows Server, it checks running processes. If it sees sqlservr.exe running, it "Triggers Probe" Powershell-Windows - MSSQL to interrogate. If permissions are not in place on the SQL side, it will still create the SQL Instance CI, but not know anything else about it such as Version, Engine Edition, Service Pack, etc.

During a recent implementation, we saw the same thing before the SMO was installed. My guess Saadi, and it is only that, is once SMO was installed, the proper permissions were not in place to collect the extra data points and I would start there. Check the Discovery Logs and ECC Queue records and find the Windows - MSSQL (nodes: x) input record. (x being a number) If you are only seeing Windows - MSSQL without the (nodes: someNumber), drill into that record and you will probably seeing an authentication failure.

Note: SQL Server Management Objects (SMO) is a collection of objects that are designed for programming all aspects of managing Microsoft SQL Server.

Discovering Microsoft SQL Servers

Best Regards,

Jeremy Perdue, ServiceNow Consultant | Contender Solutions