Discovery of Active Directory and "Computers not inventoried" report

Discussion created by MarcoCambon on Apr 10, 2019
Latest reply on Aug 1, 2019 by Samuel


I'd like to share my experience while trying to find the cause of some missing computers in the "Computers that are not inventoried" report.


This report is empty unless you enable a discovery data source.

Enabling active directory or network discovery from snowinventory server provides a comparable list of computers that, together with the list of agent inventoried machines, produces the list of "not inventoried computers".


To achieve that, Snow tries to match every single computers coming from the discovery source with the ones coming from the normal agent (or SIM connector) source.
This is a tricky task because data are originated from different sources like an agent installed inside the machine and records of an ActiveDirectory database.


Unfortunately we found that the matching algorithm sometimes fails, at least for AD discovered computers.


Here's why.

Simplifing the workflow scheme:

ActiveDirectory discovery data are stored in [SnowInventory].inv.DiscoveryMetadata table.

Among other columns there's a clientID column that is not filled in by the data coming from the AD, but is filled by the [inv].[MapClientIdsToDiscovery] store procedure in turn called by the SnowInventory server through module SnowSoftware.Inventory.Discovery2.DiscoveryClientIdMapWorkerModule.

You can check how often this module runs (default 1 hour) by printing the snowserver running config with this command:


snowserver dmc


The clientId field of inv.DiscoveryMetadata is usually "null" and is filled with a valid and already existing clientId only if the metadata of the discovered computer matches one of the already discovered computers that are stored in the [SnowInventory].inv.AgentManifest table.

This means that if module DiscoveryClientIdMapWorkerModule recently completed its cycle and you run:


Select * from [SnowInventory].inv.DiscoveryMetadata where ClientID is null

you should see all the discovered computers that do not have a correspondant inventory entry and therefore are "eligible" to finish (once moved to the SnowLicenseManager DB) in the above report.



Why we said that this match is not always reliable?

   Because I've found several rows (500/600 over 10.000-12.000) in the inv.DiscoveryMetadata table that should have    a null value in the ClientId field (=discovered but not inventoried) that has a ClientId instead.

How do I know they should not have a ClientId?

   Because the row metadata (hostname) does not match the metadata (hostname) of the inv.AgentManifest table.


You can easily prove it with:


SELECT dm.ClientId AS dmClientId, dm.SiteName, dm.IpAddress, dm.HostName AS dmHostname
FROM inv.DiscoveryMetadata dm
LEFT JOIN inv.AgentManifest am ON dm.HostName = am.HostName


At which stage is this wrong ClientID written?

As far as I can see it's written while module DiscoveryClientIdMapWorkerModule is running, but the mistake comes from the join of two tables both having 'weird' rows that -in my opinion- should not be there.

1) Table DiscoveryIdentityLookup conatins some 'weird' entries:

that are probably inserted while processing a discovery snowpack data.

The lookup field is used to match the topology string built with the AgentManifest table metadata.

Cells of the topology "lookup" field are separated by "/" character and have identical configuration in Identity tables all over the SnowInventory DB:

Cell1: type of identity (d = discover, a= agent, s= server, u=user)

Cell2: sitename

Cell3: hostname

Cell4: MAC address

Cell5: IPV4 address


As you can see all the above lookup strings contains only the sitename and the IPAddress.

This is the very cause of the mistake: snow should not rely on a sitename+ipaddress to match two IP address...can change.


2) When module DiscoveryClientIdMapWorkerModule runs, you can see these queries scrolling in the profiler:

These are the topology strings created on the fly from the AgentManifest table and even here you can see that the metadata do not include the hostname.


What happens finally is that the match between those two tables is made through the Sitename+IPAddress that, as you can guess, may change over time.

In fact, as in this example, the association is wrong.

This query retrieves the AssignedIDs of the DiscoveryMetadata row that is to be filled with the ClientID coming from the AgentManifest. 

...but the hostname of the DiscoveryMetaData table is different from the one in the AgentManifest:


this proves that the match was wrong.


In fact computer PMSMSQL01 is not an inventoried one.



The cause of missing computers in the "not inventoried computer" is wrong records in both DiscoveryMetadata table and in table generated on-the-fly (called @p4) during the DiscoveryClientIdMapWorkerModule execution.

Fixing this requires a review of the snowserver code by Snow. (probably the SnowSoftware.Inventory.Identity.dll).


Any comment is welcomed.


kind regards