Got it! Thanks for the clarification -- I appreciate your taking the time to illustrate that having to use Windows Update in Settings while keeping WUMT or WuMgr open is only needed in rare cases. I didn't mean to beat a dead horse, but I recalled discussion last summer about UUP CU problems, including an item in your FAQ, and thought it was more than simply size reporting. Also as you point out, what might work in one Windows build might not work in another build. I like your use of the size mismatch as an indicator that parallel use of Windows Settings may be needed. Perhaps you can add to FAQ D1 (Can cumulative updates be selected and installed?) something to the effect of: "For example, when an update is obviously reported as the wrong size (such as many gigabytes) in WUMT or WuMgr, this is an indication that it may fail and you may need to leave WUMT or WuMgr running and run updates from Settings as described above." (Maybe after the para starting with "If you can’t install a Cumulative Update with WUMT or WuMgt under the script but WUMT or WuMgr does identify it, . . . .") I think you should also add to FAQ D1 your statement quoted at the top of this post to expand on "Yes, it almost always works, but not every time." Sorry to detract from the flow of thought for the issue of the day, WDU task. I just wanted to throw my O&O Shutup 10 experience into the hopper and got sidetracked.
Yes, I agree with you. The script doesn't break the task scheduler. And we don't know was is caused by O&O ShutUp 10.
@Homer712, Here's a shot in the dark concerning Task Scheduler not executing some tasks: How old is your laptop and what's the chipset? I ask because I have three computers with Asus motherboards and GeForce 8300 chipsets that I had to restore from Windows 10 1803 back to 1709 and keep that way because they wouldn't execute the task to wake for client backup to WS2012R2E. I isolated this problem over a month after updating to 1803 and found numerous other complaints about it in forums, but MS never acknowledged it. That Task Scheduler problem was the reason I started using this Wrapper Script in the first place, to preserve 1709 on those three machines. Chances are good that hardware compatibility with a Win 10 version isn't the cause of running the WDU task, but it's a possibility. Look at all of the problems out there that folks are having with Win 10 updates -- having complete control over when to update and what update to allow is not only for convenience but also to defend against eventual hardware obsolescence. Just a thought to consider if your computer is an older one.
Proposal: Assign the directories the attributes Hidden+System before locking them, if you didn't already. Hidden+System is the "Super Hidden" state. Unless the user explicitly states that all system files should be visible (including two ugly desktop.ini files on the Desktop), such items will never show in Explorer.
That's probably because you run Windows like an expert user with folder view options set for "Show hidden files, folders, and drives" and unchecked "Hide protected operating system files (Recommended)". I certainly do, and that's why I always have those two dumb files on my desktop as described by @Carlos Detweiller.
Instead of creating a blocked "%systemdrive%\Windows10Upgrade" folder which would work 100% of the time (unless somebody manually gave themself permissions and deleted the folder because they think Windows Update Assistant has somehow installed itself), I could use IFEO (Image File Execution Options) in the registry to block the file "Windows10UpgraderApp.exe" from running. But I'm not sure that the registry key wouldn't be flagged by an antivirus/antimalware program. And I can't test every possible antivirus. I'm thinking the safest thing to do is to make the dummy locked folder with a notification when the script is run to inform the user the reason for the existence of the folder. Could anybody who is experienced in blocking legitimate Windows files with IFEO give me your thoughts on the possibilities of this key being flagged? I could protect the key from deletion by changing permissions, but I don't want to trigger a flag, because if that happens it might cause someone to not trust the script and stop using it because of that.
OK, this is a real long shot, so, a simple "No" and I'll go away. The comments from Whistler4 about the possibility of my issues being connected to the Windows Task Scheduler have started me thinking about a solution of being able to run the script without it being directly tied to the Windows Task Scheduler. When I mentioned possible Task Scheduler alternatives before I was not implying "instead of" but "in addition to." So, with that in mind I ran the portable version of the script rather the the installed version. The portable version still adds the two tasks to the Task Scheduler, which I thought it may not. My mistake. Anyway, is there a way to have the script be totally independent of the Windows Task Scheduler. A stand alone application. That way, one could bypass any possible Task Scheduler issues, use one of many available scheduler apps, and just recreate the tasks that the script adds to the Task Scheduler. This request/question comes from someone totally ignorant of software programming so I have no idea if this is a "two lines of code and it's done" type up thing or if we're talking about a "two sleepless nights and 5 gallons of coffee" type of thing. Also, I don't know how many instances of "your Task Scheduler ain't working" have come up here and if this is something that may help those of us in those cases. Like I said, a simple "No" will not offend me.
So if I'm understanding you correctly, you need a modified version of the script that doesn't create any tasks? That's not a problem, I can do that for you in about two minutes. I need you to verify that's what you need before I do it. Also, both tasks (WDU and Wub_task) are run with Task Scheduler with the local System account (SID S-1-5-18), so you'll need to make sure whatever Task Scheduler replacement you use does the same; however, if your Task Scheduler replacement can only run them as Administrator, I'll need to know that so I can modify the WDU.cmd file that the WDU task runs, because it checks to see if it's being run with the System account and if not, the WDU task will run but WDU.cmd will cancel the Defender update without doing anything. This will void your warranty, but if you're dissatisfied in any way the script comes with a 100% money back guarantee. Yours is the first report of the tasks not running since the script first started creating tasks in v2.1.8 on February 24, 2018; 37 versions ago. I always just increment the versions by one, 2.1.8, 2.1.9, 2.2.0, etc.
You don't need an alternate task scheduler. A cmd script can start the wdu.cmd : Code: @echo off cd /d "%~dp0" :: get admin privileges set "params=Problem_with_elevating_UAC_for_Administrator_Privileges" 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", 2 > "%temp%\getadmin.vbs"&cscript //nologo "%temp%\getadmin.vbs"&exit :GotPrivileges if exist "%temp%\getadmin.vbs" del "%temp%\getadmin.vbs" :: start the wdu task echo CreateObject^("WScript.Shell"^).Run "wdu.cmd",0 >wdu.vbs :next wdu.vbs echo wdu task started at %date% %time% >"%~dp0wdu.log timeout /t 3600 >nul goto :next Put this cmd script into the wrapper script directory. Click on it and wdu.cmd is started every 1 hour.
1. Correct. 2. I am totally, completely, utterly impressed! To me, what you guys do is all Harry Potter stuff. 3. Thank you, I'll fool around with this tomorrow morning and get back to you. Even though my team isn't in it, I still need to watch just to make sure no calls are missed or balls overinflated.
Well done! Line 202 in v2.5.5 needs to be edited in "WUMTWrapperScript.cmd" too. Code: change line 202: echo whoami /user /nh ^| find /i "S-1-5-18" ^|^| exit to ::echo whoami /user /nh ^| find /i "S-1-5-18" ^|^| exit @Homer712 does Wub_task run when you 1) log out and back in, and/or 2) reboot?
@rpo & @pf100 -- Just wondering, can the WUB task be implemented similarly, cutting Task Scheduler out of the picture altogether? And if so, would there be any value added? (But no sense in violating the if-it-ain't-broke-don't-fix-it principle.)
The function of Wub_task would have to be implemented. That's why I asked @Homer712 if that task is working two posts up.
Oh, yeah, I missed that. And, push come to shove, you are able to code the WUB function in your script. (But, still, it would be nice if Sordum got WUB to minimize to tray.)
Sorry, but you'll need to walk me through this. Do I do an install of the script and then put this file into the created folder, or, do I copy the portable version of the script to the Programs directory, then put this file (copied to Notepad++ and saved as a *.cmd file) into that directory? Tried that, right clicked, run as admin and I got a blank cmd window that did nothing, just stayed open on the screen until I finally clicked it closed.
I hate to be the bearer of bad news, but you really need to do a clean reinstall of windows to fix task scheduler. There's seriously something wrong with your install if task scheduler is broken, and if you're having trouble wrapping your head around this now - consider that it's going to just get more complex than what we've discussed so far to get this broken task scheduler workaround to work. It's quickly becoming an endeavor of diminishing returns. It's turning into a multi-page how-to on how to make a corrupted Windows 10 install work. It would be far easier in the long run to just wipe the drive and do a clean install.