Many years ago, I published a blog post to help folks track down issues involving Hardware Inventory. By accident, while helping someone troubleshoot ConfigMgr hardware inventory issues, I noticed that a step was missing. In 99% of cases, no one would need or notice this step, but since I realized it was missing I decided to update my post.
From now on this guide should help pinpoint any (I hope) issues within the inventory flow from PC to Configuration Manager (ConfigMgr) database. There are three sections: Phase 1 – Client PC, Phase 2 – MP Server, and Phase 3 – Site Server.
All screenshots are from a System Center 2012 Configuration Manager (CM12) client and site server; the site server is running Windows 2012 R2. However, the steps that I perform ARE applicable to all versions of ConfigMgr from the latest release down through SMS 2.0! The only difference you may encounter is that some of the file locations are changed between versions.
How to Troubleshoot ConfigMgr Hardware Inventory Issues
Phase 1 – Client PC
When troubleshooting a client PC, the inventoryagent.log will never say that it is doing a hardware inventory cycle, software inventory cycle, etc. It will only list the Globally Unique Identifier (GUID) that is used for that action. This table provides you with those details to translate the GUID to the inventory action.
In my example, I will use hardware inventory, but if you need to troubleshoot any of the other inventory types the process is exactly the same.
Simply replace the hardware inventory GUID with the appropriate GUID ID.
Next, open the InventoryAgent.log using CMTrace. Confirm that the hardware inventory has started by locating the GUID (red arrow).
Wait for the inventory to complete (blue arrow above). **NEW** Note the GUID (green arrow above). This might sound confusing, but this is yet another example of Microsoft mixing and matching GUIDs within a task. The green arrow GUID is not the same GUID used to identify the hardware inventory task.
Now, open the CcmMessaging.log using CMTrace. Search for the GUID noted in the previous step (red arrows below). Then look for the message that says, “MESSAGE PAYLOAD TRANSFER COMPLETE” (black arrow). Make sure that the status message says SUCCESS (green arrow below). This means that the file is uploaded to your MP. If this step fails, you should look at the IIS logs (Phase 2 – MP Server) to see if there is any indication as to why it failed, such as certificate errors.
Next, on your problem client PC, open a command prompt and record the IP address. In my case, I have two IP addresses that need to be recorded; the Wireless and the Ethernet adapters.
Phase 2 – MP Server
In Phase 2, locate your IIS logs on your MP server. They are generally found here: c:\inetpub\logs\LogFiles. Again, use CMTrace, open the current IIS log, and locate the IP address for the problem client PC. Notice the GUID is listed three times for the client IP address (between the red arrows).
If you get to this point then you know that the PC transferred its inventory to the MP and therefore it is not a client problem. If you don’t get the above lines with the GUID then the problem is on the client.
Now locate your MP client logs. These logs can be located in a few different places, but generally they will be either on the same drive as your ConfigMgr site server installation or C:\Windows\ccm\logs. In my case they were found here d:\Program Files\SMS_CCM\Logs.
Open the MP_hinv.log, and search for the computer name. In my case it is M6.
In the screenshot above, you can see that the hardware inventory from my client was received by the MP and moved into MP outboxes. Make a note of the file name (red arrow).
At this point you know that you don’t have a problem with the MP.
Phase 3 – Site Server
Open up the dataldr.log located here D:\Program Files\Microsoft Configuration Manager\Logs. Notice that the file is moved from the dataldr.box to the authenticated dataldr.box (red arrow).
Then notice a few lines later that the PC name is listed (green arrow) and the inventory is being added to the ConfigMgr 2012 database. You can see that it is added into the ConfigMgr 2012 database because 112 stored procedures (blue arrow) were executed within the database.
This also means that ~112 items were updated on the client PC from the last time the hardware inventory was run. For a full inventory expect the number of executed stored procedures to be well over 3,000.
To confirm that the data is updated and added to the ConfigMgr 2012 database, open Resource Explorer and review the last hardware scan date (gold arrow). This date/time will match the date/time for the hardware inventory as seen in the inventoryagent.log. Watch out for Time Zone Offset if the time doesn’t exactly match.
By following the steps outlined within this blog post you can effectively troubleshoot ConfigMgr hardware inventory issues within the ConfigMgr console.
If you are still experiencing issues, you may want to check what is actually being inventoried, so take a look at this post: How to Confirm That Hardware Inventory Is Working. Please let me know if you have any questions @GarthMJ.