Troubleshooting Windows 11 Upgrade: Delivery Optimization Error 0x80D02002

Introduction

If you’re trying to upgrade from Windows 10 to Windows 11 using SCCM Feature Update and run into Error 0x80D02002 – “Download of a file saw no progress within the defined period,” don’t worry, you’re not alone.
Delivery Optimization sometimes goes a bit too far, grabbing content from wherever it can find it. And when we try to troubleshoot, we might notice something strange: our computers trying to get content directly from WSUS instead of the Distribution Point or Peers, which is totally wrong. It seems like the technology combination of WSUS and Delivery Optimization wasn’t fully considered in the context of SCCM. This can be partially controlled with the right policies, but not 100%, especially in larger or enterprise environments where complexity increases.

How did you figure that out?

In the Software Center, downloads are stuck at 0% progress. The first thing an administrator checks is: Is the content on the Distribution Point? Are the boundaries set up correctly? How do other clients on the same subnet behave? All good, but with Delivery Optimization, where files are downloaded from peers, the situation has changed with UUP. You can use a PowerShell command on the client to determine where it intends to download the contents:

Get-DeliveryOptimizationStatus 

Here’s where it gets interesting. If the SourceURL points to the WSUS server, the client attempts to download the contents from the WSUS instead of from a peer. Here’s an example from the IIS logs on the WSUS server sorted by “Microsoft-Delivery-Optimization”: A GET request returns the Error 404, indicating that the content cannot be found:

How can I prevent downloads from getting stuck like this?

Here’s the simple workaround: I created a Dummy_Group on the WSUS server. This ensures that UUP updates are automatically downloaded to the server when needed, preventing the issue of downloads getting stuck.

Connect to your WSUS server and open Update Services. Right-click on Computers and select “Add Computer Group…”. and create a group, for example, “Dummy_Group”.

Set up an automatic approval process for your UUP-based ADR groups, and assign the approval to the Dummy_Group.

Finally, add the Windows Updates and Revisions settings under Advanced to ensure everything runs automatically. After that, run the WSUS sync, and the contents will be downloaded automatically. On the next attempt, the client will be able to download the contents.

Any other considerations to ensure UUP and Delivery Optimization work?

Yes, absolutely, there are various things to consider, most of which have already been outlined by Microsoft:
Unified update platform (UUP) FAQ’s – Microsoft Community Hub

However, based on my experience, I noticed that the UpdateServiceUrlAlternate Registry setting http://localhost:8005 for Delivery Optimization is sometimes missing, even with the SCCM Client settings. So, I wrote a baseline and deployed it to the clients to ensure that the registry is always present:

Evaluation:

# Path to the registry key
$registryPath = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate"
# Name of the REG_SZ value
$valueName = "UpdateServiceUrlAlternate"
# Expected value
$expectedValue = "http://localhost:8005"

# Check whether the value exists and is correct
try {
    $valueData = Get-ItemProperty -Path $registryPath -Name $valueName -ErrorAction SilentlyContinue
    if ($valueData.$valueName -eq $expectedValue) {
        Write-Host "Compliant"
    } else {
        Write-Host "Non-Compliant"
    }
} catch {
    Write-Host "Non-Compliant"
}

Remediation:

# Path to the registry key
$registryPath = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate"
# Name of the REG_SZ value
$valueName = "UpdateServiceUrlAlternate"
# Expected value
$expectedValue = 'http://localhost:8005'

# Check and create the registry key if required
if (-not (Test-Path $registryPath)) {
    New-Item -Path $registryPath -Force
}

# Create or update the registry value
Set-ItemProperty -Path $registryPath -Name $valueName -Value $expectedValue -Type String

Conclusion

In conclusion, it seems like there may be a bug that can be fixed with a workaround. Not every Delivery Optimization error indicates a problem; some arise because the peer is unreachable. Factors such as network configurations, firewalls, and proxies can contribute to these issues. In our case, we prioritized Delivery Optimization and WSUS. This scenario was successfully tested in a large environment. I hope the post has been helpful to you. Best of luck!