Home deployment sysprep troubleshooting windows

Troubleshooting Sysprep Capture Errors: A Windows Client Task Sequence Failure

Updated: • 0 • min read
Table of Contents

Troubleshooting Sysprep Capture

This article provides a comprehensive guide to understanding and resolving a specific issue where the Sysprep and Capture task sequence, crucial for Windows image deployment, unexpectedly fails. This failure typically occurs during attempts to capture Windows images that were initially installed directly from installation media, rather than via an existing Microsoft Deployment Toolkit (MDT) deployment. Addressing this issue is vital for maintaining a streamlined and efficient imaging workflow within IT environments.

Overview of the Problem

The problem primarily affects the Sysprep and Capture task sequences within Microsoft Deployment Toolkit 2012 Update 1 and Microsoft Deployment Toolkit 2013. When IT administrators attempt to capture a Windows image that originated from a standard Windows installation media, the task sequence often terminates prematurely with a series of errors. These failures can significantly disrupt deployment operations, preventing the creation of custom, sysprepped images essential for large-scale enterprise deployments. Understanding the root cause and implementing the provided workaround is key to overcoming this deployment hurdle.

This issue specifically applies to Windows 10 - all editions, highlighting its relevance for modern operating system deployments. The original knowledge base article number associated with this problem is 2797676.

Symptoms of Failure

When the Sysprep and Capture task sequence fails, users will encounter distinct error messages, both within the Deployment Summary interface and within the detailed log files. These symptoms provide critical clues to diagnosing the underlying problem.

Deployment Summary Errors

Upon failure, the Deployment Summary typically displays a “Failure” status, indicating that the operating system deployment did not complete successfully. A detailed breakdown often reveals multiple errors but no warnings. The most prominent error messages observed are:

Deployment Summary

Failure
Operating system deployment did not complete successfully.
Review the log files to determine the cause of the problem.
During the deployment process, 14 errors and 0 warning were reported.

Details …
ZTI ERROR - Unhandled error returned by LTIApply: Not found (-2147217406 0x80041002)
Litetouch deployment failed, Return Code = -2147467259 0x80004005
Failed to run the action: Apply Windows PE.
Not found (Error: 80041002; Source: WMI)
The execution of the group (Capture Image) has failed and the execution has been aborted.
An action failed.
Operation aborted (Error: 80004004; Source: Windows)
Failed to run the last action: Apply Windows PE. Execution of task sequence failed.
Not found (Error: 80041002; Source: WMI)
Task Sequence Engine failed! Code: enExecutionFail
Task sequence execution failed with error code 80004005
Error Task Sequence Manaqer failed to execute task sequence. Code 0x80004005

These errors point to issues during the “Apply Windows PE” action, a critical step where a Windows Preinstallation Environment image is deployed to facilitate the capture process. The error code 0x80041002 is particularly significant, as it indicates a “Not Found” error, often related to Windows Management Instrumentation (WMI) queries or file system operations. The 0x80004005 error is a generic “Unspecified error,” which, in this context, is a consequence of the preceding “Not Found” issue.

BDD.log File Entries

Further investigation into the BDD.log file, the primary log for MDT deployments, provides a more granular view of the failure point. The log entries reveal the sequence of commands leading to the error:

<![LOG[Taking ownership of C:\boot]LOG]!><time=”<time>” date=”<date>” component=”LTIApply” context=”” type=”1” thread=”” file=”LTIApply”>
<![LOG[About to run command: takeown.exe /F “C:\boot” /R /A /D Y]LOG]!><time=”<time>” date=”<date>” component=”LTIApply” context=”” type=”1” thread=”” file=”LTIApply”>
<![LOG[Command has been started (process ID 2748)]LOG]!><time=”<time>” date=”<date>” component=”LTIApply” context=”” type=”1” thread=”” file=”LTIApply”>
<![LOG[Return code from command = 1]LOG]!><time=”<time>” date=”<date>” component=”LTIApply” context=”” type=”1” thread=”” file=”LTIApply”>
<![LOG[ResetFolder: TakeOwn for C:\boot, RC = 1]LOG]!><time=”<time>” date=”<date>” component=”LTIApply” context=”” type=”1” thread=”” file=”LTIApply”>
<![LOG[ZTI ERROR - Unhandled error returned by LTIApply: Not found (-2147217406 0x80041002)]LOG]!><time=”<time>” date=”<date>” component=”LTIApply” context=”” type=”3” thread=”” file=”LTIApply”>
<![LOG[Event 41002 sent: ZTI ERROR - Unhandled error returned by LTIApply: Not found (-2147217406 0x80041002)]LOG]!><time=”<time>” date=”<date>” component=”LTIApply” context=”” type=”1” thread=”” file=”LTIApply”>

These log snippets clearly show that the script attempts to take ownership of the C:\boot directory using takeown.exe. The command returns an error code 1, indicating failure, which subsequently triggers the “Not Found” error within the LTIApply script. This direct evidence highlights the specific operation that leads to the task sequence failure.

