MDT 2010 Lite Touch Driver Management

By arwidmark / April 25, 2010

In the “A Drivers Saga – The Control Freak meets The Dynamic Developer” session at MMS 2010 in Las Vegas, me and Michael Niehaus presented different methods of managing drivers with MDT 2010 and ConfigMgr 2007. I focused on MDT 2010 Lite Touch, and Michael Niehaus did the ConfigMgr part. On top of that Michael started blogging about his part of the session… so now I have to do my part ūüôā

Michael’s blogs on ConfigMgr Driver Management can be found here: 

Part 1:
http://blogs.technet.com/mniehaus/archive/2010/04/29/configmgr-2007-driver-management-the-novel-part-1.aspx

Part 2:
http://blogs.technet.com/mniehaus/archive/2010/04/29/configmgr-2007-driver-management-the-novel-part-2.aspx

Part 3:
http://blogs.technet.com/mniehaus/archive/2010/04/29/configmgr-2007-driver-management-the-novel-part-3.aspx

Back to MDT 2010 Lite Touch, we have two ‚Äútypes‚ÄĚ of drivers to worry about when deploying Windows. We have drivers for Windows PE (the boot image) and we have drivers for the Windows Operating System that we deploy.
Driver management for the boot image is pretty straight forward, so I just wrote down my recommendations in this guide. Driver management for the Operating Systems that we deploy is more complex, the real answer is it depends… To simplify I have broken down drivers for the Windows Operating system in to three core scenarios, similar to what Michael did in his ConfigMgr Drivers article.


Drivers for Windows PE (the boot image)

The boot image we use for deployment is based on Windows PE 3.0 (a subset of the Windows 7 operating system). For the boot image we need at Nic and Storage drivers at minimum, but sometimes we need to add other drivers as well (such as mouse drivers for remote cards like ILO etc.) 

The good thing about Windows PE 3.0 is that it supports the same hardware as Windows 7, so if you are lucky you don’t need to add any drivers at all to it. But in this article is guidance if you need to. We also need to set the scratchspace in WinPE to increase the temporary storage that is used when the Windows setup engine is injecting drivers.

