MDT & Configuration Manager Troubleshooting: A Practical Guide

Table of Contents

The deployment of operating systems and applications, along with user state migration, can be a complex undertaking. Even with the right tools and guidance, challenges frequently arise. This guide, part of Microsoft Deployment Toolkit (MDT) 2013, aims to provide solutions for known issues and practical troubleshooting steps. It covers various scenarios to help you navigate deployment hurdles effectively.

Please note that throughout this document, “Windows” refers to Windows 8.1, Windows 8, Windows 7, Windows Server 2012 R2, Windows Server 2012, and Windows Server 2008 R2 operating systems, unless explicitly stated otherwise. MDT does not support ARM processor-based versions of Windows. Similarly, “MDT” specifically refers to MDT 2013 unless a different version is mentioned.

Understanding Logs¶

Effective troubleshooting of MDT deployments critically depends on a clear understanding of the numerous .log files generated during the process. Knowing which log files to examine for specific failure conditions and at what stage of the deployment is key to quickly diagnosing issues. What might seem like a mysterious problem can often be illuminated by the insights within these logs.

The MDT log file format is optimized for viewing with CMTrace, a tool that significantly simplifies error identification. It is highly recommended to use CMTrace whenever possible to review these log files, as it enhances readability and highlights critical information. The following sections detail the log files created during deployment and Windows Setup, offering examples of their utility in troubleshooting.

MDT Logs¶

Every MDT script automatically generates a log file that shares its name, such as ZTIGather.wsf creating ZTIGather.log. Additionally, each script updates a central master log file, BDD.log, which aggregates content from all MDT script-generated logs. These MDT log files initially reside in C:\MININT\SMSOSD\OSDLOGS during deployment. Upon completion, they are moved to either %WINDIR%\SMSOSD or %WINDIR%\TEMP\SMSOSD, depending on the deployment type. For Lite Touch Installation (LTI) deployments, logs begin in C:\MININT\SMSOSD\OSDLogs and are eventually relocated to %WINDIR%\TEMP\DeploymentLogs after the task sequence finishes processing.

MDT creates several key log files for diagnostic purposes. These include BDD.log, an aggregated log file that can be copied to a network location if the SLShare property is defined in Customsettings.ini. LiteTouch.log is specific to LTI deployments and is found in %WINDIR%\TEMP\DeploymentLogs unless the /debug:true option is active. Scriptname*.log refers to the individual logs created by each MDT script, where Scriptname is the name of the script itself.

The SMSTS.log file is generated by the Task Sequencer and meticulously records all its transactions. Its location can vary depending on the deployment scenario, potentially found in %TEMP%, %WINDIR%\System32\ccm\logs, C:\_SMSTaskSequence, or C:\SMSTSLog. The deployment wizards create and update Wizard.log, providing insights into user interactions. WPEinit.log is crucial for troubleshooting errors encountered during Windows PE initialization, documenting that process. Finally, DeploymentWorkbench_id.log is created in the %temp% folder when the Deployment Workbench is started with the /debug option.

Configuration Manager Operating System Deployment Logs¶

For deployments involving Microsoft System Center 2012 R2 Configuration Manager, specific operating system deployment log files are generated. Detailed information regarding these log files can be found in the Technical Reference for Log Files in Configuration Manager. This resource is essential for understanding the logging mechanisms within a Configuration Manager integrated environment.

When utilizing the Windows User State Migration Tool (USMT), MDT automatically configures logging options to save USMT log files to the designated MDT log locations. These specific USMT log files are created at different stages of the migration process. USMTEstimate.log is generated when estimating USMT requirements, while USMTCapture.log is created during data capture. USMTRestore.log is produced when USMT restores data to the target system.

The ZeroTouchInstallation.vbs script automatically scans these USMT progress log files for any detected errors or warnings. Upon completion, the script generates event ID 41010 to Microsoft System Center Operations Manager. This event provides a summary indicating the USMT operation type (e.g., ESTIMATE, SCANSTATE, or LOADSTATE), the total number of errors found, and the total number of warnings detected. If the error count exceeds zero, the event is logged as an Error type; if only warnings are present, it’s a Warning type; otherwise, it’s an Informational type.

ZTI USMT <usmt_type> reported <error_count> errors and <warning_count> warnings

Identifying Error Codes¶

MDT scripts produce various error codes that are recorded in the BDD.log file, each corresponding to a specific issue. Understanding these codes is crucial for efficient troubleshooting. Table 1 below provides a comprehensive list of these error codes along with their respective descriptions, serving as a quick reference guide.

Table 1. Error Codes and Their Description¶

