Deploy OOB Update with PowerShell

This blog will be about Patch Tuesday and how to deal with those optional OOB (out-of-band) updates when you configure some nice Windows Update for Business (WUfB) rings.

By now, I guess everyone has heard the news about the Microsoft January 2022-01 Updates that could break your Domain Controller (DC) or your IKE connection. If not, please bring it up or Google it.

1. The Issue Explained

As always, let’s start by looking at what happened. Microsoft decided to release two nice Updates in January 2022, KB5009543 and KB5009566.

Unfortunately, these updates could break your Windows VPN client, and you will end up with this screen: Can’t Connect to VPN

Okay, okay, it could be worse, right? Way, way worse could be seeing your DC’s ending up in a boot loop every 3 hours? I guess it’s every IT pro worst nightmare noticing this 0x50006 LSASS error in your event log

But let’s go back again to the Windows 10/11 update massacre. When we were getting the first phone calls about the VPN software not working, the first thing we did was “pausing” the Update Rings

When using the “Pause” feature updates option, you can make sure the device will stop receiving those feature updates for a period of 35 days. When configured, Intune will create a nice registry key “PauseFeatureUpdatesStartTime” inside the \Microsoft\PolicyManager\default\Update registry key.

If you want to read more about Pausing Updates and how to deal with them. Please read this blog

https://call4cloud.nl/2022/01/updates-rings-no-way-home

Normally, 35 days should be enough for Microsoft to fix it, but luckily, Microsoft decided to pull back those updates and released an out-of-band (OOB) optional update to fix it. (KB5010793 and KB5010795)

January 17, 2022—KB5010793 (OS Builds 19042.1469, 19043.1469, and 19044.1469) Out-of-band (microsoft.com)

Looking at the Highlights, it’s pretty obvious what this update is going to fix!

“Updates a known issue that affects VPN connections”

But here comes the pain! How the hell are we going to install this optional update on the devices experiencing the issue?

You can forget about that optional update automatically being deployed to the devices with the use of the WUfB deployment rings.

Because those devices targeted with WUfB will only receive the “Update Tuesday/Monthly” updates, aka Week B updates, and not the “Preview” updates or OOB Updates. Your users can click “Check for Updates” as often as they want to click on it, it will not change the fact that their systems are part of WUfB

So what now? Are we just going to deploy a PowerShell script to uninstall that update and be done with it?

wusa /uninstall Kb5009543

2. The First Attempt

Uninstalling the update could be a solution, but not the one we want! Luckily I needed to install some KB some time ago when we were dealing with the Windows Update Health Tools (KB4023057) that were missing on a device. So fixing this is going to be a piece of cake..(at least what I thought at first)

So I just downloaded this nice Proactive remediation script I created earlier to change only the KB I need to download

After changing the KB to match the optional update we need to deploy, I uploaded the script to Intune and assigned it to a PROD—eh, sorry, TEST group. Prod/test, what’s the difference?

But after waiting a while, the Proactive remediations didn’t do anything except notify the user that it was searching for updates, so I needed to take a look myself at a test device.

So the first thing I did was check out if the PSwindowsupdate PowerShell module was successfully installed.

As shown above, it was installed successfully, so that wasn’t the issue. I also tried to install the update manually, but as shown below, nothing happened.

Okay okay, let’s try something else and just try to find any available update! But you could guess the outcome, it didn’t get me any results.

And just at that point, I was like, duh. It’s an optional OOB update and unavailable to deploy with the Update ring! No wonder I couldn’t find the update!

3.The Second attempt

So now I have seen with my own eyes that my first idea wasn’t going to work—I needed to change some stuff! Looking at the script also made me realize that we are also dealing with Windows 11 now.

So I needed to change some parts in the ProActive remediation scripts (I will post the link to the zip file with both of the PowerShell scripts at the end of this part)

Detect.ps1

Let’s start with the changes in the detection script

$Version = (get-wmiobject -class win32_operatingsystem | Select Version).Version
if($Version -like "10.0.1*"){
$kb = "KB5010793"
}
elseif($Version -like "10.0.2*"){
$kb = "KB5010795"
}

$kbsearch = "*$kb*"

So we added this part to check the Windows version first and see if the required update has already been installed. Okay, that was easy, but we still need to fix the update issue itself

Remediation.ps1

Now we have learned the hard way: We can’t download or install this update using the PSwindowsupdate PowerShell module; we need to download it ourselves!

As shown below, we removed the install-windowsupdate part and replaced it with some invoke-webrequest to download the specific update for the proper Windows version.

After downloading the update, we just use WUSA.exe to quietly install it, wait for the update to be installed, and trigger the toast message. We also show a toast message to the end user; otherwise, how could they know they need to reboot their device?

Looking at the screenshot above, you will notice I have put everything after #, why? Because I am using a scheduled task to trigger it with PowerShell, run as system and with an encoded command (that’s above this part)

So every time you need to deploy an optional update, you will need to change this part and make sure you remove the # before converting it to an encoded script

Please note: You could change/update the Toast message to your liking. I guess we still need to improve it a bit and add our own company logo.

