Event banner
Event details
Though I would prefer systems that can start from a clean copy of Windows, then Plug and Play apply the better driver from Windows Update once the system is running, OEMs are allowed to inject any boot-start required drivers. As long as those OEM injected boot-start drivers survive a wipe, it should be fine. Just reset and go. That is... until a clean copy of Windows ever needs to be installed.
To help find vendors and products that have made the transition to modern device management, there is a community-maintained spreadsheet named "Modern Windows Management Database".
https://1drv.ms/x/s!AgG_boPR-xfWjN9i2Z_y_8ErM6t--A
Please help by contributing your experiences to it.
Thanks for participating in today's Windows. Cloud. Management. Your questions answered! For reference, the panel covered this topic at around 05:30.
- There are times when a system is missing important drivers such as the Wi-Fi network driver. If the system is being autopiloted from a USB Ethernet wired connection the user must wait for Windows Updates to complete before the Wi-Fi drivers are installed. Maybe an option in the ESP to install only driver updates would be helpful. Another option might be to place a "windows update" button on the autopilot login screen so the system can be updated before Autopilot is started. As for the having the user to wait for it to complete it think if some sort of status bar that showed the percent complete the user would be OK waiting. Without a status update the user may think autopilot is stuck and either power cycle the machine or call the help desk.
abandurianMicrosoft
Can you explain your use case? Usually, one would not want the user to sit and wait through multiple GBs and reboots before they can begin working. Instead, one would rather let them be productive (albeit in a limited way, if some resources are gated behind policies that demand a fully up-to-date compliance state) and have their updates installed in a background with a single reboot overnight. Makes sense?
There are use cases, where this is extremely important, for example high-security access, but they would likely prefer to use some kind of a jump host (Win365/AVD/local VDI), which can be made always available for patching, forensics and other security enforcement.
So, what would be your use case?
- One such use case would be Autopilot pre-provisioned deployment. Granted, the longer a device sits after being pre-provisioned before being handed over to the user, the less useful it would be. After all, whenever a new device is issued, be it for a new employee or for replacing an existing device, the user expects some productivity disturbance. I've found that users get more annoyed if they have to sit through restarts after they've logged in. Better to wait some extra time first and then have a device that doesn't need reboots caused by updates.
Hello. If I might "jump in" with a question/comment, if you don't mind? I understand this is about Autopilot, so feel free to move this to another thread, as you see fit. We often see many Intel GPU drivers, Audio drivers, etc. that are "tiny" file sizes yet these drivers, under "Optional Updates" are never installed by Intune/MEM update policies that include "all update" options. I wonder if we've missed something or the "Optional Updates" is not available (yet?) for Intune/MEM alike. These updates, at the moment, need to be done manually...or did we miss something? Thank you.
- Ken003: Drivers are labeled as 'Recommended' versus 'Optional' based on the way the OEM/IHV publishes them into the WU catalog. There's currently no way to automate the installation of these drivers within WUfB the WUfB Deployment Service or the services that ride on top of them (Intune, Autopatch).
