@rpo, thanks. I had planned on shooting this by you but with all the changes I just did it all in one marathon session.
@Alfonico You must have missed this post where I mention @shewolf is spreading misinformation in my thread. As far as I know, the problem has been taken care of, but her B.S. posts remain and I can't delete them. So to anyone reading this, ignore all posts by @shewolf in this thread. @Wolfzz The difference in WUMT and WuMgr as far as the script is concerned is I can disable the options in WuMgr in the lower left of WuMgr's GUI. People kept changing the options in WUMT while the script was running which you should never do. Plus with WuMgr I can register Microsoft Update to provide Office updates where with WUMT I can't. I would have switched straight over to WuMgr and forgot about WUMT forever, but I had requests to be able to choose between the two. Maybe when it's proven that WuMgr is better i can leave WUMT behind permanently. @Whistler4 You're right. I completely missed that. There was so much text to edit in the script and the readme I was trying not to miss adding WuMgr everywhere WUMT was mentioned, but obviously I missed a spot. Thanks for mentioning it. It'll be fixed in the next version.
Don't retract your statement so fast. We don't even know what %systemroot%\System32\upfc.exe does yet. I'll know within 72 hours though. I'm about 99% sure that as far as the script is concerned it's nothing to be concerned with, but if I'm wrong I'll fix it. I'm going to let it run on schedule tomorrow and analyze its effects. If it does turn out to be a problem it's a very simple edit to disable it permanently in the script and I can have an update out in just a few hours after that. Having said that, I stand by my statement that upfc.exe can't reverse changes done by the script. My only concern is that it could introduce something like Windows 10 Update Assistant V3 but I doubt that too. My guess is that upfc.exe is basically the same as running SFC which as you know can't reverse the script changes. I'll be keeping my eye on this so I'll post any news and if necessary, updates. What could upfc stand for? Updated Protected File Changer? Unicorns Providing Free Candy? Update Platform Forced Cramming-updates-down-your-throat? Update-options Protected From Changes? Universal Protected File Check (SFC)? Who knows? Edit: Found this info on a Russian site. None of it seems to have any effect on the wrapper script but I'll be watching it closely: in 1809 there appeared such a sneaky file upfc.exe (in the processes it is visible as Updateability From SCM) which restores the services and entire registry branches so that Windows periodically checks for updates. Very timely find. I, too, almost managed to curb 1809 LTSC, and among the last few there was a question of what restores some branches of the registry. Moreover, this concerns not only the update system, but also Cortana, Store, the OneDrive permission to connect to the Cloud (although the latter two, as it were, do not exist, but in fact the connection is resolved, the system restores what is not good). So, my friends, my experience says that in this edition, sharing without selecting the rights in certain branches of the registry is not enough. This will have to learn, who has not done this before. In particular, it is absolutely necessary: 1) To disable some tasks of the Scheduler. Depending on the settings, the number of such non-switchable tasks from the general list "to disconnect" may be different. For example, there are: BackgroundUploadTask Microsoft \ Windows \ SettingSync \ BackgroundUploadTask Microsoft \ Windows \ UpdateOrchestrator \ Schedule Scan Schedule Scan Schedule Scan Static Task Microsoft \ Windows \ UpdateOrchestrator \ Schedule Scan Static Task UpdateModelTask Microsoft \ Windows \ UpdateOrchestrator \ UpdateModelTask USO_UxBroker Microsoft \ Windows \ UpdateOrchestrator \ USO_UxBroker 2) For blocking several main folders of accumulation and dumping of diagnostic data - cleaning and subsequent selection of write rights with BAN (has a higher priority than no rights) C: \ ProgramData \ Microsoft \ Diagnosis \ C: \ ProgramData \ Microsoft \ Search \ Data \ Applications \ Windows \ GatherLogs \ C: \ ProgramData \ Microsoft \ Windows \ DeviceMetadataStore \ 3) To prohibit the restoration of already correctly configured parameters of the GP / Registry along the paths [HKEY_LOCAL_MACHINE \ SOFTWARE \ Policies \ Microsoft \ Windows \ Windows Search] [HKEY_LOCAL_MACHINE \ SOFTWARE \ Policies \ Microsoft \ Windows \ Onedrive] [HKEY_LOCAL_MACHINE \ SOFTWARE \ Policies \ Microsoft \ WindowsStore] After some machine downtime, some registry keys, in the above branches, the system returns back, so blocking is also necessary. Selecting rights (as a whole) - means reconfiguring them with adding their account, first of all as the Owner with full rights, also adding yourself to the general list, disabling Inheritance with reconfiguring existing system records, setting rights only to Read. Moreover, it is important not to delete the existing system records, but to leave them the opportunity to read your settings, in fact, turn off certain parameters. ------------ So the [HKLM \ SYSTEM \ Waas \ Upfc] branch, unlike the ones described above, is really blocked from changing the rights in the most severe way. But the chain of influence on the system of this "INITIATOR" (as I would call it) can still be broken, according to my ideas.
After thinking about it, even though upfc.exe can't reverse changes by the script, it makes a lot of system-wide changes that could reverse lots of custom changes done by people in an attempt to control their pc's. I'm considering pushing out an update to disable it. I just don't like the idea of Microsoft's attempts to take over your pc and upfc.exe could cause problems for people. So the question is, should I wait and see what happens, or disable it with an edit in the script and push out an update today before it ever runs? I can't decide...
Well, you need to be sure to get enough sleep. But, the quicker you get an update out, the less turmoil others will have of downloading and installing successive updates. In other words, replacing 2.5.5 soon if can do it would be good. But that shouldn't be the driving reason.
Okay. That'll also give me the chance to fix the omission of mentioning WuMgr in the configurator, incorporate @rpo's more elegant way of choosing Wumt Or WuMgr, and of course disable upfc.exe. That won't take long to do, but yeah, first I need to rest up a bit. Expect 2.5.6 tonight or in the morning.
Also, on a computer running Windows 10 1703, I've had Feature Update to 1803 hidden forever. It was hidden after I checked for updates December 11 -- I made sure using WuMgr and your script v 2.5.4. Since then, update history shows only 4 MS Office 2010 updates and the Win Malicious software removal tool x64 Dec 18 kb890830. When I updated to script 2.5.5, uninstalling 2.5.4 and ensuring update service stayed off, WuMgr showed 1803 available again. So it seems either MS changed the signature of 1803 so it shows up new, or the ubiquitous malicious software removal tool or one of the office updates reset the availability of 1803, or MS has something else going on (upfc.exe?).
2.5.3 doesn't remove update hijacker permissions as Trusted Installer as required by 1809. To do this as TrustedInstaller I have to use a third party program like Nsudo. This caused an unavoidable slowdown in 2.5.4 and 2.5.5. I don't like it that it slowed the script down some either, but it had to be done. There was no way around it. No idea what happened. Upfc.exe may have something to do with it or maybe not. We just don't know yet. I have no idea what could have changed to make 1803 reappear in updates, but it was probably bound to happen eventually anyway. As long as you can hide it again and it stays hidden, I guess it doesn't really matter.
nice to see (and back in use soon) that there is an update for the script, and what tasks you where working on! i finally upgraded the two machines (1803.81 both) from septembre eleventh.. as things begone to float. so not least thanks to ms for let my solution(s) work that well, recovering update possibility on one machine took me 2 hours so.. in some circumstances windows update can destroy lifes! this is such one, this is the main reason for stop push'back - i know that. the system with an xp vm (hosted on one, usable from both pc's) involved with a more than 20 years old "revieved" software, works perfect. it may be so, that .net framework restart (only with 1809/server2019), the ending relaxation (with 1903 release) or/and the ongoing slowly destruction of hardware @home with self-hosted windows become hot topic.. do you guys remember 03 january last year?! uhh.. - - - - - - - -- - - nsudo is great /essential! no toy ;-)
I installed WUMT Wrapper Script v2.5.6 to 1803 with the December 2018 updates (17134.471). I got CRITICAL_SERVICE_FAILED BSOD at next reboot. Safe mode didn't help, and I had to manually revert the permission changes (using another OS) to the hijacker files in System32. Has Microsoft already tightened up 1803.. :-(
Oh, s**t. Ok everybody, don't do any more updates if you're using the script, or just uninstall the script right now and use another windows update control method until I sort this out. I need to find out right now if this is an interaction with something you've done with your system that I haven't done with mine that caused the failed service BSOD, or if it's actually the script itself causing it. I'm on this like white on rice, folks. @freevista have you disabled any services yourself that the script doesn't disable? The only service I disable with the script is the windows update service. If you haven't disabled any other services, is there anything else you've done to alter your system in any way? Your feedback is vitally important right now. Thanks. Edit: As a quick note, the only substantial difference I did with the latest 2.5.6 version was to disable upfc.exe. I suspect that may be the cause but I'll let you know as soon as I find out. I'm a little irritated on how this happened because I didn't listen to my own advice which I won't go into here, but above all I don't want any harm to come to anyone's system. Thanks.
Same thing happened to me, and I restored from the previous day's backup. Some research said to be sure to install the December servicing stack update, which was the Dec 11 update, and I had not done that first. So, I decided to install everything up to the last December CU to see if that would prep it properly. However, I haven't bit the bullet - still got the last CU hidden. Also, on a laptop with totally different hardware, I couldn't boot after the last December CU with same error. I've restored that one and kept everything hidden. I haven't suspected the script until I read this.
Well, it seemed like a good idea, unless sabatoge through social engineering, so to speak. I think you know what I mean.
Which folders/files did you change permissions on? And after doing so, was the CU already installed and everything working okay? I think I could boot from a WTG10 USB flash and do the same instead of time-consuming backup restore. Thanks for your tip and info. (I hate having to watch while updates are rebooting, like watching paint dry, but if you don't, you'll never see the error message, just the boot loop.)
@pf100, I can uninstall 2.5.6 and try reinstalling the update without the script to see if that was the problem. (Or, I can get a molar extracted.) I didn't do anything to disable other services or otherwise unusual to the system, except that I ran WUB 1.0 between uninstalling 2.5.5 and installing 2.5.6.