Last Updated on March 18, 2022 by rudyooms

I guess you have all been reading my blog series. Magical Mi…Ehh Wipe Series – Call4Cloud. It will show you some weird issues with the Windows.Old folder after wiping the device when using OneDrive.

This additional blog to that series will be about the latest March Security Update 2022-03 and my experiences after installing the update and wiping the device. While installing I stumbled upon some weird behavior.

I will divide this blog into multiple parts

1. KB5011487 | KB5011493 | Windows.Old issues
2. KB5011487 | KB5011493 Wiping results
3. How to Speed it up?
4. What Changed with KB5011487 | KB5011493?
5. WaasMedicService
6. WaasMedicAgent

1. KB5011487 | KB5011493 | Windows.Old Issues

Yes…Yes!!! Yesterday (09-03-2022) the official Microsoft Fix was released to fix those Windows.Old issues!

Windows 10, version 21H2 | Microsoft Docs

Before I am going to show you what is going to happen after installing this update, let’s take a look first at what the documentation that comes with it, has to tell us!

Looking at their documentation, it is showing us some workarounds (I mentioned them in the previous blog) and the KB update itself. Luckily comparing this KB5011487 update with the January OOB updates that fixed the IKE issues, we could easily use WUfB to deploy this update to our devices.

But what if we don’t want to wait before the devices have installed this update with the use of WUfB? Because it could take some time before the update arrives at your devices!

Let’s start expediting some updates! Select 03/08/2022 – 2022.03 B Security Update to make sure this Quality update will be installed on your devices

Please read my blog about how to start troubleshooting the installation of Quality Updates when you run into some trouble!

2. KB5011487 | KB5011493 Wiping Results

I wanted to perform a test drive with the latest 2022-03 March Update on a Windows 11 VM to see what happens when we perform a remote wipe AND when we use a simple data recovery tool to check out what we could recover! Of course, we need to install the KB update first. To speed up the process a little bit I installed the necessary KB update manually. Sorry for cheating…

Also, I made sure I installed a new clean installed virtual machine, made sure OneDrive and KFM were configured and set to “always keep on this device“. After everything was set, I pressed the “wipe” button in Intune to start wiping the device!

After the device was successfully reset, I was expecting the Windows.old folder to be removed but I guess that’s not what’s happening right now?

As shown above, I didn’t even need to start a recovery tool as the data was still there? That’s odd? But when reading the Microsoft documentation, mentioning this fix again. I came across this line

I was like… huh? okay, we need to install the update to fix it but actually, we still need to wait about 7 days? In that same documentation, I also stumbled upon the KB5012414 update. Let’s find out what happens when we install the KB update itself and KB5012414

https://support.microsoft.com/nl-nl/topic/kb5012414-compatibiliteitsupdate-voor-het-installeren-en-herstellen-van-windows-11-oorspronkelijke-release-8-maart-2022-c166a62a-c0f3-4dfd-a9f1-b8f7f8758cd1?id=5004252

This update wasn’t a nice installer but a CAB file. No problem! I manually downloaded the CAB file and added it to my Windows installation with the use of the DISM tool as shown below

I guess I am getting used to wiping stuff as I again wiped this freshly installed VM. Let’s take a look at what happened with the Windows.old folder

Yes… I did use the same screenshot…Why? Because it had the same outcome!

Looking at the results above… It could probably take some time before it will be magically resolved? I was under the assumption this blog would be the final blog of this wipe series but I guess I still need to explain what happens in those 7 days. I guess it’s just magic?

3. How to speed it up

As always, RTFM… When looking at the same MS documentation it is mentioning only one possible solution to speed it up? I really don’t want to wait 7 days I guess.

WUT:

“For immediate resolution, you can manually trigger Windows Update Troubleshooter”

Luckily Microsoft also responded to give us some more clarification about those 7 days notice

Mmm.. really? This would be the first time, running a build in troubleshooter would fix something :)… But who cares, let’s first up a cmd and use the Microsoft Support Diagnostic Tool by entering this command: msdt.exe /id WindowsUpdateDiagnostic .

Another possibility would be to create an answer file with these 2 lines in it and use the TroubleshootingPack PowerShell Module.

<?xml version="1.0" encoding="UTF-8"?>
<Answers Version="1.0" />

Get-TroubleshootingPack -Path $env:SystemRoot\diagnostics\system\WindowsUpdate | Invoke-TroubleshootingPack -AnswerFile .\UpdatesAnswerFile.xml -Unattended -Result c:\temp\WUDResult

Do you know what is beautiful about this TroubleshootingPack Module? you can script it and deploy it to your devices with just a simple PowerShell script.

Results:

Huh.. Huh… And again… Huhhhh. Okay so running the troubleshooting tool, made sure when we performed a wipe the Windows.Old folder is removed? Okay… didn’t see that one coming!

Still need to test this script below a little bit more… but testing it and wiping the device after this script was pushed, removed the windows.old folder as expected!

$path = "C:\programdata\customscripts"
If(!(test-path $path))
{
      New-Item -ItemType Directory -Force -Path $path
}


$content1 = @'
<?xml version="1.0" encoding="UTF-8"?>
<Answers Version="1.0" />
'@

