2022-03 Update: The Search for Sp… Uhh Shift+F10

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

1. Introduction to Shift F10

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

Of course, I 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 be able to disable this troubleshooting option when the end users really don’t need access to it.

This solution used the possibility 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 Fix

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! Some Proactive remediations run each hour to check the contents. If the resetconfig.xml contains some words, we need to remediate them! I guess Microsoft’s troubleshooting tool isn’t the only one that is 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 detects the wrong ResetConfig.XML and exits with a failure (exit 1) to ensure the remediation script is 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!

The CMD file, the Tag file, and the ResetConfig file are ready! Let’s wipe the device to check if the possibility to use shift+f10 is blocked and if 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!