Last Updated on May 22, 2023 by rudyooms

This blog will be about Microsoft’s “their” solution to remove the lingering Windows.old folder after a remote wipe. I noticed that when using Microsoft their solution, my older solution to block the shift+F10 functionality will be disabled. This solution was also using the Push-Button reset options

I will divide this blog into multiple parts

1. Introduction
2. My Old Fixes
3. My new Fix
4. The Results

1. Introduction

Some time ago I wrote a blog about how you could block the possibility to use Shift+F10 for your end users when the device needs to enroll in Autopilot.

Of course, I do understand that sometimes using Shift+F10 to troubleshoot a broken Autopilot enrollment can be great!

Don’t get me wrong but I would also love to have the possibility to disable this troubleshooting option when the end users really don’t need access to it.

This solution made use of the possibilities to add some customization to the Push-Button reset options. The ResetConfig.XML will call upon the EnableCustomizations.CMD file to copy the DisableCMDRequest.tag into the c:\windows\setup\scripts folder to prevent the use of Shift+F10

As shown above, this is how the c:\recovery\oem folder would look like when you deployed the PowerShell script to your tenant. While digging into the technical flow, what is happening after you install the March 2022-03 security update, I stumbled upon some not-expected behavior.

As shown above, when you install the latest March 2022-03 security update ( you will notice your old ResetConfig.xml will be renamed and a new ResetConfig.XML will be placed in that folder together with an additional AfterImageApply_.cmd script.

This new resetconfig.xml only contains the fix for removing Windows.old folder after applying the Image (AfterImageApply)

Mmmm… I guess that’s not what we want because we want to ensure that windows.old folder is removed and the DisableCMDRequest.tag is placed inside the c:\windows\setup\scripts folder

2. The Old Fixe

Looking at my “old” script to block Shift+f10 and my script to remove the Windows.old folder I am using the Commoncustomizations.cmd file whereas Microsoft is using a random AfterImageApply_randomnumbers.cmd script.

Let’s again compare my solution with Microsoft’s solution? It looks almost exactly the same, doesn’t it?

So wouldn’t it be cool to combine the Shift+F10 fix and the Windows.old fix inside 1 PowerShell script?

It would be great indeed but here comes a little bit of trouble. When we deploy this PowerShell script before the device had run the troubleshooting tool we will end up with still a renamed resetconfig.xml file. So how are we going to make sure our resetconfig.xml will end up on the device?

That’s right! With some Proactive remediations running each hour to check some contents and if the resetconfig.xml contains some words we need to remediate it!. I guess the troubleshooting tool from Microsoft isn’t the only one doing some remediation!

3. The New Fix

Let’s take a look at what the Detection.ps1 and Remediation.ps1 script looks like.

Detection.Ps1

As shown below, it will try to detect the CommonCustomizations. cmd and if it exists it will check if it contains the DisableCMDRequest.tag value. If the script fails to detect the pattern it will exit the script with exit code1.

try
{
    #Get resetConfig.xml
    $filepath = "c:\recovery\oem\CommonCustomizations.cmd"
    #Test if CommonCustomizations.cmdl exist
    if(-not(Test-path $Filepath))
    {Write-Host "commoncustimzations not found"
    exit 1
    }else 
    {Write-Host "commoncustimzations found"
    } 
    #Check if CommonCustomizations.cmd contains DisableCMDRequest.TAG
    $file = (get-content -path $filepath | select-string -Pattern "DisableCMDRequest.TAG").Matches.Success
    if ($file -contains $true)  
    {Write-Host "CommonCustomizations.cmd doesnt need to be changed"
    exit 0
    }else 
    {Write-Host "Wrong CommonCustomizations.cmd version detected"
    exit 1
    } 
}
catch{
    $errMsg = $_.Exception.Message
    Write-Error $errMsg
    exit 1
    }

Remediation.ps1

This PowerShell remediation script also contains all the basics from the other Scripts. As shown below I am making sure the c:\windows.old\users folder is removed after Image Apply but I am also making sure the DisableCMDRequest.tag file is copied to the setup\scripts folder

##############################################################################
# Create disablecmdrequest in the c:\windows\setup\scripts                 #
##########################################################################
$path = "C:\Windows\Setup\Scripts"
If(!(test-path $path))
{
      New-Item -ItemType Directory -Force -Path $path
}

$path = "C:\Windows\Setup\Scripts\DisableCMDRequest.TAG"
If(!(test-path $path))
{
      New-Item -ItemType file -Force -Path $path
}


#######################################################
# Create disablecmdrequest in the oem recovery folder #
#######################################################

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

$path = "C:\recovery\oem\DisableCMDRequest.TAG"
If(!(test-path $path))
{
      New-Item -ItemType file -Force -Path $path
}

#######################################################
# create enablecustomizations.cmd in the oem folder   #
#######################################################


$content = @'
for /F "tokens=1,2,3 delims= " %%A in ('reg query "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\RecoveryEnvironment" /v TargetOS') DO SET TARGETOS=%%C
for /F "tokens=1 delims=\" %%A in ('Echo %TARGETOS%') DO SET TARGETOSDRIVE=%%A
if not exist "%TARGETOS%\Setup\Scripts\" mkdir "%TARGETOS%\Setup\Scripts"
rmdir /s /q C:\windows.old\users
copy "%TARGETOSDRIVE%\Recovery\OEM\DisableCMDRequest.TAG" "%TARGETOS%\Setup\Scripts\DisableCMDRequest.TAG" /y
'@

Out-File -FilePath c:\recovery\oem\CommonCustomizations.cmd  -Encoding utf8 -Force -InputObject $content -Confirm:$false


$MyPath = "c:\recovery\oem\CommonCustomizations.cmd"
$utf8 = New-Object System.Text.UTF8Encoding $false
$MyFile = Get-Content $MyPath -Raw
Set-Content -Value $utf8.GetBytes($MyFile) -Encoding Byte -Path $MyPath


#######################################################
# create ResetConfig.xml in the oem folder   #
#######################################################


$content2 = @'
<?xml version="1.0" encoding="utf-8"?>
<!-- ResetConfig.xml -->
<Reset>
  <Run Phase="BasicReset_AfterImageApply">
    <Path>CommonCustomizations.cmd</Path>
    <Duration>2</Duration>
  </Run>
  <Run Phase="FactoryReset_AfterImageApply">
    <Path>CommonCustomizations.cmd</Path>
    <Duration>2</Duration>
  </Run>
  <!-- May be combined with Recovery Media Creator
       configurations – insert SystemDisk element here -->
</Reset>
'@

Out-File -FilePath c:\recovery\oem\ResetConfig.xml -Encoding utf8 -Force -InputObject $content2 -Confirm:$false

$MyPath = "c:\recovery\oem\ResetConfig.xml"
$utf8 = New-Object System.Text.UTF8Encoding $false
$MyFile = Get-Content $MyPath -Raw
Set-Content -Value $utf8.GetBytes($MyFile) -Encoding Byte -Path $MyPath


#######################################################
# delete other *.cmd in the oem folder   			#
#######################################################

Get-ChildItem c:\recovery\oem\ | Where{$_.Name -Match "AfterImageApply*"} | Remove-Item

4. The Results

First, let’s take a look at how the ResetConfig.XML looks like after the troubleshooting tool was run

As told earlier, our own resetconfig.xml will be renamed and the new XML is placed inside the OEM folder. Let’s check out what changed in it and what will happen when the detection script is run!

As shown above, the script will detect the wrong ResetConfig.XML and it will exit with a failure (exit 1) to make sure the remediation script will be launched!

When the remediation scripts kick in, it will replace the ResetConfig.XML with our version and will remove the old AfterImageApply_ cmd file

Okay.. it looks like the fix has been applied to my device, let’s check out the ProActive remediations monitoring! As shown below: Remediation Status: Issue Fixed!

CMD file ready, Tag file ready, ResetConfig file ready! Let’s wipe the device to check out if the possibility to use shift+f10 is blocked and the Windows.old folder is removed!

I guess you will need to trust me when I am telling you after the wipe, Shift+F10 is blocked. Also, the Windows.old folder is removed from the device! Isn’t that great?

Two solutions combined in one proactive remediation!

Conclusion:

Even while I am sort of happy Microsoft fixed the Windows.old Issue, it could break your own Push-Button reset scripts! So please make sure you check them if you are using them!