Error code	Description
5201	A connection to the deployment share could not be made. The deployment will not proceed.
5203	A connection to the deployment share could not be made. The deployment will not proceed.
5205	A connection to the deployment share could not be made. The deployment will not proceed.
5206	The Deployment Wizard was canceled or did not complete successfully. The deployment will not proceed.
5207	A connection to the deployment share could not be made. The deployment will not proceed.
5208	DeploymentType is not set. Must set some value for SkipWizard.
5208	Unable to find the SMS Task Sequencer. The deployment will not proceed.
5400	Create object: Set class_instance = New class_name
5490	Create MSXML2.DOMDocument.
5495	Create MSXML2.DOMDocument.ParseErr.ErrCode.
5496	LoadControlFile.FindFile: ConfigFile
5601	Verify OS guid: %OSGUID% exists.
5602	Open XML with OSGUID: %OSGUID%.
5610	Verify file.
5630	Verify file: ImagePath.
5640	Verify file: ImagePath.
5641	FindFile: ImageX.exe.
5643	Find BootSect.exe.
5650	Verify directory: SourcePath.
5651	Verify directory: SourcePath\Platform.
5652	FindFile: bootsect.exe.
6001	Verify drive.
6002	Verify drive.
6010	Test for TSGUID.
6020	Robocopy returned value: Value.
6021	Robocopy returned value: Value.
6101	Check for file: DeployCab.
6102	Expand Sysprep files from DEPLOY.CAB.
6111	Run Sysprep.exe.
6121	Run Sysprep.
6191	Test for CloneTag in registry to verify Sysprep completed.
6192	Test for SystemSetupInProgress in registry to verify Sysprep completed.
6401	Authorized DHCP server.
6501	Computer backup not possible, no network path (BackupShare, BackupDir) specified.
6502	ERROR - Unable to locate IMAGEX, unable to perform backup.
6601	GetObject(… root/wmi:BCDStore).
6602	BCD.OpenStore (BCDStore).
6701	Configured protectors.
6702	Moved boot files.
6703	Create BDE partition.
6704	Defragment drive.
6705	Shrink drive.
6706	Testing for more than 1 partition.
6707	Create boot files.
6708	Encrypt the disk.
6709	Connect to MicrosoftVolumeEncryption WMI provider.
6710	Encrypting the disk.
6711	ProtectKeyWithTPM.
6712	ProtectKeyWithTPMAndPIN.
6713	ProtectKeyWithTPMAndStartupKey.
6714	Save external key to file.
6715	Protect with external key.
6716	Save external key to file.
6717	Protect key with numerical password.
6718	GetKeyProtectorNumberialP@ssword.
6718	Save password to file.
6719	Open PasswordFile.
6720	Encrypt the drive.
6721	Open DiskPartFile.
6722	Create partition.
6723	Get existing BDE drive.
6724	Open DiskPartFile.
6727	Attempt to open DiskPartFile.
6729	Create text file DiskPartFile.
6730	Execute cmd /c DISKPART.EXE /s DiskPartFile >> LogPath\ZTIMarkActive_diskpart.log 2>&1
6731	Find bcdboot.exe.
6732	Connect to Microsoft TPM provider.
6733	Get a TPM instance in the provider class.
6734	Get TPM instance.
6735	Check to see if TPM is enabled.
6736	Check to see if TPM is activated.
6737	Check to see if TPM is owned.
6738	Check to see if TPM ownership is allowed.
6739	Check to see if TPM is enabled.
6740	Check to see if TPM is activated.
6741	Check to see if TPM is owned and ownership is allowed.
6741	TPM Owner Password set
6742	TPM Owner P@ssword set to AdminP@ssword.
6743	Set TPM Owner P@ssword to value.
6744	Check to see if TPM is enabled.
6745	Check TPM owner.
6746	Check for endorsement key pair.
6747	Check to see if TPM is activated.
6748	Check to see if TPM ownership is allowed.
6749	Convert owner p@ssword to owner authorization.
6750	Create endorsement key pair.
6751	Change owner authorization.
6752	Run Cmd.
6753	Validate TPM.
6754	Get BDE instance.
6755	Protect key with TPM.
6756	Check for removable media to configure. ProtectKeyWithTpmAndStartupKey.
6757	Protect key with TPM and startup key.
6758	Look for BDE pin.
6759	Protect key with TPM and Pin.
6760	Find removable media for BDEKeyLocation.
6761	Protect with external key.
6762	Recovery P@ssword being saved to PasswordFile.
6764	Configure BitLocker policy.
7000	Unable to locate ZTIConfigure.xml; aborting.
7001	Looking for unattend AnswerFile.
7100	ERROR - This script should only run in the full OS.
7101	ERROR - Not enough values supplied for generating DCPromo answer file.
7102	ERROR - Mandatory properties for creating a new replica DC were not specified.
7103	ERROR - Mandatory properties for creating a new child domain were not specified.
7104	ERROR - Mandatory properties for creating a new forest were not specified.
7105	ERROR - Mandatory properties for creating a new forest were not specified.
7200	Unable to configure DHCP server because the service is not installed.
7201	Unable to read the scope details; GetScopeDetails() failed.
7202	Not enough values specified for scope creation.
7203	Not enough values provided to set the IP range for this scope.
7204	No value specified for scope exclusion range.
7300	Unable to issue DNS commands.
7700	Not a New Computer scenario; exiting disk partition.
7701	Disk is not large enough for System and BDE partitions, Required = 1.5 GB.
7702	Disk is not large enough for System and WinRE partitions, Required = 10 GB.
7703	DeployRoot is on disk # DiskIndex. Running an OEM Scenario: Skip.
7704	Running an OEM Scenario: Skip.
7704	Extended and logical partitions are not allowed with BitLocker.
7712	Verify Drive/Volume Drive is present. Format.
7900	FindFile: Microsoft.BDD.PnpEnum.exe.
7901	AllDrivers.Exists(“GUID”).
7904	AllDrivers.Exists(“GUID”).
9200	FindFile(PkgMgr.exe).
9601	ERROR - ZTITatoo state restore task should be running in the full OS; aborting.
9701	Nonzero return code from USMT estimate, rc = Error.
9702	User state capture not possible; insufficient local space and no network path (UDShare, UDDir) specified.
9703	Nonzero return code from USMT capture, rc = Error.
9704	No valid command line option was specified.
9801	ERROR - Attempting to deploy a client operating system to a machine running a server operating system.
9802	ERROR - Attempting to deploy a server operating system to a machine running a client operating system.
9803	ERROR - Machine is not authorized for upgrading (OSInstall=OSInstall); aborting.
9804	ERROR - Memory MB of memory is insufficient. At least Memory MB of memory is required.
9805	ERROR - Processor speed of ProcessorSpeed MHz is insufficient. At least a ProcessorSpeed MHz processor is required.
9806	ERROR - insufficient space is available on Drive. An additional Size MB is required.
9807	ERROR - insufficient space is available on Drive. An additional Size MB is required.
9901	The ZTIWindowsUpdate script should not run in Windows PE.
9902	ZTIWindowsUpdate has run and failed too many times. Count = Count.
9903	Unexpected issue installing the updated Windows Update Agent, rc = Error.
9904	Failed to create object: Microsoft.Update.Session.
9905	Failed to create object: Microsoft.Update.UpdateColl.
9906	Critical file File was not found; aborting.
10000	Create object: Set oLTICleanup = New LTICleanup.
10201	Unable to Join Domain Domain. Stop installation.
10203	FindFile(LTISuspend.wsf).
10204	Run Program LTISuspend.
41024	Run ImageX.
52012	All the wizard parameters are not set.

An excerpt from an SMSTS.log file demonstrates how error codes are typically presented. In this particular example, the SMSTS.log clearly reports an exit code of 5001, indicating a specific failure condition within the deployment. This type of log entry is fundamental for pinpointing where and why a task sequence might have failed.

Listing 1. Excerpt from an SMSTS.log file that contains error code 5001

.
.
.
The operating system installation failed. Please contact your system administrator for assistance.

The action "Zero Touch Installation - Validation" failed with exit code 5001
.
.
.

Converting Error Codes¶

Many error codes found in log files appear as cryptic hexadecimal values, making them difficult to interpret directly. However, these codes can be converted into more meaningful information to aid in problem resolution. The following process outlines how to convert a hexadecimal error code to its decimal equivalent and then translate it into a readable message.

Problem: An image capture operation fails, reporting error code 0x80070040.

Possible Solution 1: The initial step is to convert the hexadecimal error code to a decimal format. A scientific calculator, such as the one included with Windows operating systems, is suitable for this conversion. This process helps in transforming an opaque code into a numerical value that can then be further investigated.

To convert an error code:

1. Click Start, then point to All Programs. Navigate to Accessories, and then click Calculator.
2. From the View menu within the Calculator, select Scientific mode.
3. Select the Hex radio button, and then enter the last four digits of the error code, which in this case is 0040. It’s important to note that leading zeros might not be displayed while the calculator is in Hexadecimal mode.
4. Switch to Dec mode by selecting the corresponding radio button. The hexadecimal value 40 will now be converted and displayed as the decimal value 64.
5. Open a Command Prompt window, type NET HELPMSG 64, and then press ENTER. The NET HELPMSG command is invaluable for translating numerical error codes into understandable text. For the error code 0x80070040, it translates to: “The specified network name is no longer available.” This message suggests a potential networking issue on the target computer or between the target computer and the deployment share server, possibly involving incorrect network driver installations or mismatched speed/duplex settings.

Review of Sample Logs¶

MDT generates various log files that are indispensable for troubleshooting issues encountered during the deployment process. Examining these logs can provide critical insights into failures and their root causes. The following examples demonstrate how to leverage MDT log files to diagnose specific deployment problems, focusing on common scenarios like database access failures.

