Set preferred Windows 10 version

  • 16 July 2021
  • 8 replies
  • 625 views

Userlevel 1

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

8 replies

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


Badge

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.

yeah had a feeling i needed to do something like that.

hey thanks for the response! 😀

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?

Could this method be used to block the installation of Windows 11?

Badge

 

 
 

ss_tk:

 

 

 

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.

 

Be vigilant with general whitelists - I would make it more granular and only allow what you know you push out.

For instance - if general Automox, or your automox account/instance gets compromised, a bad actor could push whatever they want. 

Userlevel 1
Badge

This is probably the best Worklet I’ve come across in the platform! Worked like a charm! Thanks @Stephen_Wade 

Userlevel 1
Badge

This policy is great, but we found that if a host doesn´t have the "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" registry key for any reason, it won´t work, and the device will not be updated to the latest Feature Update. 

To fix this, you can add this in the evaluation code before first conditional:


$wuPath = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate"
$regExists = Test-Path $wuPath
if ($regExists -eq $false) {
Write-host 'Registry not set'
Exit 1
}

 

And this on the remediation, before the Set-ItemProperty:


$wuPath = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate"
$regExists = Test-Path $wuPath
if ($regExists -eq $false) {
Write-host 'Registry not set'
New-Item -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows" -Name "WindowsUpdate" -Force
}

 

Reply