This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(166.4, 75%, 26%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EMT%3C/text%3E%3C/svg%3E)
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.
I'll run a test right now to see. Last time I tested on my local, it looked like it was around 24-48 hours. What is Blackhole?
Sorry deepfreeze.. https://www.faronics.com/products/deep-freeze/enterprise
Ah, I see. No, our devices have nothing like this.
Okay, so as far as the HW Inventory falling back out of sync, I think I have a problem related to issues with our internet based client devices throwing certificate related errors connecting to our WAN facing servers. I am still investigating that part (it appears to not be a simple expired cert, wrong cert binding in IIS, or an untrusted root) but this appears to be causing the internet based hw inventories to be ignored by the MP.
While I will be able to investigate and resolve this with time, I still need to fix this resync issue, which was, as far as I understand, designed to be a very elegant stop gap for an issue like this, since my internet based clients very frequently connect to VPN, becoming internet based clients, so the resyncs should have been able to keep them up to date. Any ideas, specific to resync?
You can do something alone the lines of this.
https://askgarth.com/blog/how-to-avoid-receiving-inventory-re-sync-requests-for-snapshot-vms/
Create a batch file which triggers a full inventory of your devices. and run it daily or weekly.
Well, thats certainly a good piece of info. Thank you for that, I didnt find that in any of my reading about this. However, I can see that my ToProcessMIFS\DeltaMismatch does appear to have almost a month worth of mifs in here. Is there a console or registry setting that governs this delay period? Additionally, where is the processing of these ToProcessMIFs logged?
Hello Mitchell, i know this is a older thread but maybe you are reading.
We have investigated the same issue in our enviroment. There is often no resync policy triggered on a deltamismatch of the delta hardware inventory. Have you ever found a solution that a resync gets triggered on "WARNING - Attempting to resync due to missed delta reports (sp return code = 7)" ?
BR Bernd
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(220.8, 19%, 31%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EG%3C/text%3E%3C/svg%3E)
You can do several tricks if you like it will depend on how much work you want to do to fully automate this.
For example,
What I do is not fix the problem at the server (because yeah, don't have a solid fix for THAT). What I do is a modification of this routine: https://tcsmug.org/blogs/sherry-kissinger/515-configmgr-refreshservercompliancestate-as-a-configuration-item
That is a randomizer configitem for refreshServerComplianceState. But I take that, and change a couple of lines, basically remove the two lines for SCCMUpdatesStore, and replace it with one single line:
[wmi]"Root\ccm\invagt:InventoryActionStatus.InventoryActionID='{00000000-0000-0000-0000-000000000001}'" | Remove-WMIObject
(and then also change the write-eventlog to say what I did). fyi, I didn't copy/paste that line, I think that is all the correct number of zeros... but double-check it / test it
What that does, is remove, locally on a client. that a previous inventory has been done. What that means is that the next time the client will do an inventory on it's regular schedule, it will do a full inventory.
Based on what value you put into $MaximumRandom, "about that often" it'll trigger. So if you have that baseline run daily, and the maxrandom is 14, and the computer is on 24x7, about every 14 days it'll want to do a full at it's next hinv cycle.
So you can control full hinv triggers in multiple ways... if you do that baseline daily + maxrandomdelay of 14, it'll be about every 2 weeks. If you do that baseline every 12 hours, and maxrandomdelay of 14... it'll be about weekly. (Get it?)
Only you can decide what frequency makes sense for your environment. I'd probably keep it to be full hinv nor more than 'about monthly'
The beauty of this is it is hands-off, and the randomization of when full hinvs come in stays random.
Hi Garth & Sherry, thank you for your reply.
In our enviroment only a few percent of the managed devices are affected by the problem and an outdated hardware inventory.
We discovered to correlated issues:
So basically our idea to Workaround that is a baseline that runs Weekly, checks for hanging BITS Jobs and triggers a Full Inventory - this Baseline will be targeted on a Collection with outdated Hardware Inventories. Collectionmembers are HINV vs. Lastonline Delta > 7 Days
So we already discussed a Workaround, but before implementing my idea was to find why on that Event / missed Delta Reports no resync get´s triggered for days and sometimes weeks.
@Sherry: Your idea in short words randomizes a Full Inventory on all devices in that collection, even those were the Inventory has no problems. Little bit more traffic, but a new Major Version is guaranted. We will discuss that, thx.
BR Bernd
BTW Sherry you should add this to your presentation at MMS this year. Just saying. I have done the same idea too. But it does mean that if anything happens, it might take 14 days to "fix" itself, but most of the time that isn't a problem.