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.
Hi Will,
In the past I was in a similar role, and so as a result I regularly check my own drivers are current on my laptop and I have Lenovos Updater installed. Is the Cisco updater smart enough to see I already have current drivers from Lenovo or will it still deploy the updates anyway ?
Hi Adrian,
Great question.
Our update tool will not install a driver if there's already the same driver or a later one installed. That device will simply be ignored and you'll keep the driver that was already there.
We don't currently have logic in the SCCM targeting to check versions of all drivers you have and if all are the same or later, skip over your device altogether so you won't be prompted. While I think this would be ideal, unfortunately each laptop has multiple drivers included (the currently deployed X1 has 12 drivers for instance) and managing that logic and keeping it up to date didn't seem practical.
This is our first go at this, so depending on feedback we could revisit it, but at this stage even if you have all the latest drivers (or even ones later than those we're deploying) you'll still get prompted to install our baseline.
In normal operations, your drivers should never get downgraded. The only exception I could foresee is if there's a known bad driver version that's been released either by us or through other avenues that our OnTrack analysis shows is causing instability or has been identified as insecure, in which case we'd likely deploy a special task to downgrade the driver to a known good version to remedy the issue.
Will