For instance, I’ve seen questions from people on TechNet that have run into the pending reboot issue. I myself experienced it first hand during last week's customer's engagement. Based on a quick Web search, there’s little clear help for fixing it, so in this post, I’ll give you easy steps you can follow to remedy the most common cause of this behavior.
My particular case opened when I helped a customer transition to an MDT task sequence based on current best-practices for deploying Windows 10, including automated driver management. During deployment we noticed, that Autodesk DWG TrueView 2018 installation was not being executed properly - while Autodesk DWG TrueView 2018 setup exited with return code 0, the program was not being installed on the test system (a Lenovo Miix 510). I started investigating.
From my past experiences I knew that most Autodesk programs write a log file into the %temp% directory, so I navigated to the folder, located the DWG TrueView 2018 - English Setup.log log file and opened it:
2017/11/10:12:06:45 Administrator MDT-DEMO-2 === Setup started on MDT-DEMO-2 by Administrator === 2017/11/10:12:06:45 Administrator MDT-DEMO-2 Path_Length: 135 2017/11/10:12:06:45 Administrator MDT-DEMO-2 Current Directory \\MDT01\DeploymentShare$\Applications\Autodesk DWG TrueView 2018 11.0.31.0\Source 2017/11/10:12:06:45 Administrator MDT-DEMO-2 Launch 2017/11/10:12:06:45 Administrator MDT-DEMO-2 CommandLine /q /w /i setup.ini 2017/11/10:12:06:45 Administrator MDT-DEMO-2 Setup Windows update reboot is pending 2017/11/10:12:06:45 Administrator MDT-DEMO-2 Setup Autodesk® DWG TrueView™ 2018 - English Will restart automatically. 2017/11/10:12:06:45 Administrator MDT-DEMO-2 === Setup ended ===
The reason why setup was not installing Autodesk DWG TrueView 2018 was a pending Windows update reboot. This was unexpected, as we already set the ProtectYourPC value, which specifies whether Windows Update installs important and recommended updates automatically, to 3 (= automatic protection is disabled and MDT is in full control as to when Windows Update runs). But there's one other issue that we run into, especially if the task sequence doesn’t run for very long in the State Restore phase: Windows Update can automatically download and install recommended drivers and detailed information for many devices (such as network adapters, monitors, printers, and video cards). While this may be a good way to make sure all devices work properly, this default behavior can break OSD task sequence.
Sure enough, when I checked Windows Update history, I noticed that an update for Intel(R) HD Graphics driver was automatically downloaded and installed while the TS was running. This was caused by the customer not including up-to-date GPU drivers in the deployment share, which in turn triggered Windows Update to find and install the applicable driver from Microsoft.
Aside from the obvious (e.g. fixing Out-of-Box drivers repository), I advised the customer to disable automatic update process via a registry tweak. Windows Update provides options to control whether to download and install driver upgrades automatically or manually. The admin added this to Unattend.xml right before the </RunSynchronous> tag:
<RunSynchronousCommand wcm:action="add">
<Description>disable driver update</Description>
<Order>5</Order>
<Path>reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\DriverSearching /v SearchOrderConfig /d 0 /t REG_DWORD /f</Path>
</RunSynchronousCommand>
Note: Possible options are: 0 = 'No, let me choose what to do - Never install driver software from Windows Update', 1 = 'Yes, do this automatically (recommended)', 2 = 'No, let me choose what to do - Install driver software from Windows Update if it is not found on my computer.'
The case was closed since with that in place, Windows will no longer automatically download and install drivers through Windows Update.
We also added a script towards the end of the task sequence to - among other things - reset the driver update policy. I am including a sample script below:
# Determine where to do the logging
$tsenv = New-Object -COMObject Microsoft.SMS.TSEnvironment
$logPath = $tsenv.Value("LogPath")
$logFile = "$logPath\$($myInvocation.MyCommand).log"
# Start the logging
Start-Transcript $logFile
Write-Host "Logging to $logFile"
# ---------------------------------------------------------------------------
# Main logic
# ---------------------------------------------------------------------------
Write-Host "Resetting driver update policy to Microsoft's default value..."
New-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\DriverSearching" -Name "SearchOrderConfig" -Value 1 -Type DWORD -Force | Out-Null
Stop-Transcript
As a rule of thumb, always undo the damage you are inflicting upon recommended configuration, as this hilarious Twitter exchange will teach you:
