@rpo It's great that you've been working on the ms-defcon problem. I'll make test versions of the script with the different ms-defcon solutions you've presented and we'll see if one or more sticks. There's no hurry because the current script works. In the last few days I've been thinking about the script and the ms-defcon issue, about whether I should just tighten up a couple of loose ends on 2.7.2 like the LockFiles task errorlevel and work on the cosmetics on the first screen, and if I should try to fix the ms-defcon issue at all. After almost deciding to forget about it, I think we'll try it again.
pf100, let me first express my gratitude and appreciation for the work you have done on sledgehammer. It has reduced the number of headaches MS gives us by their benevolent efforts to protect us from our own choices by keeping us from being able to make them. (Hmm, they sound a bit like the Templars in Assassins Creed.) Anyway I thought I might share a few things I ran into and observed while updating from 2.7.0 to 2.7.1. I have a laptop that I've been using for years and has gone through windows updates to get to its current version of windows 10 1909 (18363.778) and Powershell 5.1.18362.752. I also have a desktop that I freshly installed and patched to the same verions of Windows 10 and Powershell as my laptop. Both had sledgehammer 2.7.0 installed on them via the installer and ran perfectly well, successfully retrieving the info from askwoody.com. When you released 2.7.1, I uninstalled 2.7.0 via the uninstall script and then proceeded to install 2.7.1 via the installer for it. The installer warned me about the existence of the Program File\sledgehammer directory. I did a quick check and found that it indeed did exist and it had an empty bin directory within it. I did a quick manual cleanup of the directories and proceeded with installing 2.7.1. I ran the sledgehammer.cmd file on my laptop and all was good. However, when I ran it on the desktop, it was not able to access askwoody.com. I ran again on my laptop and desktop to confirm I did not have a network issue. And all was consistent, where the laptop was successful and the desktop failed to access askwoody.com and each attempt. Being curious I decided to dig a little into why it was not working on the desktop. I started up a powershell comandline instance and ran the Invoke-WebRequest statement. I got back the following error message: The response content cannot be parsed because the Internet Explorer engine is not available, or Internet Explorer's first-launch configuration is not complete. Specify the UseBasicParsing parameter and try again. So I ran IE for the first time on the desktop and then proceeded to run the sledgehammer.cmd script. It was able to access askwoody.com sucessfully from that point on. Comparing the Invoke-WebRequest statements from 2.7.0 and 2.7.1, I see that you had dropped the UseBasicParsing and Timeout parameters. From what I read in the Powershell docs, starting with Powershell 6.0.0 the Invoke-WebRequest will only support basic parsing only. I'm no sure what version of Powershell will be coming up on the next upgrade/update of Windows, but you might want to consider putting back the UseBasicParsing parameter on the Invoke-WebRequest statement(s). I also tried to update sledgehammer from 2.7.1 to 2.7.2. The uninstall script was not uninstalling 2.7.1. It looks like you might have copied over the same one from the portable version when you built the installer and forgot to remove the REM from in from of the call to uninst000.exe. The one in 2.7.2 is the same with the call to uninst000.exe REMed out. I edited out the REM and run the uninstall comand script and it uninstalled sledgehammer, but this time around it not only left the \Program Files\sledgehammer\bin directory, it also left thw wumgr.ini file within the bin directory. Sorry if I'm a bit long winded, but I wanted to pass on the info to give a clear picture in hope that it might explain what others might be seeing and maybe help facilitating in some of you fixes. Again much thanks for what you do
@Dopey Joe Thank you for the info. It's a big help. When I'm working on the script and testing things I have to rem out uninst000.exe or the files I'm working on will be deleted when I do an uninstall, and somehow I've overlooked removing the rem statement before release. I promise everybody that will be fixed in the next release and I doubt I'll forget that ever again. So for anyone reading this, that (and maybe something else) is why uninstall isn't deleting the Sledgehammer folder, or at least all the files in it. As far as the ms-defcon situation goes, I'm trying to greatly cut down on the use of powershell, or eliminate it entirely, in that part of the script. Definitely not using powershell's Invoke-WebRequest anymore. The difference between a new install and an updated-through-the-years install you point out is interesting. I have a netbook I've upgraded over the years and is now on 1909, and a gaming pc with a clean install of LTSC 1809, and besides occasional testing on the latest insider version in a VM, I only test the script on those two computers. So from what you're saying I should do testing on a clean and not an old install of 1909 (or 2004). I think you're right.
Just a question, not looking to make more work for pf100 Every time you run the script it goes through the entire script process including the recreating of the three tasks. Wouldn't it be easier to separate things out a bit and have one script (call it "Install') which shuts down updates and creates the three tasks, and a second script (call it "Update Check") which picks up after the "creating tasks" portion of the current script. That would certainly streamline the checking for updates process rather than waiting for the entire script to run every time.
@Homer712 From the beginning of the script I've worked on the premise that I don't trust Microsoft to honor any of their update settings with GPO or registry edits. Knowing they could change anything at any time I felt like it's best to do everything every time the script is run. Another aspect is that I want the script to be as easy to use as possible. I feel like splitting the script into two scripts would work fine, but it would add another layer of complexity to the script for the user. If it took an excessive amount of time to run the script I would agree that something should be done to speed things up. The variable here is what different people consider an excessive amount of time It was a year or two ago, and I don't remember what version of the script it was, but it felt like it was taking too long to load so I went through the script line by line and managed to cut the loading time in half and it's still like that now. Well, except for the ms-defcon check which adds another delay. There's some code in the script that takes care of anything that was in a much older version just in case someone runs a new version of the script over a much older version. One example is the script's tasks which are now in their third and hopefully final location in task scheduler. If I didn't remove tasks from older locations it could be a problem. At some point I will remove that extra code but it won't really speed up the script much which is why it's still there. I'm starting to ramble, so to sum it up, it comes down to complexity to use vs load time in any consideration to split the script into two parts. I don't feel that splitting it in two would give enough performance increase to justify having two separate scripts.
@pf100 Thank you for the (as always) both detailed and informative explanation of the thought process behind the script as it now exists. And you are correct, the time it takes to process will seem different to different folks. I'm currently battling a 15 to 20 second delay (accompanied by a blank screen) after Windows 10 login before I get to the desktop. So, my definition of "excessive" is what prompted the question.
In my opinion, the overhead introduced by deleting and (re)creating the tasks every time the script is executed is non significant. Splitting the script in to différents scripts could lead to confusion for some users; sometimes they could omit to run the install task and complain when the script is in error.
Back in my post 1505, I mentioned that there are instances where I'll get two Window Defender definition updates in a row, about ten minutes apart, and I've been looking at this again simply out of curiosity. Think I may have found something that may help identify what's going on. I am able to see an update history by running Windows Updates History Viewer by Nirsoft. I also keep Task Scheduler open to watch the progress of the Sledgehammer tasks. Here's what I found: 1. The "LockFiles" and "Wub_task" tasks seem to be run and done. All happens within about a minute. 2. The "WDU" task can run for as long as ten minutes, at times as long as twelve minutes. 3. For example, the History Viewer tells me that the definitions were updated at 8:02 AM, but if I watch the WDU task in Task Scheduler it will continue to run for another ten to twelve minutes. At the ten minute mark or so, it may in fact pick up another definitions update it while it is still running MS posts a new set of definitions. Now, for this to happen all the stars and planets need to align just perfectly, but, it does happen. So my question is this, why the big difference between the running time of the other two tasks and WDU, and is that just how things are or can that time be somehow shortened?
The wdu tasks lasts at least 5 minutes : this delay is introduced to avoid resource hogging when the system is initializing after a (re)boot.
@Homer712 More specifically, line 5 of wdu.cmd in the bin folder is: Code: timeout /t 300>nul That's a 5 minute wait (300 seconds = 5 minutes) to let the pc fully boot before trying to get defender updates. If you change that line to be: Code: rem timeout /t 300>nul the delay is eliminated. Or you can change 300 to 60 for a one minute delay, well, you get the idea. Try that out and let me know how it works for you.
Adding the "rem" seems to have to have worked out so far. Everything ran just fine and I didn't notice any slowdown. We'll see if keeping the cmd modified this way has the effect of not having double definition updates posted 10 minutes apart. This "grasshopper" is learning quite a bit on this forum. Thank you!
So far not a single instance of double definition updates. If my memory is working today I seem to recall that it never seemed to happen at a time scheduled in the tasks, only upon a Restart or Shut Down/Restart. And now (at a Start or Restart) all the tasks finish within seconds of each other.
The timeout in WDU.cmd just starts and waits 5 minutes before anything else is done. Then it runs MpCmdRun.exe which should know whether the current Defender update is the latest or not. Something could have changed. I'll probably remove the timeout next release.
Indeed, the 5 minutes timeout should be deleted : after a (re)boot the wdu tasks is delayed for 10 minutes (<Delay>PT10M</Delay> parameter). After an immediate login trigged by the user or automatically after system init, two wdu tasks are scheduled due to the BootTrigger and the LogonTrigger. The task scheduled by the BootTrigger starts about 10 minutes after the task scheduled by the BootTrigger, this why we can have double definitions updates.
Could use a bit of help here. At first this might not sound like it's related to my use of Sledgehammer, but it is. 1. I have been tinkering around with the power settings on my laptop. Specifically those that determine what happens when you close the lid, push the power and/or sleep buttons, etc. Decided to have my laptop hibernate when I close the lid (in the past I would just power off). 2. Using a tutorial on TenForums I am able to create desktop shortcuts to tasks I created in Task Scheduler/Task Scheduler Library. Those shortcuts work perfectly. 3. Seeing how I am now using hibernate on my laptop, it may be in that hibernate state during one of the scheduled WDU run times. Coming out of the hibernate state, the task time has passed and WDU will not run again for another six hours or so, at which time the laptop may very well be in hibernate once again. So, my idea was to create a desktop shortcut to the WDU task so I could run it manually without having to open up Task Scheduler. But, I can not for the life of me figure out how to create that shortcut that runs a task which is located at Task Scheduler Library/Microsoft/Sledgehammer. It's either that or ask pf100 to change the tasks so they run if a scheduled run time is missed
To change the WDU task so it runs if a scheduled run time is missed just replace line 65 of vdu.vbs in the bin subfolder by : Code: " <StartWhenAvailable>true</StartWhenAvailable>" &_ If you want to run the wdu task manually without having to open up Task Scheduler, execute a copy of wdu.cmd where you comment the second line.
Copied the wdu.cmd to the desktop and changed as per above and double clicked to execute: ::Allow only WDU task to run this file:: rem whoami /user /nh | find /i "S-1-5-18" || exit cd /d "%~dp0" ::Wait 5 minutes to prevent resource hogging after reboot with missed update:: rem timeout /t 300>nul ::If WUMT or WuMgr are running, cancel Defender update and exit. If not, continue:: tasklist | findstr /i "wumt_x86.exe wumt_x64.exe wumgr.exe" && exit 1 ::If Windows Defender is running, update it. If not, cancel Defender update and exit:: sc query | find /i "windefend" || exit 1 ::Enable Windows Update service and update Defender, then disable Update Service:: wub.exe /e timeout /t 10 "%ProgramFiles%\Windows Defender\MpCmdRun.exe" -SignatureUpdate wub.exe /d /p exit /b %errorlevel% WDU did not run and this was the Task Scheduler error: