860 16 inch G11, 660 16 inch G11 Device/Credential Guard USB-A issue

[cbecktech]

Seeing an issue with the two models listed in the subject with Device/Credential Guard/Virtualization Based Security Group Policy. These devices are being imaged to windows 10 22h2 using SCCM, I have tried the driver packs available through the CMSL powershell module, as well as the HP CMSL Driver Pack website. I've also tried creating a driver pack off of a working model (ordered about 6 months ago). Once the Device/Credential Guard group policy is applied USB-A ports stop working. USB-C remains function for only network and display, but USB-A ports on any docks also are not recognized. These devices are on BIOS version HP W70 Ver. 01.05.00, 1/3/2025. Including screenshots from functional and non-functional units of the same model. We have a large number of these 860/660 G11's that we need to get to users, but are unable to due to this issue. When these devices (while USB is broken) are in-place upgraded to Windows 11, USB A ports begin functioning again. I can see while the system POSTs that USB-A ports are disabled once the OS begins to load. We've also tried imaging these devices without any antivirus enabled to see if that was the cause of the issue. Working-DevmgmtBroken-ExtensibleBroken-DriverDetailsBroken-Code10

[Bob_Loblaw_1]

It's been awhile since I've used SCCM for driver packs but to make sure we are on the same page

1. You were pulling a pack from https://hpia.hpcloud.hp.com/downloads/driverpackcatalog/HP_Driverpack_Matrix_x64.html

2. I assume then you're extracting from the exe via some tool & uploading into SCCM into the packs you need.

You used an old driver pack manually as well but only breaks when the GPO is applied.  That would mean it's a GPO derived issue but it then works on Windows 11 with the same GPO.... hmm

What behavior do you get from the OOBE?  Does the issue pop up if you bypass SCCM completely (go from OOBE, join the domain & apply the GPO)?  That's assuming the devices are windows 10 from OOBE they are probably windows 11.  You could load a USB with a windows 10 ISO for OOBE via that method.  You would only be doing that to confirm it's the pack at fault - if it breaks via OOBE as well - nothing should work with the GPO + SCCM Pack (in theory).   

The only dumb idea I can think of would be to apply the windows 11 driver pack to the windows 10 22h2 they have built?  Otherwise tinkering with the GPO or looking for custom reg hacks is where I would go next if they must be windows 10.  Windows 10 is done in October (unless you get extended support).  

Only other thing I can think of is if you have several docks - test each one you have.  Over the years depending on which dock would change behavior - or loading dock packs would resolve sometimes as well.

[cbecktech]

Thank you Bob_Loblaw_1 - I'll give these a try and report back. Correct on #1, I pulled it from there, I believe the HP powershell module also pulls the same thing. 

These devices are Windows 11 OOBE, so won't be able to test that. I plan to manually put one of these to win10, install all of HP's recommended drivers and manually join to domain and apply GPO and will report back with what happens there. 

Will also try applying the win11 driver pack to the Win10 OSD and see what happens. Thanks! 

As for docks, these devices onboard USB-A doesn't work as well, so it's both onboard and any USB-A ports that are on docks that stop functioning after the GPO is applied. The only thing that reliably makes the devices USB-A ports work again is disabling secure boot in the BIOS, but this also disables any Virtualization based security at the same time (Device/Credential Guard essentially disabling the GPO's effect). 

Thanks again for the reply, I will report back with what I find. 

[cbecktech · Accepted solution]

Solution: 
A driver that is provided during a prior cumulative update may not be being provided with some of the newer cumulatives. By installing kb5036979 manually, the Intel(R) USB 3.20 eXtensible Host Controller - 1.20 (Microsoft) gets updated to a newer version (10.0.19041.4355). 

I found this thanks to Bobloblaw's post suggesting doing a clean install of Windows 10, and seeing that the USB's continued working after manually enabling the group policy for Device/Credential Guard on the system. I noticed that Windows updates had ran prior to enabling the Group Policy. Installing the KB mentioned fixes any USB ports that become disabled after enabling Device/Credential Guard.