To be successful with boot image drivers in MDT 2010 Lite Touch I recommend that you do the following

  • Create two folders in Out-Of-Box drivers, name the folders WinPE x86 and WinPE x64.
     
  • Import any needed x86 drivers into the WinPE x86 folder, and any needed x64 drivers into the WinPE x64 folder. Note that you should only use Windows 7 drivers for the boot images, even if you plan to deploy Windows XP with MDT 2010 Lite Touch.
     
  • Create two selection profiles, one named WinPE x86 (where you select the WinPE x86 folder in Out-Of-Box drivers), and one named WinPE x64 (where you select the WinPE x64 folder in Out-Of-Box drivers
     
  • Then configure the deployment share properties to use the correct selection profile. In the Windows PE x86 Components tab, in the Driver Injection area, select the WinPE x86 selection profile. Do the same for Windows PE x64 Components tab, but select the WinPE x64 selection profile.
     
  • Also in the deployment share properties, in the Windows PE x86 Settings tab, in the Lite Touch Boot Image Settings area, set the Scratch space size to 128, do the same in the Windows PE x64 Settings tab.


Drivers for Windows Operating systems

To simplify things we usually start with one of three core scenarios when configuring drivers for MDT 2010 Lite Touch. The three scenarios are based on the size of the company, the number of operating systems being deployed, the level of control desired and the number of hardware models.

Scenario #1 ‚Äď ¬†Total Chaos

This scenario has the following assumptions. This is for a small or midsize company, they are only deploying one operating system, say Windows 7 x86, and they have a few hardware models from the same vendor. The key things here are that they are deploying just one family of operating systems and that the hardware is from the same vendor. The reason is that the larger vendors do test compatibility among their own models per operating system family, so it’s quite rare that a driver from one model will interfere with another driver.

Solution

For this scenario we recommend that you stick with the default simple PnP ID detection based method for drivers. Shorthand story is, just download and extract the drivers for each model to a folder, and import that folder into the Deployment Workbench.

Deployment Workbench with drivers imported for Scenario #1

 

 

Scenario #2 ‚Äď Added Predictability

This scenario has the following assumptions. This is a midsize company, they are deploying multiple operating systems, say Windows XP and Windows 7 x86, and they have a few more hardware models but still from the same vendor. The major difference from the first scenario is that are deploying multiple operating systems. Since the default method is using PnP ID detection among all imported drivers we need to have a way of filtering the drivers so that only Windows XP drivers are considered for Windows XP and deployments, and that only Windows 7 drivers are considered for Windows 7 deployments. The feature in MDT 2010 that we can use for this filtering is called Selection Profiles.

Solution

For this scenario I recommend that you use the default PnP ID detection based method with the addition of using selection profiles as a filter for the drivers. The configuration in MDT 2010 is that you first create two folders inside Out-of-box drivers, named Windows XP x86 and Windows 7 x86. Then we import the drivers the correct folder in the Deployment Workbench.

After importing the drivers, create a selection profile created for each operating system driver folder, and then configure the Inject Drivers action in the Task Sequence to use the correct selection profile.

‚ÄÉ

Creating the selection profiles.

Configuring the Inject Drivers action to use a selection profile.

 

 

Scenario #3 ‚Äď Total Control

This scenario has the following assumptions. This is a larger company, they are deploying multiple operating systems, say Windows XP and Windows 7 x86, they have many hardware models, and from multiple vendors. The major difference from the second scenario is that are using hardware from multiple vendors.
Since we have multiple vendors involved the testing and compatibility matrix between each model cannot be guaranteed. We need to be able to filter not only on operating system but also on a per model basis. Even though we technically could use selection profiles for this as well, this is not what they were designed for. There is another feature called DriverGroup that will help us do some more advanced filtering.

Solution

For this scenario I recommend that you use the default PnP ID detection based method with the addition of using DriverGroup as a filter for the drivers. The configuration in MDT 2010 is that you first create two folders inside Out-of-box drivers, named Windows XP x86 and Windows 7 x86. Then you create subfolders for each model you have. Then you download and extract the drivers for each model, and per operating system. Then import each per operating system folder and per model into the correct folder in the Deployment Workbench.

Please note that selection profiles and driver groups work together meaning if I have a selection profile including driver A, and a driver group including driver B, both drivers will be added. Most times you only want one or the other but they can be combined. When using drivers per model I recommend you to use the selection profile named Nothing for the Inject Drivers action. The real trick for this scenario is to name the driver folders according to the name of the model, then you can set the DriverGroup001 variable to %Model% in either the Task Sequence or in the rules.

Note: If you are having issues with drivers not detected by plug and play within the folder, you can force driver injection by changing the Inject Drivers action property to “Install all drivers from the selection profile”. The property is a bit misleading, because it’s also valid for driver groups, but the label does not really say that¬† ūüôā

Create the driver folder structure in Deployment Workbench

Add the Set Task Seuqence Variable action with DriverGroup001 set to Windows 7 x86\%Model%

Configure the Inject Drivers Action to use the “Nothing” selection profile.

 

Regards / Johan Arwidmark

MMS 2010 – Sample Sysprep Files for Windows XP SP3, April 2010

By arwidmark / April 22, 2010

 

Ever struggled with a 0x0000007B BSOD when deploying a Windows XP SP3 image?

Struggle no more, here is a working driver set and sysprep mass storage section for most current hardware models…

Instructions for adding the sample files to MDT 2010 Lite Touch

In these steps I assume you have a deployment share in the D:\MDTProduction folder, Windows XP Pro SP3 (full source) imported to the D:\MDTProduction\Operating Systems\Windows XP Pro SP3 Eng x86 Unattend folder, and that you created a Task Sequence named Windows XP Pro SP3 Eng x86 Unattend Task Sequence.

Step 1 – Download sample files

  1. Download and extract the sample files to D:\Setup\Sample Files (http://www.deployvista.com/Repository/tabid/71/EntryId/62/DMXModule/396/Download/attachment/language/en-US/Default.aspx)

Step 2 – Disable the builtin add mass storage action

  1. Right-click the Windows XP Pro SP3 Eng x86 Unattend Task Sequence and select Properties. 
     
  2. In the Task Sequence tab, configure the Windows XP Pro SP3 Eng x86 Unattend Task Sequence with the following setting, 
     
  3. Disable the Capture Image -> Add mass storage drivers to sysprep.inf for XP and 2003 action.
     
  4. Click OK.

Step 3 – Configure sysprep.inf

  1. Right-click the Windows XP Pro SP3 Eng x86 Unattend Task Sequence and select Properties.
     .
  2. In the OS Info tab, click Edit sysprep.inf.
     
  3. Edit the mass storage section using the D:\Setup\Samples Files\Sysprep\storage.txt sample

Step 4 – Add the drivers

  1. Using Explorer, copy the D:\Setup\Sample Files\$OEM$ folder to the D:\MDTProduction\Operating Systems\Windows XP Pro SP3 Eng x86 Unattend folder

Step 5 – Build and Capture

  1. Run the Windows XP Pro SP3 Eng x86 Unattend Task Sequence on a virtual machine.

 

Vitual Roundtable – Planning, testing, assessing and rolling out Windows 7 in an enterprise organization

By arwidmark / April 22, 2010

On April 29th, join Microsoft Technical Fellow, Mark Russinovich, as he will be leading a discussion around the process of planning, testing, assessing and rolling out Windows 7 in an enterprise organization.

Mark will be joined by a panel of IT professionals who are currently in the piloting and deployment process, along with Microsoft subject matter experts who can speak in depth about the technologies. The event will be broadcast live over the web at 9:00 am PDT, and will be available for on-demand viewing following the broadcast. The discussion will be open and candid, with the panel sharing insights, dispelling myths and getting down to the real story around technical adoption of Windows technologies. Specific topics will include the role of the pilot and the critical information it provides, best practices and tips & tricks for ensuring a successful effort, tools and technologies that will help automate the pilot and deployment processes, and conducting a frank post-pilot assessment. During the event, Mark will field questions coming in via the web from viewers across the globe.

Missed a previous Springboard Series Virtual Roundtable? Gain insight, tips, and tricks from Microsoft Technical Fellow Mark Russinovich, industry experts, and IT professionals from around the world from these recordings:
http://technet.microsoft.com/windows/dd421882.aspx

 

Access the VRT live at:

http://ms.istreamplanet.com/springboard/

Archived Article – Using WDS without Active Directory ‚Äď Configuring a standalone WDS

By arwidmark / April 6, 2010

 

 

Note: This is an archived Article, the latest version is available at:

http://deploymentresearch.com/Blog/tabid/62/EntryId/2/Demo-from-MMS-2011-Using-WDS-without-Active-Directory-Configuring-a-standalone-WDS.aspx

/ Johan

 

In Windows Server 2008 R2, Microsoft added support for using the PXE listener without Active Directory. Here is a complete guide on how to configure a standalone Windows Server 2008 R2 WDS Server

Pre-Requisites

In these steps I assume you have a server the following configuration

  1. A Windows Server 2008 R2 named WDS01, installed into a workgroup. 
     
  2. One network card with a fixed IPv4 address (I’m using 192.168.2.215 in my lab) 
     
  3. Two partitions, C: for the Windows Server 2008 R2 operating System, D: for Data

I also assume you have a DNS Server somewhere in the environment, maybe your local router if it’s a smaller network. In my lab my DNS server / Router has IP address 192.168.2.1. The router has DHCP server disabled.

High level steps:

  1. Download and install Windows AIK 2.0 
     
  2. Install DHCP and create a scope for the network 
     
  3. Add the WDS transport role service 
     
  4. Create and share the RemoteInstall folder structure 
     
  5. Copy the x86 and x64 boot files 
     
  6. Copy the x86 and x64 boot images 
     
  7. Configure the WDS Providers 
     
  8. Configure the Policies 
     
  9. Additional DHCP and WDS provider configuration

Download and install Windows AIK 2.0

  1. On WDS01, logon as Administrator. 
     
  2. Download and Install Windows AIK 2.0 (named Windows AIK for Windows 7 on Microsoft downloads) with the default settings.

Install DHCP and create a scope for the network

  1. On WDS01, using Server Manager, select Roles, and the select Add Roles. 
     
  2. On the Before You Begin page, select the Skip this page by default checkbox, and click Next. 
     
  3. In the Select Server Roles list, select DHCP Server and click Next. 
     
  4. On the DCHP Server page, click Next. 
     
  5. On the Select Network Connection Bindings page, accept the default settings and click Next. 
     
  6. On the Specify IPv4 DNS Server Settings page, in the parent domain: textbox, type in whatever DNS Suffix you want to use, I used tslab.net, and click Next. 
     
  7. On the Specify IPv4 WINS Server Settings page, accept the default settings and click Next. 
     
  8. On the Add or Edit DHCP Scopes page, click Add. Use the following settings.

    Scope Name: 192.168.2.0/24
     
    Starting IP address: 192.168.2.100
     
    Ending IP address: 192.168.2.199
     
    Subnet Type: Wired (lease duration will be 8 days)
     
    Activate this scope: Selected
     
    Subnet Mask: 255.255.255.0
     
    Default Gateway (optional): 192.168.2.1
     
    Click OK, and then click Next. 
     

  9. On the Configure DHCPv6 Stateless Mode page, accept the default settings and click Next. 
     
  10. On the Specify IPv6 DNS Server Settings page, in the parent domain: textbox, type in whatever DNS Suffix you want to use, I used tslab.net, and click Next. 
     
  11. On the Confirm Installation Selections page, click Install. 
     
  12. On the Installation Results page, click Close.

Add the WDS Transport server role

  1. On WDS01, using Server Manager, select Roles, and the select Add Roles. 
     
  2. In the Select Server Roles list, select Windows Deployment Services and click Next. 
     
  3. On the Overview of Windows Deployment Services page, click Next. 
     
  4. On the Select Role Services page, clear the Windows Deployment Service checkbox so that only Transport Server role service is selected, and click Next. 
     
  5. On the Confirm Installation Selections page, click Install. 
     
  6. On the Installation Results page, click Close.

Create and share the RemoteInstall folder structure

  1. On WDS01, using Explorer, create the following folder structure:
     
    D:\RemoteInstall
     
    D:\RemoteInstall\boot
     
    D:\RemoteInstall\boot\x86
     
    D:\RemoteInstall\boot\x86\images
     
    D:\RemoteInstall\boot\x64
     
    D:\RemoteInstall\boot\x64\images 
     
  2. Using Explorer, and the Advanced Sharing feature, share the D:\RemoteInstall folder as REMINST.

Copy the x86 and x64 boot files 

  1. On WDS01, using Explorer, create the D:\Mount folder. 
     
  2. Start a Deployment Tools Command Prompt (found on the start menu, in the All Programs / Microsoft Windows AIK folder), type the following command + press Enter.
     
    Imagex /mount x86\winpe.wim 1 D:\Mount 
     
  3. Leave the Deployment Tools Command Prompt open. 
     
  4. Using Explorer, navigate to the D:\Mount\Windows\boot\PXE folder, copy all content to the D:\RemoteInstall\boot\x86 folder. 
     
  5. Close all Explorer windows (the wim filter driver in WAIK 2.0 is really sensitive about open file handles when unmounting an image).
     
  6. In the Deployment Tools Command Prompt, type the following commands + press Enter after each line.
     
    Imagex /unmount D:\Mount
     
    Imagex /mount amd64\winpe.wim 1 D:\Mount 
     
  7. Using Explorer, navigate to the D:\Mount\Windows\boot\PXE folder, which now contains the x64 boot files, and copy all content to the D:\RemoteInstall\boot\x64 folder. 
     
  8. Close all Explorer windows.
     
  9. In the Deployment Tools Command Prompt, type the following command + press Enter.
     
    Imagex /unmount D:\Mount
     
  10. Using Explorer, copy the C:\Windows\system32\reminst\boot\boot.sdi file to the D:\RemoteInstall\boot folder.

Copy the x86 and x64 boot images

  1. On WDS01, using Explorer, copy any x86 boot image that you want to use to the D:\RemoteInstall\x86\Images folder, name the boot image boot.wim.
     
    Note: If you just want a boot image to test with you can copy the default Windows PE 3.0 x86 boot image from WAIK. It is named winpe.wim and is locate in the C:\Program Files\Windows AIK\Tools\PETools\x86 folder 
     
  2. Using Explorer, copy any x64 boot image that you want to use to the D:\RemoteInstall\x64\Images folder, name the boot image boot.wim.
     
    Note: Again, if you just want a boot image to test with, you can copy the default Windows PE 3.0 x64 boot image from WAIK. It is named winpe.wim and is locate in the C:\Program Files\Windows AIK\Tools\PETools\amd64 folder

Configure the WDS Providers

  1. On WDS01, using the Registry Editor, configure the WDS Providers order by navigating to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\ Providers\ WDSPXE key, and create a new Multi-String Value with the following settings:
     
    Name: ProvidersOrder 
     
    Data: WDSSIPR 
     
  2. Using the Registry Editor, configure the TFTP root folder by navigating to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\ WDSTFTP key, and create a new String Value with the following settings:
     
    Name: RootFolder
     
    Data: D:\RemoteInstall

Configure the Policies

  1. On WDS01, using Notepad, edit the C:\Windows\system32\wdssipr.dll.conf.ini file. In the IMAGES POLICY section, configure the following values
     
    X86BootImage=boot\x86\images\boot.wim
     
    X64BootImage=boot\x64\images\boot.wim 
     
  2. Save the C:\Windows\system32\wdssipr.dll.conf.ini file.

Additional DHCP and WDS provider configuration

  1. On WDS01, using a Command Prompt, configure the transport server to use DHCP by typing the following command + press Enter.
     
    WDSUTIL /Set-TransportServer /ObtainIPv4From:DHCP 
     
  2. Leave the Command Prompt open. 
     
  3. Using the Command Prompt, configure the DHCP PXEClient option, by typing the following commands + press Enter after each line.
     
    Netsh
     
    dhcp
     
    server \\WDS01
     
    add optiondef 60 PXEClient String 0 comment=‚ÄĚPXE support‚ÄĚ
     
    set optionvalue 60 STRING PXEClient
     
    exit 
     
  4. Leave the Command Prompt open. 
     
  5. Using the Registry Editor, configure the DHCP ports option by navigating to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\ WDSPXE key, and change the UseDhcpPorts data value from 1 to 0. 
     
  6. Using the Command Prompt, start the WDS transport server by typing the following command + press Enter.
     
    WDSUTIL /Start-TransportServer

Done! You should now be able to start the boot images over the network, having configured the WDS PXE listener on a standalone server.

Good luck / Johan Arwidmark

Adding a boot menu to Windows Server 2008 R2 WDS

By arwidmark / March 15, 2010

Integrating another (3rd party) boot menu for WDS in Windows Server 2008 R2 has changed compared with standard Windows Server 2008… here is how to do it…

  1. Download and extract syslinux-3.85.zip or later from http://www.kernel.org/pub/linux/utils/boot/syslinux  (it contains pxelinux) 
     
  2. Copy the com32\menu\vesamenu.c32 and com32\modules\chain.c32 files to your WDS Server, to both the D:\RemoteInstall\Boot\x64 and D:\RemoteInstall\Boot\x86 folders.
     
  3. Copy the core\pxelinux.0 file to your WDS Server, to both the D:\RemoteInstall\Boot\x64 and D:\RemoteInstall\Boot\x86 folders, then rename it to pxelinux.com 
     
  4. Download a nice background image (http://www.deployvista.com/Portals/0/DeploymentBackground.png), and save it in D:\RemoteInstall\Boot\x64 and D:\RemoteInstall\Boot\x86  
     
  5. In the D:\RemoteInstall\Boot\x64 and D:\RemoteInstall\Boot\x86 folders, make a copy of pxeboot.n12 and rename it to pxeboot.0 
     
  6. In the D:\RemoteInstall\Boot\x64 and D:\RemoteInstall\Boot\x86 folders, make a copy of abortpxe.com and rename it to abortpxe.0 
     
  7. Configure WDS to use the pxelinux.com boot file, in Windows Server 2008 R2 you have to do it through WDSUTIL, here are the commands:
     
    WDSUTIL /Set-Server /BootProgram:boot\x86\pxelinux.com /Architecture:x86
     
    WDSUTIL /Set-Server /N12BootProgram:boot\x86\pxelinux.com /Architecture:x86
     
    WDSUTIL /Set-Server /BootProgram:boot\x64\pxelinux.com /Architecture:x64
     
    WDSUTIL /Set-Server /N12BootProgram:boot\x64\pxelinux.com /Architecture:x64
      
  8. In the D:\RemoteInstall\Boot\x64 and D:\RemoteInstall\Boot\x86 folders, create a subfolder called pxelinux.cfg 
     
  9. In the D:\RemoteInstall\Boot\x64\pxelinux.cfg and D:\RemoteInstall\Boot\x86\pxelinux.cfg folders, create a file named default with the following settings
     
    DEFAULT      vesamenu.c32
    PROMPT       0
    NOESCAPE     0
    ALLOWOPTIONS 0
    # Timeout in units of 1/10 s
    TIMEOUT 300
    MENU WIDTH 40
    MENU MARGIN 0
    MENU ROWS 12
    MENU TIMEOUTROW 14
    MENU HSHIFT 5
    MENU VSHIFT 2
    MENU COLOR BORDER 30;44       #00000000 #00000000 none
    MENU COLOR TABMSG 1;36;44     #00000000 #00000000 none
    MENU COLOR TITLE 1;36;44     #00000000 #00000000 none
    MENU COLOR SEL   30;47       #40000000 #20ffffff
    MENU BACKGROUND DeploymentBackground.png
    MENU TITLE PXE Boot menu
    MENU WIDTH 80
    MENU MARGIN 18
    MENU ROWS 4
    LABEL wds
     MENU       DEFAULT
    # MENU PASSWD [email protected]
     MENU       LABEL Windows Deployment Services
     KERNEL     pxeboot.0
    LABEL local
     MENU LABEL Boot from Harddisk
     LOCALBOOT 0 
    LABEL Abort
     MENU LABEL AbortPXE
     KERNEL     abortpxe.0

Here is how it looks…¬†

Finally – Trace64, a 64-bit logviewer for the ConfigMgr and MDT log files

By arwidmark / March 4, 2010

Note: for latest version of this article, go to the below link:
http://www.deploymentresearch.com/Blog/tabid/62/EntryId/35/Trace64-finally-here-to-stay-But-it-is-hidden.aspx

Finally, after many years Microsoft released trace64 to the public, a 64-bit logviewer for the ConfigMgr and MDT log files… And yes it works in WinPE x64 too…

It’s part of the MDT 2010 Healthcare package (In the Files\DeploymentShare\Applications\HTHMDT2010\Tools folder)

Download Link:
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=cd73a2c5-76c1-48b3-a366-156900bb9493

Update 2010-04-22
The link no longer works. The release of¬†the 64-bit version of the trace¬†utility¬†was¬†not¬†approved for release so they pulled it back. It’s currently a Microsoft internal tool only. When the healthcare package will be back for download, it will sadly be without the trace64 utility.

Update 2011-09-05
Microsoft now provides the x64 version as part of the ConfigMgr 2012 Beta 2, check this article for instructions: http://www.deploymentresearch.com/Blog/tabid/62/EntryId/35/Trace64-finally-here-to-stay-But-it-is-hidden.aspx

/ Johan

 

Reference Images in ConfigMgr 2007 native mode

By arwidmark / March 3, 2010

Having workgroup machines in native mode is sort of a pain, but Microsoft actually supports it.

You need to do the following…

  1. Check the “Allow HTTP communication for roaming and site assignment” site setting in the site mode tab of site properties. (On the site server you will be using for creation of the image)
     
  2. Modify the “MobileClient.tcf” file (\bin\i386)¬† to change the setting “IISSSLState” in the [Site] section to be 95 (IISSSLState=95) on the site server.
     
  3. Re-create the bootable media (if you are using bootable media)

/ Johan

Unattend.xml – The process when using the Sysprep and Capture only Task Sequence in MDT 2010

By arwidmark / January 23, 2010

This is the process when executing a Sysprep and Capture Task Sequence in MDT 2010 (capturing a Windows 7 OS).

  1. The Unattend.xml file belonging to the Sysprep and Capture Task Sequence is copied from the Deployment Share to C:\MININT.
     
  2. The C:\MININT\Unattend.xml is updated with  the rules/settings in MDT by the Configure action in the Task Sequence.
     
  3. The Updated C:\MININT\Unattend.xml file is copied to C:\Windows\System32\Sysprep
     
  4. Sysprep is executed with the /quiet /generalize /oobe /quit switches. 
     
  5. Sysprep starts searching for unattend.xml files and will find the C:\Windows\System32\Sysprep\Unattend.xml file and use settings from the pass Generalize in it.

    Note: If there are other Unattend.xml files on the drive, sysprep might end up using another answer file than the one in C:\Windows\System32\Sysprep. For example if there is an existing Unattend.xml file in C:\Windows\Panther, this location will have higher precedence than C:\Windows\System32\Sysprep. Info on the Implicit answer file search order can be found here… http://technet.microsoft.com/en-us/library/cc749415(WS.10).aspx. If you think that the “wrong” answer file was used, you can review C:\Windows\System32\Sysprep\Panther\SetupAct.log and verify.

 

Page 4 of 15