Sledgehammer - Windows 10 Update Control

@Whistler4 Thank you for the very easy to follow post above.

In an attempt to get back on the same page with everyone else:
1. Completely uninstalled Sledgehammer rc1a which I was running.
2. Followed step #1 above and instructions in post #1697 to install rc1.
3. Followed step #3 above and changed lines 403-404 of Sledgehammer.cmd.

Everything running perfectly. Only remaining issue (believe this was brought up in the past) is the "Last Run Result" (0x1) for the "LockFiles" task (the Defender task is missing because I "rem" that out).

 

I use a simple powershell script to run Windows Update / Microsoft Store without running all sledgehammer script everytime I want to check updates.. place it in sledgehammer folder and run it through vbs script.
I have two scripts (one for WU and another for Store) and they "talk" to each other, when one closes it checks if the other one is running and don't stop wuauserv service, otherwise, wuauserv is stopped.

Spoiler: for exemple, windows update ps1 script

#Requires -RunAsAdministrator
$CurrentDir = Split-Path $PSCommandPath -Parent
$WUB = "$CurrentDir\bin\wub.exe"
$wumgr = "$CurrentDir\bin\wumgr.exe"

# Starts Windows Update Service and Open WUMGR
Start-Process -FilePath $wub -ArgumentList "/e" -WAIT
Start-Process -FilePath $wumgr -ArgumentList "-update -online 7971f918-a847-4430-9279-4a52d1efe18d -provisioned"
sleep 5

# Loop for verify if process are still running
while (Get-Process -Name *wumgr*)
{
if ((Get-Service -Name wuauserv).Status -ne 'Running')
{
Start-Process -FilePath $wub -ArgumentList "/e" -WAIT
}
Sleep 5
}

if (Get-Process -Name *Winstore*)
{
EXIT
}
Start-Process -FilePath $wub -ArgumentList "/d /p" -WAIT
EXIT

for the defender definition update "issue", maybe a simple change in wdu.cmd double checking updates would solve this (the updates, not events or update failure/abort info), like:

instead of:

Code:

"%ProgramFiles%\Windows Defender\MpCmdRun.exe" -SignatureUpdate
wub.exe /d /p
exit /b %errorlevel%

change it to something like:

Code:

"%ProgramFiles%\Windows Defender\MpCmdRun.exe" -SignatureUpdate
timeout /t 5
"%ProgramFiles%\Windows Defender\MpCmdRun.exe" -SignatureUpdate
wub.exe /d /p
exit /b %errorlevel%

 

@pf100
In my opinion there is some redundancy whith LockFiles.cmd and code in sledgemammer.cmd; redundancy means problem when updating. I suggest a minor change for LockFiles.cmd :

Spoiler

Code:

::Allow only LockFiles task to run this file::
whoami /user /nh | find /i "S-1-5-18" || exit
cd /d "%~dp0"
wmic cpu get AddressWidth /value|find "32">nul&&set PROCESSOR_ARCHITECTURE=X86||set PROCESSOR_ARCHITECTURE=AMD64
if %PROCESSOR_ARCHITECTURE%==AMD64 (
 set "nsudovar=NSudoCx64.exe"
) else (
 set "nsudovar=NSudoc.exe"
)
::::::::::::::::::::::::::::
::Set list (s32list) of update hijacker files to be disabled, then disable everything in the list.
set s32list=EOSNotify.exe WaaSMedic.exe WaasMedicSvc.dll WaaSMedicPS.dll WaaSAssessment.dll UsoClient.exe
set s32list=%s32list% SIHClient.exe MusNotificationUx.exe MusNotification.exe osrss.dll
set s32=%systemroot%\System32
::If "s32list" files were previously renamed by script, restore original file names
for %%# in (%s32list%) do (
ren "%s32%\%%#"-backup "%%#"
if exist "%s32%\%%#" del "%s32%\%%#"-backup /f /q
)
::Lock files
for %%# in (%s32list%) do (
takeown /f "%s32%\%%#" /a
icacls "%s32%\%%#" /reset
if exist "%s32%\%%#" %nsudovar% -ShowWindowMode:Hide -Wait -U:T -P:E "%systemroot%\System32\icacls.exe" "%s32%\%%#" /inheritance:r /remove *S-1-5-32-544 *S-1-5-11 *S-1-5-32-545 *S-1-5-18 >nul 2>&1
)
::If files in "s32list" aren't locked for whatever reason, rename them.
for %%# in (%s32list%) do (
ren "%s32%\%%#" "%%#"-backup
if exist "%s32%\%%#"-backup del "%s32%\%%#" /f /q
)
exit /b 0

The change consists in defining the nsudovar variable and executing iacls.exe with trustedintaller priviledge when needed.
And the corresponding code in sledgehammer.cmd is replaced by :
start "LockFiles" /wait ".\bin\LockFiles.cmd"

 

Is AskWoody Defcon system still used? because there was a recent design change yesterday or so

 

In 2.7.2 - Yes.
2.7.3 RC1 does not use it.

A design change would therefore break 2.7.2.

 

You need to login to view this posts content.

 

You need to login to view this posts content.

 

I agree that it doesn't need to be shown automatically. I can understand that it would be nice if Sledgehammer did it all. But the Sledgehammer interface already has a variety of menu selections, most that are highly useful. Adding another menu number for MS-DEFCON might add unnecessary complexity. And I'm not sure anyone wants an added screen to display in the sequence.

Personally, I visit AskWoody toward the end of the month to check the MS-DEFCON level and patch advice, and that's what triggers my use of Sledgehammer anyway.

 

False problem : @pf100 removed the programmatic interface to get the MS-DEFCON rating by replacing it by a browser call (cf line 250 of the script) as explained in the first post :
"Changed option to view current MS-DEFCON rating in script to opening MS-DEFCON rating in browser instead."

 

Right. Both the internal MS-DEFCON display and the subsequent browser call replacement worked for me. I think the question raised was whether the automatic display of MS-DEFCON was significant value added and should be continued or not.

 

Personally, I don't need it, and actually hate programs or installers force-opening URLs without my consent.

 

You need to login to view this posts content.

 

Does the Microsoft Update Health Service (uhssvc.exe) need to be disabled, and does the script do that? If so then how?

 

Just checked, and Microsoft Update Health Service is running (Automatic Delayed Start Startup Type) in my 20H2 Windows version with Sledgehammer active and effective. So, no, I don't think it needs to be disabled.

Edit: Correction - I answered too soon. It shouldn't be running or installed. See post below.

 

uhssvc = KB4023057

it should not be installed in the first place

 

Duh, yeah! Thanks! I've been blocking/hiding that update forever. I must have forgotten and let it slip through.

 

Deleted.

 

Does the script disable the files that Microsoft Update Health Tools (MUHT) uses, and hence can we just rely on the script to handle it or should we uninstall MUHT? Are there any plans for the script to lock the files in "C:\Program Files\Microsoft Update Health Tools", or make and lock the folder to prevent MUHT from installing in the first place, like what's done with Update Assistant?
@pf100