Troubleshooting: OS Deployment Stuck in Configuration Manager Task Sequence

Table of Contents

Deploying operating systems efficiently is a cornerstone of modern IT infrastructure management, particularly within environments utilizing Microsoft Configuration Manager. However, even the most meticulously planned deployment sequences can encounter unexpected halts. One such perplexing issue arises when an OS deployment task sequence fails to progress after Windows Setup or an in-place upgrade completes, specifically when an OEM product key is employed during the Windows installation process. This article delves into the root causes of this problem and provides comprehensive solutions to ensure your OS deployment task sequences execute seamlessly.

Understanding the Problem: Symptoms of a Stalled Task Sequence¶

When an OS deployment task sequence becomes stuck, it presents distinct symptoms depending on the type of deployment being performed. Recognizing these indicators is crucial for swift diagnosis and resolution.

Refresh or New Computer Task Sequence Issues¶

In a “Refresh” or “New Computer” scenario, the task sequence is designed to install a fresh copy of Windows. The deployment typically stalls during the Setup Windows and ConfigMgr step, which is a critical phase where the core operating system files are laid down, and the Configuration Manager client is prepared for installation. When this happens, the system may appear to have finished Windows installation, but the task sequence environment, which is responsible for continuing the deployment with subsequent steps like driver installation, application deployment, and final configuration, does not resume.

Upon closer inspection of the system’s log files, specifically the Setupact.log located within **%windir%\\panther\\unattendGC\\**, a telling entry can be found:

[windeploy.exe] OEM license detected, will not run SetupComplete.cmd

This log entry is the primary indicator of the problem. It clearly states that the SetupComplete.cmd script, which is essential for Configuration Manager to regain control and continue the task sequence, has been intentionally bypassed by Windows Setup due to the detection of an OEM license.

In-Place Upgrade Task Sequence Issues¶

Similarly, during an “In-Place Upgrade” task sequence, the deployment process might halt after the upgrade completes, specifically within the Upgrade Operating System step. This scenario involves updating an existing Windows installation to a newer version while preserving user data and applications. The system completes the upgrade, reboots, and presents the user with the new operating system, but the Configuration Manager task sequence fails to pick up where it left off.

The Setupact.log file, found at **%windir%\\panther\\unattendGC\\**, will again reveal specific entries that pinpoint the cause of the interruption:

[windeploy.exe] Client OS detected: 1
[windeploy.exe] OEM Licensing detected: 1
[windeploy.exe] EnterpriseS or Enterprise or EnterpriseSN or EnterpriseN edition detected: 0
[windeploy.exe] Client OS edition and OEM license detected and no enterprise edition detected, will not run SetupComplete.cmd
[windeploy.exe] Not allowed to run the Setupcomplete.cmd, will not run SetupComplete.cmd

These log entries confirm that a client OS, coupled with an OEM license, was detected, and critically, it was not an Enterprise edition. This combination triggers the system’s logic to prevent SetupComplete.cmd from executing, thereby preventing the Configuration Manager task sequence from resuming. These issues are most commonly observed when deploying non-enterprise editions of Windows, such as Windows Professional, Windows Embedded, or various Windows IoT versions, where OEM licensing is prevalent.

The Underlying Cause: Disabling of SetupComplete.cmd¶

The core reason for these deployment halts lies in a deliberate design choice by Microsoft regarding how Windows Setup interacts with OEM product keys. When an OEM product key is utilized during Windows deployment, the SetupComplete.cmd script is disabled by Windows Setup. This behavior is consistent across all currently supported versions of Windows client operating systems.

The rationale behind this design is to optimize the Out-Of-Box Experience (OOBE) for end-users, particularly in an OEM context. Microsoft’s aim is to allow end-users to reach the Start screen or desktop as quickly as possible following an OEM-installed operating system. As a result, scripts that traditionally run during or after Windows Setup, such as Oobe.cmd and SetupComplete.cmd, are suppressed if an OEM product key is detected. Any tools or services that rely on this infrastructure are expected to adapt and transition to tasks that occur after the OOBE.

What is SetupComplete.cmd?¶

