Discovery and CI Identifier for MSSQL instances

[klautrup]

Hi,
We want to ensure new Server CIs and DB Instance CIs are created manually and then afterwards when deployed enriched by Discovery.

For Server CIs Discovery uses the ootb CI Identifier "Hardware Rule" which ensures a match on 'name' thus Discovery merges with the manually created Server CI with that same name.

However, for MSSQL instances in MSFT SQL Instances (cmdb_ci_db_mssql_instance) all though there is an ootb CI Identifer "MS SQL server" matching on sys_class_name + instance_name:

Discovery does not merge with a manually created CI in that table all though there is a match on field instance_name.
Instead Discovery creates a duplicate CI and relates that as Runs On to the Server CI and Contains to the Database CIs:

In the CI Identifier I tried adding a match on the 'Name' field with higher priority:

But same result Discovery creates a duplicate.

How do I get Discovery to match with manually created SQL Instance CIs?

[DaveHertel]

Hello,  It seems you've investigated all the right pieces (and did a very nice job explaining your situation too...!).  Based on what you've described, the identifier to match on instance name appears correct. To troubleshoot, consider adding the glide system property glide.discovery.debug.classification to add debugging to logs.  Then rerun discovery of the machine then use the Node Log File Browser to see the classifier payload.. which will tell you how the machine & software is getting classified (or not classified...).  It might provide some clues for the next disco phase (identification)...

Also, to Discover SQL instances, ensure you've setup the MID server properly to explore catalogs, instances, etc.   The MID must have powershell, the Common Language Runtime (CLR) and MS SQL mgmt library, plus SQL credentials for the SQL instance.... all of which allows the MID to interrogate the SQL metadata on the machine.

MS SQL docs

Hope this helps?  

[robertgeen · Accepted solution]

This is more then likely happening because your manually created instance doesn't have a relationship to the Server. The identifier for MSSQL isn't an independent one so when it does the lookup it also looks at what parent CI it is attached to. This way if you have multiple instances with the same name on different servers you will still get unique CIs. Check to see if there is a relationships to the server (should be runs on relationship) and if there isn't you will need to have that in place for it to identify correctly. Thanks.

[DaveHertel]

Good call Robert, thank you 🙂     Indeed the dependency of the CI rule for SQL instances requires an existing relationship to the dependent CI

FYI: More about Dependencies (from CMDB identification rules docs):

Dependent identification rule  A rule in which identifying a CI requires identifying a dependent CI first. A CI can have dependency on one or more CIs, and a dependent CI can have only a single parent CI with dependency. The relationship types between the CI and its dependent CIs are also included in the identification process. To help with the identification process of dependent CIs, create dependent relationships that define the dependency chain within CI types.

The payload used for identification of a dependent CI, can include a relationship with a qualifier chain. For such relationship, if there is a matching parent/child pair, the system compares the qualifier chain in the payload, with the qualifier chain of the CIs in the database. If there is a difference, the qualifier chain in the database is updated to match the qualifier chain in the payload for that relationship.

[robertgeen]

/flex. This has bitten me in the butt many a times haha. Klautrap if this answers your questions please mark my post as the answer. Hope this fixes things for you :).