@Homer712 If you want to execute Wdu.cmd from the desktop, you have to change the third line of the script to : cd /d "pass to your sledgemammer folder\bin (for example cd /d c:\sledgehammer\bin) because wub.exe is located in the bin subfolder. This will run a cmd script and not a task scheduler task.
@rpo Initially opted to go the .cmd route as I didn't know that you could edit a .vbs file in Notepad (I use Notepad++). Just did that now and I'm sure it will be the better solution as well. Thanks for the assist!
@Homer712 : don't forget to run the script again to recreate the tasks (modifying only the .vbs files is not enough).
@rpo Ran the script right after modifying the vbs file and checked the (re)created WDU task to ensure that the settings had in fact changed to run if missed, and they were. This completely addresses concerns over missed definition updates. Thanks!
@rpo I'm sure you knew it would work, but I'm a "Trust but Verify" type of guy. Let the laptop hibernate until 6:10 PM (just past the task time) and woke it up. Let it run for a couple of minutes to settle everything back down, then took a look at the Task Scheduler and the WDU task did in fact run successfully past it task time. Thanks again!
If you want to start the scheduled task WDU without opening the task scheduler menu : Create a shortcut and enter schtasks.exe /run /tn Microsoft\Sledgehammer\wdu for the target Set WDU as the name for the shortcut and terminate Right click on the created shortcut and select Properties On the shortcut tab hit Advanced Check the Run As Administrator box and hit OK Hit OK once more to close the Properties window You can now start the WDU task by clicking on the shortcut
Created a VBS script to generate a shortcut to execute the WDU task. The shortcut is copyied to the desktop. Paste the script, copy it in your favorite text editor, save it as a ANSI file with the vbs extension in a write enabled folder and double click on the saved file. Code: Option Explicit ' Force explicit variable declaration. Dim oShell : Set oShell = CreateObject("WScript.Shell") Dim oFS : Set oFS = CreateObject("Scripting.FileSystemObject") Dim oShortcut : Set oShortcut = oShell.CreateShortcut(lnk_Path) Const lnk_Path = "WDU.lnk" ' shortcut name and path (script directory) oShortcut.TargetPath = "schtasks.exe" oShortcut.Arguments = "/run /tn Microsoft\Sledgehammer\WDU" ' schtasks parameters oShortcut.WindowStyle = 7 ' minimized window oShortcut.Description = "Shortcut for WDU task" oShortcut.IconLocation = "%SystemRoot%\System32\SHELL32.dll,46" oShortcut.Save Dim oF, oTs, s Const ForReading = 1, ForWriting = 2, ForAppending = 8 Const TristateUseDefault = -2, TristateTrue = -1, TristateFalse = 0 Set oF=oFS.GetFile(lnk_Path) ' get a File object corresponding to the shortcut Set oTs=oF.OpenAsTextStream(ForReading, TristateUseDefault) s=oTs.Read(oF.Size) : oTs.Close ' get content of WDU.lnk as a string Set oTs=oF.OpenAsTextStream(ForWriting, TristateUseDefault) oTs.Write Mid(s,1,21) & Chr(Int(Asc(Mid(s,22,1))) Or &H20) & Mid(s,23) : oTs.Close ' rewrite with admin flag set oFS.CopyFile lnk_Path, oShell.SpecialFolders("Desktop") & "\", True ' copy shortcut to desktop
Another reason the Sledgehammer folder exists between uninstall and install is because other files have been added to the folder or its subfolders. For example, if you have selected offline update and downloaded wsusscn2.cab, that file will not be deleted by the uninstall process. (Most Windows uninstall processes will not completely delete the application program folders if they contain modified or additional files alien to the program.) Once you realize this behavior, you can just accept installing into the existing folder without the need to delete it first.
@pf100, I've got a question about the second screen warning (third bullet), "If WuMgr or WUMT is offering updates, you need to hide or install them before closing WuMgr or WUMT." Is this an abundance of caution or have there been cases when unselected updates have actually launched after closing WuMgr or WUMT? The reason I ask is that, numerous times, I have gotten to the stage of viewing what updates are available to decide whether or not to install them, then closed the update tool without checking/selecting any updates, but I haven't had them be installed unintentionally. What would trigger an unintentional update if the Windows Update Service is disabled right after WUMT or WuMgr is closed?
@Whistler4 It's just to cover my a** if by some chance an update somehow made it through by cancelling the script. Nobody can say I didn't say to hide or update, even if it may be useless. I like to be overly cautious.
@pf100 At line 398 of sledgehammer.cmd 2.7.2 there is an extraenous reference to %3. Create_tasks is called with 2 parameters (but there is no incidence on the processing).
Sledgehammer includes WuMgr 1.1 and uses only that included version. And, as Sledgehammer disabled Windows Update Service, the standalone version is of very limited use.
No. If Wumgr is updated I'll make a new release of the script that includes it. If you mean can the latest version of the script block the 2004 update, then yes. There has only been two versions of WuMgr that were considered "finished" and ready for prime time use, 0.9 and 1.1, so it doesn't need to be updated very often. When this script started taking off I asked a couple of people who make projects if I should make it check for updates of itself, and the answer I got was "no".
Using Sledgehammer is mandatory if you want to delay Windows Updates for more then 35 days with Windows 2004, even for Enterprise.
I think I like that the site is just opened through the browser instead of within the script, just seems cleaner to me.
Could anyone enlighten me about what this tool is actually supposed to do? This seems exactly like what Windows Update does. It's automatic, you know how and when it does its thing, you can disable it, you can put off updates, you can choose the time at which they are installed. What else do you need? So you're saying Windows Update bypasses Windows Update..? All of those parts of Windows Update are meant to fix it when it's broken. The purpose of that is not to "force updates". It's so that regular users will not have problems when they're stuck on Threshold 1 to this day because Windows Update died 5 years ago. When was the last time that happened? You can defer updates for just long enough to know precisely when they're coming. You can set active hours when Windows Update will not download or install updates. You can disable automatic updates in general. Why completely destroy the whole thing just to have it not do what it's supposed to do for a short time? For that you could just as well configure it to update when you're not actively using the computer. How much more control do you have over Windows Update using this tool compared to just configuring it properly or disabling it altogether?