The Deployment Guys : XP Tablet PC Edition

Single WIM Deployment of Windows XP Professional and Tablet PC Edition (and Other Operating Systems)

DeploymentGuys — Mon, 13 Jul 2009 22:55:00 GMT

Update 2009-07-17: Corrected some errors in the application settings in the Extracting the Sysprep Files section that occured because I did not make all necessary changes after doing a copy/paste.

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

In my post on August 3 2009, I promised in an upcoming post I would show you how to create a single WIM file that contains several XP images with a single MDT Lite Touch Task Sequence (rerun four times). Additionally, I said that I would show you how you can deploy these images from that WIM file onto the correct target hardware using either a single MDT Lite Touch Task Sequence or a single MDT Zero Touch Task Sequence in SCCM. Well, that day is finally here!

Image Build: MDT Setup

For building and capturing images, I prefer to use the MDT Lite Touch process over Systems Center Configuration Manager 2007. You have more control over the process, you can have tasks with a visible UI for testing and troubleshooting, and since the Task Sequencer runs as the built-in Administrator account you can configure settings that can get propagated to Default User settings. So the process I'm about to describe will only use MDT Lite Touch for building and capturing images into the single WIM file. Also, everything I describe in the post was done with MDT 2008 Update 1. Once MDT 2010 has released or is close to releasing, I’ll blog what, if any, changes are necessary.

As I described in the August 3rd post, the "Single Image" process for XP Pro/Tablet PC Edition will not be supported for Service Pack 3. Because of this, I moved my current customer's XP deployment process back to separate images. Since they have to support hardware that requires both types of XP ACPI HALs, this deployment process required four XP Images:

Windows XP Professional with ACPI Uniprocessor HAL (APIC HAL)
Windows XP Tablet PC Edition 2005 with ACPI Uniprocessor HAL (APIC HAL)
Windows XP Professional with Advanced Configuration and Power Interface (ACPI) PC HAL (PIC HAL)
Windows XP Tablet PC Edition 2005 with Advanced Configuration and Power Interface (ACPI) PC HAL (PIC HAL)

If you only require a subset of these images (perhaps you don’t need to support Tablet PCs or PIC hardware, etc.), you can modify the steps that follow accordingly.

Using traditional sector-based imaging tool supporting four images would require four times the disk storage and four times the WAN traffic to replicate those images around. However, using file-based WIM images that can take advantage of "single instance storage" that allows you to store all four of these images in a single WIM file that will only be slightly larger than any single image.

All of the above images can be generated from a single MDT Task Sequence by simply running it four times on either the correct computer hardware or by using the correct XP Product Key. Unfortunately, if you try this with MDT 2008 “out of the box”, the process will fail during the attempt to capture the second image. This is because the MDT 2008 script that does the image capture, ZTIBackup.wsf, is hard-coded to use an image name of the format <TaskSequenceID><drive letter>Drive (e.g. XPPROSP2CDrive). Since an image name must be unique within a WIM file, when ZTIBackup.wsf tries to append the next image with the same image name, it fails. Therefore, to capture four image into on WIM with MDT 2008 as is you would need four identical Task Sequences. And you would need to remember to specify the same WIM file in the deployment wizard when each Task Sequence.

So to work around this limitation, I created a custom version of ZTIBackup.wsf (with the exciting name of ZTIBackupCustom.wsf). With this version you can specify the image name prefix (the part before <drive letter>Drive) using either a command line switch, /nameprefix, or a custom property, ImageNamePrefix. I used this script instead of ZTIBackup.wsf in the Create WIM step in the Task Sequence. Using only this change worked well but imposed the limitation the each run of the Task Sequence had to complete before starting the next. Also, all the runs had to be completed in the proper order so that the image index in the WIM would come out the same each time.

To get around this limitation, I changed the BackupFile MDT property (which holds the WIM file name) for each run of the Task Sequence so that each run created a different WIM file. I then created a script that uses imagex /export to combine all the WIM files in to a single WIM. This allows you to run the build in any order (even all at once) and re-run those that fail if needed.

OS Installation Media

You will need to assemble and import the XP SP2-integrated media as I described in my post on August 3 2009.

CustomSettings.ini

To control what edition of XP gets install, what image name prefix gets used, what BackupFile name is used, etc. I used MAC Address sections in CustomSettings.ini. Doing it this way requires four computers with different MAC Addresses. (I used Hyper-V and Virtual Server virtual machine as my build machines so that I didn’t need to be bothered with CD or PXE booting physical machines, but this process will work either way. I used Hyper-V to build the APIC HAL images and needed Virtual Server to build the PIC HAL images.) Here is what the CustomSettings.ini looks like:

[Settings]
Priority=Default, MACAddress, Finish
Properties=MyCustomProperty, CapturedImageIndex, ImageNamePrefix, CompletionFile, BackupFile

[Default]
OSInstall=Y

OrgName=Contoso
_SMSTSORGNAME=Contoso
SLShare=%DeployRoot%\Logs

SkipAppsOnUpgrade=YES
SkipDeploymentType=YES
    DeploymentType=NEWCOMPUTER
SkipComputerName=YES
    ;ComputerName set in MACAddress sections
SkipDomainMembership=Yes
    JoinWorkgroup=Workgroup
    ;JoinDomain
    ;DomainAdmin
    ;DomainAdminDomain
    ;DomainAdminPassword
SkipUserData=yes
    UserDataLocation=NETWORK
    ;UDDir
    ;UDShare
SkipComputerBackup=Yes
SkipBuild=YES
    ;BuildID set in MACAddress sections
SkipTaskSequence=YES
    ;TaskSquenceID set in MACAddress sections
SkipProductKey=YES
    ;ProductKey
SkipPackageDisplay=YES
    ;LanguagePacks
SkipLocaleSelection=Yes
    UserLocale=en-us
    InputLocale=en-us
    KeyboardLocale=en-us
SkipTimeZone=Yes
    TimeZone=35
    TimeZoneName=Eastern Standard Time
SkipApplications=YES
    ;Applications
SkipAdminPassword=YES
    AdminPassword=*
SkipCapture=YES
    DoCapture=YES
    ComputerBackupLocation=%DeployRoot%\Captures
SkipBitLocker=YES
    ;BDEDriveLetter
    ;BDEDriveSize
    ;BDEInstall
    ;TPMOwnerPassword
SkipSummary=YES
SkipFinalSummary=NO

[00:15:5D:11:AF:FF]
; Vista x86
BuildID=Vistax86SP1
TaskSquenceID=Vistax86SP1
CapturedImageIndex=1
ComputerName=vx86sp1%HALNAME%
WsusServer=http://MDTSERVER

[00:15:5D:11:AF:FE]
; XP Pro APIC HAL
BuildID=XPSP3
TaskSquenceID=XPSP3
CapturedImageIndex=1
ComputerName=xppro%HALNAME%
ProductKey=11111-22222-33333-44444-55555
WsusServer=http://MDTSERVER

[00:15:5D:11:AF:FD]
; XP Tablet APIC HAL
BuildID=XPSP3
TaskSquenceID=XPSP3
CapturedImageIndex=2
ComputerName=xptab%HALNAME%
ProductKey=AAAAA-BBBBB-CCCCC-DDDDD-EEEEE
WsusServer=http://MDTSERVER

[00:03:FF:64:17:41]
; XP Pro PIC HAL
BuildID=XPSP3
TaskSquenceID=XPSP3
CapturedImageIndex=3
ComputerName=xppro%HALNAME%
ProductKey=11111-22222-33333-44444-55555
WsusServer=http://MDTSERVER

[00:03:FF:64:17:42]
; XP Tablet PIC HAL
BuildID=XPSP3
TaskSquenceID=XPSP3
CapturedImageIndex=4
ComputerName=xptab%HALNAME%
ProductKey=AAAAA-BBBBB-CCCCC-DDDDD-EEEEE
WsusServer=http://MDTSERVER

[Finish]
BackupFile=%TASKSEQUENCEID%_%CapturedImageIndex%.wim
ImageNamePrefix=%TASKSEQUENCEID%.%CapturedImageIndex%.%TASKSEQUENCEVERSION%_
CompletionFile=%TASKSEQUENCEID%.%CapturedImageIndex%.txt

