Task sequence fails in Configuration Manager if software updates require multiple restarts

Applies to: Windows Server 2012 R2 StandardWindows Server 2012 StandardWindows Server 2012 Standard More

The issue is fixed in Cumulative Update 3 for System Center 2012 Configuration Manager Service Pack 2, System Center 2012 R2 Configuration Manager Service Pack 1 and in System Center Configuration Manager build 1602 (current branch).

A new optional task sequence variable, SMSTSWaitForSecondReboot, is available to better control client behavior when a software update installation requires two restarts.

For more information, see the "Software updates management / operating system deployment" section in the following Knowledge Base article:

3135680 Description of Cumulative Update 3 for System Center 2012 Configuration Manager SP2 and System Center 2012 R2 Configuration Manager SP1

Or, for System Center Configuration Manager (Current Branch), see the following topic on the Microsoft website:

Task sequence built-in variables in System Center Configuration Manager

Symptoms

Assume that a Microsoft System Center Configuration Manager task sequence that uses the "Install Software Updates" step installs a software update that triggers multiple restarts after the task sequence successfully runs the Install Software Updates task. In this situation, the task sequence can fail and generate the following error message:

Task Sequence environment not found

Note You can avoid this issue in System Center 2012 Configuration Manager Service Pack 2 and System Center 2012 R2 Configuration Manager Service Pack 1 by using the new Retry option in the Install Updates task sequence step. For more information, refer to the Install Software Updates documentation on the Microsoft TechNet website.

Cause

The first restart that is initiated by the software update is controlled by the task sequence. However, the second restart request is initiated by a Windows component (typically, Component-Based Servicing) and is not controlled by the task sequence. Therefore, the task sequence execution state is not saved before the restart because the second restart is not controlled by the task sequence. When the task sequence resumes after the second restart, no state is available to continue successfully.

Resolution

To resolve this issue, we recommend that you apply any updates that require dual restarts by using the usual Software Updates feature of Configuration Manager instead of using task sequences. The following software updates were reported to require multiple restarts.

Note This article will continue to be updated through May 2016. Then, the Configuration Manager Service Pack levels that are referenced in the "Applies to" section fall out of mainstream support. For more information, see the Microsoft Support Lifecycle policy.

More Information

Because this second restart is not controlled by the task sequence, no execution state is saved before the restart. When the task sequence resumes after the restart, no state is available to continue successfully. Additionally, the following message may be logged to the Smsts.log file when you experience this issue:

!sVolumeID.empty(), HRESULT=80004005
!sTSMDataPath.empty(), HRESULT=80070002
TS::Utility::GetTSMDataPath( sDataDir ), HRESULT=80070002
Failed to set log directory. Some execution history may be lost.
The system cannot find the file specified. (Error: 80070002; Source: Windows)
Executing task sequence
!sVolumeID.empty(), HRESULT=80004005
!sTSMDataPath.empty(), HRESULT=80070002

Task Sequence environment not found

Also, clients that are running release versions that are earlier than Microsoft System Center 2012 Configuration Manager Service Pack 1 may contain the following log entry:

Task sequence completed in Windows PE.

Note The client computer may also be stuck in provisioning mode after the task sequence fails. To determine whether the computer is in provisioning mode, check the following registry subkey:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\CCM\CcmExec

ProvisioningMode should be set to false. If it is set to true, use one of the following methods to take the client out of provisioning mode:

Use the Windows Management Instrumentation (WMI) method SetClientProvisioningMode to take the client out of provisioning mode correctly. The easiest way to do this is to run the following Windows PowerShell command:
```
Invoke-WmiMethod -Namespace root\CCM -Class SMS_Client -Name SetClientProvisioningMode -ArgumentList $false 
```
Or, run the following command at an elevated command prompt:
```
powershell Invoke-WmiMethod -Namespace root\CCM -Class SMS_Client -Name SetClientProvisioningMode -ArgumentList $false 
```
Reinstall the client.

Important Do not try to fix the client by changing the value of ProvisioningMode to false. This action will not fully take the client out of provisioning mode.

Last Updated: Sep 19, 2017

Did this solve your problem?