@pf100 on win 10 1803 x86, i've set configurater to e, its suppose to be that update service is on but any update wont automatically download as every task related to update is disabled. but today i saw that, update page is showing that last update check time (few minutes ago) and that it couldnt install updates. so how did that happen? afaik i didnt touch update button. something in my system triggered updates. and it should be examined. on another but related subject i have a suggestions. as i've posted this problem with configurater set to e, i think an extra protection should be added. i think if update service is running, in that case it is possible that some av and security programs may trigger updates to happen. as i know eset does that. so in that case i would suugest you to set metered connection status to all connection with registry. Code: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\DefaultMediaCost and set value to 2. and it needs to take permission. so with that, if anything triggers update, windows will not download updates, i know its not perfect but atleast it can stop updates to some level, and it should be used as an "extra" preventive measure in both cases (config d and e)
It's the nature of the windows update service to check for updates if it's left on automatic. The fact that it couldn't update when left on automatic (Configurator set to [E]) in your case means the script is working better than expected, so thank you for that good news. Of course, you're always at risk of a forced update by leaving updates enabled and I've never said anything to indicate otherwise. That's the trade-off of the convenience of being able to run the store at any time. But I'm still keeping my fingers crossed that this method will continue to prevent forced updates with updates enabled so please keep testing this. The script has never disabled any triggers that force updates, it instead disables the files the triggers try to run. Tracking down triggers is a waste of time, when disabling the files responsible for forced updates instead is, 1) less time consuming, and 2) works just as well if not better than disabling triggers, as you just found out. Consider this: If I tracked down all triggers and disabled them, they could introduce a new trigger with any update that could force an update. By disabling the "forced-update" files, this is less likely to happen because if a new update introduces a new "forced update" file, it's going to have a harder time running if almost all of the "forced update" susbsytem files are disabled. Disabling files works better than disabling triggers. There are some notable exceptions, for example, when an update made just one file in Update Assistant V2, triggered by a task, install Windows 10 Upgrade. That can't be predicted by either finding task triggers, or disabling files ahead of time. It has to be dealt with after-the fact as it was not known beforehand. Enabling metering interferes with some apps. I remember there was a problem a while back with the Netflix app and metering. I've heard of it causing other problems too, plus it doesn't stop updates, like you said. To me, setting connections to metered is not a solution and can cause problems so I'm not going to add it to the script. I'm only concerned with manual updating and the script is doing that. I don't want to interfere with anything except forced updates. People who truly need a metered connection can do this themselves and deal with any consequences. As always, thanks for your input. The next update will be better because of it. Defender will update if running, and won't if not. Speaking of which, I've got everything I need now to finish the next version. If I don't run into any problems, and life doesn't get in the way, it should be released later today. I have to test it with defender running, and not running, on different machines once I think it's finished many times, at least edit readme.txt of which a complete rewrite is overdue, update the uninstaller, etc., before I submit it to Major Geeks who butchers my most important file name, the one to the script, which wouldn't be a problem with an installer, but whenever I get around to working on an installer I have to work on the script.
May 16, 2018 Script updated to v2.3.0 Fixed broken automatic Windows Defender Updates. Special thanks to @rpo for going above and beyond on this fix and to @ShiningDog for testing and feedback. Changelogs here
thanks @pf100 for the update. i really appreciate the work you are doing. i will keep an eye on what triggers updates when config set to e. btw have you contacted major geeks (timothy) to pls not change the file names?
Without your input and @rpo's selfless code contribution, v2.3.0 would not be as awesome as it is. I can only take credit for figuring out a method to determine if Defender is running or not and the idea of "if defender is running, update defender, if defender is not running, don't update defender". I found a way to do that by enabling/disabling the WDU task but @rpo made it 100 times better by instead making WDU.cmd called by WDU task do all the logic by simply not doing anything and using no resources if Defender is not running. so the task can tell if defender is running or not and update it if it is. So now you can enable or disable Defender all you want and the WDU task will automatically update Defender within 24 hours if Defender is enabled and stop updating it if you disable it. Absolutely brilliant. Plus he wrote WDUcreate.vbs to create the task and dependent file WDU.cmd to work with special characters in the path and there was no way for me to know that special characters would be a problem. Also, I forgot to put in the readme.txt to not run WDUcreate.vbs directly since it's called every time you run the script. If you do run it it won't hurt anything, it'll just recreate the WDU task and WDU.cmd file that's already there after the first time you run the wrapper script. I'll put that in the OP later today. If you could track down what triggers the update service to update when it's set to automatic so it could be disabled while leaving the update service running, that could be quite phenomenal and a game-changer. That's a deep rabbit hole to go down though, so good luck. I thought about asking major geeks to stop changing my file names yesterday but was just glad to get this update done and wanted to forget about it for a while. The file I submit to them is named something like WUMTWrapperScript_v2.3.0.zip, and they extract it, rename whatever I call the script name to "Windows Update MiniTool.cmd", then they re-zip the filename to WUMTWrapperScript.zip. Why!? They obviously have an automated algorithm that extracts and scans and renames files. But yeah, I need to see if I can get that fixed.
Good Evening Boys, I have a question.... I have to start the script on different computers.... Is it possible to run the "Configurator.cmd" script via the command line? I would like to run the script with the preference of the "D" command... Is Possible ?
If you run the script it's already set to [D] by default. You have to run the Configurator to change it to [E]. Does this answer your question? Edit: If you want to make sure it's set to [D] in case someone changed it you can run this in the same folder of the the script as a self elevating batch file. SetCfgD.cmd Code: @echo off ::::::::::::::::::::::::::::::::::::::::: :: Automatically check & get admin rights ::::::::::::::::::::::::::::::::::::::::: set "params=Problem_with_elevating_UAC_for_Administrator_Privileges"&if exist "%temp%\getadmin.vbs" del "%temp%\getadmin.vbs" fsutil dirty query %systemdrive% >nul 2>&1 && goto :GotPrivileges :: The following test is to avoid infinite looping if elevating UAC for Administrator Privileges failed If "%1"=="%params%" (echo Elevating UAC for Administrator Privileges failed&echo Right click on the script and select 'Run as administrator'&echo Press any key to exit...&pause>nul 2>&1&exit) cmd /u /c echo Set UAC = CreateObject^("Shell.Application"^) : UAC.ShellExecute "%~0", "%params%", "", "runas", 1 > "%temp%\getadmin.vbs"&cscript //nologo "%temp%\getadmin.vbs"&exit :GotPrivileges ren "%~dp0wub.exe-backup" wub.exe >nul 2>&1 "%~dp0wub.exe" /d /p >nul 2>&1 exit
Thank You for the answer pf100! I apologize for asking the question badly: I would like to start the "Configurator.cmd" without user interaction. Simply start the configurator with the default "D" command without typing anything. The script starts and closes itself. And if possible, the same thing with "Uninstaller.cmd": Simply, start the script by double clicking, without pressing a key to start the removal.
When you run Windows Update MiniTool.cmd it automatically set update to disable (means configurator is set to d by default you dont need to change it) . uninstaller user interaction is needed bcoz its a critical thing to do. however you just need to remove few lines in uninstaller.cmd to remove user interaction. remove these lines from line number 10 to 14 Code: echo. & echo WUMT Wrapper Script Uninstaller echo. & echo *Note: Error messages are normal for files that echo don't exist on your system. echo. & echo Press a key to uninstall WUMT Wrapper Script. pause > nul and remove these lines from the end of script Code: @echo off echo. echo :::::::::::::::::::::::::::::::::::: echo :WUMT Wrapper Script changes undone: echo :::::::::::::::::::::::::::::::::::: echo. echo Press any key to exit... pause > nul Done
@Sk4t3, is this what you want? I repeat again, you don't have to set the Configurator to [D] because it already is set to [D] by default when you run the wrapper script. The Configurator is used to override the default [D] setting to [E] (or change it back to [D]) but if you never run the Configurator it's set to [D] and I gave you a script to force it back to [D] with no user interaction here. @ShiningDog answered your questions, and here is the resulting script that uninstalls with no user interaction. It has to elevate so for absolutely no user interaction you'd have to run it as administrator or system or whatever method you choose to bypass elevation. Code: @echo off Color 1F Title WUMT Wrapper Script 2.3.0 no interaction uninstaller ::Warning! This will uninstall the WUMT Wrapper ::Script without prompting. Not for general public use! set "params=Problem_with_elevating_UAC_for_Administrator_Privileges"&if exist "%temp%\getadmin.vbs" del "%temp%\getadmin.vbs" fsutil dirty query %systemdrive% >nul 2>&1 && goto :GotPrivileges :: The following test is to avoid infinite looping if elevating UAC for Administrator Privileges failed If "%1"=="%params%" (echo Elevating UAC for Administrator Privileges failed&echo Right click on the script and select 'Run as administrator'&echo Press any key to exit...&pause>nul 2>&1&exit) cmd /u /c echo Set UAC = CreateObject^("Shell.Application"^) : UAC.ShellExecute "%~0", "%params%", "", "runas", 1 > "%temp%\getadmin.vbs"&cscript //nologo "%temp%\getadmin.vbs"&exit :GotPrivileges @echo on ren "%ProgramFiles%\rempl-backup" rempl ren "%~dp0wub.exe-backup" wub.exe schtasks /delete /tn "wub_task" /f schtasks /delete /tn "WDU" /f del "%~dp0WDU.cmd" /f /q :::::::::::::::::::::::::::::::::: takeown /f "%systemroot%\System32\UsoClient.exe" /a icacls "%systemroot%\System32\UsoClient.exe" /reset icacls "%systemroot%\System32\UsoClient.exe" /setowner *S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464 :::::::::::::::::::::::::::::::::: takeown /f "%systemroot%\System32\WaaSMedic.exe" /a icacls "%systemroot%\System32\WaaSMedic.exe" /reset icacls "%systemroot%\System32\WaaSMedic.exe" /setowner *S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464 :::::::::::::::::::::::::::::::::: takeown /f "%systemroot%\System32\WaasMedicSvc.dll" /a icacls "%systemroot%\System32\WaasMedicSvc.dll" /reset icacls "%systemroot%\System32\WaasMedicSvc.dll" /setowner *S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464 :::::::::::::::::::::::::::::::::: takeown /f "%systemroot%\System32\WaaSMedicPS.dll" /a icacls "%systemroot%\System32\WaaSMedicPS.dll" /reset icacls "%systemroot%\System32\WaaSMedicPS.dll" /setowner *S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464 :::::::::::::::::::::::::::::::::: takeown /f "%systemroot%\System32\WaaSAssessment.dll" /a icacls "%systemroot%\System32\WaaSAssessment.dll" /reset icacls "%systemroot%\System32\WaaSAssessment.dll" /setowner *S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464 :::::::::::::::::::::::::::::::::: takeown /f "%systemroot%\System32\SIHClient.exe" /a icacls "%systemroot%\System32\SIHClient.exe" /reset icacls "%systemroot%\System32\SIHClient.exe" /setowner *S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464 :::::::::::::::::::::::::::::::::: "%~dp0wub.exe" /e
I love this forum.... Thank You pf100, ShiningDog!! thank you, you answered me. I have to send this script to the company where I work ... We have about 350 clients. We want to block all windows 10 updates: versions 1709 - 1803. When we are ready to advance in version, we will do it "in blocks" in programmed order by send Unistaller.cmd. We do not want to risk system crashes following SO updates " This script helped me a lot.
I sincerely thank you for all the work to produce this and frame the offering of it here. I tried the Major Geeks download first, but couldn't figure out how to get the configuration.cmd into action or add a shortcut to it. I fiddled about for a bit, then just decided to put all four code 'cmd's into a folder I had made called Windows Updates, right alongside the two files from the Major Geeks download which then got ignored, but left there. Then I made the four shortcuts and ran the 4th one first (WDUcreate.vbs); it was just a flash on the screen and gone, so I assume it did its job to set up Windows Defender daily updates. I'll see as time passes. The other two worked beautifully. I hope to never use the uninstall. I ran the Configurator first, then the Windows Update MiniTool. Flawless and smoothly designed. With Windows 10 1803 breathing down my neck and the new self-healing updater turning off all my settings to not update, I spent the day researching, trying different approaches and setting this up right here. Not only is this something a non-coder can follow and complete, but it addresses what we're trying to battle against. I found out about your help on the AskWoody forum. Folks, just remember to hide the updates you want to set aside for now, before you close the miniTool or they'll not be protected from the next update phase.
@pf100 as you can see, many scripts in folder is causing confusion in users. specially configurator.cmd it should be renamed to enable store/update service.cmd and windows update minitool.cmd should be renamed to wumt wrapper script.cmd for more clear understanding. its time to make a installer and make shortcut for only things which are required for user to run. this script should not be portable and it needs to be in fixed location in c drive bcoz of the task it include. readme and infos in other script is too long and i know that normal end users dont read such long read me. but at the same time detailed info is also needed for users who want to understand more. in that case i would suggest to make 2 parts in read me. one for non experienced users with info in minimum lines with minimum but most imp info so they care to read. and other part for experienced users with as much detail as you can put in heading advance. windows update minitool.cmd shouldnt contain such long info as well. it should just tell users the basic thing like it disable service and task related to update, some thing like that. with a note that for more info read read_me. also it would be good to put a check_for_updates.url with link to majorgeek page in folder. thanks
You don't have to run WDUcreate.vbs by itself but it won't hurt anything if you do. All it does is create the Windows Defender Update task and dependent file WDU.cmd. It's called from the main script so just delete the shortcut to WDUcreate.vbs. Don't move the scripts folder after running the script, but if you do just run the script again so it can fix the paths to everything. I really need to make an installer for this. Thanks for taking the trouble to make an account here to tell me that the wumt wrapper script is being mentioned as an option on AskWoody's forum. I unspoilered the installation instructions in the OP and will email major geeks today and ask them to fix the file names, then I can work on the installer. I was planning on rewriting the readme anyway so thanks for the "two part" tip to make it better. I've got a new update almost ready that makes WDUcreate.vbs create both WDU and wub_task tasks so I can remove the wub_task task code from the main script. But since it does exactly the same thing as the current version of the script, the update can wait until I hear back from major geeks to see what they can do about the script names. Edit: May 19, I got in touch with Jon at major geeks and he said he'll fix the wrapper script file name problem. So in the next version and beyond, the script name will be WUMTWrapperScript.cmd
Edit: I forgot a shortcut to the readme. I'll fix that tomorrow. Fixed. Version 2.3.1 portable and installer. I'm about to release this to the public, maybe today or tomorrow, but I'd like some input. Edit: link deleted.
The portable version will be offered always, there's just an installer option now. I usually always release the source code at the same time as a release, but I got done at the end of the day on this installer and thought I'd put it up in case anyone wanted it. The source code to everything will be posted tomorrow.
May 26, 2018 WUMT Wrapper Script 2.3.1 portable and installer. Delete your previous script folder contents and shortcuts and install using the installer or manually put the files in a folder since some file names have changed. To uninstall completely only use the uninstall shortcut in the start menu, or run Uninstaller.cmd in the script folder. Changelog since 2.3.0: Added usocore.dll to disabled files. Now all task and related file creation from main script is done by module.vbs. Added installer.