SetupComplete.cmd is a custom batch script that plays a vital role in automated Windows deployments, especially within Configuration Manager task sequences. This script is typically placed in the **%WINDIR%\Setup\Scripts\** directory by the Configuration Manager client during the initial setup phase. Its primary function is to execute specific commands after the final reboot of Windows Setup, effectively allowing Configuration Manager to regain control of the system.

Within a Configuration Manager task sequence, SetupComplete.cmd contains commands that instruct the system to restart the task sequence environment. This is how Configuration Manager is able to pick up from where Windows Setup left off and proceed with the remaining steps, such as installing applications, applying specific configurations, and joining the domain. When SetupComplete.cmd is disabled due to the presence of an OEM product key, this critical hand-off process is interrupted, causing the task sequence to fail to continue after Windows Setup finishes.

Comprehensive Resolution Strategies¶

To resolve the issue of a stalled OS deployment task sequence, two primary strategies can be employed, often used in conjunction. The core idea is to prevent Windows Setup from detecting an OEM product key during the critical phase where SetupComplete.cmd is expected to run.

Strategy 1: Utilizing KMS Client Setup Keys¶

The most straightforward and recommended resolution is to specify a Key Management Service (KMS) client setup key instead of an OEM product key during the initial Windows deployment phase. KMS client setup keys, also known as generic volume license keys (GVLKs), are publicly available keys designed to allow Windows to install and function without immediately requiring activation. They are generic and do not actually activate Windows; instead, they configure the system to look for a KMS host for activation.

By using a KMS client setup key, Windows Setup does not detect an OEM license, thereby allowing SetupComplete.cmd to execute as intended. This ensures that the Configuration Manager task sequence can continue seamlessly after Windows Setup completes. The KMS client setup key should be specified in the same locations where you would normally input your product key for the version of Windows you are deploying.

Here are common KMS client setup keys for various Windows versions:

Operating System Edition	KMS Client Setup Key (GVLK)
Windows 10/11 Professional	W269N-WFGWX-YVC9B-4J6C9-T83GX
Windows 10/11 Professional N	MH37W-N47XK-V7XM9-C7227-GCQG9
Windows 10/11 Enterprise	NPPR9-FWDCX-L2C8J-H78R2-DCOQ9
Windows 10/11 Enterprise N	DPH2V-TTNVB-4X9Q3-TJR4J-KHJW4
Windows 10/11 Education	YNMGQ-8RYV3-4PGQ3-C8XTP-7CFBY
Windows 10/11 Education N	84NMJ-4HTPP-V7X92-4VJ6Q-HRBTT
Windows Server (various versions)	Refer to Microsoft documentation

Implementation Points:

• Refresh or New Computer Task Sequence:
  • Apply Windows Settings step: Specify the KMS client setup key directly in the “Product Key” field.
• In-Place Upgrade Task Sequence:
  • Upgrade Operating System step: Enter the KMS client setup key in the “Product key” field.

This approach ensures that SetupComplete.cmd runs, and the task sequence resumes without interruption. Activation of Windows can then be handled post-deployment through your organization’s volume licensing server (KMS or Active Directory-based activation) or by applying specific MAK keys later if required.

Strategy 2: Applying the OEM Key After Setup Completes¶

In scenarios where an OEM product key must be used for activation (e.g., specific licensing requirements, or direct use of the key embedded in the hardware), you can still leverage KMS client setup keys during the initial deployment and then switch to the OEM key post-setup. This strategy ensures SetupComplete.cmd runs, and the task sequence continues, while still meeting the requirement to use the OEM key for final activation.

Here’s how to implement this two-step process:

1. Specify the KMS Client Setup Key: Follow Strategy 1 by using a KMS client setup key in the Apply Windows Settings (for Refresh/New Computer) or Upgrade Operating System (for In-Place Upgrade) step. This allows the task sequence to proceed normally.

2. Add a “Run Command Line” Step: After the task sequence has successfully passed the Windows Setup phase and the Configuration Manager client is fully operational, add a Run Command Line step.

   • For Refresh or New Computer task sequences, place this step after the Setup Windows and ConfigMgr step.
   • For In-Place Upgrade task sequences, place this step after the Upgrade Operating System step.

   In this Run Command Line step, use either changepk.exe or slmgr.vbs to apply the OEM product key. These tools are designed to change the product key of an already installed Windows operating system.

   Examples of commands:

   • Using changepk.exe:
     

     changepk.exe /ProductKey XXXXX-XXXXX-XXXXX-XXXXX-XXXXX
     

     
     Replace XXXXX-XXXXX-XXXXX-XXXXX-XXXXX with your actual OEM product key.

   • Using slmgr.vbs (for setting the key and attempting activation):
     

     cscript %windir%\system32\slmgr.vbs /ipk XXXXX-XXXXX-XXXXX-XXXXX-XXXXX
     

     
     This command installs the product key. To activate immediately (if required and possible), you can follow it with:
     

     cscript %windir%\system32\slmgr.vbs /ato
     

Retrieving OEM Keys from BIOS/Firmware¶

For devices that have an OEM key embedded in their BIOS or firmware (common for pre-built systems), you can retrieve this key programmatically. This is particularly useful if you need to apply the specific OEM key that came with the hardware.

Run the following PowerShell command in a Run PowerShell Script step within your task sequence (or manually for testing) to get the key:

Get-CIMInstance SoftwareLicensingService | Select -ExpandProperty OA3xOriginalProductKey

This command queries the SoftwareLicensingService WMI class and extracts the OA3xOriginalProductKey property, which typically holds the OEM key embedded by the manufacturer. You can capture this output into a task sequence variable and then use that variable in a subsequent changepk.exe or slmgr.vbs command.

OEM Product Key Locations in Task Sequences¶

Understanding where an OEM product key might be specified within a Configuration Manager task sequence is crucial for identifying and rectifying the issue. The key could be configured in several places, depending on the type of deployment and how the task sequence is designed.

For Refresh or New Computer Task Sequences:¶

In these sequences, a new copy of Windows is installed, and the product key can be introduced at various stages:

• Apply Windows Settings Step: This is the most common location. Within the properties of this step, there’s usually a field to enter the product key. If an OEM key is entered here, it will trigger the issue.
• Custom Answer File (Unattend.xml): An Unattend.xml file can be used to automate Windows Setup. This file is often specified in the Apply Operating System step. If the <ProductKey> setting within the **<UserData>** section of the Unattend.xml contains an OEM key, it will cause the problem.
• Task Sequence Variables: For MDT-integrated task sequences, variables such as **OSDProductKey** or **ProductKey** can be used to pass the product key to Windows Setup. If these variables are assigned an OEM key, the issue will manifest.

For In-Place Upgrade Task Sequences:¶

During an in-place upgrade, the existing operating system is upgraded to a newer version. Product key entry points differ slightly:

• Upgrade Operating System Step: This step directly initiates the Windows upgrade process. There is a field within its properties to specify the product key. Entering an OEM key here will lead to the task sequence stalling.
• OSDSetupAdditionalUpgradeOptions Variable: This variable allows you to pass additional command-line options to the Windows Setup executable (Setup.exe). If the /PKey command-line option is used with this variable to pass an OEM key (e.g., **/PKey XXXXX-XXXXX-XXXXX-XXXXX-XXXXX**), it will also cause the problem.

Automatic Detection from BIOS or Firmware:¶

In certain scenarios, Windows Setup might automatically detect an OEM product key directly from the device’s BIOS or firmware. This typically occurs on systems pre-installed with an OEM version of Windows. Even if you haven’t explicitly specified an OEM key in your task sequence, Windows Setup can still pick it up from the hardware. In such cases, the **%windir%\\panther\\Setupact.log** file will contain entries indicating that a key was found and used from the firmware, leading to the same SetupComplete.cmd disablement.

Best Practices for OS Deployment Product Keys¶

To avoid these and other activation-related issues, it’s beneficial to adopt certain best practices when managing product keys in your Configuration Manager OS deployment task sequences.

Volume Licensing Strategy¶

For enterprise environments, leveraging Volume Licensing (VL) is the standard and most robust approach. VL agreements typically provide either Key Management Service (KMS) or Multiple Activation Key (MAK) options.

