Sledgehammer - Windows 10 Update Control

Discussion in 'MDL Projects and Applications' started by pf100, Nov 28, 2016.

  1. Carlos Detweiller

    Carlos Detweiller MDL Spinning Tortoise

    Dec 21, 2012
    3,737
    3,482
    120
    Maybe download HTML site with wget, aria2 or curl and do a simple text search. As long as he doesn't change the site...
     
  2. rpo

    rpo MDL Expert

    Jan 3, 2010
    1,112
    911
    60
  3. pf100

    pf100 MDL Expert

    Oct 22, 2010
    1,832
    2,757
    60
    This fixes the LockFiles task not reporting correct errorlevel in Task Scheduler.
    Change the last line of \bin\LockFiles.cmd from
    Code:
    exit
    to
    Code:
    exit /b 0
     
  4. Homer712

    Homer712 MDL Junior Member

    Oct 22, 2018
    82
    19
    0
    Made the change, ran manually . . . works perfectly!
     

    Attached Files:

  5. pf100

    pf100 MDL Expert

    Oct 22, 2010
    1,832
    2,757
    60
    @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.
     
  6. Dopey Joe

    Dopey Joe MDL Novice

    Feb 20, 2020
    1
    2
    0
    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 :)
     
  7. pf100

    pf100 MDL Expert

    Oct 22, 2010
    1,832
    2,757
    60
    @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.
     
  8. Homer712

    Homer712 MDL Junior Member

    Oct 22, 2018
    82
    19
    0
    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.
     
  9. pf100

    pf100 MDL Expert

    Oct 22, 2010
    1,832
    2,757
    60
    @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.
     
  10. Homer712

    Homer712 MDL Junior Member

    Oct 22, 2018
    82
    19
    0
    @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.:D
     
  11. rpo

    rpo MDL Expert

    Jan 3, 2010
    1,112
    911
    60
    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.
     
  12. Homer712

    Homer712 MDL Junior Member

    Oct 22, 2018
    82
    19
    0
    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?
     
  13. rpo

    rpo MDL Expert

    Jan 3, 2010
    1,112
    911
    60
    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.
     
  14. pf100

    pf100 MDL Expert

    Oct 22, 2010
    1,832
    2,757
    60
    @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.
     
  15. Homer712

    Homer712 MDL Junior Member

    Oct 22, 2018
    82
    19
    0
    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!
     

    Attached Files:

  16. Homer712

    Homer712 MDL Junior Member

    Oct 22, 2018
    82
    19
    0
    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.
     

    Attached Files:

  17. pf100

    pf100 MDL Expert

    Oct 22, 2010
    1,832
    2,757
    60
    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.
     
  18. rpo

    rpo MDL Expert

    Jan 3, 2010
    1,112
    911
    60
    #1560 rpo, Jun 14, 2020
    Last edited: Jun 14, 2020
    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.