schtasks fails to create the scheduled task because the xml file is a unicode file without the appropriate header. Solution : first create a "header file" Code: cmd /u /c "echo CreateObject("Scripting.FileSystemObject").CreateTextFile("%~dp0%Task_Name%.xml, True).Write chr(255) ^& chr(254)">"%temp%\unihdr.vbs"&"%temp%\unihdr.vbs"&del "%temp%\unihdr.vbs" and : Code: >"%temp%\%Task_Name%.xml"&cmd /u /c type "%temp%\%Task_Name%.xml">>"%~dp0%Task_Name%.xml del /q "%temp%\%Task_Name%.xml" >nul 2>&1
It seems to me that after applying Wrapper Script the user has corrupted system integrity! Check it with the sfc /scannow command and see what he will tell you ? This usually happens when you entered with an ax in the system. Or you must correct the way you enter in the system or give up this stupidity. Average users already have a problem maintaining the integrity of the system and without having to help them with that Bulls**t.
Reading helps often: https://forums.mydigitallife.net/th...ows-update-service.72203/page-34#post-1458587 Mostly a cosmetic error since the Wrapper denies some update start ramps to run (and reactivate WU service) ... and Windows doesn't like that (APPARENTLY) . None of that processes is vital for the system. Any other critics beside that?
Trying to be snippy, cute. Where's the harm, disable the wrapper, run sfc, re-enable the wrapper, done, no errors.
When the script is run, the WDU task without the delay runs immediately as soon as it's created just before WUMT runs. So while wumt is checking for updates, WDU is checking for defender updates, then turns off the update service making WUMT stop working in the middle of updating. Checking to see if WUMT is running by itself doesn't fix the problem because the task started before WUMT did. If I make the WDU task delay 60 seconds this doesn't happen and fixes the problem. I could make the delay 10 seconds and it would probably work, but I'm not taking any chances, and 50 more seconds makes no difference; defender still gets updated. And wub_task is not resource intensive at all. You'd have to have a horribly slow computer for it to make any difference, at which point wub_task would be the least of your problems.
In addition to what @rpo said, WDU (Windows Defender Update) task doesn't do anything if you're not using Defender and it's removed if you uninstall the script, so there's no reason to remove WDU task. Edit: If you're concerned about the WDU task saying "this task has completed successfully" even though you have Defender disabled, there's a reason for that. WDU task first checks to see if Defender is running through WDU.cmd, and if it's not, it just cancels the update. So the task did complete successfully even though it didn't do anything.
Not only do you make that user has corrupted system integrity! You do not even know what you're doing!! Read this post well!! https://forums.mydigitallife.net/threads/windows-update-manager.77736/page-5#post-1460187 I already told you this once, but......? Maybe placebo will help you ?? I love you all !!
Was already answered and dismissed due to not being that easy . (You didn't even read the anwer to the post you quoted, did you) Come back with valid arguments and stop spreading FUD!!!
@pf100, If I'm not mistaken, #3 is (E)nable Update Service to allow Windows Store. You've also said in other posts that you can't recommend keeping the update service enabled under your script because there is some risk, however small. I'm just wondering if there shouldn't be a caveat about the Enable choice not being risk free right next to that menu item in the Configurator. Even though it's stated in the script if you choose (C), that statement isn't invoked for (E). (Don't want to scare people, either.) Also, I noticed that if you do select (E)nable and then select (C)ontinue to run WUMT, after exiting WUMT, the end state is that the Windows Update Service is still ENABLED. For increased safety, do you think it would be a good idea to default back to DISABLED anytime WUMT was executed and then closed? Or for that matter, anytime after a reboot? I'm aware that the script announces when (C) is picked that after WUMT closes the update service will be disabled unless overridden by the Configurator. Still . . . . People sometimes forget what states their computers are in after a while. (I'm not a big Windows Store user, so I probably don't appreciate the need to keep it working.)
@Whistler4, Good idea. When WUMT closes, no matter what you choose in the Configurator, the Windows Update service will be disabled immediately and after reboot in the next version 2.5.3. I'll reword it accordingly..