The Case of the Unexplained Boot Delay in Microsoft LiteTouch ISO
I was working with a customer recently who had noticed a significant increase in time required for MDT LiteTouch wizard to initialize. Specifically, the amount of time under review is from system post until the BDDWelcome screen is displayed. This is the familiar screen I am referring to:
What changed? Driver related? Not enough memory? Bad DNS?
The customer did mention their goal was to move to a new environment where DHCP\PXE would not be available and at least that was one known variable. The next step is to carefully consider the boot process and where logs which would be required to move forward would be located. This is a well-known article which talks about where setup logs may reside based on the phase of the deployment… but in this case the investigation is before Windows setup even starts. So where are the logs in Windows Preinstallation Environment (Windows PE) phase?
The X: drive represents the RAMDisk environment for PE. Typically, we need the content from the minint directory but for this scenario we’re going to focus on the Windows PE initialization log and unattend.xml.
X:\windows\system32\wpeinit.log
X:\unattend.xml
The wpeinit.log should shed some light on the earliest phase of the boot process where the delay has been reported. Why do we even need an unattend for PE? A mechanism is required to bootstrap MDT from within Windows PE and the unattend provides that capability by calling wscript.exe X:\Deploy\Scripts\LiteTouch.wsf.
In the first scenario, we collected logs from a legacy environment where performance meets customer expectations.
[Scenario #1 wpeinit.log DHCP Enabled on subnet – Default configuration]
Total 1 second to install network driver and verify via WMI that address is assigned. Very fast.
2014-08-13 18:15:55.935, Info Spent 1187ms installing network components
2014-08-13 18:15:56.420, Info Installing device vmbus\{f8615163-df3e-46c5-913f-f2d2f965ed0e} X:\windows\INF\wnetvsc.inf succeeded
2014-08-13 18:15:56.576, Info Installing device root\kdnic X:\windows\INF\kdnic.inf succeeded
2014-08-13 18:15:56.685, Info Spent 750ms installing network drivers
2014-08-13 18:15:56.795, Info QueryAdapterStatus: found operational adapter with DHCP address assigned.
2014-08-13 18:15:56.795, Info Spent 0ms confirming network initialization; status 0x00000000
[Scenario #2 wpeinit.log DHCP Disabled on subnet – trying to improve as you can see delay below when timeout is reached]
Total 1.5 minutes
2014-08-13 18:18:54.685, Info Spent 1078ms installing network components
2014-08-13 18:18:55.185, Info Installing device vmbus\{f8615163-df3e-46c5-913f-f2d2f965ed0e} X:\windows\INF\wnetvsc.inf succeeded
2014-08-13 18:18:55.326, Info Installing device root\kdnic X:\windows\INF\kdnic.inf succeeded
2014-08-13 18:18:55.420, Info Spent 735ms installing network drivers
2014-08-13 18:20:25.752, Info Spent 90234ms confirming network initialization; status 0x003d0002
2014-08-13 18:20:25.752, Info STATUS: SUCCESS (0x003d0002) = WPEUTIL_S_NET_CONNECTIVITY_VERIFICATION_TIMEOUT
[Scenario #3 wpeinit.log DHCP Disabled on subnet and WinPE Unattend setting DHCP to false]
Total 8 seconds
2014-08-13 18:01:01.893, Info Spent 1062ms installing network components
2014-08-13 18:01:02.361, Info Installing device vmbus\{f8615163-df3e-46c5-913f-f2d2f965ed0e} X:\windows\INF\wnetvsc.inf succeeded
2014-08-13 18:01:02.486, Info Installing device root\kdnic X:\windows\INF\kdnic.inf succeeded
2014-08-13 18:01:02.580, Info Spent 688ms installing network drivers
2014-08-13 18:01:02.736, Info UGC process exit code is 0x00000000
2014-08-13 18:01:02.736, Info Executed UGC; identity[Microsoft-Windows-TCPIP, Culture=neutral, Version=6.3.9600.16384, PublicKeyToken=31bf3856ad364e35, ProcessorArchitecture=amd64, versionScope=NonSxS], command[netiougc.exe -online], status[0x00000000]
2014-08-13 18:01:09.768, Info QueryAdapterStatus: found operational adapter with static address assigned.
Documentation to set DHCP to false can be found here. You can find the default unattends for MDT located in the following directory C:\Program Files\Microsoft Deployment Toolkit\Templates. When you update or rebuild media for deployment point the appropriate unattend will be injected into the PE LiteTouch image. (please backup the originals before making modifications with ADK)
Sample unattend.xml for Windows PE X64 with this configuration:
<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
<settings pass="windowsPE">
<component name="Microsoft-Windows-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="https://schemas.microsoft.com/WMIConfig/2002/State">
<Display>
<ColorDepth>32</ColorDepth>
<HorizontalResolution>1024</HorizontalResolution>
<RefreshRate>60</RefreshRate>
<VerticalResolution>768</VerticalResolution>
</Display>
<RunSynchronous>
<RunSynchronousCommand wcm:action="add">
<Description>Lite Touch PE</Description>
<Order>1</Order>
<Path>wscript.exe X:\Deploy\Scripts\LiteTouch.wsf</Path>
</RunSynchronousCommand>
</RunSynchronous>
</component>
<component name="Microsoft-Windows-TCPIP" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="https://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance">
<Interfaces>
<Interface wcm:action="add">
<Ipv4Settings>
<DhcpEnabled>false</DhcpEnabled>
</Ipv4Settings>
<Ipv6Settings>
<DhcpEnabled>false</DhcpEnabled>
</Ipv6Settings>
<Identifier>Ethernet</Identifier>
</Interface>
</Interfaces>
</component>
</settings>
<cpi:offlineImage cpi:source="wim:c:/temp/delme/x64/install.wim#Windows 7 ENTERPRISE" xmlns:cpi="urn:schemas-microsoft-com:cpi" />
</unattend>
In green I've defined the name of the adapter which is key. For example, on Hyper-V it was called "Ethernet" but on VMWare "Ethernet0". If you're unsure, in WinPE you can press F8 to launch a command window and list network information for clarification.
netsh interface ipv4 show interfaces
I thought this was an interesting problem because often the smallest changes which on the surface wouldn't appear to have an impact often do. So if its 1.5 minutes delay per deployment, does it matter? If you consider the possibility of thousands of deployments it can add up to quite a bit of time and well worth the investigation.