Out-File -FilePath c:\programdata\customscripts\UpdatesAnswerFile.xml -Encoding utf8 -Force -InputObject $content1 -Confirm:$false
$MyPath = "c:\programdata\customscripts\UpdatesAnswerFile.xml"
$utf8 = New-Object System.Text.UTF8Encoding $false
$MyFile = Get-Content $MyPath -Raw
Set-Content -Value $utf8.GetBytes($MyFile) -Encoding Byte -Path $MyPath

Get-TroubleshootingPack -Path $env:SystemRoot\diagnostics\system\WindowsUpdate | Invoke-TroubleshootingPack -AnswerFile c:\programdata\customscripts\UpdatesAnswerFile.xml -Unattended -Result c:\temp\WUDResult

It looks like the KB update just made a change to the Troubleshooting Tool and that “tool” is somehow scheduled to run within 7 days….. while running the Troubleshooting tool and studying the reports it created, I stumbled upon the “WaasMedicService”

4. What Changed with KB5011487 | KB5011493

After stumbling upon that Windows As a Service Medic Service, I realized this KB could have updated these files after installation. So I made sure I took some screenshots of the system32 Folder before installing this wonderful update

All of these files have the same product version: 10.0.22000.132!

So let’s update the device with the 2022-03 March Update and let’s take another look at these files

As shown above, only the WaaSMedicCapsule.dll has increased size. After checking out the Product versions of these files, we will notice these DLL’s are updated from 10.0.22000.132 to version 10.0.22000.556.

5. WaasMedicService

Now we know for sure, these files are updated during the 2022-03 update, I guess it’s time to take a better look at this nice WaaSMedic (Windows as a Service) service and what it does. When first running the Windows Update Troubleshooting tool a nice report with some errors will be shown.

It’s showing: Issue Found: “DynamicProtectionPlugin; ResetRepairPlugin” But nothing more… Okay, when this tool is telling us nothing we need to dig further!. I guess the last part “service” would mean there should be a service? Yes of course!

Looking at the description it is telling us, this service will enable remediation and protection of Windows update components. Remediation…..Remediation… It will remediate the Windows.old issue? We all know by now, this issue will be remediated within 7 days. So there must be a scheduled task configured to start this remediation?

As shown above, there is a nice subcategory inside the task scheduler \Microsoft\Windows\WaaSMedic, with a nice task inside called “PerformRemediation”. This task will be executed within 7 days as it seems.

Again, that word remediation, I guess we are all now pretty sure “something” will be remediated! But what does it do? Exactly the same thing as I described earlier, it will make sure the Windows Update Troubleshooting tool will be executed to make sure “something” will be remediated.

So how does this remediation works? Yes, I am going to dig a little bit deeper….

6. WaasMedicAgent.exe

As shown above, when executing this scheduled task (or the troubleshooting tool) will launch the WaaSMedicAgent.exe from the System32 folder. But what’s happening after it launches this Executable? It will dump some XML files inside the c:\Windows\WaaS folder

This executable will also use a DLL file inside your System32 folder called: “WaaSMedicCapsule.dll“

Looking at this DLL file we would notice it has some functions it could call upon. Looks like this DLL could Perform some Actions (Plugin_PerformAction)

Just after I noticed the use of this DLL while running MSDT some funny stuff caught my eye! Suddenly some new folders and files in the c:\Recovery\OEM were created.

To be 100% sure I also launched an additional Event Trace Logging with these 2 EventProvider ID’s configured.

 <EventProvider Id="EventProvider-Microsoft.Windows.WaaSMedic" Name="76ad4308-df7c-5f43-e668-fcea4fa1179d" />
 <EventProvider Id="EventProvider-Microsoft.Windows.WaaSMedic.Local" Name="3076679b-a75c-4705-aaa4-836903b93875" />

As shown below, it’s telling me the exact same thing, the Windows As a Service Medic will need to create these 2 files when remediation is needed

Okay…Looking at the folder and files names, it sounds exactly the same idea as I showed you last month?

Windows 21H2 | Data Wipe Command leaves User Data on disk (call4cloud.nl)

A small summary: I used the Push-button reset recovery tool and created resetconfig.xml and commoncustomizations.cmd to remove that windows.old folder during the wipe process.

To be 100% sure, I took over the permissions of this OEM folder and opened the ResetConfig.xml and cmd file from the c:\Recovery\OEM folder

When looking at the content of those files and the idea behind it, this literally happened to me!!!

And a little bit of this…

So…I was like… Wait…What, What the….? Microsoft is also using the ResetConfig.xml / Push-Button reset tool to remove that lingering Windows.old folder. Somehow I got the feeling it looks the same as I was doing. I was expecting a change in the reset code with this official fix and not using an additional tool as I did 🙂

Conclusion

So it doesn’t really matter which fix you are using… mine PowerShell fix or the Offical Microsoft Update. Even while my idea/fix was created about 1 month earlier than Microsoft their idea/fix. Looking at it, I have mixed feelings…. but I guess it’s quite an honor somehow I had exactly the same idea!

Please Note: My fix could be used without installing the latest march update! Please reach out to me if I missed something!