Microsoft Update Catalog - searching for firmware updates stopped working

Question

We are used to search for firmware updates in Microsoft Update Catalog by UEFI res ID (e.g. uefi\res_{da6b5517-b8a0-4028-9b59-23c3ede398d1}) to obtain the UEFI/capsule firmware update.

This has stopped working since last week!

Although the ID is listed among the supported hardware IDs, searching for it returns no results. For example: Update ID 1cc29a9a-ba3c-4d80-9a5e-d8348915d9e3.

Searching for driver updates using the PnP ID still works.

Answer 1

Hi there,

I am following up on this because the behavior you observed (searching by Hardware ID failing suddenly) is technically significant. It is highly probable that the search indexer has been updated to treat special characters like backslashes (\) and underscores (_) as "word breakers" or escape characters rather than literal string literals. This causes a query like uefi\res_{...} to be parsed as separate, unrelated terms rather than a single contiguous hardware identifier, returning zero results.

To bypass this tokenizer regression without leaving the Catalog interface, you should try searching for the GUID portion only, completely stripping the uefi\res_ prefix and the curly braces. For example, enter da6b5517-b8a0-4028-9b59-23c3ede398d1 directly into the search bar. The search index usually stores the GUID as a distinct, searchable token (or "word") independent of its path prefix. If the specific algorithm requires the exact Hardware ID string to be matched and refuses the GUID alone, this confirms a deeper regression in the schema mapping, in which case the Google site-search method mentioned previously is the only immediate external bypass.

From an automation perspective, if you are scraping these results for a deployment pipeline, relying on the Catalog's web search is risky as it is not an SLA-backed API. A more resilient engineering approach for retrieving these capsule updates is to utilize the Windows Update Agent (WUA) API directly. You can use a PowerShell script invoking the Microsoft.Update.Session COM object to query Search("IsInstalled=0 and Type='Driver'") against the "Microsoft Update" ServiceID. This queries the upstream metadata servers directly, bypassing the web frontend's broken search logic, and will return the precise UpdateID and DownloadUrl for the firmware applicable to the hardware ID detected by the OS.

I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

VP

Answer 2

Hi Stefan Müller,

Actually this is a known quirk of the Microsoft Update Catalog search engine that surfaces periodically. The search backend frequently changes how it indexes "Hardware IDs" versus "Strict Keywords."

It appears that Microsoft has recently tweaked the indexing logic for the public-facing Catalog search bar. It often stops indexing specific namespace strings like UEFI\RES_ or ACPI\VEN_ to improve query performance, restricting "ID-based" searches to standard PnP enumerators like PCI\ or USB.

Since you rely on this for automation or specific targeting, here are the three effective workarounds to find your firmware updates when the direct ID search fails.

1: The "Google Dork" Method (Most Effective)

The internal search engine of the Update Catalog is often worse than external search engines indexing it. Google or Bing usually capture the text on the page (which lists the supported Hardware IDs) even when the site's own search bar ignores them.

Try searching this string in Google/Bing: site:catalog.update.microsoft.com "uefi\res_{da6b5517-b8a0-4028-9b59-23c3ede398d1}"

This bypasses the Catalog's broken indexer and points you directly to the page where that text exists.

Workaround 2: Search by Update ID (If known)

You mentioned you found the Update ID (1cc29a9a...) as proof. If you are tracking these updates via a script or WSUS feed, searching by the Update ID is the only method guaranteed to never break.

Query: 1cc29a9a-ba3c-4d80-9a5e-d8348915d9e3

Note: I realize you usually search the UEFI ID to find the Update ID, so this helps only for verification, not discovery.

Workaround 3: Broaden the Search to "Model + Firmware"

Since UEFI\RES IDs are unique to a specific Firmware Capsule, usually tied to a specific System SKU (SystemProductModel), you must revert to searching for the text description.

Instead of searching for the ID, search for the System Model Name + "Firmware".

Example: Surface Pro 7 Firmware or Dell Latitude 5420 System Firmware.

Once the results appear, click the "Date" column header twice to sort by Newest. The latest firmware usually supersedes the specific GUID you were looking for anyway.

I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to ACCEPT ANSWER. Should you have more questions, feel free to leave a message. Have a nice day!

VPHAN

Answer 3

Hello Stefan Müller,

I am glad to confirm that the GUID-only method restored the functionality for you. To answer your question about why this stopped working after years of stability, it is almost certainly due to a backend change in the Microsoft Update Catalog's search indexing engine. The search service likely migrated to a newer tokenization model (similar to Azure Search or updated SQL Full-Text Search) where characters like backslashes (\) and underscores (_) are now interpreted as word-breakers or escape characters rather than parts of a literal string. Previously, the indexer mapped the full uefi\res_GUID string as a single token; now, it splits them, causing exact match queries to fail. By searching for the GUID alone, you are providing a clean, unique alphanumeric token that bypasses these complex delimiter rules.

Regarding your ConfigManager workflow, since you are iterating through a hardware inventory list rather than querying a live local system, the WUA API approach I mentioned is indeed not applicable. For your specific use case, the most robust fix is to modify your PowerShell scraping logic to preprocess the hardware IDs. You should implement a regex replace function to strip the uefi\res_ prefix and curly braces from the inventory data before sending the query to the Catalog. This ensures that your automation remains resilient against future changes to how the Catalog handles namespace prefixes or special characters.

If the issue has been successfully resolved, please consider accepting the answer as it helps other people sharing the same question benefit too. Thank you!

VP