SCCM Hardware Inventory frequently fails to assign Re-Sync policy upon Delta Mismatch

Question

I've been tearing my hair out running down this rabbit hole. I will try to list the state of my current troubleshooting, since I have chased many a red-herring on this. I have checked every article I can find about hardware inventory and its troubleshooting and all I can find about Re-sync is the general assertion that the SMS_Inventory_Data_Loader is supposed to assign a Re-Sync policy to the client object when it encounters a Delta Mismatch (Client Sends a Delta Inventory Report that is too new to be processed). I have determined that the data loader is often NOT assigning this Re-Sync policy. Triggering a Full Hardware Inventory does get processed with no issue, its just that the dataloader never assigns the policy using sp_RC_InvResync.sql.

I have parsed the appropriate logs from the client side all the way to the data loader. Here are all the logs I have verified:
Client:
InventoryAgent.log
CcmMessaging.log

MP:
MP_HWInv.log

Site Server:
Dataldr.log

I have confirmed that the InventoryAgent.log shows the client starting a {00000000-0000-0000-0000-000000000001} inventory task, completing without errors, other than some hardware classes not found, but nothing terminating. I have confirmed Agent sends the report to the MP.

I have confirmed the MP receives the report and sends the MIF to the site server. Possible Red-Herring, but I do see many error messages in MP_Hinv.log that state that "Date property year value is less than 1980 - 16010101000000.000000-000; year will be adjusted by MIF processing on site server" but I can confirm that the incoming MIF file has the corrected dates in them.

The data loader then begins processing the MIF, begins the transaction, throws the Delta Mismatch warning, code 7, rolls back the transaction, exec's spAddInventoryLog, States that it cannot process the MIF and moves it to inboxes\auth\dataldr.box\ToProcessMIFS\DeltaMismatch. The data loader finally states Done with code 408.

By comparison, when I look at an example where the loader DOES add the resync, dataldr.log includes these two lines:
Remote client hardware inventory resync generated for client GUID:---; update/insert result = 2

Send resync command to local site for machine GUID:---.

In my testing, I have found that the Data Loader does succeed to add the assignment if sp_checkHWinvReportVersion returns code 9 for a major version mismatch (or at least I havent encountered a case of it failing on this code. Possible Red-Herring), but it is very inconsistent at adding the assignment on the more common return code 7 for a missed minor version mismatch.

I see sp_RC_InvResync.sql and sp_checkHWinvReportVersion have read their procedures and I have been monitoring the database dbo.InventoryLog as well as joining dbo.ResyncPolicy with dbo.ResPolicyMap and dbo.PolicyAssignment to monitor when the Re-sync has been assigned.

I have circled around this issue and scoured for more details about what other logic might be at play here, but I cannot find anything detailing a case where the dataloader is NOT supposed to add the resync policy. This is causing my devices to very frequently fall out of sync with my Site Server, causing hardware Inventory to basically halt until I force a full Inventory.

Answer 1

does the problem go away when you force a full hw inv?

Answer 2

As far as I know, this (relatively) new functionality isn't documented. While investigating this, I also noticed that files seem to stay in the ToProcessMIFs\DeltaMismatch folder for longer than expected. It appears that files are only deleted from this folder three days after their "Date created", which is the date and time the file arrived on the site server. The "Date modified" for these files is the date and time they were generated on their respective clients. If a client has been unable to connect to its management point for whatever reason, the "Date modified" for a hardware inventory report file can be significantly earlier than the "Date created".

To my knowledge, there is no setting that can be used to change this behavior and/or the delay period. Information about all this is logged in the DataLdr.log on the site server:

• Newer version found after processing a MIF: "Found MIF <GUID>_<MajorVersion>_<MinorVersion>.MIF, moved it to <InstallationFolder>\inboxes\auth\dataldr.box\ <FileName>.MIF"
• No newer version found after processing a MIF: "Cannot find MIF with next version"
• Cleanup: "Deleting bad MIF files over 3 days old..."

Answer 3

As of ConfigMgr 2107, hardware inventory delta mismatches no longer immediately result in a resync request. Instead, the mismatched delta inventory report is moved to the new ToProcessMIFS\DeltaMismatch folder. The report stays in there for a maximum of three days. If the missing delta report is received and processed successfully within that time period, the mismatched report in the ToProcessMIFS\DeltaMismatch folder is processed as well. After three days, reports are deleted from the ToProcessMIFS\DeltaMismatch folder, and resync requests are generated for the affected clients.

Answer 4

Well, depends on how you define "go away". If I send the full inv, yes the client succeeds at executing it and the data gets loaded, no issue. the issue is that this doesnt stop the devices from potentially fall back out of sync in the future.

Answer 5

How long until it fall out of sync again (24h, week, month, year)? Are you using Blackhole or something like it? Have checked for duplicate guids?