As you (and many others) have identified, this is a concept that lacks implementation in SLM. I have given some considerable thought, and I haven't been able to find a solution within SLM.

The only solution I could come up with is to build a layer on top of SLM, a super set, in which I implement unique physical person resolution (considering one person can have multiple identities, and also the other way around that an account can represent multiple unique physical persons). Data enrichment with other sources (e.g. CMDB, on-prem AD/Azure AD, ...) possible, somewhat similar to Palantir Gotham in that the idea is that I should be able to drop in a new data source and play around with it easily in order to incorporate it. I have only played around with this, and neither have a fully implemented solution nor ironed out all wrinkles. But I have had this for a number of years now... Got a bit stuck on doing it in data vault - I did not halt myself so I tried to implement too much at once. If and when I have the time, or someone pays me to do it, I would continue...

We have implemented a solution using a custom field, filled out with an internal reference number for each user.

Then we use one of the 2 following solutions:

• We export usage data to Excel and manually merge users where necessary, we then calculate a number of required licenses that we set as a Custom Compare Value
• We schedule a daily PowerShell script to do the same as above but 100% automated, it generates a CSV file using the format ready to import into SLM, the script drops the file into the Import folder and the data on the SLM interface gets updated after the next compliance calculation

It can look a bit convoluted, but in the end, it is not as bad as it seems. Obviously, it makes it difficult to track individual users, but this can be solved if your script also generates a human-readable version of the data that lists each user by name for each app.

We have successfully implemented this solution for Microsoft RDS CAL requirements for example.

@carolai​ and others chiming in on this topic with your advice.

Just a kind reminder that you may also want to cast your votes on https://ideas.snowsoftware.com/ideas/SNOW-I-320 if you haven't already...

Thanks,

John Sorensen

Yes I also already voted for that, years ago 😒

The idea has enough votes, I think. Also a long time has gone by. Snow's Max Schönhuber already anwered 4 years ago, this is considered by Product management.

Because it still is not implemented, it unfortunately looks like Snow cannot implement that.

Meanwhile I think perhaps an additional field in a license could at least be used as workaround.

In any case we need 2 fields for quantity in a license, real license quantity and entitlement quantity.

That could be also used for Windows Server licenses, we always need to add the entitlement quantity (16), but cannot add the real license quantity ( 1 / 8)

That's why I already implemented a custom field to know the real license quantity, that helps for SA renewals.

In case of user licenses that perhaps could be used to add the real license quantity 1, and change entitlement quantity based on number of userid's of that user, so we can assign all userid's to that license and then compliance can be calculated correctly.

Yet for Visual Studio license assignments, I use a SQL script, that updates a custom field when a user has assigned a VS license and based on that custom field I use compliance exclusions. But this I can't do for all licenses with user metric, that why I asked for ideas.

But also @SamuelBaughan​  idea using powershell scripts or export/import could be helpful.