TL,DR: Updating Windows 10 to v1709 on a Device with Device Installation Restriction settings configured in group policy appears to succeed, but leaves many system devices not installed. The next time a user restarts the computer, windows fails to start.
I tested deployment of the Win10 v1709 update to a few computers over the holiday weekend. The update seemed to install successfully, and Monday morning users were able to log in. Soon after logging in, they were all prompted to restart the computer either to complete the installation of software for a Synaptics touchpad or for some other reason. When they restarted, windows failed to start. Attempts at startup repair or booting to safe mode all failed. The only way we were able to get the computer running again was to roll back to the previous version. I was able to reproduce the issue on a test computer. After installing the v1709 update, windows boots up, I can log in, and at first glance everything appears normal. However, in device manager there are many devices listed in an error state, with no driver installed. In the system event log, I found a series of events from UserPnp. These indicated that windows was trying to install drivers for various devices, but the install was not allowed because of a Device Installation Restriction policy. Going back a little bit further, I also found several errors from Windows Update Client about updates that failed to install, each of which was a driver update for some device. I tested installing the v1709 update on a computer without the device installation restriction policies applied, and confirmed that the startup failure does not occur when rebooting post update. So, it appears that after installing the v1709 update, many device drivers are not installed. Windows tries to install appropriate drivers, but is blocked by the device installation restriction policies. For some reason, even though windows initially boots after the update, the next time the computer starts, windows fails to start, even in safe mode. For reference, we have the group policy settings "Allow installation of devices that match any of these device ID's" and "Prevent installation of devices not described by other policy settings" enabled. The allow list has various hardware ID's of devices and accessories that exist in our environment, and anything not on that list will not install without an admin override. We only add accessory type devices to the allow list, not all of the integrated devices and components of a computer. Those integrated devices don't need to be explicitly allowed since they are all detected and drivers installed during OSD, well before group policy gets applied to the machine. The question is: *Is this a bug, or is this the device installation restriction policy working as intended?* I'm leaning towards a bug. These devices were all installed and working prior to the v1709 update. If devices have to be detected and drivers re-installed as part of the update, the device installation restriction policy should not prevent installation of those devices which were installed pre update. As I think about it, I know that we've had computers update from 1607 to 1703 with this restriction policy in place, and did not experience this problem on those. So the 1709 update is doing something different... That leads to the next question... *If this is not considered a bug (and thus won't be fixed by MS), how to work around the issue?* I can disable the device restrictions policy when the update is scheduled to install, but I know that not every computer will install the update right when I schedule it. So do I leave that policy disabled for an extended period, until all windows 10 computers are running v1709? Another option would be to make a list of every hardware ID detected for every model of computer we have in our environment, and add all of those to the allowed devices list. When every little system device and chipset has to be listed though, that's going to make for a long list and a big hassle. I'd really rather not do that. Frankly, neither of those sound like a good solution, so I'm really hoping that this is something MS can fix before the update goes CBB. What are your thoughts? -Steve
