Managing Drivers using WSUS at Microsoft - Introduction to "Andretti"
Drivers: Do they have to be this hard?
At Microsoft, we have ~280,000 desktops worldwide that we are managing. We spend a great deal of time (probably too much – honestly) trying to better understand how to manage the driver ecosystem.
For example, a few months back we started running SQL queries against our ConfigMgr database to determine how many drivers we currently have in Microsoft that are broken, or as we like to refer to them, “banged out”.
WSUS vs. Windows Update\Microsoft Update
Our operations team at Microsoft is responsible for ensuring that they meet a high SLA for patching of Microsoft desktops and laptops – 95% and higher. For those interested in the math, that is 266,000 within a very short period of time. I will avoid saying the “time” period to protect the innocent.
We use ConfigMgr 2007 Software Update Point (SUP) for patching of the clients with integration with ConfigMgr 2007 and ironically this system works great. However, when Microsoft IT asks us to start managing the driver ecosystem at Microsoft we were at a loss of words. Let me explain our dilemma here…
Using Group Policy to force Windows Update\Microsoft Update
At Microsoft, it is rather “easy” to enable a group policy that forces all clients to go to Windows update and\or Microsoft update for software patches and drivers. However, when an administrator decides to use group policy they are deciding to use Windows update & Microsoft update for both software patching and drivers.
For drivers, the publishing of driver catalogs in Microsoft & Windows update is slightly mis-leading by “ranking” due to the fact that very few drivers are marked as critical (less than 2%). The remainder of the drivers are actually marked as optional.
This, of course, is not an ideal solution because at Microsoft we would *love* to use SUP for patching our clients and use WU\MU for drivers. It doesn’t work this way though…
Using WSUS
We don’t use WSUS currently patching of any drivers and haven’t been for quite some time (if ever). During the building of our Windows 7 OSD solution, Microsoft IT challenged our team to solve the “driver” problem that has hindered us for the past few years. We were provided minimal requirements for “solving” the problem but we were told what to solve. So off we go in building what we call the good ‘ole “State of Affairs” where we talk about every option available including the bad ones.
We discussed chaining off of another WSUS instance and to pass the buck off to another group. For example, at Microsoft we have a dedicated Microsoft IT hardware team who works closely with the OEMs and they could manage the WSUS instance. This idea was nix’d about as fast as it was dreamed up…
We then started investigating the feasibility of updating and managing drivers using WSUS 3.1 and we found out some interesting things. For example…
- WSUS syncs only get “critical” drivers and do not sync any optional drivers
- There is no concept of supercedence in the WU\MU driver catalog. This is done using a best-bmatch algorithm by the Windows Update client and WSUS\MU.
With a little bit of investigation, we determined that around 99% of the drivers released and approved for Windows Hardware Quality Lab (WHQL) are not critical thus about 1% of drivers are actually available to WSUS users.
What does ConfigMgr 2007 offer in the Driver Space?
It was obvious to us that ConfigMgr 2007 had, with its inventory capabilities, everything we needed to effectively patch drivers at Microsoft. It was frustrating though that we didn’t have a translation feature that would pull information from ConfigMgr 2007’s metadata (or an exported list that came from ConfigMgr 2007), get what is relevant from WU\MU, and then push it to WSUS. Then we realized…
With an easy change to the MOF file -
|
/------------------------------------------------
/ SMS Driver Catalog - Device drivers information
//------------------------------------------------
#pragma namespace ("\\\\.\\root\\cimv2\\sms")
[SMS_Report(TRUE),
SMS_Group_Name("PNP DEVICE DRIVER"),
SMS_Class_ID("MICROSOFT|PNP_DEVICE_DRIVER|1.0")]
class Win32_PnpEntity : SMS_Class_Template
{
[SMS_Report(TRUE), key]
string DeviceID;
[SMS_Report(TRUE)]
string ClassGuid;
[SMS_Report(TRUE)]
uint32 ConfigManagerErrorCode;
[SMS_Report(TRUE)]
string PNPDeviceID;
};
/------------------------------------------------
// SMS System Devices - Device drivers information
//------------------------------------------------
#pragma namespace ("\\\\.\\root\\cimv2\\sms")
[ SMS_Report (TRUE),
SMS_Group_Name ("System Devices"),
SMS_Namespace (TRUE),
SMS_Class_ID ("MICROSOFT|System_Devices|1.0") ]
class CCM_SystemDevices : SMS_Class_Template
{
[SMS_Report(TRUE), key]
string Name;
[SMS_Report(TRUE)]
string DeviceID;
[SMS_Report(TRUE)]
string CompatibleIDs[];
[SMS_Report(TRUE)]
string HardwareIDs[];
[SMS_Report(TRUE)]
boolean IsPnP;
}; |
…and a refresh of the hardware inventory cycle the following query would tell us what broken (bang’d out) drivers existed at Microsoft -
1: SELECT distinct sys.resourceid
2: -- MIN(dev.[TimeStamp]),pnp.DeviceID0 as DeviceId, dev.CompatibleIds0
3: FROM v_R_System sys
4: JOIN v_GS_PNP_DEVICE_DRIVER pnp
5: ON sys.ResourceID = pnp.ResourceID
6: JOIN v_GS_SYSTEM_DEVICES dev
7: ON pnp.DeviceID0 = dev.DeviceID0 and sys.ResourceID = pnp.ResourceID
8: WHERE
9: sys.Client0 = 1
10: AND sys.Obsolete0 = 0
11: AND pnp.ConfigManagerErrorCode0>0
We then knew we had everything we needed to solve this problem.
Solving the Dilemma – Driver Management at Microsoft
After realizing that neither WU/MU nor WSUS could meet our needs exactly we went down the path of least desirable and decided to use code to solve the problem. The solution needed to accomplish the following:
- Download only the drivers needed for our Enterprise – nothing more, nothing less
- Use the WSUS infrastructure for delivery
- Modify absolutely nothing on our clients
Ben Shy, a Program Manager on my team, owned this piece and did a awesome job of meeting these 3 important yet huge goals. Ben’s design, codenamed Andretti (get it – Andretti as in Mario the Indy race car Driver), would use the following to solve this problem -
| Feature |
Purpose |
| ConfigMgr 2007 |
It was determined that we could write a service that runs as a scheduled task (or manually) that would determine what Hardware Ids (PNPIDs, Device Ids, etc.) are broken in our Enterprise with a small tweak to the ConfigMgr MOF file to ensure we get this data.
We could then easily take action on it very similar to how the client itself could take action (though most users are allowed to access WU\MU) |
| WSUS 3.1 |
We could easily push any updates we would like to have downloaded to WSUS and instruct this service to go to WU\MU and get the appropriate drivers and publish them to the WSUS catalog. |
| WU\MU |
It was determined that all the data we need is available in ConfigMgr and that we could use the WU\MU RSS feed (and a few other pieces of data) to abstract what updated drivers are available for our enterprise clients. |
This is basically what we have built at Microsoft to manage drivers for the enterprise. In a few upcoming posts, we will dive deeper into how we built Andretti and soon after maybe surprise ya with some bits for you to use. We make no implied promises but you never know!
-Chris
