As part of Microsoft’s commitment to improving Windows quality through more predictable and reliable update delivery, we are introducing a new capability that will give submission owners control over Driver Update Acceptance (DUA) creation on shared submissions. This opt-in, per-sharing-shipping-label control will allow submission owners to explicitly block receivers from creating DUA submissions on shared content — providing greater flexibility and control over driver distribution. Receivers who use automation to create DUA submissions on shared products should update their code to handle the new error responses. Default behavior will remain unchanged — DUA creation will be allowed unless the owner explicitly enables the block.
Note: This blog is intended for Microsoft partners who share or receive shared driver submissions through the Partner Center portal or API.
What's Changing
A new per-sharing-shipping-label control will allow submission owners to block DUA creation by receivers of shared submissions. When selected on a sharing shipping label, receivers will not be able to:
- Download the DUA shell
- Create new DUA (derived) submissions
The only allowed action on a DUA-blocked shared submission is publishing the driver to Windows Update as-is.
For Submission Owners
In the Partner Center Portal
When creating or editing a sharing shipping label, you will see a new option under the Properties section to block DUA creation by the receiver.
- The option is off by default — existing behavior is preserved unless you opt in.
- You can enable or disable this setting at any time, even on existing shipping labels.
- The setting applies per sharing shipping label. Different shipping labels for the same submission can have different DUA policies.
- If you share to multiple partners in a single request, the same setting applies to each resulting shipping label.
In the API
A new boolean field blockDuaCreation will be added to the existing recipientSpecifications object on sharing shipping labels, alongside the existing enforceChidTargeting property. It will be available in POST (create), GET (read), and PATCH (update) shipping label calls.
Creating a shipping label (POST):
{
"recipientSpecifications": {
"receiverPublisherId": "2600000",
"enforceChidTargeting": false,
"blockDuaCreation": true
}
}
Reading a shipping label (GET): The blockDuaCreation field will be returned in the response so you can confirm the current setting.
Updating a shipping label (PATCH): You can now include recipientSpecifications (with blockDuaCreation and enforceChidTargeting) in the PATCH payload.
{
"recipientSpecifications": {
"blockDuaCreation": true,
"enforceChidTargeting": true
},
"targeting": {
.
.
}
}
For Submission Receivers
In the Partner Center Portal
When a submission owner has blocked DUA creation on a shared submission:
- The "Upload new" and "Download DUA shell" buttons will be disabled (greyed out).
- A message will be displayed: "Driver Update Acceptance (DUA) creation has been restricted by the submission owner. The DUA shell is not available for download."
You can still create publishing shipping labels and publish the shared driver to Windows Update.
In the API
GET Submission: When DUA creation is blocked, the derivedPackage download link will be excluded from the response, and a restriction message will be included:
{
"downloads": {
"items": [
{ "type": "initialPackage", "url": "..." },
{ "type": "signedPackage", "url": "..." },
{ "type": "driverMetadata", "url": "..." }
],
"messages": [
{
"message": "Driver Update Acceptance(DUA) creation has been restricted by the submission owner. The DUA shell is not available for download."
}
]
}
}
POST Create Derived Submission: Attempting to create a DUA submission when blocked will return HTTP 412 Precondition Failed:
{
"error": {
"code": "DUACreationNotAllowed",
"message": "Driver Update Acceptance(DUA) creation has been restricted by the submission owner for this shared submission."
}
}
Action Required for API Consumers
If your automation creates DUA submissions on shared products, you must update your code to handle:
- The new DUACreationNotAllowed error code (HTTP 412) when attempting to create a derived submission.
- The potential absence of derivedPackage in the downloads.items list when calling GET Submission.
- The new messages array in the downloads response, which will contain a restriction message when DUA creation is blocked.
Failing to handle these responses may cause your automation to break when an owner enables the DUA block on a submission shared with you.
Timeline
- This new feature and the API will be available Starting May 18th.
- Documentation and resources will be published before general availability
Next Steps
- Review your current sharing and DUA workflows to understand where this control might benefit your scenarios.
- Engage with your partner counterparts to discuss how this feature might affect your existing agreements.
- Update your API automation to handle the new DUACreationNotAllowed error code (HTTP 412) and the absence of derivedPackage and the new messages array in the downloads response in GET Submission responses if you create DUA submissions on shared products.
- Contact support if you have questions or concerns about this capability through the Partner Center support channel.
⚠️ Important: Avoid strict JSON parsing
The Hardware Dev Center API may add new properties to responses at any time as part of non-breaking, additive changes. Your client must not use strict JSON deserialization that rejects unknown properties.
-
-
- System.Text.Json — Do not set JsonSerializerOptions.UnmappedMemberHandling = JsonUnmappedMemberHandling.Disallow. The default behavior (ignoring unknown properties) is correct.
- Newtonsoft.Json — Do not set MissingMemberHandling = MissingMemberHandling.Error. The default behavior is correct.
- General — If you use schema validation or strict contracts, ensure they allow additional properties.
-
This applies to all Hardware Dev Center API responses, not just this change.
FAQs
Q: Will my existing DUA submissions be affected when the owner enables the block?
A: No. Existing DUA submissions are not retroactively affected. The block only prevents future DUA creation on the shared submission.
Q: Can the owner change the setting after the shipping label is already shared?
A: Yes. The owner can enable or disable the block at any time via the Partner Center portal or the PATCH API. The change takes effect immediately.
Q: Does this require a new API version?
A: No. The blockDuaCreation field is an additive, non-breaking change. Existing API clients that do not send or read this field will continue to work as before.
Q: What happens if the owner blocks DUA on one shipping label but not another for the same submission?
A: Each shipping label has its own DUA policy. A receiver will be blocked from creating DUAs only on the specific shared submission associated with a shipping label where the block is enabled.
Q: I receive shared submissions from multiple partners. Do I need to change anything right now?
A: If your automation creates DUA submissions on shared products, you should update your code to handle the new error responses. If you only publish shared drivers to Windows Update without creating DUAs, no changes are needed.
Q: What if I need DUA for a specific shared submission where the owner has blocked it?
A: Work directly with the submission owner. They can disable the block on the relevant shipping label at any time via the portal or the PATCH API, and the change takes effect immediately.
Q: Can I block DUA for specific Hardware IDs on a shipping label?
A: No. The setting applies to the entire sharing shipping label. Use separate shipping labels if you need different DUA policies per Hardware ID.
Additional Information
- DUA documentation: Hardware submission update (DUA)
- Hardware API documentation: Hardware API
Microsoft