Troubleshooting Hardware Inventory in MECM

Endpoint Manager

Troubleshooting the Client

Check if BITS is running

The first step in troubleshooting hardware inventory on a client is to verify the BITS service is running.

BITS or Background Intelligent Transfer Service is a Windows service used to transfer data whenever there is bandwidth that is not being used by other applications. BITS also supports resuming transfers in case of disruptions so you can restart your computer and resume when you’re back online.

I’ve ran into problems where the BITS service wouldn’t start and the BITS service was greyed out, not allowing you to start the service to begin with.

On some Windows 10 versions you will notice that the display name will show as Background Intelligent Transfer Service. On other versions, it will show as BITS.

If you’re running into this issue, a simple group policy to force the client to enable the BITS service should do the trick. Here’s how you do that.

  • Open Group Policy Management Console
  • Go to Computer Configuration -> Policies -> Windows Settings -> Security Settings -> System Services. Double Click on Background Intelligent Transfer Services.
  • Set the start up mode to Automatic and click on Edit Security.
  • We’ll Change INTERACTIVE account to start, stop and pause the service. SYSTEM and Administrators should remain as FULL CONTROL.
  • On the problem child PC do a GpUpdate /force and several seconds later the service should be running again.
Enable BITS Through GPO

If this is the case for you, you might need to wait 1 or 2 days (depending on your sync cycles) for it to show up in MECM. When I had this problem, it took about 2 days for it to finally show up. 90% of the client PCs that had the BITS service greyed out were showing up as successful. The other 10% needed some additional troubleshooting.


Troubleshooting hardware inventory in MECM involves looking at the client log files, specifically the InventoryAgent.log. The path for the log file using the default MECM client folder is C:\Windows\CCM\Logs. Another thing you have to note is that MECM will never actually show that “hardware inventory” is taking place. Instead, it uses its Global Unique Identifier (GUID) to specify which inventory cycle is taking place.

Open the log file AgentInventory.log in CMTrace, and you should see that hardware inventory is starting with this line:

Inventory: Opening store for action {00000000-0000-0000-0000-000000000001}

Also, take note of the Major and Minor version of the report.

  • Major versions increment every time a full sync or a re-sync is ran.
  • Minor versions increment every time a delta sync is ran.
Inventory: Action=Hardware, ReportType=Delta, MajorVersion=2, MinorVersion=10
AgentInventory Log for Hardware Status Start

If you scroll down, you should see how many inventory items were successful, as well as detail that the report was sent to the management point. Take note of the MP_HinvEndpoint, ID. In my case, we’ll copy {FE2B6D72-547F-4090-A040-65ADD3E2BDA6}.

Collection: 58/69 inventory data items successfully inventories.
Inventory: Successfully sent report. Destination:mp:MP_HinvEndpoint, ID: {FE2B6D72-547F-4090-A040-65ADD3E2C7DC}, Timeout: 806400 minutes MsgMode: Signed, Not Encrypted

Next, we can validate the inventory message was sent to the management point by opening CcmMessaging.log in CMTrace and searching for the MP_HinvEndpoint ID – again, in my example {FE2B6D72-547F-4090-A040-65ADD3E2C7DC}.

Status : SUCCESS
Direction: Upload
Msg ID: {FE2B6D72-547F-4090-A040-65ADD3E2BDA6}
BITS Job ID: {F38AA4D5-9FFD-457D-A015-DC5747D602335}
Start time: 02/10/2019 10:39 (GMT)
Completion time: 02/10/2019 10:39 (GMT)

Troubleshooting the Management Point

On your Management Point server, open the file <ProgramFiles>\SMS_CCM\Logs\MP_Hinv.log in CMTrace. Search for the computer name of the client you are tracing. Notice the name of the MIF file identified.

Resync report from client W1, action description = Hardware
Hinv Task: Translate report attachment to file "C:\Program Files\Microsoft Configuration Manager\inboxes\auth\\HAIF7F21.MIF" returned 0

Troubleshooting the Site Server

On your Site Server, open the file <ProgramFiles>\Microsoft Configuration Manager\Logs\dataldr.log in CMTrace and search for the MIF file, such as HAIF7F21.MIF in the above example.

Notice the additional messages indicating the file was processed.

So by this point we should have a pretty good idea of what might be going on. After checking the logs on the client machine, then the MP and Site Server, our next step is to see if there is anything within the SMS_INVENTORY_DATA_LOADER component. To get there open up your MECM console, and go to Monitoring -> System Status -> Component Status, and then right-click SMS_INVENTORY_DATA_LOADER, and then Show -> All Messages.

SMS Inventory Data Loader

Do another search for the client machine or even the .MIF file from above and you should get even more insight as to what’s going on. I’ve seen from different clients that they’re getting:

Inventory Data Loader failed to process the file E:\Program Files\Microsoft Configuration Manager\inboxes\auth\\Process\HAIF7F21.MIF because it is larger than the defined maximum allowable size of 500000.

In this situation, you adjust the maximum file size by editing the registry on your MECM server. Browse to HKLM\Software\Microsoft\SMS\Components\SMS_INVENTORY_DATA_LOADER and change the configured Max MIF Size to the size of your choice. Change the Base from Hexadecimal to Decimal to enter in the value.

Note: Increasing the Max MIF Size may lead to increased database storage.

Article sources: 

SCCM Client Side Inventory Troubleshooting How validate on client side (
Client send Inventory How to Validate on Server side. (
Troubleshooting Hardware Inventory in SCCM | Step By Step Guide (

Leave a Reply

Your email address will not be published. Required fields are marked *