Wusa.exe return code checking

  • Add wusa.exe return code checking
  • Leave it
0 voters

Running into an issue with HCL MS content and I suspect this has been around for some time.

Here is the scenario:

Here is the 2019 hotfix for November:

prefetch windows10.0-kb5046615-x64_d88444ff882129230297936cb0a221157099d074.msu sha1:d88444ff882129230297936cb0a221157099d074 size:718440109 https://catalog.s.download.windowsupdate.com/d/msdownload/update/software/secu/2024/11/windows10.0-kb5046615-x64_d88444ff882129230297936cb0a221157099d074.msu sha256:8263637e991e7889e7384d935827b8aaf68d1c53cdd02a91d01199eb22a89f88

// Is Windows Update service running?
continue if {exists running service "wuauserv" OR NOT exists service "wuauserv" whose (start type of it = "disabled")}

waithidden "{pathname of system folder & "\wusa.exe"}" "{pathname of client folder of current site & "\__Download\windows10.0-kb5046615-x64_d88444ff882129230297936cb0a221157099d074.msu"}" /quiet /norestart

action requires restart "d88444ff882129230297936cb0a221157099d074"

Notice that we do not check wusa.exe return codes (which is good practice) and instead we see action script above.

HCL is relying on the relevance engine to accomplish the same thing but for us, it can take up to 45m for all of that realization to pass.

Scenario:

  1. Hotfix runs
  2. Return code 112 is received from wusa (space is low on OS drive)
  3. Hotfix fails but the relevance engine marks the content as not relevant (not sure why but I suspect it has to do with the action requires restart being set)
  4. Reboot
  5. If customer has any built-in retries (like we do) the retry runs to completion because the hotfix is not relevant giving the impression that all is ok when it really isn’t.
  6. Around 45m later from start of failed fix installation, the relevance engine marks the content as relevant again and then that endpoint ends up on naughty lists of not patched.

I don’t understand the logic of this versus changing the action script code for all MS content designed like (for example) KB5046615. Check the wusa.exe return codes for 0 or 3010 (reboot required) and make the hotfix post a failure status if a return code other than 0 or 3010 is posted by wusa.exe.

We do not like to clone HCL content for reasons like this, we need to convince development to add return code checks for all MS content existing today and in the future.

Proposal:

waithidden “{pathname of system folder & “\wusa.exe”}” “{pathname of client folder of current site & “__Download\windows10.0-kb5046615-x64_d88444ff882129230297936cb0a221157099d074.msu”}” /quiet /norestart

continue if {exit code of action = 0 or exit code of action = 3010}

action requires restart “d88444ff882129230297936cb0a221157099d074”

Please vote at top so I can convince L3 that checking return codes of wusa.exe is a better approach to reliance on the relevance engine.

You can submit a request for enhancement with all the necessary details; ideas with more clarity and justification will always carry more weight.

Customer Idea Portal | HCLSoftware

I consider this a bug.