Troubleshooting Hardware Inventory in SCCM

Troubleshooting hardware inventory in SCCM can be a daunting task. Sometimes your hardware inventory cycle tab is missing, other times, the hardware scan is not updating. This can put you in a world of hurt if you leave it broken for too long. I say that because if a client machine has not properly scanned in for a hardware inventory, the collections that it may belong to could also not be updating. It’s especially important if those collections happen to be deployment based, which recently was the case for me. So in this article I’ll go over the necessary steps to troubleshoot the inventory flow and give you step by step details to troubleshooting hardware inventory and finally have it updating properly in your SCCM console.

We’ll assume in this guide that you have basic network connectivity and your client machine is able to successfully ping your SCCM server. We will also assume that you have HW inventory enabled on your client setings.

To give you a high level overview of the hardware inventory process flow for SCCM, it looks something like this.

Troubleshooting The Client Machine

If you’re experiencing issues on a single machine or multiple machines we’ll want to start with the client PC and work our way up. This may sound like an unorthodox way but we need to see what, if any, do these machines have in common. After all, the inventory flow starts with the client PC and works its way up to the Management Point (MP) and eventually the Site Server.

Before we get started digging into logs and such, you’re going to need the proper tool do so. So head on over to Microsoft to download and install System Center Configuration Manager Toolkit. This kit should be in your arsenal of Ninja tools through out your SCCM career. Once you have that, let’s move on.

Check if 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 personally 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.

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.

 

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 SCCM. 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.

Looking into the InventoryAgent.log

The next course of action to troubleshooting hardware inventory in SCCM is to look at the client log files, specifically the InventoryAgent.log. The full path for the log file is C:\Windows\CCM\Logs. Another thing you have to note, is that SCCM will never actually show that the “hardware inventory” is taking place. Instead it uses its Global Unique Identifier (GUID) to specify which inventory cycle is taking place. Below is table shown for easier reference.

Inventory Cycle	Global Unique Identifier (GUID)
Hardware Inventory Cycle	{00000000-0000-0000-0000-000000000001}
Software Inventory Cycle	{00000000-0000-0000-0000-000000000002}
Discovery Data Collection Cycle	{00000000-0000-0000-0000-000000000003}
File Collection Cycle	{00000000-0000-0000-0000-000000000010}

Once you have the AgentInventory.log opened up with CMTrace, you can see that its shows Inventory: Opening store for action {00000000-0000-0000-0000-000000000001}. This is letting us know that SCCM is currently processing the Hardware inventory cycle. 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.

 

If you scroll down some more you can also see that the report was successfully sent to the MP. Take note of the MP_HinvEndpoint, ID: In my case we’ll copy {92858D93-1095-4C62-B979-40E306A1EDD5}

Next we want to check the CcmMessaging.log. In there we’re going to search for the MP_HinvEndpoint ID we noted in the step above.

If we see that the status shows SUCCESS, we can safely say that the inventory scan reported successfully to the Management Point server.

Troubleshooting The Management Point (MP) Server

On your MP we’ll want to open up SCCM_install_dir\SMS_CCM\Logs\MP_Hinv.log using CMTrace. Do a search for the computername of the problem child PC. In my case my computername is PAC-WIN1002.

 

At this point the Management Point server has successfully received the report from the client and sent it over to the Site Server (Noted by the Returned 0). Also take note of the .MIF file. In my case it’s H14I3VJ5.MIF. Next up, it’s time to take a look at the Site Server.

Troubleshooting The SCCM Site Server

As mentioned before, in a lot of cases your MP and your site server will be the same server. This is the case for me as well so I’ll navigate to SCCM_install_dir\Microsoft Configuration Manager\Logs and open up the dataldr.log.

While in the dataldr.log do a search for the problem child PC and you will begin to see that the process job is running. If something were wrong it will tell you here. I’ve seen it show up as an SQL Error in, or ERROR – attempt to update non-existent row (sp = pOperating_System_DATA). Invalid command: exec dbo.pWorkstationStatus_DATA, or Rollback transaction: Machine=ComputerName.

SMS_Inventory_Data_Loader Logs

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 SCCM console and go to Monitoring -> System Status -> Component Status and than right click SMS_INVENTORY_DATA_LOADER and Show -> All Messages.

 

Do another search for Mr problem child 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\dataldr.box\Process\H14I3VJ5.MIF because it is larger than the defined maximum allowable size of 500000.

The Fix for that:
On your SCCM server open regedit.exe and go to HKLM\Software\Microsoft\SMS\Components\SMS_INVENTORY_DATA_LOADER. Next you’ll want to change the default Max MIF Size from 5000000 to something larger like 32000000

Trigger a Hardware Inventory Sync Cycle

Going to back to the problem child machine we’ll want to trigger a new hardware sync cycle. To do that, Let’s go to Control Panel -> Large/Small Icons -> Configuration Manager -> Actions tab and highlight Hardware Inventory Cycle and click Run Now. You should go through the process flow and see if this time there are still more errors occurring. If everything was successful, the hardware inventory should show up in the SCCM console. Depending on the number of clients now showing up, it could take some time for SCCM to go through the backlogs.

If you want to manually force a full hardware inventory cycle you can follow our guide on how to do that as well.

Conclusion

So to recap on all of the troubleshooting hardware inventory steps we performed, I’ll give you a guys a TLDR, bullet point style.

• Download CMTrace to view the logs.
• Check if the BITS service is running and on automatic startup.
• On client PC, open InventoryAgent.log to see if reports were sent to MP.
• On client PC, open CcmMessaging.log to see if payload was successful.
• On MP Server, open MP_Hinv.log to see if MP send the .MIF to the Site Server.
• On Site Server, open dataldr.log to see if the transaction completed successfully.
• On SCCM Console, open SMS_INVENTORY_DATA_LOADER for more details on client PC.
• Trigger a manual hardware inventory cycle and go through inventory flow.
• Wait for SCCM go to through backlogs.

 

So hopefully this was able to resolve your issue and help you troubleshooting hardware inventory in a much more efficient way. On another note, be sure to check us out on our Youtube Channel and subscribe for awesome sysadmin content.