Software Suite Structure and Software Model relationships

[jfortenbaugh]

@SrinivasRamanu1 

I've attempted to research relevant ServiceNow documentation/training, YouTube videos, and forum posts for clarification on multiple SAM reconciliation topics.  Are there suggested resources that expand on SAM topics to assist in troubleshooting efforts?  Some that provide detailed best practices?

Any assistance with the following is greatly appreciated.

Assumptions:

1. Software installation data is discovered and compiled in the software installation table

2. SW discovery models determine discovered SW publisher, product, version, and edition from the raw data provided by discovery sources (mid server, SCCM, etc)

   a. Normalization is necessary to ensure all relevant discovery models are configured for the correct publisher, product, version, edition, software model

3. SW models utilize discovery maps to identify the software publisher, product, version, and edition

   a. Within SW models, products are organized by child/parent suite structure for reconciliation and license compliance

4. SW entitlements contain license data, such as rights, license metric, software model, etc

5. Device and user allocations consume rights from active SW entitlements

6. Reconciliation uses SW installation data, refined by SW discovery models and related to SW models, to determine:

  -- Allocated in use (licensed installs)

  -- Not allocated in use (unlicensed installs)

  -- Allocated not in use (Device/User allocations with no related installs?)

  -- Not allocated (rights/licenses available for use)

  -- Allocations needed (number of allocations to create from named license metrics)

Questions

1. Discovery model SW model field is not mandatory. If populated, does ServiceNow force the relationship?

2. SW model suite structure - should products be structured in multiple levels or a few levels?

  -- i.e. Windows Server > WIndows Server 2019 > WIndows Server 2019 Standard > Windows Server Standard

  -- Or list multiple versions as children directly to the parent (Windows Server Standard)

       --- Windows Server, Windows Server 2019, Windows Server 2019 Standard, etc

3. Are there detailed reconciliation best practices available?

4. There are instances where similar installation records are processed differently.  I'm left speculating when there's no clear and obvious reason for the reconciliation results.  I've isolated 2 similar records that produced separate results.  I reviewed every available column within the SW installation table to determine the root cause with no luck.  I speculate that there's additional data I cannot access that would provide further insight.

The same device reports Microsoft Windows Server 2019 Standard and Windows 2019 Standard installations.  What would cause an installation to show 2 versions of the same SW name?

- Both records are reconciled as Windows Server Datacenter licensed installs.

- Inferred Suite Level: 999

- Inferred Suite: Microsoft Windows Server Datacenter

- Discovery models: Microsoft Windows Server 2019 Standard 10.0.17763, Windows 2019 Standard

- Both Discovery models have the SW model set to Microsoft Windows Server 2019 Standard

- Entitlement: Microsoft Windows Server Standard

  -- License metric: Per Core (with CAL)

When reviewing the same Discovery model (Microsoft Windows Server 2019 Standard 10.0.17763) the list of associated device installations produces unequal results. 

Server A:

- Inferred Suite Level: 999

- Inferred Suite: Microsoft WIndows Server Datacenter

- License metric result: Per Core (with CAL)

- Is allocated: true

- Software model source: Calculator

Server B:

- Inferred Suite Level: 1

- Inferred Suite: Microsoft WIndows Server Standard

- License metric result: (empty)

- Is allocated: false

- Software model source: Automatic SMR creation

All other columns match.

1. Why does server B match to the correct Suite Parent, but the metric is incorrect?  Inversely, why does server A match to the wrong Suite Parent, but the metric is correct?

2. With a Suite Inference Level of 999, I would think the license metric would be blank since 999 tells there are issues matching to the correct suite.

3. What causes server B to have a suite inference value of 1 (correct suite parent), but no license metric?

4. How can I determine the difference between server A and B?

5. The "Is allocated" data is odd to me since neither devices have device allocations. It seems ServiceNow defines "allocation" for varying purposes that do not relate.

a. In the License Workbench, for the Windows Server Standard product, it shows "Allocations in use".  If there are no allocations created in the Device Allocation table for the Microsoft Windows Server Standard entitlement, I would have to assume the License Workbench "allocation" represents something else.

A few final questions for now...

1. I've noticed some discovery models have a naming convention outside of the expected standard.

- Discovery model name: Windows 2019 Standard

- Publisher: MIcrosoft

- Product: Windows Server

- Version: 2019

- Edition: Standard

