Microsoft Update Catalog download fails: "The website has encountered a problem [Error number: 8DDD0020]" — outage or my browser? Workaround

The test is which part fails.

A real catalog outage takes the whole site: search returns nothing, or the page itself 5xxs, or the hostname does not answer. If the search page renders results and only the download popup dies with 8DDD0020, that is not an outage, that is the download path.

The diagnosis people have converged on in the thread on Microsoft's own Q&A site is mixed content. The catalog's download popup is built on old plumbing and hands the browser an http:// stream from an https:// page. Modern Edge, Chrome and Firefox block that silently, and what you see is a blank popup or that error number. It explains the pattern you describe exactly: cross-browser, cross-OS, cross-ISP, because it is the browsers that changed, not your network.

Workaround from that thread, per site:

1. click the settings icon to the left of the URL
2. open the site permissions for catalog.update.microsoft.com
3. make sure JavaScript and DOM storage are allowed
4. change "Insecure content" from Block to Allow for that domain

Honest caveat: that is the community diagnosis, not an official statement. I could not find a Microsoft root cause note or a server-side fix announcement for it.

General rule for "is it them" that has served me well: one endpoint broken in one specific way is almost always you. Several unrelated services broken at once is them.

Worth knowing that both patterns have happened here inside a few weeks. On 23 July there was a genuine Azure-side event that took Windows Update, the Microsoft Update Catalog, the Microsoft Store, WSUS and Teams together — started late morning Pacific, resolution complete a couple of hours later. That one was unmistakable because five things you never think about failed simultaneously.

What you are describing is the opposite shape: one narrow function of one site, reproducing identically everywhere. Check the Azure status page and your service health dashboard first because it costs thirty seconds, and when they are green, believe them and go look at the browser.

Once the popup is working again, do the thing that stops this being a problem next time: copy the direct .msu download URL into your runbook next to the KB number, along with the file hash.

The catalog website is a discovery tool. The file behind it is just an object on a CDN. If you already have the URL from a previous cycle you can fetch it with curl or Invoke-WebRequest without touching the site at all. Verify the hash every time, because URLs do get re-pointed.

For anything automated, remove the dependency entirely. Fetch the .msu once by hand, put it in your own artifact storage, record the SHA-256, and have the patch job pull from there. Then a browser regression or a bad afternoon at the vendor cannot block a patch cycle.

The general principle: a website in the critical path of your automation is an outage waiting for a date.

One more thing to rule out before you escalate: TLS inspection. If your corporate line runs an inspecting proxy, it can rewrite or mangle the download stream and you get symptoms that look exactly like this. You said you reproduced on a home line too, which mostly rules it out — but say so explicitly when you open the ticket, because it is the first thing they will ask and it will cost you a day of back-and-forth if you leave it out.

This smells like name resolution. Flush your DNS, reset winsock, try a different resolver. Half the "site is down" reports I get turn out to be a stale DNS cache.