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

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.

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 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).

    Priority=IsTabletCheck, Default
    Properties=MyCustomProperty, TabletPnpIds, IsTablet


    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.

    DeviceMgr    DeviceID

    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):

    Priority=IsTabletCheck, ByTabletType, Default
    Properties=MyCustomProperty, TabletPnpIds, IsTablet, XPTabletProductKey




    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. 

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:

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.

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.

MDT XP Pro-Tablet Single

Comments (30)
  1. DeploymentGuys says:


    From watching Task Manager it looks like the Windows File Protection scan happens as a thread in the Winlogon process, so you can’t watch for the exit of a process to see if the scan is done.

    However, running sfc /scannow while running XP in a Hyper-V VM did not copy the HID files to the C:WindowsSystem32Drivers.

    So for testing, I simply expanded the three files from the XP source, mounted the existing WIM, and copied the files into the C:WindowsSystem32Drivers.  Just doing that solved the problem.  I was going to see if scripting the same thing into the build process is sufficient.

    Michael Murgolo

  2. DeploymentGuys says:

    Jeff C,

    At what service pack level is your installation media?  Are you installing the .NET Framework in your image?  Have you read the August 3 updated post on this topic?  Have you dug through the setup*.log files in the Windows directory for errors?

    Michael Murgolo

  3. DeploymentGuys says:


    Simply changing the product key does not enable the tablet feature.  The process must also perform the tasks done by ZTI-XPTabletSingleImage.wsf.  And these tasks should only be done on Tablet hardware.  If you want to use my solution, you need to set IsTablet to True on only Tablet hardware (which you can do by make/model if you want).

    Michael Murgolo

  4. DeploymentGuys says:


    This will be no different that any other driver type and will vary by manufacturer.  Some post them as Zip files.  Others have self extracting EXE’s.  Some have installers that have an “extract” command line switch.  Others include them are part of a sofware installation.  It’s all over the map.

    As far as the drivers that can be expanded from CD1 of the Tablet media, those are fairly old.  You will likely be able to get newer, better matched drivers from the manufacturer.

    Michael Murgolo

  5. Anonymous says:


    At what point do you get this error?  Have you added the CMPNENTS and I386 folders to c:windowssource directory?  Also, you will need to mount your image and load the software hive and make changes to ServicePackSourcePath & SourcePath.  Both will need to point to c:windowssource.

    The above only applies if you did not build your WIM from MDT.  



  6. DeploymentGuys says:

    Rich – I posted about some XP SP3 considerations here:

    Fred – It appears you are trying to use these scripts with an unattended installation from the source media.  This process can only be used with a Syprepped image deployment of XP.

    Michael Murgolo

  7. DeploymentGuys says:


    Yes, we have see this issue with the .NET Framework.  I actually have a draft of post on this topic.  I’ll try to finish it today.

    Michael Murgolo

  8. DeploymentGuys says:


    Thanks for posting the questions and the solution.  This appears to be solving the problem we’ve been seeing with the Lenovo tablets at my customer.  I built the image in Hyper-V and those files were missing.

    I’m so glad that we started this blog and that I’d blogged this topic.  It would have taken a lot longer to figure this out.  🙂

    Michael Murgolo

  9. DeploymentGuys says:

    Jeff C,

    The process described here is not intended for use with an unattended installation.  If is for use with a Sysprep image deployment of XP Professional.

    Michael Murgolo

  10. Rich says:

    Hi Michael,

    Excellent write up!  After reviewing this, I only have one question regarding setup for MDT 2008 LTI.

    I currently only use out of box drivers for Network and Mass Storage Device drivers.  Is there a way to install the Digitizer drivers dynamically using DriversPaths in the CS.ini?



  11. Hi Rich,

    It will depend on the hardware manufacturer, but as long as the digitizer drivers are "NICE" drivers (see Ben’s post – then you should be able to user DriverPaths as well.


  12. Rich says:

    Hi Mike,

    Is this the process for extracting the appropriate drivers that we need to import into the Deployment Workbench?

    To add the drivers for the Human Interface Device (HID) Digitizer Display to the Digitizer directory, you must first extract the files from the i386 directory on CD1 of the Windows XP Tablet PC Edition 2005 media set. To extract the files, type the following commands at a command prompt:

    expand d:i386hiddigi.in_ c:sysprepi386digitizerhiddigi.inf

    expand d:i386mutohpen.sy_ c:sysprepi386digitizermutohpen.sys

    expand d:i386serial.sy_ c:sysprepi386digitizerserial.sys

    expand d:i386wacompen.sy_ c:sysprepi386digitizerwacompen.sys



  13. Rich says:

    Hi Mike,

    I forgot to ask this.  What is the process for extracting the digitizer drivers for the hardware manufacturer?



  14. dustin says:

    TABLET Edition .net framework issues

    Have you run into any of the known issues with the tablet/media center edition .net frameworks causing issues post install?

    I’ve laid this framework out numerous times and the components actually install as necessary on only the tablet pc’s, all works as normal. But the .net framework causes some major problems – the GAC is corrupted from the tablet OCM install of .net and i am unable to install any application that makes use of certain .net framework assemblies (MS office, visual studio, etc, even the .net framework service packs won’t reinstall).

    Looking for a hopeful solution to this.


  15. Mark says:

    I have set this up on an XP build without installing the .Net Framework. My tablets use the in-the-box digitizer, and I have extracted it and added it to my driver files for the tablet. But when it installs the image XP gets a Yellow bang on the driver (it installs but does not work properly). I am using Fujitsu tablets. Has anyone seen this behavior?

  16. Barry Hartmann says:

    The driver bang you are seeing is most likely coming from one of the Fujitsu system devices.  The "driver" software is embedded within the Fujitsu Button Software or the Fujitsu System Extension software.  You have to extract the driver after installing on a reference machine.  What is the PnP ID of the device showing the problem?

  17. Mark says:

    I have discovered the source of my problem. My image does not have hidclass.sys installed. Any thoughts on how to get this driver to install?

  18. Barry Hartmann says:

    Please post the PnP IDs of problem devices.  How did you determine that your problem was with the hidclass.sys.

  19. Barry Hartmann says:

    Also, what model of Fujitsu Tablet are we talking about?

  20. Mark says:

    Actually, the problem was not with the Fujitsu’s but with the machine I was building my image. I was using VMWare ESX to build my image, and since it did not have any USB devices the drivers did not get installed into the image. That said Windows should install them – one would think. I did find a solution – (see the section about Reinstall any missing files). Basically, I scripted this process in my build task sequence, and I have resolved the issue.

  21. Mark says:

    I determine the problem by using Dependancy Walker from the Support Tools on wacompen.sys on one of the tablets. It showed that hidclass.sys was missing. The three drivers referenced in were all missing

  22. Mark says:

    To be quite honest, I had tried to do this about 3 months ago and gave up. Just to let you know when you run sfc /scannow there is no wait to wait on the task directly, so I just put in a sleep. I am going to look and see if I can write a vb script to see when the window exits.

  23. Mark says:

    I have found that the SFC scan did not replace the files either. Here is my command file that I am using – it is in the script directory with the sleep.exe program from the resource kit –

    pushd %0..

    rem expand c:windowssourcei386hidir.sy_ c:windowssystem32drivershidir.sys

    expand c:windowssourcei386hidusb.sy_ c:windowssystem32drivershidusb.sys

    expand c:windowssourcei386hidparse.sy_ c:windowssystem32drivershidparse.sys

    expand c:windowssourcei386hidclass.sy_ c:windowssystem32drivershidclass.sys

    sfc /scannow

    sleep.exe 720


  24. Rich says:

    Hi Mike,

    This process is solid and might I be the first to say that I have this working in my environment.  The XP Pro to Tablet conversion is simply GREAT.

    Thanks for helping us streamline our deployment process.  As always, you "guys" provide the best information out there on OS Deployment.



  25. Rich says:

    Hi Mike,

    One question I have is does this process work when I upgrade my current image to XP SP3?  Is there anything I need to change on the Master Image to support this process?



  26. fred says:

    I’ve tried this but am getting a ZTI ERROR "the Tablet PC Edition components (c:$win_nt$.~btsourcecmpnents) are missing". Any clue as to what I am missing?

  27. Greg Lambert says:

    In MDT I have XP SP2 as OS and then added the CMPNENTS for TabletPC.  I then integrated SP3.

    During deployment my objective is to have make & model set the product key for tablets thereby enabling the tablet features.

    In the first testbed (tablet) this works as expected, however, testing an non-tablet deployment results in a product key prompt that will not accept the XP key.  Only the TabletPC key is accepted and the on display keyboard is visible identifying tablet components are loading.

    Any ideas?

  28. D. Ruhle says:

    If anyone has installed the Windows XP command console (c:cmdcons) on their captured image it will break the windows folder detection logic within zti-xptabletsingleimage.wsf.

    The script locates the windows folder by finding the first folder on the drive that contains a "system32" folder, which in my case is c:cmdcons as it also contains a system32 folder.

    This is easy to fix – just modify the wsf script to look for "sourcecmpnents" instead of "system32" on line 137 and you should be okay:

    If oFSO.FolderExists(sDir & "sourcecmpnents") then

  29. Jeff C says:

    I tried this on a Dell GX-745 and an HP tablet TC4400.  I loaded XP into MDT along with the various latest drivers for these models from HP and Dell. I had no issues whatsoever on the Dell desktop–it loads XP and some apps and customization scripts. The tablet PC, however, never gets that far.  It copys the files to c:minint, says it is performing the Unattended installation, runs ZTI-XPTabletSingleImage.wsf, does the next few phases, reboots.  It then starts Windows Setup and goes to a BSOD.  I thought it might be the UBERBUG but that fix didn’t help so I’m open for ideas.  

  30. Jeff C says:

    turns out my first issue was a HAL one.  I’m beyond it now and got my sysprepped image working with the HP Tablets.  We recently pulled out another tablet (DRS Hammerhead) and I built my image on it to make sure we wouldnt have a HAL Issue, sysprepped and captured it.  I deploy it, it converts it to XP Tablet, but the onboard keyboard is just a big blue box.  Other than that, it works great.  Think this is a .NET frame issue?  I did install every patch I could find before capture.  Is there a quick fix or am I back to square one?

Comments are closed.

Skip to main content