The edition of XP (Professional or Tablet PC Edition 2005) that gets install is controlled by using the correct Pro or Tablet Product Key. (In this sample 11111-22222-33333-44444-55555 represents the XP Pro product key and AAAAA-BBBBB-CCCCC-DDDDD-EEEEE represents the XP Tablet PC Edition product key.) The BackupFile name is constructed from the TaskSquenceID and the custom property CapturedImageIndex. So for example the BackupFile name for the XP Pro APIC HAL image would be XPSP3_1.wim. The prefix for the image name within the WIM the TaskSquenceID, the custom property CapturedImageIndex, and the TASKSEQUENCEVERSION. For the the XP Pro APIC HAL image, the ImageNamePrefix would be something like XPSP3.1.05.

Image Build: Task Sequence Details

Installing XP Service Pack 3

As I stated in my post on August 3 2009, the only way to create a supported installation of Windows XP Tablet PC Edition 2005 Service Pack 3 is to first install Tablet PC Edition from Service Pack 2 media and then install the Service Pack 3 Update. So to be consistent, the task sequence creates all the XP images by first installing from SP 2 media and installing the SP 3 Update as an Application in the Custom Tasks group.

I did this by download the Windows XP Service Pack 3 Update from here: http://www.microsoft.com/downloads/details.aspx?FamilyId=5B33B5A8-5E76-401F-BE08-1E1555D4F3D4&displaylang=en. I extracted the contents of the update to a temporary folder with the following command:

WindowsXP-KB936929-SP3-x86-ENU.exe /x:<temporary folder path>

Then I used the temporary folder to import the extracted Service Pack 3 Update as an Application in MDT with the following settings:

Folder name: Microsoft Windows XP Service Pack 3 Update
Name: Windows XP Service Pack 3 Update
Version: 1.0
Publisher: Microsoft
Language: en-US
Source: .\Applications\Microsoft Windows XP Service Pack 3 Update
CommandLine: Update.exe /passive /norestart /n
WorkingDirectory: .\Applications\Microsoft Windows XP Service Pack 3 Update\i386\update

Updating the \Windows\Source folder

MDT copies the XP installation source files into the %windir%\Source folder so that it is available if an optional component needs to be installed later. Unfortunately, since you are installing from SP 2 media and installing the SP 3 Update later the %windir%\Source folder will be at SP2 but the installed OS will be at SP3. To fix this you have to add step to the Task Sequence to update the %windir%\Source folder with the SP3-level installation source files.

To do this, create a temporary folder. Copy ZTIUtility.wsf from the MDT Scripts folder and the custom scripts LTI-ReplaceWindowsSource.wsf and LTI-CopySysprepFiles.wsf (in the ZIP attachment below) into this folder. Create a subfolder of the temporary folder called Source. Copy the contents of the SP3-level integrated media or slipstreamed version of the XP Pro installation CD files into the Source folder (copy all files/folders from the CD especially the Support folder, not just the i386 folder). The folder should look similar to this:

Import this folder as an Application with source files with the following settings:

Folder name: Windows XP Professional Service Pack 3 Integreted Media
Name: Windows XP Professional Service Pack 3 Integreted Media
Version: 1.0
Publisher: Microsoft
Language: en-US
Source: .\Applications\Windows XP Professional Service Pack 3 Integreted Media
CommandLine: cscript.exe LTI-ReplaceWindowsSource.wsf
WorkingDirectory: .\Applications\Windows XP Professional Service Pack 3 Integreted Media

Add this as an Install Application step in the Custom Tasks group.

If you are going to create your media for this step by slipstreaming SP3 into an SP2 installation source, this is what I recommend that you do. Download the Windows XP Service Pack 3 - ISO-9660 CD Image File from here and burn it to a CD using software that can burn ISO images to CD. (I like using ImgBurn for this but there are many others you can use.)

Copy the SP2 installation source that you imported following my instructions in the August 3, 2009 post to a temporary folder. Delete the Dotnetfx, Support, and Valueadd folders from the temporary folder. Replace them with the ones on the XP SP3 CD you just created. Then use the SP3 installer (WindowsXP-KB936929-SP3-x86-ENU.exe) on the root of the CD to integrate SP3 into the temporary folder using the following command:

WindowsXP-KB936929-SP3-x86-ENU.exe /integrate:"<temporary folder path>"

Copy the resulting installation files into the Source folder in the above instructions. Then create a Install Application step in the Custom Tasks group to “install” this as I described above.

Extracting the Sysprep Files

MDT copies the Sysprep files from the operating system folder in the Distribution folder. Because of this, the Sysprep files copied will be the SP2 versions instead of the SP 3 versions. Similar to the above step, we need to make sure the SP3 versions get copied instead.

Create another Application in MDT as Applications without source files or elsewhere on the network with the following settings:

Name: Windows XP Professional Service Pack 3 Sysprep Files
Version: 1.0
Publisher: Microsoft
Language: en-US
CommandLine: cscript.exe LTI-CopySysprepFiles.wsf
WorkingDirectory: %DeployRoot%\Applications\Windows XP Professional Service Pack 3 Integreted Media

Then create a Install Application step in the Custom Tasks group to “install” this.

Changing the Create WIM Step

You still need to copy ZTIBackupCustom.wsf from the attached Zip file, place it in the MDT Scripts folder, and change the command line of the Create WIM step to use it instead of ZTIBackup.wsf.

Merging the WIM files

After completing all four runs of the Task Sequence, there should be four WIM files in the \Distribution\Captures folder: XPSP3_1.wim, XPSP3_2.wim, XPSP3_3.wim, and XPSP4_1.wim. To merge them all into a new single WIM file (XPSP3.wim), I created the following CMD script (MergeXPImages.cmd) to do this. It uses a small VBScript as well (both included in the Zip attachement). This script is run on the MDT Server. Be sure to change the set CAPTURES=D:\Distribution\Captures line to point to your Captures folder path.

@echo off
setlocal

call "%ProgramFiles%\Windows AIK\Tools\PETools\pesetenv.cmd"
set CAPTURES=D:\Distribution\Captures

:: Get the Last Modified date for the previous merged WIM if it exists
:: and create an environment variable
If exist "%CAPTURES%\XPSP3.wim" (
    for /f "tokens=*" %%i in ('cscript //nologo GetFileDateInfo.vbs "%CAPTURES%\XPSP3.wim"') do set %%i
)

:: Rename previous merged WIM so as not to overwrite or merge to the previous WIM
If exist "%CAPTURES%\XPSP3.wim" rename "%CAPTURES%\XPSP3.wim" "XPSP3_%FileLastModified%.wim"

:: Merge the source WIMs into a single destination WIM
call :MERGEIMAGE "%CAPTURES%\XPSP3_1.wim" "%CAPTURES%\XPSP3.wim"
call :MERGEIMAGE "%CAPTURES%\XPSP3_2.wim" "%CAPTURES%\XPSP3.wim"
call :MERGEIMAGE "%CAPTURES%\XPSP3_3.wim" "%CAPTURES%\XPSP3.wim"
call :MERGEIMAGE "%CAPTURES%\XPSP3_4.wim" "%CAPTURES%\XPSP3.wim"

goto :EOF

:MERGEIMAGE

    for /f "delims=<> tokens=2,3*" %%i in ('imagex /info "%~1" 1') do set %%i=%%j
    imagex /export "%~1" 1 "%~2" %NAME%
    imagex /info "%~2"

goto :EOF

Deploying the XP Multi-image WIM

So now that you have this multi-mage WIM file, how do you make sure that the correct image gets applied in the deployment Task Sequence? The steps are different depending on whether you are deploying with MDT Lite Touch Installation or with System Center Configuration Manager 2007 with MDT Integration. You must use MDT Integration and an MDT Task sequence in ConfigMgr so that the Gather step will run.

In both cases you will need to make the changes to CustomSettings.ini and use ZTI-DetectHardwareExit.vbs as shown in the Edit CustomSettings.ini for Detecting Tablet PC Hardware section of my post on August 3 2009. Using this multi-image WIM requires that the IsTablet variable is set correctly to True or False.

System Center Configuration Manager 2007

