Skip to main content

Inside setup - troubleshoot Windows deployment issues

Applies to: Windows 7, Windows Server 2008 R2

It is certainly great to see so many companies migrating to Windows 7 and Windows Server 2008 R2, but it is also great to see that they are taking advantage of the new deployment tools that have been released in the same period. That being said, when compared with Windows XP and Windows Server 2003 deployment, deploying the new Windows platform is quite different. In this article, I will give you a few tips and tricks for quickly solving common issues with Windows deployments, both with core setup tools and with deployment solutions like Microsoft Deployment Toolkit (MDT) and Microsoft System Center Configuration Manager (ConfigMgr).

The Windows setup engine

No matter what tool you are using to deploy Windows 7 or Windows Server 2008 R2, at some point it will run the new Windows setup engine. It could be the full setup experience you get when running setup.exe or the mini-setup equivalent after applying a Sysprep Windows image using tools like ImageX from the Windows Automated Installation Kit (AIK). Whenever setup is running, it needs configuration information; it can prompt you for it, but most often it queries an answer file (unattend.xml) for the information. The setup engine is logging all its action to a log file (the setupact.log file) and it is this file we need to review when Windows setup encounters an error.

Issue #1: Windows setup prompts with strange error code

In the scenario depicted below, we are deploying Windows 7 with a unattend.xml file, but it fails in the middle of the setup with a strange error code:

Windows Setup Error Code Screenshot

Solution: Do not click OK. Instead, press Shift-F10 to locate the setupact.log file (this file will be in different locations depending on when setup fails). In this case, the real error is that we typed an incorrect computer name into our unattend.xml which setupact.log showed. These are the lines from setupact.log. On purpose I had assigned a computer name with more than 16 characters to my unattend.xml file (which I have seen customers do), and that is what caused setup to choke.

Computer Name Error Text Screenshot

Tip! For a list of possible locations for the setupact.log file, refer to this article

Back to top

Using MDT 2010 Lite Touch to deploy Windows

When using MDT 2010 Lite Touch to deploy Windows, issues are more complex to troubleshoot. This is because MDT adds another layer of tools and scripts on top of the core setup engine and the Windows AIK tools. Luckily MDT also provides additional error handling and log files that can help us figure out what's going on so, in the end, we are better suited for troubleshooting. To better understand troubleshooting you need to keep in mind how the process goes when deploying Windows with it.

When using MDT to deploy Windows we use a so-called Task Sequence. The Task Sequence is our list of steps or actions that needs to be done during deployment. Some commonly-used steps are formatting the drive, injecting drivers, running Windows setup with an answer file, installing applications, and installing updates.

The MDT 2010 Lite Touch bare metal deployment process looks like this:

  1. The boot image starts from CD/USB or PXE and, once started, connects back to the deployment server.
  2. The deployment wizard starts and reads the deployment settings (rules) from the server and either starts the deployment automatically or prompt you for input (depending on the settings on the server). The settings are stored in memory.
  3. The selected Task Sequence is started and starts executing the actions or steps in it. For example, to make sure setup obtains the correct settings, the following actions are involved:
    a. Gather - Reads the deployment settings
    b. Configure - Updates the unattend.xml with the appropriate settings
    c. Apply Operating System - Runs setup.exe with the updated unattend.xml file
  4. After the operating system image is applied the task sequence will reboot the machine and continue where it left off after reboot.

When troubleshooting MDT 2010 Lite Touch, we also use log files, but they are stored in different locations than setupact.log. Each MDT script generates its own log file but the BDD.log contains a summarized view of all other MDT log files. The logs are stored in X:\MININT\SMSOSD\OSDLOGS, C:\MININT\SMSOSD\OSDLOGS, or C:\Windows\Temp\DeploymentLogs depending on when the deployment fails. BDD.log is the master log file, but the SMSTS.log file may also yield additional clues as to why a Lite Touch deployment breaks. (By the way, the log files are formatted to be read by the trace32 utility.)

Issue #2: MDT 2010 Lite Touch fails connecting to the server

This is a quite common error, but how do we troubleshoot it? In this case, I know that the user and password provided is correct.

User Credentials Error Screenshot

The next step is to press F8 to get a command prompt. Since this error is very early in the process, there is no C: volume created to store log files so MDT stores them in RAM. So after opening the BDD.LOG with trace32 (or Notepad) in X:\MININT\SMSOSD\OSDLOGS (the RAM drive) we see the following:

Rules Typo Error Screenshot

The real error is that we have typed an error in our rules. The deployment share is shared as MDTProduction$ but we have typed MDTProducton$ (without the "i") in the rules.

Back to top

Using ConfigMgr 2007 to deploy Windows

As when using MDT 2010 Lite Touch to deploy Windows, adding ConfigMgr 2007 to the picture makes deployment issues more complex to troubleshoot when compared with just using the Windows 7 DVD. MDT 2010 Zero Touch components will reduce the pain by adding more than 100 commonly-wanted features, including additional error handling, to ConfigMgr 2007. In contrast with common belief, MDT actually reduces the complexity when working with ConfigMgr OSD, not the other way around.

When deploying Windows using ConfigMgr 2007, ConfigMgr stores its additional log files in X:\Windows\Temp, C:\_SmsTaskSequence\SMSOSD\OSDLOGS and C:\Windows\System32\CCM\Logs or C:\Windows\SysWOW64\CCM\Logs depending on the platform. With ConfigMgr, the master log file is SMSTS.log but the MDT log files may also have useful information. To access the log files on the client, check the Enable command support (testing only) box in the boot image properties to enable F8 while in Windows PE.

Zero Touch Dialogue Box Screenshot

Back to top

Other useful logs when deploying Windows

  • Cbs.log - for troubleshooting DISM commands to inject drivers, language packs, updates, and so on
  • - for troubleshooting drivers
  • Netsetup.log - for troubleshooting domain join issues
  • WindowsUpdate.log - for troubleshooting Windows Update installations

Happy troubleshooting!

Back to top

Additional resources

About the author

Johan Arwidmark is a consultant and all-around geek specializing in systems management and enterprise-level Windows deployment solutions. Johan speaks at several conferences each year, including TechED events around the world. Johan is also actively involved in deployment communities like and, and has been awarded the Microsoft MVP award for more than seven years.