Thanks @Mathew Wai The PC I am having this issue with is at work, and with me living in Australia it is now Friday night and I am happy to not be at work for a few days
However I will do that as soon as I return to the grind on Monday and post the results back here.
I am now starting to see how my confusion arises in regard to this body of work and I will in future try and direct my questions to the relevant author. I once again thank you all for all this.
No worries @EdTittel and the origins are a bit convoluted aren't they
Well this discussion seems to have cleared it up quite a bit.
Yesterday when I looked, the MajorGeeks link for the WUMT Wrapper Script 2.5.5 listed a user name that was obviously pf100 but it listed Mr.X on the Wilders Security Forums. This name Mr X also comes up in the dialog window after the script is run. The username in the MajorGeeks Author field now reads pf100 on the My Digital Life forum so there is now some consistency as should be to my way of thinking.
@Matthew Wai is also rightfully credited with being the author of his fork of the script and also the Check_for_updates.vbs script.
All of you three guys that either wrote parts of this script package, and also have this thread like @EdTittel have done a fabulous job in getting this valuable information into the public domain.
Last edited by Pedro147; 01 Feb 2019 at 17:32.
Some history of the script: The first version for 10240 RTM just disabled the windows update service. That soon stopped working in later versions of windows 10. I thought about it a while and decided that since everybody else was using registry edits (I don't trust that), and since disabled forced update tasks were being randomly re-enabled, I would disable the files the update hijacker tasks tried to run instead. I saw a post somewhere by TairikuOkami about removing file permissions to disable files so I took that route. The script has grown a lot since then, disabling Windows Update Assistant, creating tasks Wub_task to keep wuauserv disabled and WDU task to update defender, and lots more. I had a lot of help along the way; many coders have helped me. I've also used random bits of code I found in google searches. All I did was take ideas of others and put it into a script that works. I could not have done this alone. Matthew Wai is the first to modify the script (so it gives you notifications). I'm sure others have modified it for their own needs, but Matthew is the only one I know of to make his modifications public. I like what he did, but I don't need notifications. I prefer to check manually. I've thought about using his modifications, with his permission first of course which he already gave me, but then I would have to provide a choice of notifications or not in the menu. That would use Matthew's modifications if the user picked notifications. At this time I'm not comfortable adding more complexity to the script. I may at some point consider adding Matthew's code to the script. I probably at this point should put the project on github so people could more easily fork it but 1) I don't know how to use github, and 2) maintaining the script already takes all my coding free time. The Peter principal states that: people in a hierarchy tend to rise to their "level of incompetence". I'm not sure where that level is with me. I haven't reached it yet, but to make the script a lot more complex I would have to treat this almost like a full time job, and I just don't want to turn something I love (the script) into something I dread. But I haven't taken any options off the table yet.
Yes, the third line reads "Title WUMT Wrapper Script 2.5.5". My Windows is Version 1809 (OS Build 17763.107) in Oracle VM VirtualBox 5.2.20. The script is in C:\WUMT Wrapper Script\WUMTWrapperScript.cmd. I have just run it again, and I can create new files in "%systemroot%\UpdateAssistant".
I have got access after clicking on "Continue" below. Is that normal?
These commands in the script lock those folders. It requires the variable %nsudovar% to be set, and for nsudo to exist in the script folder.
In the picture you showed, I don't have access after clicking continue.Code:%nsudovar% -ShowWindowMode:Hide -Wait -U:T -P:E "%systemroot%\System32\icacls.exe" %systemroot%\UpdateAssistant /inheritance:r /remove:g *S-1-5-32-544 *S-1-5-11 *S-1-5-32-545 *S-1-5-18 >nul 2>&1 %nsudovar% -ShowWindowMode:Hide -Wait -U:T -P:E "%systemroot%\System32\icacls.exe" %systemroot%\UpdateAssistantV2 /inheritance:r /remove:g *S-1-5-32-544 *S-1-5-11 *S-1-5-32-545 *S-1-5-18 >nul 2>&1
Sorry, I have just edited my above post. Please look at the added screenshot.
I edited my post to say I don't have access after clicking continue in your screenshot. Try my script without your modifications and tell me what happens.
Edit: I'm testing this in an early version of 19H1 in VirtualBox. If it's allowing you access after clicking continue in your screenshot using an earlier version of Windows, don't click continue. What version of windows 10 are you testing this in?
Quote