Understanding the new Windows update history experience
Published Feb 18 2021 10:00 AM 26K Views

This past October, we notified you that we were going to improve the Windows update history experience, particularly with regard to release notes. Our optimization efforts are complete and I'd like to take this opportunity to walk you through the changes and improvements.

KB identifiers and URL structure

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:

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.

For those of you who are familiar with viewing web-based source code, there is still a way to locate the KBID for future reference.

  1. Right-click on the article.
  2. Select “view page source."
  3. Look for <meta name="awa-kb_id" content="#######" />
  4. The number listed as the value for “content” is the KBID.

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.

Landing pages and update pages

There are two different types of articles that make up the Windows update history experience:

  • Landing/product pages
  • Update pages

Landing page and update pages for Windows 10, version 20H2 and Windows Server, version 20H2Landing page and update pages for Windows 10, version 20H2 and Windows Server, version 20H2

Landing pages

Landing/product pages supply details on the overall feature update release. These details may include information on the servicing lifecycle, known issues, troubleshooting, and related resources.

Update pages

Update pages supply information on a specific update. These updates service the operating system detailed on the landing page. On an update page, you'll find:

  • Highlights – fixes important to both consumer and commercial audiences.
  • Improvements and fixes – addressed issues in more detail specially targeted to commercial audiences.
  • Known issues with the update.
  • Information on how to get and install the update.
  • A detailed list of all files that were changed as part of the update.

File lists

Where the file list appears on the update history pagesWhere the file list appears on the update history pages

The file list can be found at the bottom of each update history page in the “How to get this update” section and enables you to track which system files were affected as part of the release. This allows you to gauge risk and impact. In prior releases, the file list was working improperly and not supplying the versioning or the architecture information for newer operating systems. With our new format, this issue is resolved and versioning is now working as expected. There are still files listed as “not applicable”, however, these are files that do not have versioning information. The files are also now organized by architecture, so it is easier to see which files belong to a specific architecture, as shown below:


RSS and article sharing

Really Simple Syndication (RSS) feeds will continue to be available for the Windows update history pages. If you are already subscribed to Windows update history RSS feeds, you will continue receiving updates and no further action is necessary. However, please note that the feature that allows the initiation of a new RSS subscription has been delayed and will be available in the next few months.

The ability to share an article via Facebook, LinkedIn, and email will be coming soon and we look forward to providing this new functionality for our customers. To make the wait worth it, here is a brief walkthrough of how it will work:

Share controls on the Windows update history pagesShare controls on the Windows update history pages


Selecting the Facebook icon will trigger the dialog below. You can then provide a comment and select whether to post to your story or your news feed.

Sharing a Windows update history page article via FacebookSharing a Windows update history page article via Facebook


To share an article on LinkedIn, select the Linked in icon, log in, and choose to share the post or send it as a private message.

Sharing a Windows update history page article via LinkedInSharing a Windows update history page article via LinkedIn


The ability to share articles via email works as it has previously. You will be able to select the envelope icon and your default email client will open a new email message with a link to the content embedded in the content.

Sharing a Windows update history page article via emailSharing a Windows update history page article via email


If you have feedback on this new experience, please feel free to reach out via the feedback options at the bottom of each article. Selecting “Yes” or “No” will provide you with a dialog to elaborate on how we are doing.

How to provide feedback on the Windows update history pagesHow to provide feedback on the Windows update history pages

We believe that these changes will make it easier for you to search for, and find, the resources you need to support and get the most out of your Windows experience. We look forward to bringing you future improvements!

Iron Contributor

Hi @Christine Ahonen 

If a KBID is not in the title, it will not appear in the URL.

Why can't you just add it to the url? You've got a title and a huge guid there already. KBID isn't an overhead. But no, you make us view or parse the source. 


Yourapproach doesn't make sense, but you don't really bother to explain it.




Hold the phone.  Enough.  Don't mess with my KB numbers this is how we all "speak" in terms of patches, patch management, etc.  I noticed that the other day when I was looking at a page and had to really search for it's KB number.

Clearly this is making it easier FOR YOU but not FOR US.  You remember, us?  Your customers?  The ones you should be making happy?  If it is a KB, then it needs to have a KB IN THE URL.  Period.

Copper Contributor

