Software Installations not showing in Licenses Required. (Inferred Suite interference?)

[Kelly Logan]

We are testing out SAM Pro on our Dev instance, have installed the Service Graph Connector for Microsoft SCCM as well as the Microsoft Publisher Pack. We also have Horizontal Discovery running, though we are set to rely on SCCM for software information. 
We have been getting Software Installations and Discovery models created, primarily from SCCM.
We imported a Microsoft License Statement and it created entitlements as expected, using PPNs. 
After reconciliation however, there seems to be a gap that is not immediately clear to me. 

(Note: I am using the Published Products feature, so only the currently needed products are being displayed.)

The primary question is - what determines the Licenses Required value? When there are many software installations connected, why would this be zero?

For example, Looking at Windows Server, the "Any Version and/or Edition" product listing, we see a User CAL for 93 Licenses, but 0 Licenses required. (No installs requiring action.)

If I look at the software model, "Microsoft Windows Server", I see that it is linking with 86 Discovery Models. So far so good.

If I then look at one of the Discovery Models with software installations, like "Windows Server 2022 Standard 10.0.20348", I see 82 Software Installations directly connected.

So, if 82 software installations are connected to a discovery model, which is connected to a software model, which is connected to an entitlement, why is that entitlement showing zero Licenses Required?

I noticed the Inferred suite/product and added it to the published products and that seemed to get all the license required connections.

But isn't a suite only supposed to be used if it's more advantageous licensing, and component licenses supposed to be used if none are available? 

Also, regarding the Installations requiring action - This is also odd and perhaps related. The Software Installs listed have many, many duplicate Discovery models for no reason I can discern. They are for the exact same version of Windows 10 or 11, but each software installation of the same version created a separate model for each. 

Each one is normalized, with the same values, but only one or two software installations each.

Shouldn't these all be sharing the same Discovery model? 

[dreinhardt]

Hi @Kelly Logan,

this is correct, detected CAL usage information gathered for Windows & SQL Server is not processed and it creates the need for a manual process to link the CAL data with the CAL usage data record linked with your software model. As mentioned above the new insights were introduced with Xanadu and I hope the feature will be enhanced with the next releases to automate the assignment.

If the system has installation information that can be used to determine usage, and it has the User CAL metric, both supplied directly by Microsoft, why don't these work together? Where specifically is the gap?

With the increasing use of remote access and streamed apps, I believe that installations are increasingly becoming less relevant as an indicator for a CAL. Even though it is not yet automated, I believe that the existing data can be linked to the CAL usage in a partially automated way using a flow/process, thus creating added value.

Best, Dennis

[Vladimir Yordan]

Hello @Kelly Logan , 
We were facing the same issues as in your case, so we raised a HI support case and met with SAM representatives. 
They explained a causation of missing installs would be (in our case) missing Downgrade rights on the Entitlements. What we did is we loaded our entitlements from Microsoft MLS and MPSA data without PPNs. Those caused no match in the content service's Software models and thus, not having downgrade rights and software suits to those Windows server software models. We resolved that by re-loading entitlements with PPNs and this matched to correct Models with Downgrade rights and Software Suits. An additional step was to add Install conditions to the models, as explained in this video: https://youtu.be/mK3vxJgUciQ?t=2 . It turns out as explained here, that Windows Server licenses fall under Visual Studio, and that piece of the puzzle we were missing.