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).
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.
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:
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.
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:
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.)
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.
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:
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
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.
Back to top
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 deploymentresearch.com and myitforum.com, and has been awarded the Microsoft MVP award for more than seven years.