As promised, here is the link to the zip file containing the detection and remediation script!

https://call4cloud.nl/wp-content/uploads/2022/01/detect.zip

4. Results

After waiting some time to get the proactive remediations script deployed, the end-user would be prompted with the toast message telling you, you will need to reboot your device!

Of course, I wanted to be sure the update was installed successfully. So I entered this PowerShell command $status = Get-hotfix | where-object {($_.HotFixID -like $kbsearch )} to be sure.

As shown above, the toast message was right! The update is installed successfully! Let’s circle back to the ProActive remediations and take a look to see if they are also detecting the update now!

As shown below, the proactive remediations are without any errors and show us the KB5010795 has been installed!

And maybe the most important thing is that after installing those out-of-band updates AND rebooting, the Windows VPN client will work again! (sorry for the bad screenshot 🙁 )

5. Microsoft’s solution

Of course, Microsoft also has some good documentation on how we could deal with these kinds of updates

https://docs.microsoft.com/en-us/mem/intune/apps/apps-win32-deploy-update-package

Looking at this wonderful article, you will notice that they advise you to create a PowerShell Script, add those installations (.MSU) files to that same folder, and convert it to a Win32App.

Just like my script it uses the Windows Update Stand-Alone (WUSA) installer to install those packages

wusa.exe .\windows10.0-kb4532693-x64_e22f60a077a0ec5896266a18cc3daf26bfc29e16.msu /quiet /norestart -Wait

So instead of downloading it from the website, you add those files to the Win32App! Of course, this solution will also work as expected. But I love the Toast message and the Proactive remediations notification output a lot more. But for everyone not licensed to use proactive remediations, this solution is fantastic!.

6. The Windows 11 Insider Preview Build Fix

Now that I’ve shown you the options you have to fix your regular Windows 10 and Windows 11 devices, we still need to take a look at the Windows 11 Insider preview version because those nice fixes Microsoft released can’t be used on an Insider build.

Luckily, there is a solution to ensure that your Windows 11 Insider preview devices can use the IKE connection again.

When using L2TP Vpn connection, you are making use of the IKE and AuthIP IPsec Keying Modules Service. When looking better at that service, you will notice it uses a DLL called: IKEEXT.DLL in the system32 folder. With the latest insider previews, this file is updated to a newer version

So let’s download the Windows Insider Beta Build 22000.194 and open the install.wim file with 7-zip to extract that IKEEXT.dll file

If you don’t want to wait for the download and extract the file, you could also download the file directly from my website

https://call4cloud.nl/wp-content/uploads/2022/01/ike.zip

Now place that file in a new folder and let’s create a PowerShell script to

1. Change the Owner and permissions of that file
2. Stop the IKE service
3. Overwrite the IKEEEXT.dll file
4. Star the IKE service

After you have created the PowerShell script, make sure you convert the Powershell Script and the file to a nice Win32 app with the Microsoft Win32 Content Prep tool. 

$SID = "S-1-5-32-544"
$Account = new-object System.Security.Principal.SecurityIdentifier($SID)


try
{
	$Itemexists = test-path 'C:\Windows\system32\ikeext.dll'
      $ItemList = Get-Item -Path C:\Windows\system32\ikeext.dll
}
catch
{
	write-host "an error occurred"
       exit 1
}


if($Itemexists)
{ 

	$Acl = $null; 
    	$Acl = Get-Acl -Path $Itemlist.FullName; 
    	$Acl.SetOwner($Account); 
    	Set-Acl -Path $Itemlist.FullName -AclObject $Acl; 
}else{ 
	Write-Host  "File not found!"
        #exit 1            
}

try
{
	$Acl = Get-Acl -Path $Itemlist.FullName; 
      $owner = $acl.owner
}
catch
{
	write-host "owner not found"
      #exit 1
}


if ($owner -eq $SID)      
{
   	$myPath = $itemlist
	$myAcl = Get-Acl "$myPath"
	$myAclEntry = "nt authority\system","FullControl","Allow"
	$myAccessRule = New-Object System.Security.AccessControl.FileSystemAccessRule($myAclEntry)
	$myAcl.SetAccessRule($myAccessRule)
	$myAcl | Set-Acl "$MyPath"
	

	$myPath = $itemlist
	$myAcl = Get-Acl "$myPath"
	$myAclEntry = $account,"FullControl","Allow"
	$myAccessRule = New-Object System.Security.AccessControl.FileSystemAccessRule($myAclEntry)
	$myAcl.SetAccessRule($myAccessRule)
	$myAcl | Set-Acl "$MyPath"
	
}else{
       Write-Host "Permissions couldnt be changed"
       exit 1
}

try
{

net stop IKEEXT
copy-item .\ikeext.dll -Destination c:\windows\system32\ikeext.dll
net start IKEEXT
write-host "PatchApplied"	
	exit 0
}
catch
{
	write-host "an error occurred"
      exit 1
}

Conclusion

Sometimes, you will need to do some manual labor to fix things! It’s a shame there isn’t a way to deploy these kinds of optional updates with built-in Intune tools, but then again, we have proactive remediations, right?