At the tail end of June 2023 and into the first week of July 2023, many admins started to report that application inventory data was missing in Intune for some managed devices with the release of Intune Management Extension 1.68.105.0.
Upon further investigation we started to notice this behaviour too. While the issue has since been fixed by Microsoft we felt it prudent to explain why this happened so you can understand if you are affected by the issue still.
Let the fun begin…
What went wrong?
The IME is responsible for installing Win32 apps, among other things. was updated around the end of June 2023 and started rolling out to managed devices. You have zero control over the release cadence of the IME, it gets pushed to your devices as a LOB app. Yep, you heard that right…no test rings for you my friend, the proverbial flood gates have been opened.
You have to sit back like a good admin and take the auto updates on the chin. Remember when you recieved that mint green bread maker from cousin Bob on your wedding day? Like back then, you have no control over Bobs shopping habbits…you also have no control over when the IME updates.
It’s all good though? These things are well tested..right?
Oh for sure. It just so happens that with the release of IME 1.68.105.0, something seems to have slipped the net.
A Dynamic Link Library (DLL) appeared to be playing havoc with inventory results:-
“C:\Program Files (x86)\Microsoft Intune Management Extension\Microsoft.Management.Clients.IntuneManagementExtension.Win32AppInventoryCollector.dll”
What “specifically” went wrong?
The IME uses a specific WMI class to collect Win32app inventory data:-
Win32_InstalledWin32Program
The source code snippet below illustrates that class being used:-
Once the IME has collected the results from that class, it would save the results into the registry in the following key:-
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\IntuneManagementExtension\Inventories
But something went horribly wrong. After the inventory was collected and posted to that registry key – it was DELETED, and not re-populated.
This key is pivotal because it is used for delta’s to compare the previous inventory results with the current one and post back delta changes to the Intune service.
As part of the inventory collection process could not read inventory data from that key, the evaluation appeared to be marking inventory data for deletion and posting that to the Intune Service. Status 2 in the report posted in the JSON body indicates inventory item delete action and the Report Type 0 indicates a delta scan
What was deleting that key then? The IME, of course. Something in the code change was causing the inventory keys to be removed, but not repopulated.
With this IME release, you could also have tracked inventory collection and evaluation in a new log file which appeared, namely Win32AppInventory.log
The end result here was inventory reconciliation was wiping out discovered apps data at the device level in Intune. This was also propogated up to the aggregated discovered apps report too.
Your reports were not as accurate as you thought they were 🙁
What is the fix?
After a few days looking through source code and testing the behavior I had a pretty good handle on what was going wrong and reported observations to the product group at Microsoft.
Note: I am not claiming that report prompted action. I’m sure the team were already aware of the issue and working on a fix.
Around the middle of July 2023, a new IME was released, 1.68.204.0
Inventory data was no longer being wiped from the registry and not re-populated – normal service had resumed. Woohoo! Full inventory scans and delta inventory scans were posting accurate inventory data to the Intune service again.
The new Win32AppInventory.log log file looks to be reundant with this IME release. Perhaps it will see the light of day again in a future release.
The idea of splitting out the IME log was exciting, allbeit short lived. The IME log gets very noisy so splitting out inventory data to its own log file gave us hope that we might see other IME workloads earning their own log file too, some day.
Summary
Although the product group have been engaged, we still haven’t heard more info about this bug yet.
The @IntuneSupportTeam did acknowledge it at least, on Twitter
We don’t have control over the IME release cadence to the managed devices in our environemnt. Who is thinking abour ConfigMgr’s pre-production deployment option as they read the previous sentence? Sound nice right?
As we opt for “Cloud First”, we have to be OK with the idea of losing a bit of control over the nuts and bolts that we can tweak. In the same breath, we should not lose our voice of reason. A lack of control shouldn’t come at the sacrifice of quality.
You hold the gold coins in your pocket – voice your concerns to providers of cloud services. I’m not saying go break their door down and give them the hairdryer treatment – let’s be civil. But you absolutely you do have the ear of the person you are paying money to. Tell them what works and what doesnt work. Let them know the deal breaker scenarios and the “nice to haves”.
Giving feedback is how we build better products 🙂
