TL;DR: Some background on Windows Releases, and some speculation on why the latest build of Windows 10 Version 1803 has been delayed
BVT
My first job at Microsoft was working as a tester in the Windows NT build lab. First build 807. The job was to test Windows NT to ensure that it passed a series of automated regression tests, and met the basic functionality requirements to be sent out for broader testing within the Windows NT Product Groups. Called Build Verification Testing.
Testing things like Word, Excel, Notepad, Network Connectivity, printing, etc… Believe it or not, this was *before* Internet Explorer. so no Web browsing.
The idea is that if you could *not* perform some basic operations, then you wouldn’t want the build to get out to the larger test org, so they don’t have to waste their time on a build version that can’t even run notepad.
Windows 10
Which brings up back to Windows 10. There are a lot of testing phases involved with Windows 10. Each phase involves more people, broader testing, each phase, hopefully testing more functionality in the OS:
- Build lab testing (BVT)
- Microsoft internal testing
- Fast Ring ( external to Microsoft )
- Slow Ring
- Semi-Annual Channel – Targeted ( Official release ) – RTM
- Semi-Annual Channel ( Broad Deployment )
I still call the full releases “RTM” Release to Manufacturing, although for most builds, they get published to Windows Update and/or the volume licensing sites. There are still some builds that actually get put on USB Sticks, so I guess there is a factory… somewhere.
Cumulative Updates
Additionally Patches ( Cumulative updates ) also follow a Fast/Slow/Release schedule, so if you wanted to you could be deploying pre-release Cumulative updates to your test machines to get ahead of potential problems.
What’s interesting is that as of this post, the Cumulative Updates for Windows 10 version 1803 are already up to 17133.73! Seventy Three builds since the start.
For most minor bugs that are identified after an OS is released, Microsoft has a well defined update process defined that can update and fix most issues. If you find a minor bug in notepad, then don’t release the FULL OS again, just send out the CU notepad fix via Windows Update!
Showstoppers
Not all builds make it to the next level. Sometimes the builds are just tests, and there is no need for them to continue on, they don’t have the final set of features, or have too many bugs.
But what could cause a build that nears full release to get reset like 1803? I don’t know the exact details of what is causing 17133 to have problems, but I know it’s not a minor problem. Again, minor problems can and *should* be fixed via Cumulative Updates.
Instead I speculate the problem can’t be fixed by Cumulative Update, or some other problem that prevents some machines from even installing CU’s.
That would be bad. This is my thoughts of why 17133 is delayed.
Take away
Sometimes we as IT professionals get so wrapped up in just one kind of testing that we forget to test all the environments. Perhaps we are only testing the bare-metal OS Wipe and Load process, or just testing In-Place upgrade. Really we need to test both.
(I Have a client that just had this problem, they were only testing Bare Metal Wipe and Load scenarios, and were surprised that a couple of Dell’s didn’t survive a In-Place upgrade to 1709, even though we strongly recommended In-Place upgrade testing across a wide selection of hardware types).
Additionally, add at least one Cumulative Update to your testing procedures, if you can’t service a machine after installing an OS, then you are going to have problems sometime in the future :).
-k
Keith's Consulting Blog 