If you have a KB number, put it in the URL. If you're rewriting URLs anyway, you can come up with a scheme to include the KB. Consider Amazon's URL format (disclosure - this is to a book I co-wrote).


I can use any 10-digit ISBN number and look for it on Amazon using the form amazon.com/dp/<ISBN-10>. So if I type in amazon.com/dp/0135561086 it will rewrite to https://www.amazon.com/SQL-Server-2019-Administration-Inside/dp/0135561086/.


Note how the URL contains the ISBN number at the end of the rewritten URL, which is analogous to the KB number.


Don't remove the KB number from the URL. If you can put a GUID at the end, you can also include the KB number.

Copper Contributor

However, please note that the feature that allows the initiation of a new RSS subscription has been delayed and will be available in the next few months.

But facebook sharing was important to get through? :lol:

RSS is the ideal way to follow an update list like this, it's basically the perfect use case for RSS. Please get the easy-to-find links on the page as soon as possible.

For those of you who are familiar with viewing web-based source code, there is still a way to locate the KBID for future reference.

  1. Right-click on the article.
  2. Select “view page source."
  3. Look for <meta name="awa-kb_id" content="#######" />
  4. The number listed as the value for “content” is the KBID.

Wait what? Please consider a user-friendly and commonly understandable way.


There is DELL / Citrix / Commvault / Sophos everybody is using KBs in their URLs, what is the benefit of this change?

Copper Contributor

Please have the KB number as a search option in the title. Listing the updates as you have in the past has been instrumental for me in assisting both myself and my (and also your) customers. I do not believe this new change will make it easier for end users or the tech community to find these updates. If you are trying to make it better for your customers, I do not believe "This is the way".  Thank you.

Copper Contributor

When tackling updates, it's very common for me to just type support.microsoft.com/help/kb###### into the address bar. This is a *terrible* change, and I fail to see the benefit of it in any way.


Please reconsider/revert the change.

Iron Contributor

Here's a bookmarklet for those who want to create a simple url


from an ugly url like



1. Bookmark any page to your favorites bar

2. Edit the bookmark and replace the url with the code

javascript&colon;void(prompt("URL:", ("https://support.microsoft.com/kb/").concat(document.querySelector('meta[name="awa-kb_id"]').content)))

3. Visit the page with the ugly url and click the bookmarklet, then press Ctrl+C



This will work as long as they don't change or remove the meta name for the KBID in the page source. 


As a side note, this team won't communicate with the community - they never respond. I wonder why they keep the comments open. They already disabled editing comments, so the next logical step is to disable commenting. 

Thank you for your feedback. The primary concern seems to be around KBID’s so let’s dig into this a little bit further:

This is the result of our change over to a new Content Management System (CMS). This new CMS does not support the old URL patterns and so we needed to adapt to the new structure. To have this function like the old system, we have added redirectors to use both older patterns:

·        support.microsoft.com/help/KBID

·        support.microsoft.com/KB/KBID  

Typing either one of these old patterns will take you to the new URL. You can still link to the old URL patterns and it will take you or your customers to the correct location. Additionally, ALL Windows servicing update articles will have the KBID in the title. This means all the Windows security updates as well as the non-security updates. These articles will be fully searchable.


Moving on to RSS feeds. I believe Jay mentions above that it seems like we had prioritized Facebook sharing over RSS feed subscription.  Actually, both Facebook sharing and RSS feed subscription are delayed.  RSS subscriptions have been prioritized as first with the sharing functionality coming in a close second.


Finally, I would like to thank Vadim, thank you for the innovative tool! I’m sure that this will be of great benefit to this community. 

I will continue to monitor here for follow-up questions and respond as soon as possible.


I totally get it that you moved platforms and it's a publishing problem.  But AT A GLANCE (without looking at the source file of the web site) tell me what KB number this is?




I lost two hours on an early Saturday morning when that patch "paused" my VMs and my domain controller wouldn't boot.  Needless to say it sticks in my mind. But I can't visually see that KB number for it easily anymore.  


Without looking in the meta data, if you were tasked to block that update or review if it's been installed in systems knowing that it had a detrimental impact in HyperV deployments and kicked bitlocker recovery keys when installed on certain laptops, could you determine the KB number easily from that page?


You've also removed the publishing date metadata so that it's way harder to - again - at a glance - know when a KB has been updated.


None of these changes make our jobs easier.

