Incomplete MSFT SQL Server Edition Information in Software Discovery Model
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-29-2024 03:52 AM - edited 02-29-2024 09:54 PM
This discovery model, "Microsoft SQL Server 2016 (64-bit)," doesn't specify an edition. We discovered 50 devices with this model installed.
We searched these 50 devices in the MS-SQL instances table (cmdb_ci_db_mssql_instance) and found multiple editions (Enterprise and Standard).
How can we normalize the discovery model "Microsoft SQL Server 2016 (64-bit)" when some devices have the Standard edition and others have the Enterprise edition?
search the same devices from MS-SQL instances table
Also without edition our SAM ELP will be incorrect. Please help!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-01-2024 01:31 PM
What was your discovery source? Some discovery sources may not find SQL Server edition. Here are some other things for you to look into / consider.
1.) Look into the machine record itself, and see if you have multiple installation records.
2.) If multiple software installations exist on the same machine, and one has an edition, the machine should ultimately show the correct license consumption, although you will still see these instances of "unlicensed install"
3.) Notice that these are manually normalized. That means that these will be "locked" to this model unless you receive a Suggested Normalization. Try to avoid this in the future.
4.) Investigate the real machine itself. You may have a installation of plain "SQL Server" that is what you are seeing, where the System Admin has an incomplete installation
5.) Open a SN ticket if this is for SN Discovery. Could be Discovery logs where the Discovery is incomplete, although since your SQL Instance is populated, this may not be occurring.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-03-2024 02:27 PM
Hi @Nurulaslah Anua,
as mentioned by @Ryan97 SQL Server edition detection is based on multiple set of data points to be checked and it depends on the discovery source. For SCCM, Tanium and others, it depends "if the tools is able to get these details" and the the second critial path is "is the integration able to put the data into the correct CMDB table."
For ServiceNow Discovery, they documented it quit well what steps and settings are required to ensure the SQL Server edition is discovered by ITOM -> Microsoft SQL Server and Cluster discovery (servicenow.com).
With the latest "probes and pattern" update we've increased our SQL server discovery quality a lot, especially in case of SQL Server components detection (requires Vancouver or later).
Next step is to check the discovery logs and identify why the edition step is not able to get the correct data.
Best, Dennis
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-08-2024 03:43 PM
Hi Dennis,
I spend too much time in reconciling SQL Server and the suite components. 🙂 I agree that the SQL Server discovery capability (especially component discovery) has improved alot in recent releases, but I don't believe there is a solution yet for discovering the editions of Reporting Services (even in W) but I would be delighted if you told me that I had my facts wrong in this regard!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-04-2024 05:11 AM
Ive done a bit of work on SQL Server discovery recently and for the most part it works as expected - that said i currently have an issue with 2016 where its not working as below (patterns 1.10.1).
When SQL Server is discovered on a device it runs the MSSQL DB on Windows Pattern - this collates all the process and edition data, and updates the MS-SQL instances table [cmdb_ci_db_mssql_instance]. In addition when this pattern runs it also runs a post script called 'Sync Installed Software' - this creates/should create a software installation in [cmdb_sam_sw_install] with the correct edition and version details - these software installs are identifiable by the field 'created by application pattern' = 'true'. This software record is then linked from the [cmdb_ci_db_mssql_instance] record.
So my suggestion is rather than worrying about normalising the 'Add/Remove Program' Discovery models, which do not contain this information, look for the software installs where 'created by application pattern' = true.
I believe these are the records that SAM Pro uses in reconciliation, but we don't use SAM Pro 😞
Hope this helps - Please mark as helpful if it does