Normally the title would reflect the Publisher Product Version Edition naming convention.  Is this caused by the software installation discovered record?  It seems to complicate things as there are no SW models with that naming convention.

 a. When creating a SW model for it, the result is Microsoft Windows Server 2019 Standard. Is this correct? Or is there a way to force the name to match the discovery model?  Understandably, I don't want to leave the Publisher blank and enter Windows in lieu of Windows Server for the product.  Is there a way to avoid the automatic naming after entering data in the fields or am I overthinking this?

2. Within the discovery model form, the "Automatically matched" checkbox is unchecked after manual normalization.  Is it best practice to have it checked?  What are the implications of it unchecked?  I haven't noticed any differences with reconciliation when it's either checked or unchecked.

[Stephen42]

Bumping up as I am also looking for a solution to this.

[Ivocosta01]

Also looking at this. 

[dreinhardt]

Hi @jfortenbaugh,

I'll try to answer your questions step by step, could also be in multiple postings.

Questions

1. Discovery model SW model field is not mandatory. If populated, does ServiceNow force the relationship?

2. SW model suite structure - should products be structured in multiple levels or a few levels?

  -- i.e. Windows Server > WIndows Server 2019 > WIndows Server 2019 Standard > Windows Server Standard

  -- Or list multiple versions as children directly to the parent (Windows Server Standard)

       --- Windows Server, Windows Server 2019, Windows Server 2019 Standard, etc

3. Are there detailed reconciliation best practices available?

4. There are instances where similar installation records are processed differently.  I'm left speculating when there's no clear and obvious reason for the reconciliation results.  I've isolated 2 similar records that produced separate results.  I reviewed every available column within the SW installation table to determine the root cause with no luck.  I speculate that there's additional data I cannot access that would provide further insight.

---

A1: Yes, it is part of the reconciliation process to assign the discovery model to the best matching software model based on all the logics, rules, conditions, etc.

A2: No, please do not add the same/more detailed product as a suite component. We did the same for Core Infrastructure Suite (CIS) to ensure all Windows Server Model are captured and it end up in not trustworthy data and the support recommend to remove the incorrect suite components.

Recommendation: Keep the suite components as close to the content data as possible

If you created a Windows Server Standard entitlement + software model, the reconciliation will add all other Windows Server software models (the more detailed ones with Version) to the generic model which is linked to an entitlement. If a Windows Server software model isn't linked, then it indicates that one of the necessary requirements is not met. For example, a condition or CI data for CPU, environment, etc. is missing.

A3: No

---

4. There are instances where similar installation records are processed differently.  I'm left speculating when there's no clear and obvious reason for the reconciliation results.  I've isolated 2 similar records that produced separate results.  I reviewed every available column within the SW installation table to determine the root cause with no luck.  I speculate that there's additional data I cannot access that would provide further insight.

The same device reports Microsoft Windows Server 2019 Standard and Windows 2019 Standard installations.  What would cause an installation to show 2 versions of the same SW name?

- Both records are reconciled as Windows Server Datacenter licensed installs.

- Inferred Suite Level: 999

- Inferred Suite: Microsoft Windows Server Datacenter

- Discovery models: Microsoft Windows Server 2019 Standard 10.0.17763, Windows 2019 Standard

- Both Discovery models have the SW model set to Microsoft Windows Server 2019 Standard

- Entitlement: Microsoft Windows Server Standard

  -- License metric: Per Core (with CAL)i

 A4: To answer this question I need a few more details. Could you please check the columns "Active" and "Discovery Source". SAMP includes a de-duplication to end up in only one active installation if data is provided by different sources. Do you import data from multiple sources, e.g., SCCM, Discovery ? Two installation records could also happend when the inventory system identifies multiple types of install records - Registry, SWID Tag, Filescan, Add/Remove

Before covering the last part of your questions. Could you please ensure you're reverted all changes you've made to suite components for your Windows Server Standard software model. Do you created the entitlement/software model based on a PPN or without? If created without, please ensure to use a DMAP when creating a software model.

Please share a screenshot of the two mentioned discovery models for better insights into the current situation. The discovery model name is not updated when the model is normalized, it's created based on the software installation record. Final status should be either "Normalized" by the content library or correct manually normalized. Please try to "Revert Normalization" to allow internal process to normalize it based on content data.

Best practice to create software models is 1) based on a PPN per entitlement, 2) based on a existing DMAP, 3) manually. You can check if the software model covers all discovery models by using the related link "show matching discovery models" it should include the mentioned discovery models.

Looking forward to your answer!

Best, Dennis

[SrinivasRamanu1]

@jfortenbaugh  Thanks for reaching out. I see very interesting and helpful questions here. It would really help if you can send me an email directly on this so we can have a meeting on it. email: srinivas.ramanujaiah@servicenow.com