If you are deploying with System Center Configuration Manager, the setup is very straight forward. Import the WIM files as an Operating System Image Package. In your Task Sequence you will now need to have four Apply Operating System Image steps instead of one. Give each a unique step name like Apply OS – XP Pro APIC HAL to avoid confusion as to why there are four. For all of them you will check Apply operating system from captured image and select the Image package you just created. Then for each one you will select a different Image number (1, 2, 3, or 4). Finally you will set conditions on the Options tab on each Apply Operating System Image step. For example, the conditions for the XP Pro APIC HAL image would look like this:

The table below shows the various settings for all the Apply Operating System Image steps.

Step Name	Image #	Conditions
Apply OS - XP Pro ACPIAPIC HAL	1	HALNAME equals ACPIAPIC and IsTablet equals FALSE
Apply OS - XP Tablet ACPIAPIC HAL	2	HALNAME equals ACPIAPIC and IsTablet equals TRUE
Apply OS - XP Pro ACPIPIC HAL	3	HALNAME equals ACPIPIC and IsTablet equals FALSE
Apply OS - XP Tablet ACPIPIC HAL	4	HALNAME equals ACPIPIC and IsTablet equals TRUE

Similarly, you should have two Apply Windows Settings steps, one with the XP Professional Product Key and one with the XP Tablet PC Edition Product Key:

Step Name	Product key	Conditions
Apply Windows Settings – XP Pro	(Windows XP Professional Volume License Key)	IsTablet equals FALSE
Apply Windows Settings - XP Tablet	(Windows XP Tablet PC Edition 2005 Volume License Key)	IsTablet equals TRUE

MDT 2008 Update 1

If you are using MDT Lite Touch Installation, things get a little trickier. First import the WIM as a Operating System into MDT. After you do you will see four entries in Operating Systems like XPSP3.1.05_CDrive in "Windows XP SP3\XPSP3.wim" if you used a folder name of Windows XP SP3 during import.

When you create your deployment Task Sequence select the one that starts with XPSP3.1 as the operating system to install. This will be the XP Pro APIC HAL image which should be the one that will be installed most often. You can only have the one Install Operating System step in an MDT Task sequence.

When you import a WIM as an Operating System in the Deployment Workbench it creates one or more entries in \Distribution\Control\OperatingSystems.xml. It will create one entry for each image in the WIM files. Below is an example of the entries in OperatingSystems.xml for my multi-image XP WIM file

<os guid="{e22d5b4a-1d2f-4c73-860a-ced219bb8c09}">
<Name>XPSP3.1.05_CDrive in "Windows XP SP3\XPSP3.wim"</Name>
<Description>
</Description>
<Platform>x86</Platform>
<Build>5.1.2600.5512</Build>
<Type>Windows XP</Type>
<Source>.\Operating Systems\Windows XP SP3</Source>
<IncludesSetup>False</IncludesSetup>
<SMSImage>False</SMSImage>
<ImageFile>.\Operating Systems\Windows XP SP3\XPSP3.wim</ImageFile>
<ImageIndex>1</ImageIndex>
<ImageName>XPSP3.1.05_CDrive</ImageName>
<Flags>
</Flags>
<HAL>acpiapic_up</HAL>
<Size>3003</Size>
</os>
<os guid="{1c47ea5f-73cd-44f2-a0a6-37583ac9b774}">
<Name>XPSP3.2.05_CDrive in "Windows XP SP3\XPSP3.wim"</Name>
<Description>
</Description>
<Platform>x86</Platform>
<Build>5.1.2600.5512</Build>
<Type>Windows XP</Type>
<Source>.\Operating Systems\Windows XP SP3</Source>
<IncludesSetup>False</IncludesSetup>
<SMSImage>False</SMSImage>
<ImageFile>.\Operating Systems\Windows XP SP3\XPSP3.wim</ImageFile>
<ImageIndex>2</ImageIndex>
<ImageName>XPSP3.2.05_CDrive</ImageName>
<Flags>
</Flags>
<HAL>acpiapic_up</HAL>
<Size>3236</Size>
</os>
<os guid="{61c15f32-1f9f-4c64-806a-202eaccac425}">
<Name>XPSP3.3.05_CDrive in "Windows XP SP3\XPSP3.wim"</Name>
<Description>
</Description>
<Platform>x86</Platform>
<Build>5.1.2600.5512</Build>
<Type>Windows XP</Type>
<Source>.\Operating Systems\Windows XP SP3</Source>
<IncludesSetup>False</IncludesSetup>
<SMSImage>False</SMSImage>
<ImageFile>.\Operating Systems\Windows XP SP3\XPSP3.wim</ImageFile>
<ImageIndex>3</ImageIndex>
<ImageName>XPSP3.3.05_CDrive</ImageName>
<Flags>
</Flags>
<HAL>acpipic_up</HAL>
<Size>3051</Size>
</os>
<os guid="{a8f8689f-ed34-4595-a2f8-02ef98832979}">
<Name>XPSP3.4.05_CDrive in "Windows XP SP3\XPSP3.wim"</Name>
<Description>
</Description>
<Platform>x86</Platform>
<Build>5.1.2600.5512</Build>
<Type>Windows XP</Type>
<Source>.\Operating Systems\Windows XP SP3</Source>
<IncludesSetup>False</IncludesSetup>
<SMSImage>False</SMSImage>
<ImageFile>.\Operating Systems\Windows XP SP3\XPSP3.wim</ImageFile>
<ImageIndex>4</ImageIndex>
<ImageName>XPSP3.4.05_CDrive</ImageName>
<Flags>
</Flags>
<HAL>acpipic_up</HAL>
<Size>3284</Size>
</os>

You will notice that each entry is assigned a unique GUID. This is what MDT uses to track what OS to install when you select an OS in the Install Operating System step. Unfortunately, MDT takes the GUID from the entry selected in the Install Operating System step and sets a global Task Sequence variable called OSGUID with the value. This means that to change what OS gets installed within the Task Sequence, you have to override the OSGUID value with the GUID for the OS you want to install. You also need to override the variable IMAGEINDEX as well. To do this you need to create a series of Set Task Sequence Variable steps to override both variables using conditions similar to those on the ConfigMgr steps. Below is a table showing the Set Task Sequence Variable steps for my sample above that should immediately precede the Install Operating System step and their conditions. There should be no conditions on the Install Operating System step.

Step Name	TS Variable	Value	Conditions
Set OSGUID - XP Tablet ACPIAPIC HAL	OSGUID	{1c47ea5f-73cd-44f2-a0a6-37583ac9b774}	HALNAME equals ACPIAPIC and IsTablet equals TRUE
Set IMAGEINDEX - XP Tablet ACPIAPIC HAL	IMAGEINDEX	2	HALNAME equals ACPIAPIC and IsTablet equals TRUE
Set OSGUID - XP Pro ACPIPIC HAL	OSGUID	{61c15f32-1f9f-4c64-806a-202eaccac425}	HALNAME equals ACPIPIC and IsTablet equals FALSE
Set IMAGEINDEX - XP Pro ACPIPIC HAL	IMAGEINDEX	3	HALNAME equals ACPIPIC and IsTablet equals FALSE
Set OSGUID - XP Tablet ACPIPIC HAL	OSGUID	{a8f8689f-ed34-4595-a2f8-02ef98832979}	HALNAME equals ACPIPIC and IsTablet equals TRUE
Set IMAGEINDEX - XP Tablet ACPIPIC HAL	IMAGEINDEX	4	HALNAME equals ACPIPIC and IsTablet equals TRUE

You will also need to set the ProductKey property to either the XP Pro or XP Tablet key depending on whether IsTablet equals FALSE or TRUE respectively. This can be done using conditioned Set Task Sequence Variable steps or using CustomSettings.ini by adding sections like the ones shown below:

[Settings]
Priority=IsTabletCheck, ByTabletType, Default
Properties=MyCustomProperty, TabletPnpIds, IsTablet, XPTabletProductKey

[IsTabletCheck]
TabletPnpIds=ACPI\WACF004,ACPI\WACF008,ACPI\MAI3310,ACPI\FUJ02E5
UserExit=ZTI-DetectHardwareExit.vbs
IsTablet=#DetectDevices("%TabletPnpIds%")#