Cause of the Problem

The root cause of this problem lies within the LTIApply.wsf script, a core component of the MDT process responsible for applying images and preparing the system. Specifically, the script fails to perform a crucial check: verifying the existence of the boot folder on the system partition before attempting to change its ownership.

The takeown.exe command is designed to grant ownership of a file or folder to an administrator. However, if the specified target, in this case, the C:\boot folder, does not exist, takeown.exe will fail with a “Not Found” error. Since the LTIApply.wsf script doesn’t incorporate a preparatory check to ensure the folder’s presence, the execution of takeown.exe against a non-existent directory results in an error. This unhandled error then cascades, causing the entire Sysprep and Capture task sequence to terminate prematurely, leading to the overall failure of the image capture process. This oversight in the script’s logic is the direct reason for the observed deployment failures.

Workaround for Resolution

To resolve this issue, a minor but critical modification is required in the LTIApply.wsf script. This modification involves adding a conditional check to ensure the boot folder exists before the script attempts to change its ownership. By creating the folder if it doesn’t already exist, we prevent the takeown.exe command from failing.

Identifying and Modifying the Script Files

The LTIApply.wsf script needs to be updated in two primary locations to ensure the fix is applied consistently across your MDT environment:

  1. Deployment Share Script:

    • %DeployRoot%\Scripts\LTIApply.wsf
    • Note: %DeployRoot% refers to the path you specified when your MDT deployment share was initially created. This is the active script used during deployments from that share.

  2. MDT Program Files Template Script:

    • C:\Program files\Microsoft Deployment Toolkit\Templates\Distribution\Scripts\LTIApply.wsf
    • This is the template script that is copied to new deployment shares. Modifying it here ensures that any new deployment shares created in the future will automatically include this fix. It is a good practice to update both to ensure consistency.

Steps to Apply the Workaround

Before making any modifications, it is highly recommended to create a backup of both LTIApply.wsf files. This allows for easy restoration in case of any unforeseen issues.

  1. Navigate to the first script location: Open File Explorer and go to %DeployRoot%\Scripts\ (e.g., C:\DeploymentShare\Scripts\).
  2. Make a backup: Copy LTIApply.wsf and paste it into the same folder, renaming the copy to LTIApply.wsf.bak or LTIApply_original.wsf.
  3. Open the script: Right-click LTIApply.wsf and open it with a text editor like Notepad, Notepad++, or Visual Studio Code.
  4. Locate the target section: Search for the comment line that reads "Copy bootmgr". This section typically deals with operations related to the boot manager and the boot partition.

  5. Insert the new code: Immediately above the existing code block under the “Copy bootmgr” section, insert the following VBScript code:

    If not oFSO.FolderExists(sBootDrive & "\Boot") then
 oFSO.CreateFolder(sBootDrive & "\Boot")
End if

    This code snippet performs a simple check: it verifies if the folder specified by sBootDrive & "\Boot" (which translates to C:\Boot in most cases) exists. If it does not exist (If not oFSO.FolderExists(...)), then it proceeds to create that folder (oFSO.CreateFolder(...)).

  6. Save the file: Save the modified LTIApply.wsf file.

  7. Repeat for the second script location:
    • Navigate to C:\Program files\Microsoft Deployment Toolkit\Templates\Distribution\Scripts\.
    • Perform steps 2-6 for this LTIApply.wsf file as well.
  8. Update Deployment Share: After modifying the script in your %DeployRoot% share, it is essential to update your deployment share. In the Deployment Workbench, right-click your deployment share and select “Update Deployment Share.” Choose to “Optimize the boot image updating process” and “Completely regenerate the boot images” to ensure the changes are propagated to the LiteTouch boot images used during deployment. This step is crucial for the fix to take effect in your deployment environment.

By implementing this workaround, the boot folder will be reliably present before takeown.exe is executed, preventing the “Not Found” error and allowing the Sysprep and Capture task sequence to complete successfully.

More Information on the Issue

This specific issue regarding the Sysprep and Capture task sequence often raises questions about why it occurs primarily when capturing images deployed from standard Windows media, but not when capturing images originally deployed by MDT. The distinction lies in the partition structure and available space on the “System Reserved” partition created during the initial Windows installation.

System Reserved Partition Differences

When Windows is deployed using MDT 2012 Update 1 (or later versions), it typically creates a System Reserved partition with a size of 499 megabytes (MB). This larger size is significant because it provides ample free space. During a capture operation, MDT needs to apply a Windows PE (Preinstallation Environment) image to a partition to boot into a temporary environment from which the current operating system can be captured. With 499 MB of free space, the System Reserved partition usually has enough capacity for MDT to apply this WinPE image without issues.