Hi Susan,

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.

Thank you for actively caring @Christine Ahonen 

This was an update widely pushed to our machines, it wasn't an outlying article.  Any patch that comes down the Windows update pipeline labeled as "

Method 1: Windows Update 

This update is available through Windows Update. It will be downloaded and installed automatically.  "


The KB article for it should be clearly posted in the article so that one doesn't have to dig into the contents of it.


If something is going to be pushed through the Windows update channel, it needs a KB front and center.  Indeed what K_Wester said.  Thank you.  I know that this is just what you guys have to use/live with but these limitations cause inefficiencies.

Copper Contributor

So if I'm understanding this right, these changes are happening because of limitations in a new CMS, yes?

Then it sounds like you shouldn't move to this new CMS. In the tug of war between headaches for the hundreds of Windows Update team members versus headaches for the MILLIONS of IT pros out there, I think doing what's best for the customers takes precedence. So let's do everyone a favor: hit the pause button on the rollout.

Honestly, the reasons that you've given seem trivial to fix. I mean, come on, even the URL for this article has a numeric ID: 2146594. How hard can it be? All reasonable CMS will allow you to control the format of the URL, and allow you to template in specific data in each document. It's incomprehensible that Microsoft cannot have these features. You're MICROSOFT.


Unless, of course, there are ulterior motives for this otherwise inexplicable change. Is there something you want to tell the rest of the class, Christine?

Copper Contributor

So you changed the CMS and put the customer last since you probably don't have developers who will add support for KB IDs in your new CMS ? Are you nuts? Some long GUID replaces the KBID in the URL? Listen to your customers, don't get rid of KB ID from URL. Change your CMS then!!!

Copper Contributor

Hi all. Stumbled upon this from a news on whatever IT magazine I wandered upon.

Raised eyebrows on seeing the a multi-billion-NET-PROFIT-per-YEAR company not being able to anticipate a smooth transition to a new website engine.

Raised double eyebrows and rolling eyes when seeing that comment about "new CMS engine does not support maintaining old url" (which is not even a true obstacle by the way, webservers be it Apache or Nginx, can do silent and smooth url rewrite although this is certainly more complex than having the engine with all actual data manage it directly).

Wondered what CMS you could use, went to check on actual website if it was the one I though (disclaimer: I'm not a big Microsoft user, so not too familiar with the support website)... Then grinned hard because it was easy for me to check out my wild guess was right on point.


So two things (actually three).

1/ What you did was damaging for your community, and it clearly feels as a "Microsoft-centered first" change.

Not that it's anything new from my experience as a Microsoft Windows user, but that's another topic. XD

It is however very nice to see you acknowledge the problem at least, and are apparently looking for ways to make everyone happy (which is why I decided to create an account and contribute).


2/ Putting a one-way redirect was a good thing to do but, as everyone stressed, not sufficient.

And while creating url aliases that use "human words" is a good practice "in general", for a technical centric content database, it may not actually be the best move. Reasons behind such urls are "making easier for search engines to index and properly reference them" (still right here), making browsing easier for users (missed mark here: urls are often too long since generated from a lengthy oneliner).

I may be wrong (although I think not) in asserting that you can perfectly serve the same content under several urls without suffering penalties on SEO by clarifying to search engines that one is the canonical ("true") page while others are just "mirrors".

And I don't see why you would stop providing that way to browse updates content either. I mean, you necessarily had to keep that "KB id" information for all content in your new system, in order to set the oneway redirects (unless you made a separate handcrafted list? I cannot even envision that). So you necessarily have a field in which to continue storing the information for new contents. And you necessarily also still have the logic behind id generation, even if it's not (yet?) implemented on your website.

So you have the "datastore", the "id generation" logic, you just have to make your CMS use and expose them. Big deal? I don't think so. :)


3/ Fun fact: both operations you say are unsupported by your CMS aka a) providing "old way" to browse support content and b) "stamp the date upon publish" (which I guess is not just "update timestamp of last change" but "add a timestamp whenever the KB is updated on a stack historizing all updates")... Are both largely doable (just probably not from interface alone, that is true). Because I "know" the CMS you use.

In its latest iteration probably (I hope for you ^^). And no, I didn't do anything intrusive at all. I just know most of the times when a site is *-powered because many things in the global look and feel, navigation structure and html/css trees are so similar from one to another. So I'm 99% sure of myself. Any webdev with a bit of experience with the main competitors in the CMS ecosystem could do the same. :)


