|
There are isolated problems with current patches, but they are well-known and documented on this site. |
So you want to ensure you get feature release XXXX and no later than that right? So you are on 1903, you forgot to download the 1909 iso and yet you
[See the full post at: Patch Lady – my favorite new windows update setting]
Susan Bradley Patch Lady/Prudent patcher
If I use “Select the target Feature Update version”, should I disable “Select when Preview Builds and Feature Updates are received”? I’m using the latter now.
You should use either TargetReleaseVersion or Feature Deferrals , but not both. If you use TargetReleaseVersion, set deferrals to 0 0r 1, as they are going to be ignored anyway.
It means ANY Feature deferral. Wherever you set it.
You should only use EITHER TargetReleaseVersion OR Feature deferral.
NOT both.
So, if you use TargetReleaseVersion, set deferrals to 0 0r 1, as they are going to be ignored anyway.
I felt that the deferral pulldown and the GP setting would achieve the same outcome, but just wanted to be sure. I had 365 Feature deferral set as well as the Target Release Version set to 1909; I’m glad I read Susan’s article this morning.
Edit: I also notice it’s in your revised version of AKB2000016. I should have read more carefully 
This way I’m good until well into next year, if that proves necessary. I also have an ISO of v2004 build 19041.450 (August 11) stored, just in case it’s ever needed.
Thank you for the clarification. I’ve removed Feature deferrals and now just have the GP setting – 1909.
Read Section 1 on “Setting TargetReleaseVersion” in AKB2000016.
**NOTE: According to official sources, these settings are ignored in Home Edition, but at the current time, it appears that the manually made settings in the Policy section of the Registry also work for Home Edition. That may be changed by Microsoft in the future.
So WU Blockers are still a reliable safeguard for Home Editions – curiousity satisfied
I’d certainly feel safer using a 3rd party blocker with WUShowhide or WUMgr on a metered connection if I were a home edition user.
Thanks PK
We have LSTC entry 2016 (which is 1607 I believe) and 2019 entry (1809). We buy these for our Advantech touch panels, but there was this “jump” between them. I was asking Advantech for the most recent LSTC and he said, that 2019 entry is the latest we can get
Neverthe less, I think, that mr. Anonymous might be actually right. Im not sure, but LSTC does not mean your PC will not update if you click the button. I was warned aboud this. Its just that your license is supported 10 years. That does not mean it works differently from other Windows 10.
Never the less LSTC is not for Office computers, so.. maybe mr. Anonymous is using this wrong for office PC.
Also, I locked our LSTC panels with EWFMGR (it is similar to Windows emebded in the past). Changes are simply lost after restart. So if anybody (by accident) clicks the button, these changes will be wiped next reboot.
BTW setiting up kiosk in Windows 10 is one of its best features remaining hidden to vast majority of users! Wonder why, lot customer whants exactly that!
Dell Latitude 3420, Intel Core i7 @ 2.8 GHz, 16GB RAM, W10 22H2 Enterprise
HAL3000, AMD Athlon 200GE @ 3,4 GHz, 8GB RAM, Fedora 29
PRUSA i3 MK3S+
If you “check for updates” whatever is in preview – for example the preview cumulative updates – will come down. You can “let” the machine find the feature release but when I’m in an impatient mode, I will – depending on the date on the calendar – click on check for updates. LTSC 1809 will stay on 1809. It will get monthly updates and preview updates though anytime you click on check for updates.
Susan Bradley Patch Lady/Prudent patcher
The defer for 365 days triggers inadvertent installs. You could always build and export out the reg key and use that method.
Susan Bradley Patch Lady/Prudent patcher
The reg key is srill something you send people and you need admin rights ro apply
As long as the machines are on a network you can get to and you have admin credentials, you will be able to apply that registry key remotely – using Powershell etc.
cheers, Paul
I have never had the 365 deferral cause an inadvertent install, as long as you are aware of the version the PC is on and the 365-day point of the next released version. I don’t believe that function is broken.
But it can happen if you just leave PCs unattended/unmonitored. If you have all PCs on the same version, and all set to 365-days, that’s fine. If, on the other hand, the PCs are on different versions and you have MANY, it can be almost impossible to keep up individually. So in that case, TargetReleaseVersion is safer b/c is assures all PCs are at the same point and you can set a timetable/schedule for change.
What I see is the big difference between a business environment where mass control is needed and the consumer environment where individual control/attention is possible
Yes, I am kind of in-between. We have a good amount of stations and laptops, but not on the same network, scattered across North America. I wouldn’t say at all I am close to a consumer environment, but I am a bit of a rogue for managing PCs. I don’t care that they don’t run the same version, as long as they run an old supported version and update without issues by themselves.
For me, the GP deferral worked fine until now, except that feature updates sometimes didn’t install until I manually green lighted them, even if support had ended. I had stations sitting with feature updates waiting and never installing until the user clicked install. That’s pretty bad security-wise, but it is interesting that I had this problem while everyone else seemed to struggle to not get those feature updates. I don’t think it does that anymore. Maybe it was a bug on one of the older versions. I got normal updates until the feature update and then it waited for the user to click install now and never installed by itself.
The setting is interesting if you want to skip versions and run the same version a bit longer than the few months of support remaining when you defer 365 days.
Remember Susan comes from a business environment where control of updating must be applied to many PCs and not on an individual PC basis. In that environment, the IT manager cannot keep up with the settings for hundreds of individual machines. So a setting needs to be “set and forget,” and the settings everywhere changed to known values according to a company standard, on a set schedule/timetable.
On the other hand, the consumer environment is quite different. A great number of consumers are on default settings and completely unaware of controls to updating. Those who are somewhat technically inclined are usually focused on one, or a limited number of PCs. They are more aware of settings, the update cycle, and EOLs of each version. They usually know where their machines stand in relation to these points.
So, given those differences in environment, it is much easier for IT to set every PC at a known value and schedule coordinated changes to achieve their goals. In this case, TargetReleaseVersion is a much better, safer solution.
The consumer has more latitude. Using TargetReleaseVersion is easy because of awareness of the version the PC is currently on, and being able to make a choice of which version is desirable. So this is one way to control Feature updates.
But all of the consumer’s machines do not have to be on the same version at the same time, or meet a set standard/timeline, like in the business environment. If deferrals are used, instead of TargetReleaseVersion, the consumer can be aware of the end of each deferral period and the EOL of the version, and not be a victim of forced upgrades every six months.
So consumers have more leeway in choosing between TargetReleaseVersion and Feature Deferrals. As a consumer, you should choose the one that works best for you.
**** However, one thing is clear. Use EITHER TargetReleaseVersion OR Feature deferrals, but NOT BOTH. If you use TargetReleaseVersion, set deferrals to 0 0r 1, as they are going to be ignored anyway.
In a post above (#2306443), PKCano said:
**** However, one thing is clear. Use EITHER TargetReleaseVersion OR Feature deferrals, but NOT BOTH.
This statement is not quite correct.
When I look over the Microsoft documentation (linked to in post #2306251) it says, regarding the Group Policy Setting “Select the target Feature Update version”:
When you use this policy, specify the version that you want your device(s) to use. If you don’t update this before the device reaches end of service, the device will automatically be updated once it is 60 days past end of service for its edition.
When you set the target version policy, if you specify a feature update version that is older than your current version or set a value that isn’t valid, the device will not receive any feature updates until the policy is updated. When you specify target version policy, feature update deferrals will not be in effect.
Therefore:
#1 – Setting the target release version will invalidate the other deferral settings. (i.e. Any deferral values do not matter.)
#2 – Setting a target to an older or invalid version will PERMANENTLY DEFER any feature updates until the policy is changed.
This looks like a backdoor trick to guarantee that no Feature Update will occur until you want it.
I don’t see where that invalidates “Use EITHER TargetReleaseVersion OR Feature deferrals, but NOT BOTH.”
If you want to delay/control Feature updates, it does you no service to use both methods. You can use either one exclusively and they serve the purpose of delaying/preventing Feature upgrades. If you set both, deferrals will not work. If you use TargetReleaseVersion, set deferrals to 0 0r 1, as it’s going to be ignored anyway. The above statement helps eliminate confusion on the part of consumers.
I just ran a test to confirm and, yes, only setting the TargetReleaseVersion to 2010 works at this point to make the 20H2 update show up in wushowhide.
Sounds like a minor edit of the AKB is in order with regards to this development, thanks to Microsoft! 
Hopefully they go back to the customary naming convention they’ve used to this point to avoid confusion. After all, their instructions in GPedit clearly state to enter the version just as it appears on the version you’re trying to stay on. Half the room calling it 20H2 and the other half calling it 2010 is normally a non-starter! But we are talking about MS here.
If you set TargetReleaseVersion to 2004, you should be offered v2004 through Windows Update once the system scans for updates on its own.
Either way you upgrade will work. If you do it through WU, you will get 2004 up-to-date. If you use the ISO, it may not be the latest Build.
If you set TargetReleaseVersion to 2004, you should be offered v2004 through Windows Update once the system scans for updates on its own. Either way you upgrade will work. If you do it through WU, you will get 2004 up-to-date. If you use the ISO, it may not be the latest Build.
In the “A little knowledge is dangerous” category …. I’m ready to do TRV = 2004, too. Does my 365 Deferral NOW refer to 20H2, or Should it be changed to -0- because the TRV 2004 setting prevents 20H2, anyway, Or is some other Run: Gpedit.msc setting requd before the TRV change that allows 2004?
What about GP=2 setting? Leave & will I then see 2004 is Ready & just Clk a Dnload button?
For fun, I’ve got the 10.0.19041-(450) ISO via MCT (9/14) and the Heidoc site only shows — 2004 May 2020 — as a Dnlod choice. Is the Only way to know what Dnload Ver is offered is to Dnload it and do the DISM exercise? No one has spoken of this, AFAIK.
W10 Pro 22H2 / Hm-Stdnt Ofce '16 C2R / Macrium Pd vX / GP=2 + FtrU=Semi-Annual + Feature Defer = 1 + QU = 0
If you use TargetReleaseVersion, according to MS documentation the Feature deferral setting will be ignored. If you set TargetReleaseVersion = 2004, that is the version you get and Feature deferrals then don’t refer to anything. So my recommendation in to set deferrals to 0 or 1 (since they will be ignored anyway). But you need to do that AFTER you set TargetReleaseVersion and APPLY it, or you leave yourself open to deferral of 0 or 1 being your only protection (and you would get 20H2.).
MS documentation also says that if you use TargetReleaseVersion, and the version you set reaches EOL, you will be force upgraded after 60 days. So you need to keep that in mind also.
You should basically use one or the other to control Feature updates, but not both.
Does my 365 Deferral NOW refer to 20H2,
Your 365 refers to number of days from your CURRENT installed Windows 10 version release date.
If you are on 1909 365 days end at November 12, 2020.
1909 EOL is May 2021 (18 months of support).
If you set TargetRerleaseVersion, according to MS the Feature deferral setting will be ignored. See above,
Hi, I have now set my TRV to 1909, for the time being, and so want to cancel the Feature deferral previously set to 365. My updates are currently paused until we move to Defcon 3 or higher; if I revert the Feature deferral to 0 – but touch nothing else – will it trigger a Search for Updates? Silly question, I’m sure, but you can’t be too careful when you’re not totally sure what you’re doing! Many thanks.
2 Macrium Images & Then ….. I “Applied” 2004 in Business WU TRV and Then made Feature Deferral -0- although it isn’t supposed to matter. WU is checking daily early a.m., so tomorrow I’ll hopefully have a 1st glimpse of some result (nothing is in wushowhide now) – & I’ll update when relevant.
PKC, I only saw Alex’s post earlier and thus replied only to him, although your’s appears ahead of him now. ?? Thanks to all for the Replies.
W10 Pro 22H2 / Hm-Stdnt Ofce '16 C2R / Macrium Pd vX / GP=2 + FtrU=Semi-Annual + Feature Defer = 1 + QU = 0
I wouldn’t know, my Latin’s a bit rusty these days. But scanning for updates is precisely what I don’t want to do right at the moment.
Dell Latitude 3420, Intel Core i7 @ 2.8 GHz, 16GB RAM, W10 22H2 Enterprise
HAL3000, AMD Athlon 200GE @ 3,4 GHz, 8GB RAM, Fedora 29
PRUSA i3 MK3S+
Question is, why does that not exist? Makes me wonder. Same way as never seeing a Feature Update separate in Updates. I wonder what might be wonky.
See this screenshot.
Donations from Plus members keep this site going. You can identify the people who support AskWoody by the Plus badge on their avatars.
AskWoody Plus members not only get access to all of the contents of this site -- including Susan Bradley's frequently updated Patch Watch listing -- they also receive weekly AskWoody Plus Newsletters (formerly Windows Secrets Newsletter) and AskWoody Plus Alerts, emails when there are important breaking developments.
Notifications