[ByTabletType]
Subsection=Tablet-%IsTablet%

[Tablet-True]
ProductKey=AAAAA-BBBBB-CCCCC-DDDDD-EEEEE
OSInstall=Y

[Tablet-False]
ProductKey=11111-22222-33333-44444-55555

OSInstall=Y

[Tablet-Error]
OSInstall=N

[Default]

where 11111-22222-33333-44444-55555 represents the XP Pro product key and AAAAA-BBBBB-CCCCC-DDDDD-EEEEE represents the XP Tablet PC Edition product key.

Creating Multi-image WIM files with Other Operating Systems

Creating and deploying multi-image WIM files can be done with other operating systems. For example, you could use a single task sequence to create an custom WIM that contains custom images of Windows Vista Business and Windows Vista Enterprise. Or create a single WIM file with Windows Server 2008 Standard, Enterprise, and Datacenter. (You would generally only include images of the same OS and the same architecture with a single WIM. You would not benefit from single instance storage if you tried to include x86 and x64 images in the same WIM.) To do this, the image build process would have to be done more like the MDT 2008 deployment method described above. What is unique about XP is all the images were created for the same source “Operating System” (the XP SP2 media). For including multiple editions of other operating systems in a single WIM requires using multiple MDT “Operating Systems” in the Task Sequence. This requires overriding the OSGUID and IMAGEINDEX like the process above except you would have to condition off another variable.

For example, let’s say you wanted to create a WIM that contains custom images of Windows Vista Business and Windows Vista Enterprise. You could set a custom variable call Edition like this:

[Settings]
Priority=Default, MACAddress, Finish
Properties=MyCustomProperty, CapturedImageIndex, ImageNamePrefix, CompletionFile, BackupFile, Edition

[Default]
OSInstall=Y

.
.
.

[00:15:5D:11:AF:FF]
; Vista Business x86
BuildID=Vistax86SP1
TaskSquenceID=Vistax86SP1
Edition=Business
CapturedImageIndex=1
ComputerName=vbx86sp1
WsusServer=http://MDTSERVER

[00:15:5D:11:AF:FE]
; Vista Enterprise x86
BuildID=Vistax86SP1
TaskSquenceID=Vistax86SP1
Edition=Enterprise
CapturedImageIndex=2
ComputerName=vex86sp1
WsusServer=http://MDTSERVER

.
.
.

In the image build Task Sequence you would select the most often deployed OS (let’s say Windows Vista Enterprise for example) in the Install Operating System step. You would then create Set Task Sequence Variable steps that override the OSGUID and IMAGEINDEX with the ones for Windows Vista Business with a condition of Edition equals Business.

For deploying the resulting WIM you would do similar conditioned steps for ConfigMgr and MDT but you would have to again use a custom variable for the condition that perhaps get set per computer, location, or role in CustomSettings.ini or the MDT database.

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.

This post was contributed by Michael Murgolo, a Senior Consultant with Microsoft Services - U.S. East Region.

Windows XP Tablet PC Edition 2005 Deployment White Papers Updated for Service Pack 3

DeploymentGuys — Wed, 21 Jan 2009 23:09:00 GMT

As I mentioned in the Windows XP Service Pack 3 Considerations section of my Full Update post on the Single Image process, that process will no longer be supported with Service Pack 3. While none of what I stated there has changed, there are now updates to the "official" TechNet white papers for those who considered my blog post less that official. J

Many thanks to Scott McArthur and Dewitt Hurst of Microsoft Enterprise Platforms Support for initiating and then pushing the TechNet content owners to make these updates happen.

Here are links to the updated white papers. The notes on Service Pack 3 can be found in the Important section at the beginning of each page.

Deploying Microsoft Windows XP Tablet PC Edition 2005
Updated: January 21, 2009

Deploying Windows XP Tablet PC Edition 2005: Single-Image Deployment Supplemental Guide
Published: August 01, 2004 | Updated: January 21, 2009

This post was contributed by Michael Murgolo, a Senior Consultant with Microsoft Services - U.S. East Region.

Implementing the "Windows XP Tablet PC Edition 2005 Single-Image Deployment Supplemental Guide" Process in MDT 2008 - Full Update

DeploymentGuys — Sun, 03 Aug 2008 22:00:00 GMT

Since my original post on this topic back in May I have received a lot of useful feedback, encountered several issues with this process, and with help have found solutions for all of them. There is also important new information about Window XP Service Pack 3 and this process. Because of this I have decided to create this new post that is a full update so that all of this information can be found in one place. I will leave the original post up for a while for people who are still using the old scripts. However, I will be deleting the post content at some point.

Is this Really a "Single Image" Process?

Before I get into the details of this process, I want to address a topic that seems to frequently generate confusion when creating Sysprep images of Windows installations. Unfortunately the title chosen for the "Single Image" Guide does not help matters. Strictly speaking you cannot have a single image for Windows NT architecture operating systems before Windows Vista and Windows Server 2008 unless you have hardware on which Windows will use the same Hardware Abstraction Layer (or HAL) when Windows is installed from the installation media on that hardware.

The HAL is layer of software that hides (or abstracts) the details of the underlying hardware platform so that Windows services and applications do not have to deal with the hardware directly. They will make calls to the Windows API for generic resources or functions (memory, etc.) and calls will be made to the HAL which will then interact with the hardware to accomplish this. This makes it easier to write applications and operating system components. It also make it easier to port Windows itself to other hardware platforms.

Unfortunately for versions of Windows before Window Vista and Windows Server 2008, you cannot create an image on hardware of one HAL type and deploy it to hardware of another HAL type (with a few exceptions). Windows XP has six HAL types as follows:

Standard PC
MPS Uniprocessor
MPS Multiprocessor
Advanced Configuration and Power Interface (ACPI) PC
ACPI Uniprocessor
ACPI Multiprocessor

The two MPS HAL are compatible. Therefore, an MPS Uniprocessor image can be deployed to an MPS Multiprocessor computer. Likewise, an ACPI Uniprocessor image can be deployed to an ACPI Multiprocessor computer. So if you had hardware of all HAL types, you would need a minimum of four XP Sysprep images to support them. Luckily, nearly all modern computers are ACPI machines. So for current deployments, if you had computers of all three ACPI HAL types you would need two XP images:

Advanced Configuration and Power Interface (ACPI) PC HAL
ACPI Uniprocessor HAL

(The second image could in theory have the ACPI Multiprocessor HAL, but it if you deploy an ACPI Uniprocessor image of XP to ACPI Multiprocessor hardware, the HAL will change automatically. This does not happen the other way around.) For your reference, the HAL options for XP and Windows Server 2003 are documented in Microsoft Knowledge Base article 309283.

So the term "Single Image" process for converting XP Pro to Tablet PC Edition really should be called something like the "Convertible Image" process. It does not mean you will necessarily have only one one XP image to deploy.

(And even though Windows Vista and Windows Server 2008 no longer have this HAL dependency, you still need to have one image per PC architecture. For example, you would need one image for x86, one for x64, and one for IA-64 for each Windows Server 2008 SKU if you had machines of all three architectures.)

2008-08-05 Update - "HAL Swapping"
As you can see from a few of the comments below, there are people who are doing scripted changes of the HAL using either direct file replacements, using the Sysprep.inf answer file entries, or some combination of the two. Direct HAL file replacements are always unsupported by Microsoft. Any HAL replacement using the Sysprep.inf answer file entries using combinations not found in the About UpdateUPHal or About UpdateHal sections of Microsoft Knowledge Base article 309283 are also unsupported. While doing this may appear to "work", if issues occur later that impact your users ability to work that can be traced to unsupported HAL changes you may have a new expensive redeployment project on your hands. I am not speaking of a hypothetical situation here. This has happened to customers who have done this. The benefit of having a "single" image through HAL swapping is not worth the risk of possibly redeploying large numbers of machines.

Windows XP "Single Image" Process