However, when a Windows image is installed directly from standard Windows installation media (e.g., a retail DVD or USB stick), the System Reserved partition that is created usually has a smaller size, typically 350 MB. Furthermore, this 350 MB partition already contains the Windows Recovery Environment (WinRE) image. The presence of WinRE, combined with the smaller overall partition size, means there isn’t enough free space remaining for MDT to successfully apply its WinPE image directly to this partition.

MDT’s Behavior and the LTIApply Script

Because the System Reserved partition lacks sufficient free space, the LTIApply script, designed to intelligently handle such scenarios, automatically defaults to selecting the main System Partition (typically the C: drive) to apply the WinPE image. This is a logical fallback, as the system partition usually has abundant space.

As part of the process of applying the WinPE image to the System Partition, the LTIApply script needs to ensure it has the necessary permissions. This involves changing ownership of key boot-related files and folders, including bootmgr and the boot folder itself, on the System Partition. The takeown.exe command is used for this purpose.

The problem, as highlighted, is that the LTIApply script’s logic, at the time of these MDT versions, assumed the boot folder would already exist on the System Partition if it chose that partition for WinPE deployment. This assumption proved false in certain scenarios, particularly for installations from retail media where the C:\boot folder might not be present at that specific stage or in that exact configuration. Consequently, the takeown.exe command, when executed against a non-existent C:\boot folder, fails, leading to the cascading errors and the ultimate failure of the Sysprep and Capture task sequence. The workaround specifically addresses this oversight by ensuring the folder’s presence before the ownership change is attempted.

General Best Practices for MDT and Image Management

Beyond this specific workaround, adopting broader best practices for MDT deployments and image management can prevent numerous issues and enhance the reliability of your imaging process.

Regular MDT Updates

Always ensure your Microsoft Deployment Toolkit installation is updated to the latest available version. Newer versions often include bug fixes, performance improvements, and support for the latest Windows versions. While this article addresses a specific issue in older MDT versions, staying current reduces the likelihood of encountering known problems.

Proper Partition Sizing

For future deployments, especially if you create custom images, consider the implications of partition sizing. Ensure that any System Reserved or EFI System Partitions have sufficient free space to accommodate recovery environments or temporary WinPE images, even if MDT is not the primary deployment method. While MDT automatically provisions a larger System Reserved partition, manual or other deployment methods might not.

Script Version Control and Backups

Treat your MDT scripts (.wsf, .ps1, etc.) as critical code. Implement some form of version control (even a simple manual system of dated backups) before making any modifications. Always back up original files before applying any patches or workarounds, as demonstrated in this article. This mitigates risks and simplifies rollbacks.

Thorough Testing

Before deploying a fix or a new image to your production environment, conduct thorough testing in a controlled lab environment. Test all aspects of the task sequence, including deployment, capture, and any custom applications or configurations. This helps catch unforeseen issues before they impact end-users.

Log File Analysis

Develop proficiency in analyzing MDT log files, especially BDD.log, SMSTS.log (if integrated with SCCM), ZTI*.log, and LTI*.log. These logs provide invaluable insights into the deployment process, helping to pinpoint failures and diagnose root causes effectively. Tools like CMTrace can simplify log viewing.

Understanding Sysprep

A deep understanding of the System Preparation Tool (Sysprep) is fundamental. Sysprep prepares a Windows installation for imaging by removing machine-specific information. Issues with Sysprep can directly lead to capture failures. Ensure your reference image is properly generalized and any applications installed are Sysprep-compatible.

Network and Storage Reliability

Ensure the underlying infrastructure, including network connectivity to your deployment share and the storage where images are stored, is robust and reliable. Intermittent network issues or storage problems can manifest as seemingly unrelated task sequence failures.

Regular Deployment Share Updates

After making any changes to your deployment share, such as adding drivers, applications, or modifying scripts, always remember to update the deployment share. This action regenerates the boot images and ensures that the latest changes are included in your deployment media.

By adhering to these best practices, IT professionals can build more resilient and efficient Windows deployment systems, minimizing downtime and streamlining the imaging process.

Conclusion

The Sysprep and Capture task sequence failure, characterized by “Not Found” errors during the takeown.exe command on the C:\boot directory, is a specific challenge that can significantly impede Windows image management. This issue, primarily affecting images originally deployed from Windows installation media, stems from an oversight in the LTIApply.wsf script’s logic regarding the existence of the boot folder on the system partition.

By applying the simple yet effective workaround detailed in this article—inserting a conditional folder creation statement within the LTIApply.wsf script—administrators can successfully bypass this error. This fix ensures that the necessary directory is present before ownership is attempted, allowing the WinPE image to be applied correctly and the capture process to proceed without interruption. Furthermore, understanding the nuances of System Reserved partition sizing and MDT’s behavior provides valuable context for preventing similar issues in the future. Implementing the provided fix, coupled with general best practices for MDT and image management, will contribute to a more stable, efficient, and reliable deployment environment.

Have you encountered similar Sysprep or MDT capture errors? What workarounds or solutions have you found most effective in your environment? Share your experiences and insights in the comments below!

Post a Comment