Set preferred Windows 10 version

In our environment, Windows 10 feature updates weren’t appearing in the list of available patches. Here’s a solution that doesn’t require downloading an ISO file.

There is a registry setting to target a specific feature update. Once we set that registry setting, the feature update became available as a regular patch and we could manage it easily with Automox.

This script checks if the machine is running Windows 10, and if so it sets the TargetReleaseVersion and TargetReleaseVersionInfo registry values to match the update you specify. To modify the script for your preferred Windows 10 version, just edit the $targetFeatureUpdateVersion variable in the evaluation and remediation scripts. Use the version numbers as listed on the Windows 10 release information page.

Evaluation:

<#
.SYNOPSIS
  Checks if the registry is set to upgrade Windows 10 to a specific version.

.DESCRIPTION
  Checks if the computer is running Windows 10 and if the TargetReleaseVersion and
  TargetReleaseVersionInfo registry keys are set in this location:
  HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate

  Exits with 1 (non-compliant) if the computer is running Windows 10 and the keys are missing,
  otherwise exits with 0.

.NOTES
  The Automox agent is 32-bit, so we use a script block to run commands in a 64-bit
  PowerShell process. This is the easiest way to access the 64-bit registry.
#>

$scriptblock = {
    # Use the version number as listed at https://aka.ms/ReleaseInformationPage
    #####
    $targetFeatureUpdateVersion = "20H2"
    #####
    
    $windowsVersion = (Get-WmiObject win32_operatingsystem).Caption
    if (-not $windowsVersion.Contains("Windows 10")) {
        return 0
    }

    $wuKeys = Get-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate"

    if ($wuKeys.TargetReleaseVersion -ne 1 -or $wuKeys.TargetReleaseVersionInfo -ne $targetFeatureUpdateVersion) {
        return 1
    }
    else {
        return 0
    }
}

$exitCode = & "$env:SystemRoot\sysnative\WindowsPowerShell\v1.0\powershell.exe" -ExecutionPolicy Bypass -WindowStyle Hidden -NoProfile -NonInteractive -Command $scriptblock
exit $exitCode

Remediation:

<#
.SYNOPSIS
  Sets the registry to upgrade Windows 10 to a specific version.

.DESCRIPTION
  Sets the TargetReleaseVersion and TargetReleaseVersionInfo registry keys in this location:
  HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate

.NOTES
  The Automox agent is 32-bit, so we use a script block to run commands in a 64-bit
  PowerShell process. This is the easiest way to access the 64-bit registry.
#>

$scriptblock = {
    # Use the version number as listed at https://aka.ms/ReleaseInformationPage
    #####
    $targetFeatureUpdateVersion = "20H2"
    #####
    
    Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" -Name TargetReleaseVersion -Value 1 -Type DWord
    Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" -Name TargetReleaseVersionInfo -Value $targetFeatureUpdateVersion -Type String
}

& "$env:SystemRoot\sysnative\WindowsPowerShell\v1.0\powershell.exe" -ExecutionPolicy Bypass -WindowStyle Hidden -NoProfile -NonInteractive -Command $scriptblock
exit 0
4 Likes

Ran this in my environment and got massive alerts from Bitdefender. Looks like it doesn’t like the powershell process running?

That’s a fairly common thing with endpoint security programs. I added Automox to our application whitelist which worked for us. We can go further with our particular endpoint security software and say if PowerShell is invoked by Automox, let it run. I don’t know how exactly Bitdefender works, but you could probably do something similar.

1 Like

yeah had a feeling i needed to do something like that.
hey thanks for the response! :grinning:

Nice worklet. I’m testing it, but I don’t find the new available patch. From a computer that is 20H2 in its Device>Software page it should appear some patch with the 21H1 tag, isn’t it?