For just about as long as there has been Windows XP Tablet PC Edition, there has been a guide on the Microsoft web site for the process of taking a Sysprep image of Windows XP Professional and "transforming" it at deploy time into Tablet PC Edition. This guide can currently be found here. A few years ago, I scripted this process for one customer's home-grown deployment framework. Last summer I ported this process over to BDD 2007 Lite Touch. Finally, several months ago, I moved this process over to MDT 2008 for both Lite Touch and Zero Touch (SCCM) deployment. In this post, I will review what needs to be done to prepare your Windows XP SP2 image to use this process and how to use the scripts (included in the Attachments link below) to implement this process with MDT LTI or MDT ZTI with SCCM. (Note: This will likely work with BDD 2007 and/or SMS 2003 OSD, but I haven't tested this. Let me know what happens if you try it by adding a comment to this post.)

To create an image with MDT that will support this process, you need to include the CMPNENTS folder from CD 2 of the Tablet PC Edition 2005 media in your Windows XP SP2 installation media. (Please see the Windows XP Service Pack 3 Considerations section below for information on how SP3 affects this process.) I will describe here how to do this with MDT Lite Touch. After adding the Window XP SP2 installation media as an Operating System in the Deployment Workbench, use Windows Explorer to open the Distribution folder. Copy the CMPNENTS folder from CD 2 of the Tablet PC Edition 2005 media into the Windows XP installation media folder at the same level as the i386 folder as shown in the figure below. (For those needing to create XP SP3 images see the Windows XP Service Pack 3 Considerations section below.)

Once you have XP SP2 added as an Operating System and have added the CMPNENTS folder to it, you can then use MDT Lite Touch to build and capture your Sysprep image. If you want to use an MDT Task Sequence in SCCM to build and capture your reference image, add the matching CMPNENTS folder to the Window XP SP2 installation media before importing it into SCCM as an Operating System Install Package. This will ensure that the MDT scripts will place the CMPNENTS folder in the C:\Windows\Source folder in the image. This is where the scripts expect to find it at deploy time. (If you need to use an existing Windows XP image with this process, you will need to make some changes to ensure that it will work with this process. See the section below for details.)

After your image has been updated in this manner, you must then update MDT. There are two parts to this process. The first part is determining whether the target computer is a Tablet PC and the second is executing the scripted changes to convert the OS to Tablet PC Edition if the target computer is a Tablet PC. There are a numbers of ways to determine whether the target computer is a Tablet PC. You could add a custom property to Make/Model detection called IsTablet (must have a value of True or False). If you are using CustomSettings.ini to store your Make/Model information, you would put a direct entry in the CustomSettings.ini Make/Models sections. If you are using the MDT database, you could add an IsTablet field to the MakeModelIdentity table, populate the IsTalbet field of the Make/Model rows with True or False, and add a database query to CustomSettings.ini to retrieve the IsTalbet field.

However, I took another approach that I find simpler to maintain. It involves detecting whether the target computer has Tablet digitizer hardware. I add a custom property to CustomSettings.ini called TabletPnpIds. In this property I placed a comma separated list of the Plug & Play Device ID's of the digitizer devices on all supported Tablet PC model. Then a user exit script uses this list to determine if the target computer is a Tablet PC and sets the IsTablet property accordingly.

To update MDT to use my entire process, use the following steps (respecting any change management process or change windows you have, of course). If you want to use your own method of setting IsTablet, then you can skip the Edit CustomSettings.ini for detecting Tablet PC hardware steps and implement you own method.

Add the Custom Scripts to the MDT Scripts: First, extract the scripts from the attached ZIP file and add them to either your LTI Scripts folder or your SCCM MDT File package. Be sure to update your MDT Files package and Distribution points in SCCM after doing this.
Edit CustomSettings.ini for Detecting Tablet PC Hardware: You will need to add the following to CustomSetting.ini to use my method of determining whether the target computer is a Tablet PC (additions in blue).

[Settings]
Priority=IsTabletCheck, Default
Properties=MyCustomProperty, TabletPnpIds, IsTablet

[IsTabletCheck]
TabletPnpIds=ACPI\WACF004,ACPI\WACF008,ACPI\MAI3310,ACPI\FUJ02E5
UserExit=ZTI-DetectHardwareExit.vbs
IsTablet=#DetectDevices("%TabletPnpIds%")#

Important Notes - Those of you that have used the scripts for this process from my original post, please notice that several things have changed:

The Plug & Play IDs used in the TabletPnpIds entry no longer need the trailing backslash. However, if you forget to remove them it will still work. I have put code in the new script to check for this and remove them from the variable in memory if found.
The name of the UserExit script has changed. The old script was called ZTI-DetectTabletExit.vbs. The new script, ZTI-DetectHardwareExit.vbs, was designed to allow general purpose hardware detection. See the section later in the post for details.
The name of the procedure called from the UserExit script has changed. The old one was called DetectTablet and it took no arguments. The new one, DetectDevices, takes the Plug & Play ID list as its input argument.

You will need to populate TabletPnpIds property with the digitizer Device ID's for your Tablet PC models. To determine the Plug & Play Device ID's of the digitizer devices, you will need one of each supported Tablet PC model with Windows XP SP2 or higher or Windows Vista already installed and the digitizer driver installed. On each PC, open Device Manager and find the entry for the digitizer device. This will likely be under the Human Interface Devices category and will likely have the word "Pen" or "Digitizer" in its name. Right click on the device and select Properties. On the Details tab, select Device Instance Id (or Device Instance Path on Vista) from the drop down list.

In the case of the "Wacom Penabled MiniDriver" shown above, the Device Instance Id is ACPI\WACF004\4&2F7DB942&0. The portion of this ID up to the last backslash, ACPI\WACF004, is the Device ID. The portion after the last backslash, 4&2F7DB942&0, is the Instance ID for this device. The Device ID is one of several hardware ID's embedded in the device by the manufacturer to be used for Plug & Play detection. The Instance ID is a unique identifier assigned to a particular device by Windows when it is detected. The Instance ID allows Windows to uniquely identify a device when there is more than one of the same device present in the system (for example, two of the same model network card). The part we are interested in is the Device ID. Put the Device IDs, excluding a trailing backslash, in the TabletPnpIds entry separated by commas.

You can also use ID's found under the Hardware Ids or Compatible Ids it you want to "generalize" the detection to a set of devices that share a common Hardware Id or Compatible Id. (The Device ID determined above should be the first Hardware ID listed) Items from these properties should be used as they appear in the dialog box (i.e. there is no Instance ID to remove).

The last two entries in the IsTabletCheck section tell the MDT Gather task to run ZTI-DetectHardwareExit.vbs and set the IsTablet custom property to the result of the DetectDevices function in the script.

Edit CustomSettings.ini for Setting the Tablet PC Edition Volume License Key: The next changes to CustomSetting.ini set a custom property called XPTabletProductKey to your Tablet PC Edition Volume License Key. If you do not have one and you are a Select License, Enterprise Agreement, and Enterprise Subscription Agreement customer, then see the Notes section in the Single Image Deployment Guide to obtain one.

Add the following changes to CustomSetting.ini so that XPTabletProductKey will have a value when IsTablet is true. Replace AAAAA-BBBBB-CCCCC-DDDDD-EEEEE with your Tablet PC Edition Volume License Key. (Additions for this part in green):

[Settings]
Priority=IsTabletCheck, ByTabletType, Default
Properties=MyCustomProperty, TabletPnpIds, IsTablet, XPTabletProductKey

[IsTabletCheck]
TabletPnpIds=ACPI\WACF004,ACPI\WACF008,ACPI\MAI3310,ACPI\FUJ02E5
UserExit=ZTI-DetectHardwareExit.vbs
IsTablet=#DetectDevices("%TabletPnpIds%")#

[ByTabletType]
Subsection=Tablet-%IsTablet%

[Tablet-True]
XPTabletProductKey=AAAAA-BBBBB-CCCCC-DDDDD-EEEEE

If you are using SCCM, remember to update your Settings Package with the updated CustomSetting.ini.
Edit the Task Sequence to Add a Step to Run ZTI-XPTabletSingleImage.wsf: The next step is to edit the Lite Touch or SCCM MDT Task Sequence to run ZTI-XPTabletSingleImage.wsf during the middle of the PostInstall phase. The picture below shows this for an SCCM MDT Task Sequence.

