Event banner
Event details
The demo for drivers management was interesting, but focused on manual management. With Windows Autopatch, is it possible to automatically approve all drivers installation for Ring0 (i.e. labs devices), while having some gating before drivers become available to other rings?
It looks like managing drivers manually is a lot of overhead, and requires manual assignment to groups. How are we notified of new drivers being available in Windows Autopatch, so that we can proceed with assignments?
Finally, I feel that the naming convention for drivers is pretty vague. "Intel - Extension - %version%" -- how are we supposed to identify to which equipment and/or computer models such a driver targets? That is especially true when we identify a specific driver causing issue, i.e. using the local Computer Management MMC -- how can we resolve the name/version of a driver in the MMC versus the name/version being displayed in Windows Autopatch?
This session focused on advanced capabilities for when you need more control. If you’re looking for more details on the common driver management scenario with automatic policies, check out our other session here: aka.ms/UpdateHarmony.
Currently, there isn't a way to automatically approve drivers listed under the Other Drivers tab. This isn’t a request we’ve heard frequently, but we’d love to better understand your needs. If this is something that would benefit your workflow, please private message me with details on your use case.
To help with driver awareness, the Drivers to Review column in the Driver Updates tab shows how many recommended drivers are in the 'Needs Review' state, meaning no admin action has been taken yet (Approve, Pause, or Decline).
Regarding driver naming conventions, changing the name format to include more details isn’t straightforward since drivers often target multiple device models (CHIDs) and hardware components (HWIDs). However, we’re actively exploring ways to provide more context, including which of your devices (by model) are impacted and details on which component within the device a driver will affect. These are two of the most requested improvements for driver management, and we’re investigating solutions to enhance this experience.