Microsoft's decision to hide KB identifiers from some Windows update support documents is unhelpful madness

For years, Microsoft has used KB identifiers (or knowledge base identifiers that take the form KBXXXXXXX) to refer to updates for Windows. As well as being a handy means of identifying a particular update, it also provides an easy way to cross reference the same updates across various pieces of documentation.

But last month Microsoft announced that it is changing the system. The company is not getting rid of KB identifiers, but it is changing the way they are used in release notes and support documentation. In many instances, the KB identifier will be hidden in the source code of web pages -- something even Microsoft concedes is "not ideal".

See also:

• Microsoft confirms printing problems and blue screens after latest Windows 10 updates
• Microsoft is pretty much giving up on 3D in Windows 10
• Microsoft releases KB5000802 and KB5000808 updates for Windows 10 -- and there are already problems

In a recent post on the Windows IT Pro blog, Microsoft's Christine Ahonen explains: "One of the primary ways that many find release notes is through the use of a KB identifier (KBID). We use a unique identifier for each Windows update. Once a KBID is created, it is then used to identify the update throughout the release process, including documentation. In the older experience, the KBID was used in several different ways: In the URL (e.g. https://support.microsoft.com/help/#######); In the article title; In the article metadata; As a reference in the body of the article (e.g. pointing to other relevant articles)".

Referencing a notification published back in October, Ahonen goes on to detail how the new system will work;

With the new experience, many of these methods are still utilized, just in different ways. For instance, the URL structure of https://support.microsoft.com/help/<KBID> is still supported, however, it will redirect to a newly formatted URL https://support.microsoft.com/<locale>/topic/<article-title><GUID>. Additionally, if a KBID appears in the title of a page, it will appear in the URL. If a KBID is not in the title, it will not appear in the URL. Types of articles where you may not find a KBID include informational articles and articles released for non-cumulative updates or specialty packages.

So what about the support articles for which a KB identifier is not immediately visible? This is where "those of you who are familiar with viewing web-based source code" are invited to take a peek at the code of a page in order to gather this useful snippet of data.

Ahonen says:

We understand that this workaround is not ideal and are working to find a more user-friendly means of providing this ID within the article body.

Perhaps unsurprisingly, the response to this change has not been particularly positive. With so many people having become so used to the way KB identifiers have been used by Microsoft for so many years, the change -- which is necessitated by the fact that a new CMS used by Microsoft "does not support the old URL patterns" -- has angered many people including MVP Susan Bradley. She complains that the new system makes it much more difficult to determine the KB number of a particular update from support documentation. She also complains that the new system means that the date articles were published is also not visible which makes it harder to tell when a page was last updated.

Ahonen responded to these points saying:

I agree that it is frustrating not to be able to find the KBID on the page or in the URL for some of these outlying articles. We are looking at various solutions to work around the limitation.  The more we understand the way that customers use these ID's the better our resolution will be.  That's why feedback like yours and the other members here is so valuable.

Regarding the publishing date, this is another limitation of the CMS.  The old system used to stamp the date upon publish. The newer system does not provide this capability but there are manual ways we can look at working around this.  I will pass this feedback along to the team and see what we can do.

While it is clear that the change is the result of implementing a new CMS, it beggars belief that Microsoft was happy to switch to a new system that makes such a fundamental change that impacts on so many people in such a detrimental way. And with the company's track record of problematic updates, the need to be able to easily cross-reference support documents and updates' KB identifiers is hugely important.

Image credit: JeanLucIchard / Shutterstock