For an SCCM MDT Task Sequence, be sure to check the Package box and select your MDT Files package.
Import Digitizer Drivers: This should go without saying but you must import digitizer drivers into the Deployment Workbench for LTI or into the Drivers library and add them to Driver Package(s) for SCCM. The Single Image Deployment Guide shows how to extract the "in the box" digitizer drivers. But if you don't have any devices that need them, use the PC manufacturer's drivers instead. You do not need to place any drivers in the C:\Sysprep\i386\Digitizer folder as shown in the Guide. Use the Deployment Workbench Out-of-Box Drivers or SCCM Driver Packages to handle drivers instead.

That completes the setup. When you deploy this XP Task Sequence to a Tablet PC, your Windows XP Professional Image should magically transform into Windows XP Tablet PC Edition 2005. If you want to test this process and don't have any Tablet PC's handy or you want to test using Virtual Machines (Virtual PC, Virtual Server, Hyper-V, VMWare, etc.) then use the following trick. Pick a device on your target computer (it's not really important which one it is) and place it's Device ID, or one of it's Hardware Ids or Compatible Ids in the TabletPnpIds list. This will cause the IsTablet property to evaluate to True for this machine and it will result in Tablet PC Edition being installed on this non-Tablet computer.

Windows XP Service Pack 3 Considerations

-----Important Information!-----

In my post on May 22, I mentioned how I slipstreamed Service Pack 3 into an XP SP2 installation source that had the CMPNENTS folder from CD2 in the same location. Well, I have some good news and some bad news about this (unfortunately mostly bad). I can't go into any details about why what I'm about to write is the way it is or why I only just found out about this until an official knowledge Base article is released.

First the bad news. The teams involved in creating Service Pack 3 have decided that neither slipstreamed nor integrated media (i.e. what you would download from the volume licensing site) will be supported for Tablet PC Edition or Media Center components for Service Pack 3 (even though you can make the slipstream media successfully as I have shown). This is not currently documented publicly or anywhere that the Microsoft Services people would have found it. I would not have blogged about the slipstreaming process if I had know it was not going to be supported.

That means to create a supported installation of Windows XP Tablet PC Edition 2005 Service Pack 3, you have to do the following:

Install Tablet PC Edition from Service Pack 2 media
Then install the Service Pack 3 Update

What does that mean for the Single Image process? Since there is no supported way to obtain an SP3 version of the CMPNENTS folder, you cannot use an XP Pro SP3 image with the Single Image process. Therefore, to deploy XP SP3 and Table PC Edition you will have to do one of the following:

Deploy an XP Pro SP2 image (converting to Tablet PC Edition as needed) and update to SP3 as part of the task sequence
Deploy separate Pro and Tablet PC Edition SP3 images

Unfortunately, this greatly reduces the value of the Single Image process if you want to deploy XP SP3. In fact, my customer and I have decided that for their deployment we will deploy separate Pro and Tablet PC Edition SP3 images (at least until we decide whether a Design Changed Request has any chance of success). And it will actually have to be four images since they have hardware of both ACPI HAL types.

So you might ask "Could there possibly be good news about this?" Well, the good new is that in an upcoming post I will show you how to create a single WIM file that contains all four images with a single MDT Lite Touch Task Sequence (rerun four times). And I will show you how you can deploy these images from that WIM file onto the correct target hardware using either a single MDT Lite Touch Task Sequence or a single MDT Zero Touch Task Sequence in SCCM.

Using Windows XP Images that were not Built with MDT

If you build your Windows XP Professional image with an MDT Lite Touch Task Sequence, it will ensure that the following things are done so that the scripts for this process will work correctly:

Copy the Windows XP installation files (i386 folder) to C:\Windows\Source folder.
Copy the Tablet PC CMPNENTS folder (must be of the same Service Pack version as the Windows XP installation files) to C:\Windows\Source folder.
Set the SourcePath & ServicePackSourcePath Registry string values in HKLM\Software\Microsoft\Windows\CurrentVersion\Setup to point to C:\Windows\Source.

I recommend that you add these step to your image build process and then build and capture a new version of you image. However, if you have an existing Windows XP Professional SP2 WIM image, you can use ImageX to mount the WIM image, copy the required folders into the C:\Windows\Source folder, load the offline Software Registry hive, edit SourcePath & ServicePackSourcePath entries, unload the hive, and commit the changes. This WIM image will then be useable with this process. Since this is really a new "version" of your image, update any image version tattoo (Registry, file, etc.) in the image as well. (I don't usually recommend manually updating WIM files since it can lead to bad image version management habits)

Thanks to Rich Coulter of Pella Corporation for pointing out that I did not have enough detail in my original post on this topic and for finding the misspelling of the word Detect in the old ZTI-DetectTabletExit.vbs script name (ZTI-DectectTabletExit.vbs). I used copy and paste when using the script name, so the same misspelling was everywhere and it worked. Rich had the audacity to actually type the script name into his CustomSettings.ini, so it didn't work, of course. J

Issues with the .NET Framework

Another Microsoft Consultant (Barry Hartmann of MCS Federal, thanks Barry!) encountered an issue with this process if you have the .NET Framework installed in your Windows XP Professional image. The XP Pro to Tablet PC Edition conversion uses a rather unintelligent, brute force installation process to install .NET Framework 1.0 (which is required by some Tablet PC Edition components). If a newer version of the .NET Framework is installed in your image, this process will downgrade shared files and registry values. This essentially breaks the newer version of the .NET Framework.

Barry encountered this problem when he tried to install Project 2003 on a machine deployed with the "single image" process that had the .NET Framework 3.5 installed in the original XP Pro image. The Project installation fails with the .NET Framework in this state.

The one obvious solution (the one my customer has chosen) is to not include the .NET Framework in the XP Pro image. My customer will be installing .NET Framework 3.5 as an operating system specific post deployment item in the SCCM Task Sequence. The other thing that seems to correct this if the .NET Framework is in the image, according to Barry's testing, is to initiate a repair on the highest version of the core Framework installed (1.1 or 2.0) after the deployment/conversion process.

These blog posts referenced below contain the command lines you should be able to use to repair the .NET Framework 2.0 RTM and 2.0 SP1:

For 2.0 RTM - http://blogs.msdn.com/astebner/archive/2006/02/07/527219.aspx (the commands there are for uninstall, but if you leave off /u it will do a repair instead)
For 2.0 SP1 - http://blogs.msdn.com/astebner/archive/2008/02/19/7805444.aspx

Issues with Digitizer Drivers when Building the Reference Image in a Virtual Machine

While working with my current customer, we found that when we deployed XP to their Tablet PC models, we would see the OS convert to Tablet PC Edition just fine but the built-in keyboard, pointing devices, and digitizers would not work except for about one out of every 10 or 20 deployments. At that point we had added the INF based drivers for all these devices (that were not "in the box" drivers) to the SCCM driver packages. The devices would show up in Device Manager banged out as disabled with driver startup problems. We tried a whole bunch of things to correct the issue: disabling the Single Image conversion, changing driver versions, switching to using driver "installers" in the State Restore phase, running the driver "installers" from cmdlines.txt, etc. Nothing changed the outcome. Oddly enough, if we deleted the devices from Device Manager and restarted, Plug & Play would reinstall them and they would work fine.

We were about to point the finger at the PC and/or digitizer vendor when fortune smiled on us. Someone named Mark posted a comment to the original blog entry complaining of similar problem. Luckily, Mark was apparently smarter than I am because he used the Dependency Walker from the Support Tools on wacompen.sys on one of his tablets. It showed that hidclass.sys was missing. It turns out that when you build your image in a virtual machine (I was using Hyper-V and Mark was using VMWare ESX) without USB devices, the Human Interface Device (HID) drivers do not get installed (as they would when building on any modern physical machine). Since the Wacom digitizer drivers have a dependency on the HID drivers, the Wacom drivers fail to load during Minisetup and the devices are marked disabled.

The work around to this problem involves copying the HID driver files referenced in the Reinstall any missing files section of KB 315973 to C:\Windows\System32\Drivers during the image build. I have included a script, LTI-CopyXpHidDrivers.wsf, in the attachment below that can be used with the MDT Lite Touch Installation image build process. Run this script in the State Restore phase before Sysprep and image capture.

Many thanks got out to Mark for figuring this out. It would have taken us much longer to get around this blocker without your help.

Issues with the Win32_PnpEntity WMI Class

When I was testing the scripts original post with my customer we ran into an issue with the Lenovo X61 computers. Sometimes the computer would correctly convert to Tablet PC Edition and sometimes it would not. While I was investigating, I found that if we started a refresh from a running operating system, IsTablet would evaluate to True and the conversion would work fine. However, when I kicked off a bare metal installation by PXE booting into WinPE, IsTablet would evaluate to False and the conversion would not happen.

So I booted the machine with a generic WinPE 2.1 CD. The Lenovo X61 that we were testing with had the Wacom multi-touch digitizer device (DeviceID - WACF008). Since my script that looked for the digitizer PnP ID uses the Win32_PnpEntity WMI class, I decided to use the WMI Command Line (WMIC) to see if this device was reported by querying this class. When I issued the following command it returned No Instance(s) Available.

wmic path Win32_PnpEntity where (DeviceID like "ACPI\\WACF008\\%")

Running the same command in a full OS like XP or Vista returned the device information

I had added Devcon.exe from the Windows Server 2003 Support Tools to the WinPE CD. Devcon is a command line version of Device Manager and can be used to query and configure devices. Devcon uses the device management API to do this. Using the following Devcon command did return the digitizer.

X:\>devcon hwids ACPI\WAC*

ACPI\WACF008\4&32BDFEF7&0
    Hardware ID's:
        ACPI\WACF008
        *WACF008

So it turned out that the root cause appears to be a bug in the Win32_PnpEntity class in WMI when running in WinPE. I exchanged e-mails with Michael Niehaus of the MDT Team about this. It turns out that they had encountered this same problem with other devices as well. Because of this, they do not use this WMI class for device detection. They wrote their own utility (Microsoft.BDD.PnpEnum.exe) that uses the same API’s as Devcon to enumerate the HardwareID’s and CompatibleID’s for the devices in the machine and outputs this as XML. Look at ZTIDrivers.wsf to see an example of how to use it in an MDT script. So I rewrote my script (ZTI-DetectHardwareExit.vbs) to use their utility. It now work correctly 100% of the time.

Using ZTI-DetectHardwareExit.vbs for General Device(s) Detection in MDT

While I was rewriting the Tablet device detection script to use Microsoft.BDD.PnpEnum.exe I realized that the script could be used as a general purpose device detection script. You can define any set of Hardware Ids or Compatible Ids in one variable (comma separated list) and set a variable that will be set to True if any of the devices in the list are present. Just set a new custom variable to hold the PNP ID list (e.g. IntelGigabitNicPnpIds or NVidiaDisplayAdapterIds) and then set a variable for the returned result like this:

HasIntelGigabitNic = #DetectDevices("%IntelGigabitNicPnpIds%")#

Use the CustomSettings.ini section above as a guide.

Summary

So to sum up, if you follow the process as outlined in the first section and account for the .NET Framework issue and the HID driver issue when building images in a virtual machine you will be able to use this process successfully with Service Pack 2. Unfortunately, the lack of support for using this process with Service Pack 3 has greatly diminished it's usefulness.

Hopefully this post will be my final word on this topic. It would be nice to post about another topic. :-)

Please post comments with any feedback, suggestions, or issues.

This post was contributed by Michael Murgolo, a Senior Consultant with Microsoft Services - U.S. East Region.

Implementing the "Windows XP Tablet PC Edition 2005 Single-Image Deployment Supplemental Guide" Process - Important Update

DeploymentGuys — Thu, 12 Jun 2008 23:19:00 GMT

In my post on May 23rd, I described using this process with MDT 2008. Since that post, another Microsoft Consultant (Barry Hartmann of MCS Federal, thanks Barry!) encountered an issue with this process if you have the .NET Framework installed in your Windows XP Professional image. The XP Pro to Tablet PC Edition conversion uses a rather unintelligent, brute force installation process to install .NET Framework 1.0 (which is required by some Tablet PC Edition components). If a newer version of the .NET Framework is installed in your image, this process will downgrade shared files and registry values. This essentially breaks the newer version of the .NET Framework.

These blog posts referenced below contain the command lines you should be able to use to repair the .NET Framework 2.0 RTM and 2.0 SP1:

For 2.0 RTM - http://blogs.msdn.com/astebner/archive/2006/02/07/527219.aspx (the commands there are for uninstall, but if you leave off /u it will do a repair instead)
For 2.0 SP1 - http://blogs.msdn.com/astebner/archive/2008/02/19/7805444.aspx

Finally, a few fixes were made to one of the scripts from the May 23rd post. Barry discovered incorrect paths were written to files in certain SCCM deployment scenarios. The attachment with that post has been updated with the newer version.

This post was contributed by Michael Murgolo, a Senior Consultant with Microsoft Services - U.S. East Region.

Implementing the "Windows XP Tablet PC Edition 2005 Single-Image Deployment Supplemental Guide" Process in MDT 2008

DeploymentGuys — Fri, 23 May 2008 19:44:00 GMT

03 August 2008 - Important Update

The content in this post is obsolete. Please see my new August 3rd post for a complete update. I will leave this post up for a while for people who are still using the old scripts. However, I will be deleting the post content at some point.

For just about as long as there has been Windows XP Tablet PC Edition, there has been a guide on the Microsoft web site for the process of taking a image of Windows XP Professional and "transforming" it at deploy time into Tablet PC Edition. This guide can currently be found here. A few years ago, I scripted this process for one customer's home-grown deployment framework. Last summer I ported this process over to BDD 2007 Lite Touch. Finally, about a month ago, I moved this process over to MDT 2008 for both Lite Touch and Zero Touch (SCCM) deployment. In this post, I will review what needs to be done to prepare your Windows XP SP2 or SP3 image to use this process and how to use the scripts (included in the Attachments link below) to implement this process with MDT LTI or MDT ZTI with SCCM. (Note: This will likely work with BDD 2007 and/or SMS 2003 OSD, but I haven't tested this. Let me know what happens if you try it by adding a comment to this post.)

