Microsoft Security Update for Windows 7 for x64-based Systems (KB2984976), titled RDP 8.0 update for restricted administration on Windows 7 or Windows Server 2008 R2 and released on October 14, 2014, as one of that month’s Patch Tuesday updates, appears to cause multiple restarts when applied during the Install Software Updates step within a System Center Configuration Manager Task Sequence. The second restart is not controlled by the Task Sequence engine and causes the engine to be unable to resume the Task Sequence when the computer comes back up after the second restart. The Task Sequence therefore fails to complete.

This behavior is a known issue with software updates that require multiple restarts, as documented in KB2894518, titled Task sequence fails in Configuration Manager if software updates require multiple restarts. Microsoft’s recommendation in KB2894518 is to deploy those updates that require multiple restarts outside of a Task Sequence.

If your patching procedure is to deploy Software Updates and other application updates during a maintenance Task Sequence and a hotfix is applied during the Install Software Updates step that causes multiple restarts, then the Task Sequence fails and potentially causes computers to go unpatched until they next run the Task Sequence. Therefore, it is important to quickly identify problematic hotfixes and deploy them outside of the Install Software Updates step in the Task Sequence.

When the Task Sequence fails due to a hotfix forcing multiple restarts, the TSManager component writes the following entries to smsts.log:

Failed to restore logs from cache. Execution history may be lost.	TSManager	10/17/2014 2:21:52 AM	2644 (0x0A54)
Task Sequence Manager executing as service main thread	TSManager	10/17/2014 2:21:52 AM	2644 (0x0A54)
Environment scope successfully created: Global\{51A016B6-F0DE-4752-B97C-54E6F386A912}	TSManager	10/17/2014 2:21:52 AM	2644 (0x0A54)
Environment scope successfully created: Global\{BA3A3900-CA6D-4ac1-8C28-5073AFC22B03}	TSManager	10/17/2014 2:21:52 AM	2644 (0x0A54)
Failed to locate the local data path. The files needed to resume the task sequence are missing.  This could be because the task sequence finished while in Windows PE.  Please check the largest available partition for SMSTSLog\smsts.log file for more information.
The system cannot find the file specified. (Error: 80070002; Source: Windows)	TSManager	10/17/2014 2:21:52 AM	2644 (0x0A54)
Task Sequence Manager could not initialize Task Sequence Environment. code 80070002	TSManager	10/17/2014 2:21:52 AM	2644 (0x0A54)
Task sequence execution failed with error code 80070002	TSManager	10/17/2014 2:21:52 AM	2644 (0x0A54)
Cleaning Up.	TSManager	10/17/2014 2:21:52 AM	2644 (0x0A54)

The exact language of the entries will vary based on the version of SCCM, with the above coming from SCCM 2012 R2.

A method of determining the culprit

Until I can figure out how to tell whether an update is going to schedule its own restart by observing some property of the hotfix itself, I’m left using a time-consuming process of elimination to determine which hotfix is responsible for the second restart during a Task Sequence.

In our environment, we run updates through SCCM on both our 64-bit Windows 7 workstations and our Windows Server 2008 R2 servers, and sometimes these two platforms receive different updates. When the Task Sequence failure occurs on only one platform, the first thing I do is to look at the hotfixes that are not applied to both platforms.

This month, fourteen hotfixes that require a reboot are installed on our workstations during the Task Sequence. Below are the entries written to the Setup log in Event Viewer on a Windows 7 workstation, where a second reboot occurred. Items followed by an asterisk “*” also appear in the Setup log in Event Viewer on a Windows Server 2008 R2 server, where a second reboot did not occur.

A reboot is necessary before package KB2984972 can be changed to the Installed state. *
A reboot is necessary before package KB2972100 can be changed to the Installed state. *
A reboot is necessary before package KB3001554 can be changed to the Installed state.
A reboot is necessary before package KB2977292 can be changed to the Installed state. *
A reboot is necessary before package KB3000061 can be changed to the Installed state. *
A reboot is necessary before package KB3000988 can be changed to the Installed state. *
A reboot is necessary before package KB3000869 can be changed to the Installed state. *
A reboot is necessary before package KB2949927 can be changed to the Installed state. *
A reboot is necessary before package KB2968294 can be changed to the Installed state. *
A reboot is necessary before package KB2952664 can be changed to the Installed state.
A reboot is necessary before package KB2984976 can be changed to the Installed state.
A reboot is necessary before package KB2987107 can be changed to the Installed state. *
A reboot is necessary before package KB2979570 can be changed to the Installed state. *
A reboot is necessary before package KB2994023 can be changed to the Installed state. *

The process of elimination begins, then, with those hotfixes that were installed on the workstations but not on the servers. Thankfully, in our environment this is just three hotfixes:

• KB3001554 – September 2014 update for DVD playback in Windows 7 SP1
• KB2952664 – Compatibility update for upgrading Windows 7
• KB2984976 – RDP 8.0 update for restricted administration on Windows 7 or Windows Server 2008 R2

To work through the suspect hotfixes, I set up a VMware virtual machine that was patched up to September 9, 2014. I created a snapshot of this test computer and then ran the maintenance Task Sequence on it to confirm that the Task Sequence abruptly ended during the Install Software Updates step.

Next, I selected one of the hotfixes to eliminate. My first choice was KB2952664 because it has a long and troubled history and seems to not be necessary in our enterprise environment. Even this month, it seems to be problematic, as it was released on October 14, then re-released on October 16. See the InfoWorld article Windows 7 patch KB 2952664 fails with error 80242016 for more on the struggles Microsoft has had with this hotfix. I removed KB2952664 from the Software Update Group deployed to the test computer, reverted to my snapshot and ran the maintenance Task Sequence again. It still ended abruptly, so KB2952664 was not the culprit.

Without re-adding KB2952664 to the Software Update Group, I removed KB2984976 from the Software Update Group. The KB2984976 hotfix deals with RDP and shares files in common with the last hotfix to require multiple restarts, KB2965788 (which was the subject of a similar blog post that I wrote about this problem back in June). Microsoft has now included KB2965788 among those hotfixes listed in KB2894518.

I reverted to my snapshot again and with KB2984976 unavailable to my test computer, the Task Sequence was able to proceed through the Install Software Updates step, indicating that KB2984976 is responsible for the multiple restarts among the October Patch Tuesday updates.

If anyone has a better method of identifying whether a hotfix is going to schedule a restart that is not controlled by SCCM, please post a comment. I would love to find a faster way, possibly by looking at how these hotfixes schedule the restart differently than most updates.

The October 2014 Patch Tuesday updates did not go smoothly for Microsoft:
http://www.infoworld.com/article/2834535/security/four-more-botched-black-tuesday-patches-kb-3000061-kb-2984972-kb-2949927-and-kb-2995388.html
http://www.infoworld.com/article/2834930/security/microsoft-yanks-botched-patch-kb-2949927-re-issues-kb-2952664.html