Software Suite Structure and Software Model relationships

jfortenbaugh · ‎10-12-2023

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.

RKH · ‎03-25-2024

@

Srinivas Ramanu

, Software models without any subscriptions, discovery model or installation but created by system could you share some suggestion on how to investigate how these software models are created by system/admin and how can these be corrected?

dreinhardt · ‎04-25-2024

Hi @RKH

software models can be created by the following actions

- PPN based entitlement on-boarding will create the linked model with reference to the DMAP

- Downgrade rights per DMAP for each software model will create all linked models as well

- Suite components per DMAP will create models as well (e.g., Visual Studio is about 200 Suite components, as soon the Visual Studio model is created based on PPN or DMAP it will create all suite components as models)

Best, Dennis

Should my response prove helpful, please consider marking it as the Accepted Solution/Helpful to assist closing this thread.