To create an image with MDT that will support this process, you need to include the CMPNENTS folder (of the same Service Pack version) from CD 2 of the Tablet PC Edition 2005 media in your Windows XP SP2/SP3 installation media. I will describe here how to do this with MDT Lite Touch. After adding the Window XP SP2 or SP3 installation media as an Operating System in the Deployment Workbench, use Windows Explorer to open the Distribution folder. Copy the CMPNENTS folder from CD 2 of the Tablet PC Edition 2005 media (must be from the matching Service Pack version) into the Windows XP installation media folder at the same level as the i386 folder as shown in the figure below.

Then use MDT Lite Touch to build and capture your image. If you want to use an MDT Task Sequence in SCCM to build and capture your reference image, add the matching CMPNENTS folder to the Window XP SP2 or SP3 installation media before importing it into SCCM as an Operating System Install Package. This will ensure that the MDT scripts will place the CMPNENTS folder in the \Windows\Source folder in the image. This is where the scripts expect to find it at deploy time. (I don't usually recommend doing the following since it can lead to bad image version management habits but if you have an existing Windows XP Professional SP2/SP3 WIM image, you can use ImageX to mount the WIM, copy the matching CMPNENTS folder into the \Windows\Source folder, and commit the changes. This WIM will then be useable with this process. Since this is really a new "version" of your image, update any image version tattoo (Registry, file, etc.) in the image as well. However, if you have already automated the image build with MDT, I recommend that you just rerun the image build and capture instead.)

After your image has been updated in this manner, you must then update MDT. There are two parts to this process. The first part is determining whether the target computer is a Tablet PC and the second is executing the scripted changes to convert the OS to Tablet PC Edition if the target computer is a Tablet PC. There are a numbers of ways to determine whether the target computer is a Tablet PC. You could add a custom property to Make/Model detection called IsTablet (must have a value of True or False). If you are using CustomSettings.ini to store your Make/Model information, you would put a direct entry in the CustomSettings.ini Make/Models sections. If you are using the MDT database, you could add an IsTablet field to the Settings table, populate the IsTalbet field of the Make/Model rows with True or False, and add a database query to CustomSettings.ini to retrieve the IsTalbet field.

However, I took another approach that I find simpler to maintain. It involves detecting whether the target computer has Tablet digitizer hardware. I add a custom property to CustomSettings.ini called TabletPnpIds. In this property I place a comma separated list of the Plug & Play Device ID's of the digitizer devices on all supported Tablet PC model. Then a user exit script uses this list to determine if the target computer is a Tablet PC and set the IsTablet property accordingly.

Add the Custom Scripts to the MDT Scripts: First, extract the two scripts from the attached ZIP file and add them to either your LTI Scripts folder or your SCCM MDT File package. Be sure to update your MDT Files package and Distribution points in SCCM after doing this.
Edit CustomSettings.ini for Detecting Tablet PC Hardware: You will need to add the following to CustomSetting.ini to use my method of determining whether the target computer is a Tablet PC (additions in blue).

[Settings]
Priority=IsTabletCheck, Default
Properties=MyCustomProperty, TabletPnpIds, IsTablet

[IsTabletCheck]
TabletPnpIds=ACPI\WACF004\,ACPI\WACF008\,ACPI\MAI3310\,ACPI\FUJ02E5\
UserExit=ZTI-DectectTabletExit.vbs
IsTablet=#DetectTabletPC#

You will need to populate TabletPnpIds property with the digitizer Device ID's for your Tablet PC models. To determine the Plug & Play Device ID's of the digitizer devices, you will need one of each supported Tablet PC model with Windows XP SP2 or higher or Windows Vista already installed and the digitizer driver installed. On each PC, open Device Manager and find the entry for the digitizer device. This will likely be under the Human Interface Devices category and will likely have the word "Pen" or "Digitizer" in its name. Right click on the device and select Properties. On the Details tab, select Device Instance Id (or Device Instance Path on Vista) from the drop down list.

In the case of the "Wacom Penabled MiniDriver" shown above, the Device Instance Id is ACPI\WACF004\4&2F7DB942&0. The portion of this ID up to the last backslash, ACPI\WACF004, is the Device ID. The portion after the last backslash, 4&2F7DB942&0, is the Instance ID for this device. The Device ID is one of several hardware ID's embedded in the device by the manufacturer to be used for Plug & Play detection. The Instance ID is a unique identifier assigned to a particular device by Windows when it is detected. The Instance ID allows Windows to uniquely identify a device when there is more than one of the same device present in the system (for example, two of the same model network card). The part we are interested in is the Device ID. Put the Device IDs, including a trailing backslash, in the TabletPnpIds entry separated by commas.

The last two entries in the IsTabletCheck section tell the MDT Gather task to run ZTI-DectectTabletExit.vbs and set the IsTablet custom property to the result of the DectectTabletPC function in the script.
Edit CustomSettings.ini for Setting the Tablet PC Edition Volume License Key: The next changes to CustomSetting.ini set a custom property called XPTabletProductKey to your Tablet PC Edition Volume License Key. If you do not have one and you are a Select License, Enterprise Agreement, and Enterprise Subscription Agreement customer, then see the Notes section in the Single Image Deployment Guide to obtain one.

Add the following changes to CustomSetting.ini so that XPTabletProductKey will have a value when IsTablet is true. Replace AAAAA-BBBBB-CCCCC-DDDDD-EEEEE with your Tablet PC Edition Volume License Key. (Additions for this part in green):

[Settings]
Priority=IsTabletCheck, ByTabletType, Default
Properties=MyCustomProperty, TabletPnpIds, IsTablet, XPTabletProductKey

[IsTabletCheck]
TabletPnpIds=ACPI\WACF004\,ACPI\WACF008\,ACPI\MAI3310\,ACPI\FUJ02E5\
UserExit=ZTI-DectectTabletExit.vbs
IsTablet=#DetectTabletPC#

[ByTabletType]
Subsection=Tablet-%IsTablet%

[Tablet-True]
XPTabletProductKey=AAAAA-BBBBB-CCCCC-DDDDD-EEEEE

If you are using SCCM, remember to update your Settings Package with the updated CustomSetting.ini.
Edit the Task Sequence to Add a Step to Run ZTI-XPTabletSingleImage.wsf: The next step is to edit the Lite Touch or SCCM MDT Task Sequence to run ZTI-XPTabletSingleImage.wsf during the middle of the PostInstall phase. The picture below shows this for an SCCM MDT Task Sequence.

For an SCCM MDT Task Sequence, be sure to check the Package box and select your MDT Files package.
Import Digitizer Drivers: This should go without saying but you must import digitizer drivers into the Deployment Workbench for LTI or into the Drivers library and add them to Driver Package(s) for SCCM. The Single Image Deployment Guide shows how to extract the "in the box" digitizer drivers. But if you don't have any devices that need them, use the PC manufacturer's drivers instead. You do not need to place any drivers in the C:\Sysprep\i386\Digitizer folder as shown in the Guide. Use the Deployment Workbench Out-of-Box Drivers or SCCM Driver Packages to handle drivers instead.

That completes the setup. When you deploy this XP Task Sequence to a Tablet PC, your Windows XP Professional Image should magically transform into Windows XP Tablet PC Edition 2005. If you want to test this process and don't have any Tablet PC's handy or you want to test using Virtual Machines (Virtual PC, Virtual Server, Hyper-V, VMWare, etc.) then use the following trick. Pick a device on your target computer (it's not really important which one it is) and place it's Device ID in the TabletPnpIds list. This will cause the IsTablet property to evaluate to True for this machine and it will result in Tablet PC Edition being installed on this non-Tablet computer.

12 June 2008 - Important Update

In this post, I described using this process with MDT 2008. Since that time, another Microsoft Consultant (Barry Hartmann of MCS Federal, thanks Barry!) encountered an issue with this process if you have the .NET Framework installed in your Windows XP Professional image. The XP Pro to Tablet PC Edition conversion uses a rather unintelligent, brute force installation process to install .NET Framework 1.0 (which is required by some Tablet PC Edition components). If a newer version of the .NET Framework is installed in your image, this process will downgrade shared files and registry values. This essentially breaks the newer version of the .NET Framework.

These blog posts referenced below contain the command lines you should be able to use to repair the .NET Framework 2.0 RTM and 2.0 SP1:

For 2.0 RTM - http://blogs.msdn.com/astebner/archive/2006/02/07/527219.aspx (the commands there are for uninstall, but if you leave off /u it will do a repair instead)
For 2.0 SP1 - http://blogs.msdn.com/astebner/archive/2008/02/19/7805444.aspx

Finally, a few fixes were made to one of the scripts. Barry discovered incorrect paths were written to files in certain SCCM deployment scenarios. The attachment has been updated with the newer version.

Please post comments with any feedback, suggestions, or issues.

This post was contributed by Michael Murgolo, a Senior Consultant with Microsoft Services - U.S. East Region.

Configuring default settings for Windows image deployment - Update for Windows XP SP3

DeploymentGuys — Thu, 22 May 2008 02:14:00 GMT

In my previous post on this topic, I mentioned that Windows XP Service Pack 2 will copy the Administrators settings to Default User (see sections B & C). The new profile copy is the default behavior in SP2 with no built-in way to disable it. To disable it you had to request the hotfix from KB887816 from Microsoft Customer Support.

This has changed with Windows XP Service Pack 3. The fix from KB887816 is included in SP3. (See KB946480 for a list of fixes included in SP3.) Therefore, the behavior for SP3 is no profile copy by default. To enable the profile copy, you now have to add UpdateServerProfileDirectory=1 to the [Unattended] section of Sysprep.inf before running Sysprep. Unfortunately, due to an oversight you will not find this documented in the Microsoft Windows Preinstallation Reference (ref.chm) included with the SP3 Deployment Tools. KB887816 is currently one of the only references for this setting, as far as I know. (KB908784 also references this setting with respect to a problem that the profile copy can cause on Windows Server 2003)

8/3/2008 Update

In this post I orginally provided some instrutions about slipstreaming SP 3 into an installation source with the Tablet PC Edition CMPNENTS folder in it. Well it turns out that slipstreaming SP3 into the CMPNENTS will not be supported. See my August 3rd post for details.

This post was contributed by Michael Murgolo, a Senior Consultant with Microsoft Services - U.S. East Region.