Obviously YMMV but I set out to try to answer the question a lot of us have especially lately on the eves of 1809 being released, but wanting to keep our old/older versions of Win10 since they “work”.
All testing done on a fresh installed Pro 1703 Guest Hyper-V VM, which was not connected to the internet until Automatic Updates could be Disabled in Group Policy. This is under Administrative Templates\Computer Configuration\Windows Components\Windows Update\Configure Automatic Updates = Disabled (0). I used 1703 for 2 reasons – 1) it’s the oldest Win10 retail (non-LTSB) ISO I have on hand, and 2) there are obviously 2 Feature updates currently out that supersede 1703, those being 1709 and 1803. This would give me good, potential real-world results on what we can expect once 1809 is released.
Once rebooted and connected to my Bridged vNIC (which connects the VM to my physical network as if it were a physical machine and assigns it its own IP address), I grabbed both WUMT and wushowhide, in an effort to test both of these as well and see if there was any difference (answer: there wasn’t/isn’t).
Random but related thought: I noticed that you can change the Branch and Feature and Quality deferrals in GP under Administrative Templates\Computer Configuration\Windows Components\Windows Update\Defer Windows Updates, but the settings in Settings are never shown to reflect your new GP settings unless you use MS’ Settings panel to check for updates; once you trigger an update check, the deferrals in GP are shown and grayed out in Advanced Options.
My hypothesis is that if you have your current machine set to Current Branch for Business (CBB) / Semi Annual Channel (SAC), and you have deferrals set for at least Feature Updates to some extent, if your machine wants to grab and update, it will grab one of the older ones, and not 1809. This is what I want and hope, at least, and I think most others feel the same way. We can safely assume that 1809 will be released under the Current Branch (CB) / Semi Annual Channel (Targeted) [SACT] branch when released, if history repeats, as it should. 1809 should be CB/SACT (and NOT CBB/SAC) for 2-3 months after release, unless MS flips the switch even sooner than they did with 1803.
The good news is, after testing, my hypothesis rings true.
After installing all updates from July 2018 or older (using WUMT), I started playing with Feature Update deferrals.
With Feature Update deferrals set to 221 days, I was offered the 1709 update (KB4343897).
(Obviously between 222 days – 365 days, I was not offered any Feature updates.)
The 1709 Feature update was offered with deferrals set between 221 days – 49 days.
With it set to 48 days, I was offered the 1803 update (KB4343909).
Again, this shows my hypothesis to be correct. Depending on your deferrals, if you want to keep ‘what you have’, set them now! Or, at least before 1809 is changed to the CBB/SAC branch which I would imagine will be sometime right before Christmas. (Merry Christmas from the Grinches at Microsoft!)
I would also like to mention, again, that WUMT and wushowhide provided the same results. I know people cast some doubt on the legitimacy of WUMT as a 3rd-party, possibly sketchy solution, but I’m here to dispel those thoughts and say that in my experience, with this experiment, WUMT performed exactly identical to wushowhide, MS’ official mechanism for controlling and hiding/not installing updates. Obviously WUMT has a lot more features under its belt, but if you grab WUMT from MajorGeeks (https://www.majorgeeks.com/files/details/windows_update_minitool.html), you have a good, virus/malware-free copy of the application and can use it in good faith.
In closing, I hope you find this post helpful. I know it set my mind somewhat at ease, because I quite like 1709, and plan on going to 1803 when I have to, not 1809. This experiment shows me that I’ll be able to do just that, while 1809 sits in the kettle cooker for a bit longer and matures.
