Use Proactive remediations to report on or install the Microsoft Update Health tools

Microsoft recently made a download available for their Update Health tools – if you’re using Microsoft Endpoint Manager and enrolling or co-managing Windows devices these tools need to be installed to make use of the capability for expediting quality updates.

For devices connected to Windows Update or Windows Update for Business these tools should already be installed, but in some cases they aren’t – and those devices can’t have updates expedited.

If the tools aren’t installed, MS would like some feedback so they can figure out why – but since they made the tools available for download, we also have the option to manually deploy them if desired, which is something you might want to do when migrating from another software update solution like MEMCM to MEM / WUfB, for example – pre-deploy these tools so they will be ready to use the expedite feature right away.

I created some scripts that can be used with Proactive remediations – the detection script will report on whether the Update Health tools are installed, and optionally you can use the remediation script to go ahead and download and install the tools if they are missing, without needing to package them as an app.

Devices with the tools installed will report the tools version and install date in the Pre-remediation detection output. Devices where the tools are missing will report “Update tools not installed” and if remediated will show the same tools info in the Post-remediation detection output.

I’d suggest to just run a one-time deployment when you need rather than run it repeatedly on a schedule.

11 thoughts on “Use Proactive remediations to report on or install the Microsoft Update Health tools

  1. Why not run it as a script instead of proactive remediation? The latter is intended for recurring activity’s.

  2. Hi – I’m having trouble with the remediation side – I see you have updated your script a few weeks ago. The script fails to run with an exit code of 1639.

    If I manually run the remediation script it is failing on the msi install – it is bringing up the msi options screen where Windows tells you all of the different arguments you can choose from with the msi command.

    I’ve reviewed the script and can not see anything wrong with it. Any ideas?

    1. Interesting…if you run this code on the device do you get the full msi filename as output?

      $DownloadDirectory = “$env:Temp”
      $DownloadFileName = “Expedite_packages.zip”
      $LogDirectory = “$env:Temp”
      $LogFile = “UpdateTools.log”
      [int]$CurrentBuild = Get-ItemProperty “HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion” -Name “CurrentBuildNumber” | Select -ExpandProperty CurrentBuildNumber
      if ($CurrentBuild -gt 22000)
      {
      $OSVersion = “Windows 11 22H2+”
      }
      elseif ($CurrentBuild -eq 22000) {
      $OSVersion = “Windows 11 21H2”
      }
      else
      {
      $OSVersion = “Windows 10”
      }
      $MsiLocation = “$DownloadDirectory\$($DownloadFileName.Split(‘.’)[0])\$OSVersion”
      $File = Get-Childitem -Path “$MsiLocation\*.msi” -File
      $File.FullName

      1. Yes I do – its very odd. Its only when the entire remediation script runs that it looks like an option is missing from the install command.

  3. Yes – this is what is retuned

    C:\Users\matt.d\AppData\Local\Temp\Expedite_packages\Windows 11 22H2+\UpdHealthTools.msi

  4. The detection script as-is in your git wasn’t working for me and resulted in every machine reporting that the tools were not installed. MS posted their own PS script that looks for “4023057” which is the KB for the update health tools. https://learn.microsoft.com/en-us/mem/intune/protect/windows-10-expedite-updates

    That worked better, but on a machine that has just upgraded from Win10 to Win11, it appears the install history is deleted, so the search fails.

    The simple solution I went with was to check and see if the uhssvc service is running, and if it is, call it a day.

    1. Thanks for the comment. The detection method is still working fine for us. I assume you did set the “Run script in 64-bit PowerShell” option – otherwise it may not return results from the registry correctly.

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.