• KMS Activation: This is ideal for organizations with 25 or more client machines and 5 or more server machines. During deployment, use the generic KMS client setup keys (GVLKs). These keys are purely for installation and don’t activate the system immediately. The actual activation happens automatically when the deployed client connects to your internal KMS host server. This significantly simplifies deployment by decoupling the product key from the activation process.
• MAK Activation: For smaller organizations or systems that rarely connect to the corporate network, MAK keys can be used. Each MAK key has a finite number of activations. While you can use MAK keys during deployment, it’s often more flexible to use GVLKs during setup and then apply the MAK key in a post-OS installation step, similar to how an OEM key is applied in Strategy 2.

Avoid Hardcoding OEM Keys Directly¶

As demonstrated by this troubleshooting scenario, directly embedding OEM product keys into the initial stages of a task sequence or Unattend.xml can lead to deployment failures. While OEM keys are valid for activation, their interaction with SetupComplete.cmd makes them unsuitable for the initial phase of an automated Configuration Manager deployment. Always prefer GVLKs for the installation phase.

Secure Key Management¶

If you must manage a significant number of different product keys (e.g., specific MAK keys for different departments or OEM keys for a repair process), consider integrating Configuration Manager with tools like the Microsoft Deployment Toolkit (MDT) for more advanced key management capabilities, or use encrypted task sequence variables to store and retrieve keys securely. Never hardcode sensitive product keys in plain text within scripts or task sequence steps if they are not generic.

Advanced Troubleshooting and Log Analysis¶

While the primary fix involves managing product keys, understanding how to further troubleshoot can be invaluable if the issue persists or other problems arise.

Key Log Files in OS Deployment¶

Familiarity with Configuration Manager and Windows Setup log files is paramount:

• smsts.log: Located in **C:\Windows\CCM\Logs\SMSTSLog\** (or a temporary drive during WinPE phase), this is the primary log for the Configuration Manager task sequence. It details every step of the task sequence, including successes, failures, and environmental changes. Always start here for general task sequence troubleshooting.
• Setupact.log & Setuperr.log: Found in **%windir%\panther\** (and **%windir%\panther\unattendGC\**), these are Windows Setup’s own logs. Setupact.log provides detailed information about every action taken by Windows Setup, while Setuperr.log focuses on errors encountered. These are critical for understanding why Windows Setup behaved a certain way, such as disabling SetupComplete.cmd.
• Cbs.log: Located in **%windir%\Logs\CBS\**, this log provides information about component-based servicing, which includes Windows updates and feature installations. Useful if the upgrade process itself has issues.

Task Sequence Step Review¶

Always review the task sequence steps, particularly those related to “Apply Windows Settings” and “Upgrade Operating System.” Check their properties for any explicit product key entries. Also, examine any Unattend.xml files or task sequence variables that might be passing product keys to Windows Setup.

Environmental Checks¶

Ensure the deployment environment is stable:

• Network Connectivity: Verify that the target machine has consistent network connectivity, especially during the post-setup phase when the Configuration Manager client needs to communicate with the Management Point to resume the task sequence.
• Disk Space: Insufficient disk space can cause various issues during Windows installation and upgrades. Ensure ample free space is available.
• Driver Compatibility: While less directly related to the OEM key issue, incorrect or missing drivers (especially storage or network drivers) can prevent a system from booting correctly or communicating with the network after Windows Setup, indirectly making the task sequence appear stuck.

Conclusion¶

The issue of an OS deployment task sequence stalling due to an OEM product key can be a significant roadblock in automated deployments. By understanding that the presence of an OEM key disables SetupComplete.cmd, which is critical for Configuration Manager to resume its operations, administrators can effectively implement the provided solutions. Utilizing KMS client setup keys during the initial Windows installation and then applying OEM keys or specific MAK keys in a subsequent “Run Command Line” step offers a robust and reliable method to ensure smooth and uninterrupted OS deployments. Adhering to these best practices will not only resolve this specific issue but also contribute to a more resilient and efficient OS deployment strategy within your Configuration Manager environment.

Have you encountered this issue in your Configuration Manager deployments? What strategies have you found most effective in managing product keys? Share your experiences and insights in the comments below!