Windows 10 Driver Publishing Workflow

Reselling (Redistributing) Drivers and the Driver Update Acceptable Process

In addition to hardware partners publishing their drivers, they can also grant a copy of the driver for other hardware partners to download and/or distribute. This is known as the resell process.

If Partner A submits a driver for signing, Partner A can then resell the driver to Partner B and Partner C, who can independently distribute the driver through Windows Update as if they were Partner A. Resell submission is only available through Compatibility signing. Please refer Section2.5.1.

This provides partners the right to publish the driver to Windows Update. This offloads the work of Partner A to manage driver distribution for Partner B and Partner C.

Note that a resold submission cannot be resold (again).

In addition to the resell process a hardware partner may modify an initial or resold driver through the Driver Update Acceptable process, and then distribute the drivers. There are limitations to what can be modified, such as only particular parts of an INF file (such as HWIDs, installation targeting information, branding,and so on).

The resell and Driver Update Acceptable process is defined in the Manage Hardware Submissions article on MSDN:
https://msdn.microsoft.com/en-us/library/windows/hardware/br230784.aspx

3. Pre-Windows 10 Driver Publishing Workflow

   1. Driver Submission Options

Previous Windows releases provide hardware partners the ability to sign and publish drivers through the DevCenter Dashboard. A hardware partner had one of three options to choose from when submitting a driver (as illustrated in Error: Reference source not found). These options are shown in Figure : Legacy Driver Publishing Workflow (Win7, Win8.0, Win8.1):

Figure : Legacy Driver Publishing Workflow (Win7, Win8.0, Win8.1)

List : Legacy Driver Publishing Options

1. 
   Submit the driver for signing only
   This option was commonly used when the hardware partner wanted to have a driver signed so that it installed correctly on a device running Windows; however, the hardware partner planed on distributing the driver itself (not using Windows Update). This was also used for hardware partners to enable testing on a production system prior to widely distributing the final release version of the driver or firmware.
   (Refer to in Error: Reference source not found).
   
   
2. 
   Submit the driver for publishing to Windows Update as optional
   In this option, the driver was signed and then published to Windows Update. In this case the hardware partner intended for the driver to be available for driver provisioning and was available to users to update if they opt into it. To accommodate this the driver is marked as optional (refer to the Missing Driver and Update Driver Scenarios in List ). The user only received it if they opend Windows Update, scanned for updates, and then explicitly selected the driver to install. Since this workflow is non-intuitive, it was considered as available only to advanced users or users directed by customer support.
   (Refer to in Error: Reference source not found).
   
   
3. 
   Submit the driver for publishing to Windows Update as critical
   In this option, the driver was signed, and then published to Windows Update. In this case the hardware partner intended for the driver to be available for driver provisioning, manual updating, and to be available for automatic installation when AutoUpdate occurs (refer to the Missing Driver, Update Driver, and AutoUpdate Driver scenarios in List ). To accommodate this the driver would be marked as critical. This required Microsoft’s explicit approval. Marking a driver as critical is a rare event.
   (Refer to in Error: Reference source not found).
   

All driver submissions were stored in the DevCenter Dashboard driver repository regardless of which option above the hardware partner requested. Both a pre-signed and signed copy of the driver was stored for archiving purposes.

This workflow is described in List .

List : Legacy Workflow Steps

1. 
   The hardware partner submitted a driver and Windows Hardware Certification Kit (WHCK) logs to the DevCenter Dashboard. The DevCenter Dashboard validated the logs to ensure the driver was compatible with the device class it targeted.
   If the WHCK logs did not pass validation, the submission was rejected and the hardware partner was informed. The workflow then ended.
   If the hardware logs were successfully validated, then the driver was signed and the workflow continued.
   
2. 
   The signed (and pre-signed) driver package was archived in the DevCenter Dashboard database.
   
3. 
   The hardware partner could then download the signed driver (option in Error: Reference source not found).
   
4. 
   At any time after the driver had been signed, the hardware partner could optionally choose to publish the driver as optional ( in Error: Reference source not found) or as critical ( in Error: Reference source not found).
   
5. 
   The published driver was available to the public for Missing Driver, Update Driver, and (if requested and approved) AutoUpdate Driver scenarios.
   

2. Removing a Driver from Windows Update

The hardware partner had the ability to remove the published driver from Windows Update. This would revoke all three of the Windows Update publishing scenarios for the driver (refer to the Missing Driver, Update Driver, and Auto Update Driver scenarios in List ). Microsoft would still retain a copy of the driver in its internal repository. The hardware partner would still have access to download the signed driver even though it was no longer published on Windows Update.

4.