I’m with the Desktop Platforms team. We manage the fleet of Windows devices, Macs and Linux machines provided and supported by IT at Cisco.
Our team has tried a number of approaches to driver updates on the Windows side over the years and have at times struggled with the balance of ‘leave it alone if it’s working’ and ‘update to the latest to ensure they’ve got the best’. We’d generally ensure we had the most recent hardware drivers installed as part of our OS provisioning process, but unless needed because something was broken or a security issue was discovered, we wouldn’t proactively go out and update hardware drivers to machines already built with Windows in the fleet.
On the wireless side, choosing to leave things alone unless we have to update has proven to cause some issues over the years as we sometimes struggled to stay in sync with the GIS teams managing our wireless infrastructure, especially in Alpha locations or other buildings where pilots might have been run.
Over the last couple of years we became more proactive with our wireless driver upgrades and have pushed out wireless driver updates 3 or 4 times (including during KRACK and other vulnerabilities). When we have pushed out wireless driver updates, we’ve done so silently with no notification to the user and have configured them to pre-stage the driver on the machine, but not install it until the user naturally rebooted. We would then update the driver via a scheduled task upon that next reboot so as to avoid network interruption. This wireless update process has worked quite well for us with little user impact, and we’ve stayed up to date on required drivers and potential bad updates via this Tech Zone page maintained by TS.
This has worked OK for us, but with the move to Windows 10 and its semi-annual ‘feature updates’ (basically a new version of Windows every 6 months) which we have to install, driver updates to existing machines have become even more critical as outdated drivers can cause many issues with stability as well as straight out blocking or causing feature updates to fail during installation. This has led to us moving to a proactive driver ‘baselining’ where we’re starting to push out updates to all our machines quarterly to ensure they stay up to date. We’re including wireless drivers in these updates.
We’re doing this in a more user impactful way as we’re updating large numbers of drivers and a reboot is required afterwards for them to become active. Prompts will be given with users being able to postpone a limited number of times and then the update will be forced once that interval is complete:
This is the type of dialog users will be shown. This one is for a BIOS update, but the driver baseline is similar:
Before going to general users, all our deployments go through QA and then to our UAT devices in our organisation and across different functions with Spark rooms used to collect feedback on any issues that may be discovered during this process. Right now, the driver baseline is in UAT but is expected to be deployed more widely soon.
We’ve also been proactive in our decisions around endpoints we deploy, so on the Windows side when deploying Lenovos we ensure that the SKUs we select always contain Intel chipsets that are dual band and well supported by our wireless network. This also limits the number of wireless drivers we need to monitor updates for. Even though we deploy 3 or 4 different models of Lenovos and deploy to many countries globally, that consistency of a single Intel wireless chipset per laptop generation helps immensely compared to what I’ve heard about at other enterprises.