[su_box title=”Update 2016/10/28″ style=”glass” box_color=”#000000″ title_color=”#F0F0F0″]This issue is now resolved in the October 27, 2016—KB3197954 (OS Build 14393.351) update :


File information and complete details available in the KB3197954 support article.[/su_box]

With the increasing speed of new Windows 10 releases, SCCM administrators will be faced with new testing process before deploying to all your users. During this process at a customer, we found an hardware inventory problem affecting only Windows 1607 devices. We were able to reproduce the problem in our lab and finally decided to submit the problem to Microsoft. They confirmed that it’s actually a bug that seems to reside in the latest Windows 10 1607 release. We had no inventory problem on this device using Windows 10 1511 and no changes were made in SCCM. The hardware inventory just stopped working after the Windows 1607 upgrade. We also reproduce the problem on a fresh Windows 1607 deployment.

Our setup is on SCCM 1606 but this error is present also on SCCM 1511.

We found 2 links that is identifying the problem. You can up vote the Connect item if you’re affected by this problem.

What’s causing the SCCM Hardware Inventory Problem on Windows 10 1607

The problem reside under the file encryption feature in Windows 10 1607 which cause an error when trying to send the file to the management point. The EFS feature is not new to Windows 10. It has been in Windows for years. Read more about EFS on this Technet article.

Here’s how to check if you’re affected by this problem :

  • We’ll start by checking the server logs which there’s no entries related to the device in the MP_Hinv.log and Dataldr.log on the Management Point
  • On the client InventoryAgent.log, we can see that the XML was generated and sent to Management Point
    • Inventory: Starting reporting task Reporting: 92 report entries created Inventory:
    • Reporting Task completed in 18.785 seconds
    • Inventory: Successfully sent report.
    • Destination:mp:MP_HinvEndpoint, ID: {831C6FFD-651A-48A3-F187DCFB38FB}, Timeout: 80640 minutes MsgMode: Signed, Not Encrypted
    • Inventory: Cycle completed in 109.319 seconds

Since BITS is used to send the reports, we’ll check the BITS jobs status on our affected client :

  • Open a PowerShell session
  • Launch the command : Get-BitsTransfer -allusers -verbose

SCCM Hardware Inventory problem Windows 10 1607

  • Check the JobState column, you can see TransistentError on CCM Message Upload jobs
  • On a administrator command prompt, we’ll look at the job status
  • Type the following command : Bitsadmin /list /allusers /verbose

SCCM Hardware Inventory problem Windows 10 1607

  • See the error code 0x8007177f – This machine is disabled for file encryption for our job {831….8FB}
  • Browsing to the path of the file (C:\Windows\CCM\ServiceData\LocalPayload) we can see that jobs are pilling up

SCCM Hardware Inventory problem Windows 10 1607

The machine effectively has EFS disabled by Group Policy but it was also disabled on Windows 1511 using the same GPO without any SCCM hardware inventory problem.


At the time of writing this post, there’s only a workaround proposed by Microsoft Support. Enabling EFS on the affected clients which means that your users can suddenly encrypt files and folders on their system… Maybe not a good solution for all environment.

To enable EFS on the affected client :

  • Open Regedit
  • Browse to HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\CurrentVersion\EFS\
  • Change the EfsConfiguration key value from 1 to 0 – (Yes 0 means Enabled and 1 is disabled)
  • Reboot the system

SCCM Hardware Inventory problem Windows 10 1607

  • Once rebooted, initiate a manual hardware inventory and the process should complete successfully

We’ll update this post if we have new information about this SCCM Hardware Inventory problem on Windows 10 1607. Meanwhile, use the Connect Item to up-vote or use the comment section to share your experience.

Comments (11)


12.14.2017 AT 04:35 AM
Hi, Amazing...that helped me resolve one of the long pending issue that we had. I knew its coming from BITS but was not sure how to resolve it..thanks.


01.03.2017 AT 10:37 AM
My company was having a similar problem. After enough digging we found out that our issues were not due to how the Inventory data was being sent by the client, but rather, it was SCCM that determining that the data was bad. We were consistently seeing that data related to Processes was being rejected. Upon turning off Inventorying Processes, we saw a dramatic decrease in the number of bad mifs being processed by SCCM. Our main category of Bad mifs was ErrorCode_4. The process that seemed to be passing bad info as smss.exe, typically the UserModeTime data.


12.01.2016 AT 11:19 AM
Still no word from Microsoft about fixing this then? Has the 1610 release fixed it for anyone?


12.06.2016 AT 06:24 PM
The problem was on the client side and has been resolved with KB3197954 (OS Build 14393.351) update. If you run WINVER.EXE, the version build should be greater than or equal to 14393.351.


10.27.2016 AT 07:18 PM
I just verified that the issue is resolved on a couple systems. I watched the queue (C:\Windows\CCM\ServiceData\LocalPayload) empty out within about 20 seconds and I now have hardware inventory including apps that were just installed today.


10.27.2016 AT 07:00 PM
Problem reportedly addressed now as of 14393.351 - released today! Addressed an issue that prevented System Center Configuration Manager from performing inventory uploads via Background Intelligent Transfer Service (BITS) when Encrypting File System (EFS) has been disabled.


10.20.2016 AT 07:03 AM
I'm having the same issue since the upgrade. Thanks for going into great detail as to why the issue is occurring!


09.12.2016 AT 01:51 AM
The Microsoft Connect link doesn't work. Is the feedback possibly deleted? I think it should be under the https://connect.microsoft.com/WindowsServer/ section accepting bug reports for SCCM.

Jonathan Lefebvre

09.15.2016 AT 11:44 AM
Hi, Link is working, you need a Microsoft Connect account to see it and be part of the program for SCCM. https://connect.microsoft.com/ConfigurationManagervnext Jonathan