Failure to Access the Database¶

Problem: A deployment fails while executing a CustomSettings.ini file that contains multiple sections and uses the Priority property to dictate processing order. The BDD.log file records several distinct error messages, indicating a problem with database access permissions. These errors suggest a fundamental issue preventing the script from interacting with the database.

The BDD.log shows the following errors:

• ERROR - Opening Record Set (Error Number = -2147217911) (Error Description: The SELECT permission was denied on the object 'ComputerAdministrators', database 'AdminDB', schema 'dbo'.)
• ADO error: The SELECT permission was denied on the object 'ComputerAdministrators', database 'AdminDB', schema 'dbo'. (Error #-2147217911; Source: Microsoft OLE DB Provider for SQL Server; SQL State: 42000; NativeError: 229
• ERROR - Unhandled error returned by ZTIGather: Object required (424)

For clarity, the log file contents above have been represented as they appear when viewed using CMTrace.

Possible Solution: The core of the issue, as highlighted by the first line of the log sample, is a denial of permission to access the database. This denial prevents the script from establishing a secure connection, likely because a user ID and password were not available, leading to an attempted database access using the computer account. The most straightforward resolution is to grant Read access to the database for everyone. This action ensures that the necessary permissions are in place for the deployment scripts to function correctly.

Troubleshooting¶

Before diving into complex troubleshooting methodologies, it is crucial to review foundational requirements. Always ensure that all specified software and hardware prerequisites for the deployment have been thoroughly met. Overlooking these basic steps can often lead to installation issues that are easily preventable, saving significant time and effort.

Application Installation¶

Application installation issues are a common source of deployment problems, often stemming from security blocks or network interruptions. This section reviews frequent problems and their corresponding solutions. Addressing these specific scenarios can significantly improve the reliability of your application deployments within an MDT environment.

Blocked Executables¶

Problem: Installation source files downloaded from the internet are frequently marked with one or more NTFS file system data streams. These data streams, which store metadata about the file’s origin, can trigger an Open File – Security Warning prompt. This warning halts the installation process, requiring manual intervention by clicking Run to proceed.

For more detailed information on NTFS data streams, consult the Microsoft documentation on File Streams. Tools like the More command or the Streams utility can be used to view these streams, as illustrated in Figure 2. Understanding their presence is the first step toward resolving the security prompt.

Possible Solution 1: To remove NTFS file system data streams from a single file, right-click the installation source file and select Properties. On the General tab, click Unblock, and then click OK. This action effectively removes the security warning. Repeat this process for every installation source file that is blocked by these data streams.

Possible Solution 2: For a more efficient approach, especially with multiple blocked files, utilize the Streams utility from Sysinternals. As previously mentioned and shown in Figure 2, this tool can remove NTFS file system data streams from multiple files or even entire folders simultaneously. This method saves considerable time compared to unblocking each file individually.

Lost Network Connections¶

Problem: An installation may unexpectedly fail if it involves the installation of new device drivers or significant alterations to device and network configurations. Such changes can cause a temporary lapse in network connectivity, which, if not properly handled, will lead to the installation failing. This is particularly problematic for applications that require constant network access during setup.

Possible Solution: To mitigate network connectivity loss during installations, implement the ZTICacheUtil.vbs script. This script is designed to enable download and execute functionality for the installation process. It leverages Background Intelligent Transfer Service (BITS) for downloads if the Configuration Manager distribution point supports Web-based Distributed Authoring and Versioning (WebDAV) and BITS. Simultaneously, it modifies Configuration Manager to first run the ZTICache.vbs script, ensuring that the program does not delete itself prematurely during the deployment, thereby maintaining data integrity through network interruptions.

The 2007 Microsoft Office System¶

Problem: When deploying the 2007 Microsoft Office system alongside a Windows Installer patch (MSP) file, the installation might fail with a specific error code, 30029. This issue indicates a problem in how the patch is applied during the Office setup process. Investigating the logs can help pinpoint the exact cause of this failure.

Further examination of the ZTIApplications.log typically reveals entries similar to these:

• About to run command: \\Server\Deployment$\Tools\X86\bddrun.exe \\Server\Share\Microsoft\Office\2007\Professional\setup.exe /adminfile \\Server\Share\Microsoft\Office\2007\Professional\file.msp
• ZTI Heartbeat: command has been running for 12 minutes (process ID 1600) Return code from command = 30029
• Application Microsoft Office 2007 Professional returned an unexpected return code: 30029

Possible Solution 1: A common resolution involves relocating the MSP file to the Updates directory within the Office installation source. After moving the file, run setup.exe without specifying the /adminfile option, allowing Office Setup to automatically discover and apply the patch. For more detailed guidance on deploying updates during Office installation, refer to the Microsoft documentation on Deploying the 2007 Office system.

Possible Solution 2: Verify the configuration of the MSP file itself. Ensure that the Suppress modal check box is not selected within the MSP file’s properties. This setting can sometimes interfere with the installation process, leading to unexpected failures. Additional information on configuring deployment settings can be found in the Overview of 2007 Office System Deployment.

AutoLogon¶

Automatic logon functionality is critical for smooth MDT deployments, particularly in Lite Touch Installation (LTI) and Zero Touch Installation (ZTI) scenarios. However, various factors can disrupt this process, leading to deployment interruptions. This section examines common auto-logon problems and their effective solutions, ensuring an uninterrupted deployment experience.

Logon Security Banners¶

Problem: MDT task sequences operate within an interactive user session, necessitating automatic logon of the target computer using a pre-defined administrative account. If a Group Policy Object (GPO) is active that enforces a logon security banner, this automatic logon will be prevented. The security banner halts the logon process, waiting for a user to manually accept the displayed policy, thereby interrupting the deployment.

Possible Solution: To circumvent this issue, ensure that the GPO enforcing the logon security banner is applied only to specific organizational units (OUs), rather than being included in the default domain GPO. When joining computers to the domain, initially specify an OU that is not affected by such a GPO. As a final step in the Task Sequence Editor, include a script—perhaps a Microsoft Visual Basic® Scripting Edition—to relocate the computer account to its intended, secured OU after the initial logon-sensitive tasks are completed.

If you are reusing existing Active Directory® Domain Services (AD DS) accounts, make sure to relocate the target computer’s account to an OU not affected by the GPO enforcing the security logon banner *before deploying to that computer.*

Prompted for User Credentials¶

Problem: An image was captured from a computer that was already joined to a domain. Subsequently, when this image is deployed to a new target computer, the deployment process unexpectedly halts. Auto-logon fails to occur, and the user is prompted to manually enter appropriate credentials. The deployment only resumes after credentials are provided and the user logs on, indicating a fundamental issue with the domain join state of the source image.

Possible Solution: When preparing source computers for image capture, it is imperative that they are not joined to a domain. If the source computer was domain-joined, first remove it from the domain and join it to a workgroup. Then, re-capture the image from this workgroup-joined computer. After recapturing, attempt the deployment to a target computer to determine if this resolves the credential prompting issue, as it is often caused by domain membership lingering in the captured image.

BIOS¶

The Basic Input/Output System (BIOS) settings on target computers can significantly impact deployment success. Misconfigurations, especially related to hardware modes, can lead to critical system errors and prevent the operating system from starting correctly. This section addresses a specific BIOS-related problem and its solution.

Problem: Deploying to a target computer equipped with Intel vPro technology may result in a stop error, preventing the system from starting. This occurs despite all updated drivers being included as out-of-box drivers in the Deployment Workbench. The issue points to a deeper system configuration problem beyond just missing drivers.

Possible Solution: Review the Serial Advanced Technology Attachment (SATA) mode configured in the target computer’s BIOS settings. The default mode might be set to Advanced Host Controller Interface (AHCI). Unfortunately, certain Windows operating systems do not natively support AHCI by default, which can lead to boot failures. Changing the SATA mode in the BIOS to a compatible setting, such as IDE or Legacy, often resolves this stop error, allowing the operating system to start successfully.

Database Problems¶

Database connectivity is often central to MDT deployments, enabling dynamic configuration and data retrieval. However, misconfigured firewalls or broken connections can severely disrupt this process, leading to deployment failures. This section details common database-related issues and their remedies, focusing on SQL Server environments.

Blocked SQL Server Browser Requests¶

Problem: During the MDT deployment process, the system often needs to retrieve information from Microsoft SQL Server® databases. However, errors can arise if the firewall on the database server is improperly configured. This misconfiguration can block legitimate connection attempts, preventing MDT from accessing critical deployment data stored in SQL Server.

Possible Solution: The Windows Firewall in Windows Server is designed to protect computer resources, but it must be correctly configured to allow SQL Server access. If the firewall is blocking connection attempts, you must configure it on the computer running SQL Server. This typically involves opening specific ports or allowing the SQL Server executable through the firewall. For detailed instructions on configuring firewall ports for SQL Server, refer to the Microsoft documentation: Configure the Windows Firewall to Allow SQL Server Access.

Named Pipe Connections¶

Problem: MDT deployments that rely on SQL Server databases can experience errors related to broken connections, often due to named pipe issues. These problems typically occur if named pipe connections are not enabled within Microsoft SQL Server itself. Without properly configured named pipes, the deployment process may fail to establish a stable connection to the database.

Possible Solution: To resolve these connection problems, ensure that named pipes are enabled in SQL Server. Additionally, if using named pipes, the SQLShare property is required when establishing a connection to an external database. This property specifies a network share that provides a security context for the connection, as Windows PE lacks a default security context. For LTI deployments, the user account makes the connection, while ZTI deployments with Configuration Manager use the network access account. Read access to the SQLShare is essential. Note that the SQLShare property is not needed for TCP/IP connections to the database.

Enable named pipe connections by following the steps relevant to your SQL Server version:

• Enable Named Pipe Connections in SQL Server 2008 R2
• Enable Named Pipe Connections in SQL Server 2005

Enable Named Pipe Connections in SQL Server 2008 R2¶

To enable named pipe connections in SQL Server 2008 R2, follow these steps:

1. On the computer hosting SQL Server 2008 R2, click Start, point to All Programs, then Microsoft SQL Server 2008 R2, and click SQL Server Management Studio.
2. In the Microsoft SQL Server Management Studio console’s Object Explorer, right-click sql_server_name (the name of your SQL Server instance) and click Properties.
3. The Server Properties - sql_server_name dialog box will appear.
4. In the Server Properties dialog box, under Select a page, click Connections.
5. On the Connections page, ensure that the Allow remote connections to this server checkbox is selected, then click OK.
6. Close the Microsoft SQL Server Management Studio console.
7. On the computer running SQL Server 2008 R2, click Start, point to All Programs, then Microsoft SQL Server 2008 R2, point to Configuration Tools, and click SQL Server Configuration Manager.
8. In the SQL Server Configuration Manager console, navigate to SQL Server Configuration Manager (Local) / SQL Server Network Configuration / Protocols for sql_instance (where sql_instance is your SQL Server instance name).
9. In the details pane, right-click Named Pipes and click Enable. A warning dialog will appear, indicating that changes require a service restart.
10. In the Warning dialog box, click OK.
11. In the SQL Server Configuration Manager console, navigate to SQL Server Configuration Manager (Local) / SQL Server Services.
12. In the details pane, right-click SQL Server(sql_instance) and click Restart. The progress bar will indicate the service restart status.
13. Close the SQL Server Configuration Manager console.

For additional information, refer to the blog post: How to enable remote connections in SQL Server 2008.

Enable Named Pipe Connections in SQL Server 2005¶

To enable named pipe connections in SQL Server 2005, complete the following steps:

1. On the computer hosting SQL Server 2005, click Start, point to All Programs, then Microsoft SQL Server 2005, point to Configuration Tools, and click SQL Server Surface Area Configuration.
2. In the SQL Server 2005 Surface Area Configuration dialog box, click Surface Area Configuration for Services and Connections.
3. In the Surface Area Configuration for Services and Connections – server_name dialog box, navigate to MSSQLSERVER\Database Engine, and then click Remote Connections.
4. Select Local and remote connections, then choose Using both TCP/IP and named pipes, and click Apply.
5. In the same dialog box, navigate to MSSQLSERVER\Database Engine, and then click Service.
6. Click Stop. The MSSQLSERVER service will cease operation.
7. Click Start. The MSSQLSERVER service will resume operation.
8. Click OK to confirm your changes.
9. Close the SQL Server 2005 Surface Area Configuration.

For more detailed information, consult the Microsoft Support article: How to configure SQL Server 2005 to allow remote connections.

Deployment Scripts¶

Deployment scripts are integral to MDT, automating various tasks throughout the installation process. However, issues with these scripts can lead to unexpected halts or errors. This section addresses common problems related to MDT deployment scripts and provides practical solutions to ensure their smooth execution.

Credentials_script¶

Problem: During the final startup sequence of a newly deployed computer, the user is unexpectedly prompted to provide user credentials. This can sometimes be accompanied by error 0x80070035, indicating that the network path was not found. This issue typically suggests a lingering configuration from the deployment process that interferes with the system’s ability to access network resources or finalize the logon.

Possible Solution: Ensure that the Windows Imaging Format (WIM) file used for deployment does not contain any residual MININT or _SMSTaskSequence folders. These folders are temporary artifacts of the deployment process and, if present in the final image, can cause logon and network access issues. To remove them, first use the ImageX utility to mount the WIM file, then manually delete these folders from the mounted image before finalizing and deploying it.

ZTIWindowsUpdate¶

Problem: The ZTIWindowsUpdate.wsf script, used for applying software updates during deployment, may fail with the error “wuredist.cab not found” reported in both ZTIWindowsUpdate.log and BDD.log. This occurs if the script attempts to communicate directly with the Microsoft Update website to download Windows Update Agent binaries, scan for updates, and download/install them. The problem arises when the target computer lacks proper internet access, or the deployment share does not contain the necessary Windows Update Agent installation files.

Possible Solution: To resolve this, follow the detailed steps outlined in the “ZTIWindowsUpdate.wsf” section of the MDT Toolkit Reference document. This section provides comprehensive guidance on configuring your environment to ensure the script can successfully access and install updates. This might involve pre-populating the deployment share with required files or ensuring appropriate network connectivity and proxy settings are in place for internet access.

Deployment Shares¶

Deployment shares are the backbone of MDT, storing all necessary installation files, drivers, and scripts. Problems with updating these shares, particularly related to WIM files, can bring deployments to a halt. This section focuses on a critical issue concerning WIM file updates and its resolution.

Problem: When attempting to update a deployment share, the process fails, and the user receives a message indicating that the mounting of one or more .wim files was unsuccessful. This error prevents the deployment share from being refreshed with the latest operating system images or updates, causing a significant roadblock in the deployment workflow. This problem points to an issue with the WIM file’s integrity or the tools used to manage it.

In a “simple” environment:

• MDT typically picks up WIMGAPI.DLL from C:\Windows\system32 (always in the path). The version of this WIMGAPI.DLL must match the version (build) of the operating system.
• On a 64-bit operating system, MDT always uses the x64 WIMGAPI.DLL file; only that file should be in the system PATH. On a 32-bit operating system, MDT always uses the x86 WIMGAPI.DLL file; only that file should be in the system PATH. (Other products, such as Configuration Manager, use the 32-bit version of WIMGAPI.DLL, even on a 64-bit operating system, but they manage and install that version.)

Possible Solution: Open a Command Prompt window and execute where WIMGAPI.DLL to identify the locations of this critical DLL. For the first entry in the list (the one found by searching the path), verify that its Version property matches the build of the installed Windows Assessment and Deployment Kit (Windows ADK). Crucially, ensure this version also matches the operating system build number. A mismatch in WIMGAPI.DLL versions is a common cause of WIM mounting failures, as the incorrect version may not be able to properly interpret the WIM file format.

The Windows Deployment Wizard¶

The Windows Deployment Wizard guides users through the deployment process, but its behavior can sometimes be unexpected. Specifically, wizard pages might appear even when configured to be skipped, causing unnecessary interruptions. This section addresses this common problem and provides its solution.

Wizard Pages Are Not Skipped¶

Problem: A specific wizard page is displayed during deployment, even though the MDT database (MDT DB) or CustomSettings.ini file has been configured to skip it. This behavior defeats the purpose of automation and can lead to user confusion or delays in the deployment process. The unexpected appearance of a wizard page indicates a misconfiguration in the skip logic.

Possible Solution: To successfully skip a wizard page, you must ensure that all properties normally configured on that page are correctly specified with appropriate values in either the MDT DB or the CustomSettings.ini file. If any required property for a skipped wizard page is improperly configured or omitted, that page will be displayed during the deployment. For detailed information on which properties are necessary to ensure specific wizard pages are skipped, consult the “Providing Properties for Skipped Deployment Wizard Pages” section in the MDT Toolkit Reference document.

Disks and Partitioning¶

Disk and partitioning issues are a frequent source of failures in operating system deployments, especially when involving advanced features like BitLocker or specific disk types. Problems can range from insufficient disk space to incompatibility with logical or dynamic disks. This section reviews various disk-related challenges and their effective solutions.

BitLocker Drive Encryption¶

Deploying BitLocker Drive Encryption requires precise configuration for successful implementation. Several potential problems can arise related to the target computer’s setup. These issues often involve scripting failures, device recognition problems, or insufficient disk space for the BitLocker system volume.

• In ZTI and UDI deployments, the ZTIBde.wsf script may fail with the error “Unable to open registry key ‘HKEY_CURRENT_USER\Control Panel\International\LocaleName’ for reading,” as detailed below.
• USB devices, CD drives, DVD drives, or other removable media devices on the target computer might appear as multiple drive letters, affecting BitLocker recovery key placement.
• Shrinking drive C on the target computer to provide sufficient unallocated disk space can encounter problems, hindering BitLocker activation.

ZTIBde.wsf Script Fails with the Error “Unable to open registry key ‘HKEY_CURRENT_USER\Control Panel\International\LocaleName’ for reading”¶

Problem: During Zero Touch Installation (ZTI) or User-Driven Installation (UDI) deployments, attempting to enable BitLocker on the target computer results in the ZTIBde.wsf script failing. The specific error message encountered is “Unable to open registry key ‘HKEY_CURRENT_USER\Control Panel\International\LocaleName’ for reading.” This indicates a problem with the script accessing locale information.

Possible Solution: The ZTIBde.wsf script runs under the system context in ZTI and UDI, meaning a full user profile is not loaded. Consequently, when the script tries to read locale information from the registry (specifically, the user profile), it cannot find it because the profile isn’t fully available. As a workaround, explicitly specify the locale in the UILanguage property. This ensures the script has the necessary locale information without relying on a fully loaded user profile, allowing BitLocker deployment to proceed successfully.

Devices Appear as Multiple Drive Letters¶

Problem: Certain devices, particularly USB drives, CD/DVD drives, or other removable media, can sometimes present themselves to Windows as multiple logical drive letters. For instance, a single device might emulate both a 1.44-megabyte (MB) floppy disk drive and a memory storage drive, leading Windows to assign letters like A, B (for floppy emulation), and F (for storage). By default, MDT scripts are programmed to utilize the lowest available drive letter, which in this example would be A.

Possible Solution: To override MDT’s default behavior, you can manually select the desired drive letter on the Specify the BitLocker recovery details page within the Windows Deployment Wizard. The wizard’s summary page will display a warning to inform the user about which drive letter was chosen for storing BitLocker recovery information. Additionally, both the BDD.log and ZTIBDE.log files record all detected removable media devices and specifically note which device was ultimately selected for storing BitLocker recovery information, providing a valuable audit trail.

Problems with Shrinking Disks¶

Problem: BitLocker deployment requires at least 2 gigabytes (GB) of unallocated disk space to create the system volume, which stores the hardware-specific files necessary to load Windows after the BIOS boots the computer. On existing computers, it’s often necessary to shrink drive C to free up this space. However, in some instances, the Diskpart tool may be unable to shrink drive C sufficiently, frequently due to fragmented disk space.

Possible Solution 1: If Diskpart fails to free enough space, a potential solution involves defragmenting drive C. First, run the Diskpart shrink querymax command to identify the maximum amount of disk space that can be unallocated. If this value is less than 2 GB, proceed to clean drive C of unnecessary files and then defragment it. Afterward, run Diskpart shrink querymax again to verify that more than 2 GB can now be unallocated. If the value remains insufficient, consider defragmenting drive C multiple times for optimal optimization or, as a last resort, back up data from drive C, delete the existing partition, create a new one, and then restore the data.

Possible Solution 2: The ZTIBDE.wsf script by default runs the Disk Preparation Tool (bdehdcfg.exe) and configures the system volume partition size to 2 GB. While it is possible to modify the ZTIBDE.wsf script to alter this default size, modifying MDT scripts is generally not recommended due to potential compatibility and support issues. Customizations should be carefully considered and tested.

Support for Logical and Dynamic Disks¶

Problem: When performing a Refresh Computer deployment scenario, the deployment process may unexpectedly fail if the target computer utilizes logical drives or dynamic disks. This issue prevents the successful reinstallation or update of the operating system, as MDT has specific limitations regarding disk configurations. This highlights a fundamental incompatibility that must be addressed before attempting such deployments.

Possible Solution: MDT does not officially support deploying operating systems to logical drives or dynamic disks. To successfully deploy to such a target computer, you must first convert any logical or dynamic disks into basic disk partitions. This often involves backing up data, repartitioning the disk, and then restoring the data onto the newly configured basic partitions. Ensure the disk configuration aligns with MDT’s supported formats before initiating the deployment.

Domain Join¶

Domain joining is a critical step in many deployments, seamlessly integrating new computers into an existing network. However, challenges can arise, especially in specific network environments. This section addresses a common domain join problem encountered with static IP configurations and provides a robust solution.

Problem: During deployment, the Windows Deployment Wizard gathers all necessary information for the target computer, including credentials, domain join details, and static IP configuration. Upon completion of Setup, it’s observed that the system has not successfully joined the domain and remains in a workgroup. This typically occurs in environments without Dynamic Host Configuration Protocol (DHCP).

Possible Solution: An LTI deployment configures static IP information after the operating system is fully up and running. If the target computer is on a network segment without DHCP, an automated domain join specified in Unattend.xml will fail because network connectivity to the domain controller cannot be established without an IP address.

To resolve this, configure Unattend.xml to initially join a workgroup. Then, integrate the built-in Recover from Domain task sequence step into your task sequence. Place this step after the static IP address has been successfully applied, allowing the computer to correctly join the domain once stable network connectivity is established.

Driver Installation¶

Driver installation is crucial for ensuring hardware functionality and a smooth user experience. Microsoft provides tools and guidelines to facilitate seamless, automated driver deployments. For comprehensive information on device and driver installation, consult the official Microsoft documentation on Device and Driver Installation.

This section reviews common device driver installation issues and their solutions. Addressing these problems is essential for preventing hardware conflicts and ensuring the stability of deployed systems.

Troubleshoot Device Installation with SetupAPI.log¶

The white paper, Troubleshooting Device Installation with the SetupAPI Log File, offers valuable insights into debugging Windows device installation processes. It provides specific guidelines for driver developers and testers on how to interpret the SetupAPI log file effectively. This resource is indispensable for anyone needing to diagnose complex driver-related problems.

One of the most useful log files for debugging is the SetupAPI.log file, a plain-text record of information related to device installation, service pack installation, and update installation. It meticulously tracks device and driver changes, along with major system modifications, starting from the most recent Windows installation. This section specifically focuses on using the SetupAPI.log file for troubleshooting device installation, omitting details pertaining to service pack and update installations.

New Computer Deployments¶

New Computer deployment scenarios, particularly those initiated via Pre-Boot Execution Environment (PXE) boot, can present unique challenges. Successful PXE boot is foundational for these deployments, and ensuring its proper configuration is paramount. This section addresses common PXE boot issues and provides solutions to facilitate reliable new computer deployments.

PXE Boot¶

The PXE protocol initiates with the client computer broadcasting a DHCP Discover packet, which includes an extension identifying the request as originating from a PXE-compliant client. If a boot server supporting this extended protocol is available, it responds with an offer containing the IP address of the server that will service the client. The client then uses Trivial File Transfer Protocol (TFTP) to download the executable file from the boot server. Finally, the client computer executes the downloaded bootstrap program, commencing the deployment process.

The initial phase of this protocol leverages a subset of DHCP messages, allowing the client to discover a boot server for new computer setup. While the client typically obtains an IP address during this opportunity, it’s not strictly required for PXE. The second phase, between the client and boot server, utilizes the DHCP message format for convenient communication but is otherwise distinct from standard DHCP services. The following sections outline step-by-step solutions for common PXE client initialization problems.

Review the following solutions for PXE boot issues:

• Disable Windows PE Logging in Windows Deployment Services
• Ensure the Proper DHCP Configuration
• Improve PXE IP Address Assignment Response Time

Disable Windows PE Logging in Windows Deployment Services¶

The very first procedure recommended for troubleshooting PXE boot issues is to ensure that logging to setupapi.log has been disabled within Windows Deployment Services. Excessive logging can sometimes introduce delays or interfere with the boot process.

Ensure the Proper DHCP Configuration¶

The specific router configuration for DHCP broadcast forwarding can vary significantly depending on the router models in use. Some routers support forwarding to an entire subnet or router interface, while others can target a specific host. When DHCP servers and the computer running Windows Deployment Services (WDS) are on separate machines, it is crucial to ensure that routers forwarding DHCP broadcasts are configured to allow both the DHCP and WDS servers to receive client broadcasts. Failure to do so will prevent the client computer from receiving a reply to its remote boot request, effectively halting the PXE process.

Consider whether a router positioned between the client computer and the remote installation server is blocking DHCP-based requests or responses. If the Windows Deployment Services client and server reside on different subnets, the intervening router must be configured to forward DHCP packets to the WDS server. This is necessary because WDS client computers discover a WDS server using a DHCP broadcast message. Without proper DHCP forwarding, these client broadcasts will not reach the WDS server. This DHCP forwarding mechanism is sometimes referred to as DHCP Proxy or IP Helper Address in router configuration manuals; refer to your router’s specific instructions for detailed setup information.

Improve PXE IP Address Assignment Response Time¶

If you observe a significant delay (15–20 seconds) for a PXE client computer to retrieve an IP address, several elements should be checked. These delays can impede the efficiency of new computer deployments and point to underlying network configuration problems.

• Verify that the network adapter on the target computer and the switch or router port are configured to the same speed and duplex settings (e.g., automatic, full duplex). Mismatched settings can lead to negotiation delays and poor network performance.
• Check if the IP address for the Windows Deployment Services server is included in the IP Helper file on the router facilitating the connection. If the list of IP addresses in the IP Helper file is extensive, consider moving the WDS server’s address closer to the top of the list. This optimization can reduce the time it takes for DHCP requests to reach the WDS server.

Restarting the Deployment Process¶

During the testing and troubleshooting phases of new or modified task sequences, it often becomes necessary to restart the target computer. The objective is typically to initiate the deployment process from the very beginning. However, MDT retains a record of its progress on the hard disk, meaning a simple restart will cause MDT to resume from its last checkpoint, which might not be the desired behavior.

Possible Solution: To ensure that the deployment process restarts completely from the beginning, you must manually delete the C:\MININT and C:\_SMSTaskSequence folders on the target computer. These folders contain the state information that MDT uses to resume a deployment. After deleting them, restart the target computer, and the deployment should then re-initialize from scratch, allowing for thorough testing of the initial task sequence steps.

Sysprep¶

System Preparation Tool (Sysprep) is a crucial utility for preparing Windows installations for imaging. However, issues related to Sysprep can affect how computers are joined to domains and placed within Active Directory. This section reviews a common Sysprep-related problem concerning computer account placement and offers solutions.

The Computer Account Is in the Wrong OU¶

Problem: After a deployment, the target computer is successfully joined to the domain, but its computer account is located in an incorrect Organizational Unit (OU) within Active Directory Domain Services (AD DS). This misplacement can lead to incorrect Group Policy application and administrative challenges. The issue often arises from pre-existing accounts or misconfigured OU paths during deployment.

Possible Solution 1: If a computer account for the target machine already existed in Active Directory prior to deployment, it will retain its original OU location. To move the account to the specified OU, incorporate an additional task sequence step. This step should utilize an automation tool, such as a Microsoft Visual Basic® Scripting Edition (VBScript), to programmatically relocate the computer account to the desired OU after the domain join is complete.

Possible Solution 2: Verify the format and existence of the specified OU. An incorrect OU path will prevent the computer account from being placed in the intended location. The correct OU format should follow the distinguished name convention, for example: OU=Reception,OU=NYC,DC=Woodgrovebank,DC=com. Double-check for any typos or structural errors in the OU path provided during the deployment configuration.

Configuration Manager¶

Configuration Manager integration with MDT enhances deployment capabilities, but specific issues can arise during setup, particularly with PXE service points. This section addresses a common error encountered when configuring PXE service points and provides a straightforward solution.

Problem: When attempting to create a Configuration Manager PXE service point and selecting the Create self-signed PXE certificate option, the error message shown in Figure 3 is displayed. This error indicates a failure in the certificate generation process, often related to leftover files from previous configurations.

Possible Solution: If a PXE service point had previously existed on the server being configured, it’s possible that the uninstallation process did not fully remove the self-created certificates. To resolve this, manually delete the PXE certificate folder located at C:\Documents and Settings\user_name\Application Data\Microsoft\Crypto\RSA, where user_name is the account that performed the current or previous configuration. After deleting this folder, the New Site Role Wizard in the Configuration Manager console should successfully complete the PXE service point creation.

Task Sequences¶

Task sequences are the core of MDT and Configuration Manager deployments, defining the precise order of operations. However, task sequences can exhibit unpredictable behavior or fail outright due to misconfigurations or underlying issues. This section explores various task sequence-related problems and offers practical solutions.

The Task Sequence Does Not Finish Successfully¶

Problem: A task sequence may fail to complete successfully or exhibit unpredictable behavior during deployment. This often stems from modifications made to the Install Operating System task sequence step (for LTI) or the Apply Operating System Image task sequence step (for UDI and ZTI) after the initial creation of the task sequence. Such changes, like swapping a 32-bit Windows 8.1 image for a 64-bit one, can lead to inconsistencies and deployment failures.

Possible Solution: It is strongly recommended to create a new task sequence whenever you intend to deploy a different operating system image. Modifying the operating system image referenced within an existing task sequence step, particularly after its initial setup, can introduce unpredictable results and break the deployment. Creating a fresh task sequence ensures that all dependencies and configurations are correctly aligned with the new operating system image.

The OEM Task Sequence Incorrectly Appears for a Boot Image Created for a Different Processor Architecture¶

Problem: A task sequence based on an LTI OEM task sequence template is unexpectedly displayed for a boot image with a different processor architecture. For example, an OEM task sequence designed to deploy a 64-bit operating system might appear as an option when using a 32-bit boot image. This could lead to confusion or incorrect selections during the deployment process.

Possible Solution: This behavior is, in fact, expected. OEM task sequences within LTI are not categorized as “platform-specific.” Consequently, they will always be listed as available options, irrespective of the processor architecture of the boot image currently in use. Administrators should be aware of this distinction and ensure they select the appropriate task sequence that matches their target hardware and intended operating system architecture, despite the seemingly incorrect listing.

Bad Task Sequence Item (Invalid OS GUID) Message in the Windows Deployment Wizard¶

Problem: When running the Windows Deployment Wizard, users encounter the error message “Bad Task Sequence Item (Invalid OS GUID).” Despite the operating system being listed in the OperatingSystem.xml file, it does not appear in the Deployment Workbench. This indicates an underlying issue with how the operating system source or its associated SKUs are managed.

Possible Solution: This problem typically arises when an SKU associated with a task sequence has been deleted, but other SKUs for the same operating system source still exist. If the task sequence referencing the deleted SKU is selected, the “Bad Task Sequence Item (Invalid OS GUID)” error appears. To resolve this:

• Remove all SKUs from the operating system source: This action cleans up any orphaned references, allowing the Windows Deployment Wizard to behave normally without displaying the error.
• Change the task sequence to use a different operating system image: Modify the affected task sequence to point to a valid and existing operating system image.

Apply Network Settings¶

Problem: When configuring the network connection name within the Deployment Workbench, a validation error occurs, prompting the message: “Please enter a valid name for the network adapter.” This error prevents the network settings from being applied, halting the configuration process. The issue usually relates to character restrictions in network adapter names.

Possible Solution: The specified connection name must adhere to strict naming conventions, typically disallowing spaces and certain invalid characters. To resolve the validation error, remove any spaces and invalid characters from the network connection name you have entered. Ensure the name consists only of alphanumeric characters or hyphens, as this often satisfies the naming requirements for network adapters.

Use Continue on Error¶

Understanding the behavior of the “Continue on error” setting for task sequence steps is crucial for designing robust deployment workflows. When this option is configured, it dictates how the task sequence proceeds when a step encounters a failure. This setting can significantly impact the overall execution of your deployment.

If an MDT task sequence step is not configured to continue on error and that specific step returns an error, all remaining task sequences within that particular task sequence group will be skipped. However, it’s important to note that the remaining task sequence groups in the overall sequence will still be processed.

Consider the following example with two task sequence groups, each containing multiple steps:

• Group A
  • Step A
  • Step B
• Group B
  • Step A
  • Step B

If Group A\Step A is configured not to continue on error and it fails, then Group A\Step B will not be processed. However, all task sequence steps within Group B will still be processed, as the “continue on error” setting only applies to steps within the failing group. This behavior allows for partial recovery or execution of independent groups.

The User State Migration Tool¶

The User State Migration Tool (USMT) is essential for migrating user data and settings during deployments. However, it can sometimes encounter issues, such as failing to restore specific items like desktop shortcuts. This section addresses a common USMT-related problem and its solution.

Missing Desktop Shortcuts¶

Problem: When using USMT to migrate user data, desktop shortcuts that point to documents stored in network shared folders may not be restored correctly. While these shortcuts are successfully captured during the Scanstate phase, they are never restored to the target computer during the Loadstate phase. This results in missing shortcuts for network resources on the deployed machine.

Possible Solution: To ensure network shortcuts are restored, you need to edit the MigUser.xml file. Locate and comment out the following line, which typically filters out irrelevant links:

Original:

<include> filter='MigXmlHelper.IgnoreIrrelevantLinks()'>

Modified:

<include> <!-- filter='MigXmlHelper.IgnoreIrrelevantLinks()'> -->

By commenting out this filter, USMT will no longer ignore these network-based shortcuts, allowing them to be successfully restored to the target computer during the Loadstate process. This modification ensures a more complete user profile migration.

Windows Imaging Format Files¶

Windows Imaging Format (WIM) files are central to MDT deployments, encapsulating the operating system image. Corruption or issues with these files can lead to deployment failures. This section focuses on problems related to corrupt WIM files and their diagnostic indicators.

Corrupt WIM File¶

Problem: During image deployment, the process unexpectedly fails, with the BDD.log file displaying specific error entries. These entries indicate a problem with the WIM file itself, suggesting it might be corrupt or improperly handled. A typical sign is an ImageX failure with a return code of 2.

The BDD.log file might contain entries such as:

• The image \\Server\Deployment$\Operating Systems\Windows\version1.wim was not applied successfully by ImageX, rc = 2
• LTIApply COMPLETED. Return Value = 2
• ZTI ERROR - Non-zero return code by LTIApply, rc = 2

Further investigation, such as attempting to mount the WIM file using ImageX, results in the error: “The data is invalid.” Additionally, it might be observed that the date stamp of the .wim file is significantly older than the current date. This discrepancy often suggests that another process, like a virus scanner, might have held the .wim file open after a previous read or write operation, leading to its corruption.

Possible Solution: The most reliable solution for a corrupt .wim file is to restore it from backup media. Since corruption often indicates data integrity issues that cannot be easily repaired, using a known good backup ensures that a pristine image is used for deployment. Regular backups of WIM files are critical to mitigate such problems and maintain deployment readiness.

Windows PE¶

Windows Preinstallation Environment (Windows PE) is the initial boot environment for MDT deployments. Issues within Windows PE can prevent the deployment process from even starting, often due to insufficient resources, missing components, or incorrect drivers. This section addresses common Windows PE problems and their solutions.

Deployment Process Not Initiated—Limited RAM or Wireless Network Adapter¶

Problem: When deploying an image to certain target computers, Windows PE successfully starts, runs wpeinit, and opens a Command Prompt window. However, the deployment process itself does not initiate. Troubleshooting this by attempting to map a network drive from the target computer often reveals that the network adapter drivers are not loaded, pointing to a connectivity issue preventing the deployment from proceeding.

Possible Solution 1: The Deployment Wizard may not be starting due to insufficient RAM. Verify that the target computer has a minimum of 512 MB of RAM. Crucially, ensure that no shared video memory consumes more than 64 MB of this 512 MB, as this can reduce the effective RAM available for Windows PE. Versions of Windows PE supported by MDT are unable to run on target computers with less than 512 MB of RAM.

Possible Solution 2: If the issue persists and appears related to network drivers, a common practice is to not include wireless drivers in the Windows PE image. Wireless drivers can sometimes cause instability or conflicts within the minimal Windows PE environment, preventing the network adapter from initializing correctly. Focus on including only essential wired network drivers for initial connectivity.

Deployment Process Not Initiated—Missing Components¶

Problem: When troubleshooting a failed deployment, a review of the BDD.log file might reveal the following critical entry: ERROR - Unable to create ADODB.Connection object, impossible to query SQL Server: ActiveX component can't create object (429). This error typically indicates that a necessary component for database connectivity, specifically ActiveX Data Objects (ADO), is missing from the Windows PE environment.

Possible Solution: This error often points to the Windows PE image not having been created using MDT. If you are operating within a Configuration Manager environment, avoid using one of the existing Windows PE images that Configuration Manager might have automatically created. Instead, create a new Windows PE image specifically using the Import Microsoft Deployment Task Sequence Wizard. This wizard ensures that all necessary MDT components, including those for Microsoft ActiveX® Data Objects (ADO), are correctly integrated into the Windows PE image, thus resolving the ADODB.Connection object creation failure.

Note: The Windows PE images created by Configuration Manager typically contain components supporting scripting, XML, and Windows Management Instrumentation (WMI), but they often lack components that support Microsoft ActiveX® Data Objects (ADO).

Deployment Process Not Initiated—Missing or Incorrect Drivers¶

Problem: On certain target computers, Windows PE starts, executes wpeinit, and displays a Command Prompt, but fails to initiate the actual deployment process. Attempts to map a network drive from the target machine indicate that network adapter drivers are not loaded. A review of the SetupAPI.log file in X:\Windows\System32\Inf further reveals Windows PE errors during network adapter configuration, including the message: “This driver is not meant for this platform.” This occurs despite drivers from the Out-of-Box Drivers list having been injected into the image.

Possible Solution: It is highly probable that Windows PE is encountering a driver conflict with another injected driver. To resolve this, when configuring the settings for the Windows PE image in the Deployment Workbench, create a dedicated Windows PE drivers group. This group should contain only essential network adapter and storage drivers. Then, configure the deployment share to exclusively use this specialized Windows PE driver group. This targeted approach minimizes potential conflicts by limiting the number of drivers loaded into the lean Windows PE environment.

Deployment Process Flow Charts¶

This section provides two comprehensive sets of flow charts designed to visually represent the MDT deployment process: one for Lite Touch Installation (LTI) and another for Zero Touch Installation (ZTI) with Configuration Manager. Each flow chart meticulously illustrates the various tasks executed during its respective deployment type, offering a clear, step-by-step overview.

Familiarize yourself with these deployment process flow charts by:

• Reviewing the LTI deployment process flowcharts, which detail each phase of a Lite Touch Installation.
• Reviewing the ZTI deployment process flowcharts, providing insights into the Zero Touch Installation process when integrated with Configuration Manager.

LTI Deployment Process Flowcharts¶

Flow charts are provided for the following phases of Lite Touch Installation (LTI), offering a visual breakdown of the deployment process:

• Validation (Figure 4): Details the initial checks and validations performed by MDT.
• State Capture (Figure 5 and Figure 6): Illustrates the process of gathering user state and data from the old operating system.
• Preinstall (Figure 7, Figure 8, and Figure 9): Covers the preparatory steps before the new operating system installation.
• Install (Figure 10): Focuses on the actual installation of the operating system image.
• Postinstall (Figure 11 and Figure 12): Describes tasks executed immediately after the OS installation.
• State Restore (Figure 13, Figure 14, Figure 15, and Figure 16): Shows the process of restoring user data and settings to the new OS.

Images are omitted as per prompt, but would typically be included here as Figure 4 through Figure 16.

ZTI Deployment Process Flowcharts¶

Flow charts are provided for the following phases of Zero Touch Installation (ZTI) deployment with Configuration Manager, illustrating the automated process:

• Initialization (Figure 17): Details the initial setup and environment configuration.
• Validation (Figure 18): Covers the preliminary checks and validations.
• State Capture (Figure 19): Illustrates the process of capturing user state and data.
• Preinstall (Figure 20): Describes tasks performed before the OS installation.
• Install (Figure 21): Focuses on the actual operating system installation.
• Postinstall (Figure 22): Covers steps immediately following OS installation.
• State Restore (Figure 23 and Figure 24): Shows the process of restoring user data and settings.
• Capture (Figure 25): Details the final image capture process, if applicable.

Images are omitted as per prompt, but would typically be included here as Figure 17 through Figure 25.

Microsoft Support¶

Microsoft is committed to supporting users of the Microsoft Deployment Toolkit, offering comprehensive assistance through various channels. For professional and premier level support, resources are available to help you resolve complex issues and optimize your deployment strategies.

• Professional level support
• Premier level support

Feel free to share your experiences, ask questions, or provide additional troubleshooting tips in the comments below. Your insights help the community grow!