Updating a computer with Device Installation Restrictions GPO applied loses all installed drivers

Bronze Contributor

I've started testing the update from v1703 to v1709, and found that the update seems to ignore any info on previously installed hardware and drivers, re-detecting everything from scratch.  Because we have the group policy "Prevent installation of devices not described by other policy settings" enabled, windows fails to install the drivers for any devices not explicitly allowed in another policy setting.  The end result, after the update is installed, is a computer with many detected devices having no driver installed.  

 

Is this the expected behavior when updating to v1709?

 

This did not happen when updating from v1607 to v1703.  Does v1709 change how it handles existing devices & drivers during the update?  

 

 

11 Replies

As part of the Windows 10 feature update installation process, all drivers are reinstalled to ensure that the latest drivers are always used.  I don't see why the behavior you are seeing would be any different for 1703 vs. 1709.

Don't know why but in my case (2 monitors) the second one is blank after a new build. This did not occur six months ago when installing builds of Creators Update. This all began with FCU. Have to go in every time and 1. right click to get Nividia control panel 2. Click to acivate all displays. 3. Turn off all the programs Nvidia lists (Corsair water cooling, Corsair keyboard, Cloud settings, etc.) 4. then Nvidia makes the changes - until next build... . 

Even if the update is re detecting hardware and installing fresh drivers, I would have expected it to remember what devices were already installed and allow the installation of those drivers.  That's basically how the GPO works normally, it doesn't affect anything that is already installed, only prevents the installation of new devices.    

 

Generally, we only add the hardware ID of 'accessory' type devices to the explicit allow list, basically anything that will be added to the computer after the initial imaging.  This is because all integrated hardware gets detected and drivers installed during the imaging process well before GPOs are applied to the computer.  Adding every possible hardware ID for every integrated component of every computer model we use, and then keeping that list updated for new models, sounds like a huge hassle.  

The only alternative I can think of is disabling the device installation group policy temporarily when we deploy the update.  We can probably deploy the update and expect most computers will install it on a scheduled date, but there will always be some that don't get it for one reason or another.  That would mean leaving the GPO disabled for perhaps weeks, until every computer has completed the 1709 update.  And if this is expected with every feature update, we'll have to do it again and again.  

 

Can you recommend any other workaround or solution to this issue?

Well, now that the AMA is over, hopefully this thread will still catch the eye of someone with some insight on the issue.  If the behavior I'm seeing is really the expected interaction of the device restriction group policy settings and Windows 10 feature updates, I can't imagine anyone actually being able to use this GP setting.   

 

One data point that I didn't mention initially:  We also have the group policy setting "Allow administrators to override Device Installation Restriction policies" enabled, which allows any device admin to install drivers that are otherwise blocked by policy.  I don't think that would make a difference to whether device drivers can be installed during the update process, but thought I'd make note of it just in case.  

I was hoping that whatever the root cause of this issue was would be resolved by the time the "Business Ready" version of the update was released, but it seems that is not the case.  I've deployed the new "Feature update to Windows 10 (business editions), version 1709, en-us" to a test computer running Windows 10 v1703, and the results were the same as before.  The computer blue screens and goes into a boot loop after the update, with the only solution being to roll back to the previous version of windows. 

 

I'm hesitant to open a support ticket for this issue, as I half expect them to tell me that this is 'working as designed', and leave me out the $500 fee and with no viable solution to the problem.  Still, that may be my next step.  I'm going to have to push this update out sooner or later, and I don't see a reasonable workaround at this point. 

have you logged feedback for this using the Feedback Hub app at all yet?

Question : Are you rewriting the (in this case) Nvidia driver with the one that is already on the desktop or are you detecting the device and simply sending latest upgrade ?  I researched this with Nvidia and for some reason their drivers also started forgetting my second display when I downloaded them in between builds. They have been working on this and at least the last 3 updates that came directly from them recognized my settings and re-applied them when the new driver was installed. The setting in question is the one that 'Activates all Displays' . It is located under 3D Settings when Configure SLI, Surround, Physx is selected when you right-click and open Nvidia Control Panel. After this is set Windows will open with all the displays being recognized and turned on.  If that checkbox does not get clicked then Windows will still recognize (in my case) the two GTX cards but only the first display will be Active. I suspect the driver is fine every time and even if there is a new one installed it is not likely to be an issue. So are we talking about a setting 'within' the driver that Windows does not pickup or a configuration file that gets written over when a new build comes in ?  Somehow I think Nvidia has figured this out with their driver updates but the install methodology may be different when applied by Microsoft. 

@Deleted - I'm not sure that the issue that you're describing is related at all to what I'm seeing.  If there's a link that I'm missing, please help me understand.

 

The issue that I have is that after installing the feature update to v1709 on a computer with Device Installation Restriction policies set, the computer will not boot.  It initially blue screens during boot, and then on subsequent attempts it goes to Startup Repair.  The only way that I've been able to get windows to boot at that point has been to roll back to the previous version of windows. 

 

If I disable the device installation restriction policies before installing the update, the update installs successfully.  Windows boots and is fully operational after the update. 

We see this issue during 1709->1803 upgrade. We expect that "Allow administrators to override Device Installation Restriction policies" is respected during upgrade, because uprade runs under administrative account. How (timing) you disable the "Device Installation Restriction policies" during upgrade? 

I ended up going through and finding what devices were prevented from installing during the upgrade, and adding those hardware ID's to the list of allowed devices in the group policy.  It definitely seems like something that should NOT be required, but at least it let me upgrade computers.