So, for the easiest thing: "provide a way for users to browse update informations with the old url system".

Two things: a) provide a way to browse with that url pattern, b) ensure a KB id is provided for new contents

I guess your "content" has been configured to use its "title" and "uuid" to generate those urls? But you must have another field that stores your internal KB identifier, let's call it 'kbi'.

For a), your devs must simply create a custom route with the old url structure, with a parameter, requiring that this parameter respects a specific pattern. Then associate that with a code that will simply fetch the content matching the provided KB, and "render" (display) it directly, or redirect to the "true" url.

For b), your devs simply have to...

- first, somewhere in their custom code, write the algorithm that generates the new KB.

- second, use something the engine provides to, just before a new content is saved, compute and set the value in your kbi field.


For the other thing, "stamp the publishing date", I'm not sure I understand the actual need (since, as said, I'm not familiar with MS updates), but if it's just about "expose to end-users some dates where the update has been modified" while it's certainly not doable from interface it shouldn't be too much trouble to do from code as well.


I refrained from publishing any example code or providing more precise indications here because I don't know if that would be appreciated, but I would gladly provide some on a more private channel if you would like. I of course have no actual idea on how your organized your data, but from an external point of view it should not represent a great deal of effort to make it work.


Good continuation to you. :)

Best regards,



Thank you everyone for the detailed feedback.  I will pass this along to our development team and keep you apprised of any future changes.




Silver Contributor

Thank you for sharing 

It is compliance with new cloud-based model where you have we have different and regular builds.

Dear @Christine Ahonen I am noticing some unfortunate issues with the new CMS.



1. some pages have a download icon but this one does not work anymore

random example:
Beschreibung von Windows Management Framework 3.0 für Windows 7 SP1 und Windows Server 2008 R2 SP1 (...

2. some downloads like SQL feature pack are missing the prefix \x86 or \x64 so one can only distinguish the correct architecture by the filesize (x64 is usually bigger)
Download Microsoft® SQL Server® 2012 SP4 Feature Pack from Official Microsoft Download Center


I believe this has changed with your new CMS. 




Thank you for your examples.  Item #1 is indeed an issue with our CMS.  I have forwarded that issue along to our developers.  Item#2 is a different tool. However, under the "Additional information" section you will find the link to submit bugs via Microsoft Connect.  This is the best way to get this feedback to this team.


Downloads Addtional info.gif

Hope this helps.





Hello @Christine Ahonen thanks for your ongoing support, quick and helpful replies here.
I understand the said reporting is refers to issues with the product, rather with the KB pages, isn't it? it would be a whole lot pages to report. The reason is that "Unfortunately" old pages hosting pre Service Pack versions are still online So for SQL 2015 it would be 4 pages alone + 2012 SQL + 2016 + 2017 and 2019 SQL. 
Could you imagine there is an easier way. Before the CMS update I have not seen this issue on the KB download page missing the folder prefixes.
Attached a screenshot for better understanding.



Iron Contributor

Oh, I was wrong when I stated that this team never responds. I guess they felt the heat from the customers this time and finally joined the discussion. Kudos to @Christine Ahonen

Let me comment on a couple of items then.


Finally, I would like to thank Vadim, thank you for the innovative tool! I’m sure that this will be of great benefit to this community. 

Please don't think that this tool solves the community problem. Nobody knows about this little bookmarklet.


The more we understand the way that customers use these ID's the better our resolution will be.

Let me provide you with one more example: URLs with non-Latin characters. Would you prefer to see this




or this



To put this in another perspective, here's a picture of the maximized Telegram messenger with the screen resolution of 1920x1200 (1080 woud've been even worse).


Do you like the top message better? :)




Iron Contributor

P.S. Well, I wasn't able to deliver the full point with non-latin URLs, let me try again (I can't edit posts, remember?)

How about this one?



And there's no place for KBID here. Right? LOL

Offtopic: "I can't edit posts, remember?" 

Editing posts was possible until a few weeks ago. Now it is only editable if you are the owner of the original post and reply. Reached out to a moderator but ultimately didn't help. 

Version history
Last update:
‎Feb 02 2023 10:21 AM
Updated by: