Somewhere back in 2017, I wrote this article for our internal Knowledge Base, including a complex script, to support giving insight into where something goes in the wrong direction, so the trained eye could easily recognize connections and maybe find a root cause.... I had to remove some of the links as they would not work for external readers.
Since the release of Snow Inventory 5 we got plenty of issues with Clients between Snow Inventory and Snow License Manager.
The last few weeks I was more hunting down this issues than doing anything else. Source of all this is the new function of deduplication, to handle multiple sources. But it worked too good for some of our Customers. Finally I found some Data in the Database to identify the potential Clients in Danger.
Attached you will find a Script, which could be used after the migration, to adjust the hostnameonly function or identify issues in multi-source environments.
How it works
Snow Inventory Server creates "Identities" for the incoming Inventory Files. You can read here "Getting the most out of the new "Hostname only mode" in Inventory Server 5.1.7", which properties are used for an identity. The Server looks the identity up, if it has a perfect match, nothing happens with the identity. If one parameter changes, the Value "IdentityUpdateCount" in inv.AgentManifest raises by one. if there is no match so far, it will create a new Identity and a new Computer. So if you have a Infrastructure around with Computers, all sharing the same Biosserialnumber and MachineSID, Snow Inventory is able to handle them all on one Dataset. With the Hostnameonly mode, available since SI5.1.7, this could be corrected.
The second Value, which is used from the script, is the check, how many Inventoryfiles were handled during the last seven days for a specific Client. Per default our Agent should send one File per Day. Of course it could happen, that there are more Files and it would be normal, but every thing other than our primary / secondary Data Source (check "How Inventory 5 server combines data from multiple sources" ) combinations should be avoided.
So concluding, a high "IdentityUpdateCount" (my favourite had here 100.000 + on one Computer) plus many handled Files => looks more than suspicious.
You can adjust the @identitygap value at the top of the script. If the customer had several attemps to switch the datasource, it could happen, that it grow thru the time.
The columns identity-... shows you, how unique the used values are.
The computers with the top counts in identity-hostname are at the top, followed by the most processed files during the last 8 Days, followed by the Computers with the highest ununique Biossn / machinesid combination. NULL Values gives an extra Boost.
At the end of the scripts I added some lines, to allow you start evaluating what's wrong.
Analysing the Data
Directly after a SI3 to SI5 Migration the Identity Update Count should be 0, if not this will produce orphaned Computers in Snow License Manager.
During normal Processes, the Identity Update count could rise. i.e.
- the Computer is renamed
- the Agent delivers more data after an update
That shouldn't happen so often per Computer. I think...
Unnormal Processes could be:
- too less unique identifiers with no good or no "Hostnameonly" configuration
- multiple primary Inventory Sources (i.e. SCCM and Snow Inventory Agent)
During normal Processes, the Filecount per week could rise. i.e.
- the computer was Offline a long time, and send a bunch of inventory Files at once.
- Microsoft Windows Server can be inventoried via a Agent/3rd Party Inventory and our Hyper-V Scanner.
During non normal processes, the filecount per week could rise i.e.
- Multiple primary Inventory Sources (i.e. SCCM and Snow Inventory Agent)
Hope that helps, Oliver
31.10.2017 - Added a colum to show, if the "Hostnameonly" mode was applied for this Identity.
25.10.2019 - added notes and slm9 support in the further troubleshooting lines and added scope variable to control depth of scan