Building and Deploying XP Embedded Images

 

David Reed, John Macintyre, and Stephen Berard
Microsoft Corporation

June 2003

Applies to:
    Microsoft® Windows® XP Embedded with Service Pack 1

Summary

This white paper is a collection of documentation that will walk embedded developers through the various steps involved with building and deploying Windows XP Embedded with Service Pack 1 run-time images using the Windows Embedded Studio tools.

Topics covered include best practices in using the Target Analyzer Probe (TAP.exe) and Target Analyzer (TA.exe) applications, creating hardware macros in Component Designer, and using deployment technologies such as System Cloning, System Deployment Image (SDI), and PreBoot Execution Environment (PXE).

Contents

Getting Started
Best Practices for TAP.exe
How to Choose between TA.exe and TAP.exe
Creating a Hardware Macro
Building the Image
Configuring EWF
Configuring System Cloning
Image Deployment with SDI
PreBoot Execution Environment (PXE) Boot Image Deployment
Additional Resources

Getting Started

It all begins with TAP.exe and Windows Preinstallation Environment (WinPE). The best way to start a new Microsoft® Windows® XP Embedded configuration is to boot to a WinPE environment and run TAP.exe to generate a hardware profile for the target system. The first Windows XP Embedded with Service Pack 1 installation disc is a bootable WinPE image. You will be using this version of WinPE for this tutorial.

To use WinPE, make sure your target system's basic input/output system (BIOS) supports boot to CD-ROM. Configure the system's BIOS boot device order to boot to the CD-ROM first, then insert the first disc of the Windows XP Embedded with SP1 installation CD-ROM and restart the computer. When prompted by the system BIOS to boot from CD-ROM, do so to start the WinPE setup routine.

First, set up your bare metal computer with all of the peripherals you intend the final device to have. Next, insert Windows XP Embedded installation disc 1 into the CD-ROM drive of the target computer and boot to WinPE. When the computer is in the WinPE environment, navigate to the \XPE directory and run TAP.exe with the following parameters to save the devices.PMQ file to a floppy drive:

tap /O a:\Kiosk-HW.PMQ

TAP.exe will then produce a hardware profile (a .pmq file) of the target computer and save the results of the hardware query to a:\Kiosk-HW.PMQ file on drive A. Next, copy the Kiosk-HW.PMQ file to your development computer where you have installed the Windows XP Embedded Tools and Database.

Best Practices for TAP.exe

TAP,exe is a great tool to ease the Windows XP Embedded development process. However, as with any tool used in the development environment, the tool is only as good as the implementation it is used in. TAP.exe does an excellent job of finding all of the hardware in a system, but it often finds more devices than are required in the final embedded image.

In situations in which TAP.exe is run on a full desktop system (for example, Windows XP), TAP.exe will find all of the hardware and software components required to operate the system. TAP.exe will even find devices that were once installed in the system, but were later removed.

For this reason, it is very important that embedded developers using TAP.exe carefully review the results of an imported PMQ file for erroneous hardware to ensure that they do not include more hardware support than they really require in their final embedded image.

The best way to use TAP.exe is from within the WinPE environment. Running TAP.exe in the WinPE environment will usually result in a fairly minimal PMQ or hardware profile of the target system. One of the main reasons for this is that WinPE does not load Software Enumerated Devices (swenum) such as wide area network (WAN) miniports and the Kernel Audio subsystem, so the resulting PMQ file is smaller and easier to work with.

The following tables show the differences in the number of devices that TAP.exe will find on various environments:

Full Desktop environment  
Typical Windows XP Pro or Windows 2000 Desktop 65–75 devices
Typical Windows XP Pro or Windows 2000 Laptop 90–100 devices
WinPE Environment  
Typical Windows XP Pro or Windows 2000 Desktop 35–45 devices
Typical Windows XP Pro or Windows 2000 Laptop 45–55 devices

As you can see, running TAP.exe under the WinPE environment will yield the best results for creating a minimal configuration run-time image.

What devices does TAP.exe find in a WinPE environment? Just about everything you really need. It will find all of the core parent devices such as Peripheral Component Interconnect (PCI) and Accelerated Graphics Port (AGP) devices, the correct system hardware abstraction layer (HAL), disk drives and CD-ROM drives, system chipsets and critical boot devices required to start the system, and some basic universal serial bus (USB) device support.

How to Choose Between TA.exe and TAP.exe

Target Analyzer (TA.exe) is another tool you can use to query your target hardware and create a minimal footprint hardware profile, but TA.exe lacks the support needed to find many of the child devices present on most systems. This is because of how TA.exe works.

TA.exe only scans the PCI bus of the target system, and will only locate primary Parent devices it can find attached to the system's PCI bus, but TAP.exe scans the system's registry to obtain a list of detected devices.

TA.exe will only operate correctly in a Real Mode operating system (such as Microsoft MS DOS®); it has no way to load or scan a system's registry for devices. TAP.exe on the other hand, is supported only on Windows 2000, Windows XP, and Microsoft Windows Server™ 2003, and is not supported on any other Microsoft operating systems.

What child devices will TA.exe find? It will only find child devices such as PS/2 mouse devices and keyboards, and communication and printer ports. TA.exe will not find such devices as the system's disk drive, USB peripherals and hubs, floppy disk drives, and advanced configuration and power interface (ACPI) devices such as power buttons, fans, and thermal controls.

Running TA.exe on WinPE enables you to create an image faster than running TA on Windows XP, because WinPE does not report many devices that are indexed by Windows XP, and therefore gives you a smaller .pmq file. This behavior is similar to that of running TAP.exe on WinPE, as opposed to running it on Windows XP Pro, as stated previously.

A Note About ACPI HALs and TA.exe:

The critical ACPI component—Microsoft ACPI-Compliant System—will not usually be detected by TA.exe and will be missing from your configuration. Be sure to add this component to avoid crashes during First Boot Agent (FBA) setup. You can easily use Filter Manager (within Target Designer) to search for all components that have "ACPI" in their display name to easily locate most of the ACPI "stack."

Another critical ACPI component is the specific Integrated Drive Electronics (IDE) BUS Master Controller for the chipset that is on your target hardware. Missing or having the incorrect IDE BUS Master Controller will usually result in a bug check 7b message on the first boot of FBA setup.

Creating a Hardware Macro

This section demonstrates how to make a hardware macro (component) from a PMQ file in Component Designer. This is the first step in image building using the Windows Embedded Studio set of tools. After you complete this step, you will have a base operating system (OS) configuration that supports your target hardware. To do this, start Component Designer, and on the File menu, click Import. Use the Browse option to locate your PMQ file, and then click Next to continue.

Before beginning the import process, you can specify the name and path of a log file for the importer to generate during the import process. Having the import log will help troubleshoot undetected or unsupported devices that may require third-party driver support.

After an import log has been specified, start the PMQ import process. The device look-up procedure usually takes about 10 minutes, but when complete, the importer will produce a hardware macro component of your target hardware.

After the import process has completed, place focus on the new macro component, and view the main properties of the component. You will notice that Target Analyzer is listed as the component author in addition to the component owner. You can remove this if you want and place your own name in these fields so others in your organization can trace this component back to you if needed.

You can also edit the company name and copyright information with that of your company or project. The Description field is a great place to keep notes about the hardware macro; you can also add tidbits of information such as the computer's make and model number so you can keep track of these details.

To control the footprint, you can also do some device pruning of the imported devices before you save your hardware macro. If you are not a hardware expert, you can use the Reducing the Windows XP Embedded Run-time Image Size white paper on MSDN® to help remove unneeded hardware devices that may impact your final image.

To see what hardware components were found during the import process, click the Component node or the Group Dependencies node of your hardware macro, and walk through the devices found during the import process. If you do not require sound or modem support in your image, these devices should be on the top of your list to remove, if present. In addition, if your design will only need to support a PS/2 mouse and keyboard, you can remove all COM and LPT ports while pruning your macro. If you do not plan to support floppy disk or CD-ROM access in your final image, you can remove references to these devices as well.

This pruning will give you a smaller, more secure image, and will help keep your Windows XP Embedded image footprint to a minimum.

If you want the macro component to be configurable in Target Designer, you can add the Selector Prototype component as the prototype of your hardware macro. To do this, navigate to the main component properties page, and click the Browse button on the Prototype field. Navigate to the Software | Test & Development category in the database, select the Selector Prototype (R,1507) component, and then click OK to add this component as your prototype.

Now everything is ready to go, and the last thing you must do is release your component so it is in a final state.

  1. Right-click the Kiosk-HW component in the component browser, and then click Release component.
    You will be prompted that this action will set the component to a final revision.
  2. Click OK, save the SLD file, and close Component Designer.

The next step is to import the SLD file you created, so you need to launch Component Database Manager.

  1. After Component Database Manager is running, click Import on the main database tab.
  2. Browse to the location where you saved your SLD file and then select the SLD file for import.
    The import process should be fairly quick, and when it is complete, you can close Component Database Manager.

You are now ready to start the build process, and need to launch Target Designer and start a new SLX file.

  1. In the component browser window, you should see your Kiosk-HW component listed. Add this component to your configuration and then click the Settings node.
  2. A dynamic Hypertext Markup Language (DHTML) window will appear, which lists all of the components that your macro will include in your configuration.

Building the Image

Now that the hardware configuration is ready, you can start adding the Windows subsystem support you want to your image. You can start by adding the Runtime Quick Start Helper Macro. This component is in the Windows XP Embedded with SP1 database under the Software | Test & Development category. Add this component to your configuration and click its Settings node to see its configurable DHTML settings.

This "helper" macro will resolve the common component dependencies that users encounter when building a run-time image. You must make one modification to this macro if you want to include Enhanced Write Filter (EWF) support in your final image. Click the Settings node of the Helper Macro, and disable the option for Microsoft Windows NT® Loader so it is not added to the run-time image.

If you want Enhanced Write Filter (EWF) support in your image, you must add the EWF component. The EWF component has a component dependency on the version of Windows NT Loader required for EWF support, so you need only add this component to your image and you are ready to go.

You will also need to use the System Cloning tool to prepare your final image for mass distribution, so search for the System Cloning Tool—Hotfix Q810144 and add it to your configuration.

You also need to add networking support to the image, so you must include the Transmission Control Protocol/Internet Protocol (TCP/IP) with the Client For Microsoft Networks macro component.

Now that the hardware and software components are ready, you are ready to perform your first dependency check. The settings you want to configure for EWF and System Cloning will all be available after the first dependency check has completed. Additional settings for User Interface core (shell settings) and Administrator passwords will also need to be configured, so it is best to configure everything at one time.

Configuring EWF

After your dependency check has completed, you might want to include EWF support in your Windows XP Embedded runtime. EWF allows you to boot your OS from read-only media (such as flash or CD-ROM) or a write-protected hard drive. Before reading the next section, it is strongly recommended that you familiarize yourself with EWF and what it can do for your embedded design, so you can decide whether or not you need to implement EWF functionality. You can start with the EWF product documentation and Using the Enhanced Write Filter (EWF) in Windows XP Embedded.

Types of Overlays

There are two basic types of EWF overlays supported in Windows XP Embedded with SP1. First, there are disk-based overlays, which redirect all writes to a separate partition on a hard disk. The data stored on the overlay partition may be committed to the protected volume if desired. Multiple disk overlays can exist for a single volume, and they can be layered. This allows for the creation of several checkpoints of the disk. You can peel back overlay layers to restore to a previous view. This is controlled through the EWF Manager Application. Windows XP Embedded with SP1 supports up to nine overlays per volume.

The second type of overlay is a random access memory (RAM-based) overlay. RAM-based overlays redirect all writes to memory. In general, this data is lost when the computer is shut down or rebooted. Windows XP Embedded with SP1 has the ability to persist this data upon shutdown. However, if the computer is not properly shut down, the data will be lost. Only one RAM overlay may be configured per volume. Your selection of EWF overlay is dependent on the requirements of your device.

Configuring Disk-based Overlays

The following steps detail how to configure your image to support an EWF disk overlay:

  1. In Target Designer, add the Enhanced Write Filter component to your image. If you are protecting your boot volume, you will also need to include the EWF NTLDR component.
  2. Configure the settings for your device, selecting DISK as the overlay type.
  3. In the EWF Volume Configuration, select the number of protected volumes and overlay levels. Set the partition size according to the amount of space you want to have in the overlay. Make sure that you enter the disk and partition number for each of the protected volumes, and select the Start EWF Enabled check box.

For a description of all of the fields, see the Windows XP Embedded documentation.

Typical RAM Overlay Configuration

EWF Volume Configuration  
Maximum Number of Protected Volumes 1
Maximum Number of Overlay Levels 1
EWF Partition Size in KBytes 128,000
Start EWF Enabled Yes
Enable Lazy Write No
Disk Number 0
Partition Number 1
Disk Type IDE SCSI IDE
Overlay Type Disk
  1. Configure, build, and deploy your image to the device. You will need to partition your drive so that you have free space available in an extended partition on the drive; this will be used by EWF to store data in the disk overlay, so it needs to be sufficiently large to accommodate your data. For example, to have 100 megabytes (MB) of overlay available for your protected volumes, this partition would have to be at least 100 MB.

    Note   If an extended partition does not exist and you have fewer than four primary partitions, you will need to leave unpartitioned space on the drive.

  2. Boot your device. During FBA, EWF will configure itself based on the settings in the registry. It will create and format the EWF partition.

Configuring RAM-based Overlays

The following steps detail how to configure your image to support an EWF RAM overlay:

  1. In Target Designer, add the Enhanced Write Filter component to your image.

  2. Configure the settings for your device, setting the EWF partition size to 0 and selecting RAM as your overlay type.

  3. In the EWF Volume Configuration select the number of protected volumes.

  4. Set the number of overlay levels to 1 and the partition size to 0. Make sure you enter the disk and partition number for each of the protected volumes, and select the Start EWF Enabled check box. For a description of all of the fields, please consult the Windows XP Embedded documentation.

    Typical DISK Overlay Configuration

    EWF Volume Configuration  
    Maximum Number of Protected Volumes 1
    Maximum Number of Overlay Levels 1
    EWF Partition Size in KBytes 0
    Start EWF Enabled Yes
    Enable Lazy Write No
    Disk Number 0
    Partition Number 1
    Disk Type IDE SCSI IDE
    Overlay Type RAM
  5. Configure, build, and deploy your image to the device. You will need to partition your drive so that you have at least 32 KB of free space available in an extended partition on the drive (see footnote in previous section for more detail). This will be used by EWF to store configuration data for the RAM overlay between boots.

  6. Boot your device. During FBA, EWF will configure itself based on the settings in the registry. It will create a minimal EWF partition to store its configuration information.

For additional information about EWF, see Using the Enhanced Write Filter (EWF) in Windows XP Embedded.

Configuring System Cloning

There are many techniques you can use to deploy your Windows XP Embedded images. The method you choose is dependent on your embedded device requirements. The first method covered in this paper is System Cloning. The system cloning tool is required for mass deployment of a single image. The core feature of the System Cloning Tool is to generate a unique Security Identification (SID) for each computer you deploy. If you copied the same image to every device, every device would share the same computer SID. This presents a problem because every device running Windows XP Embedded is required to have a unique computer SID so it is uniquely identified on a network.

Note   It is strongly recommended that embedded developers download QFE — Q810144 for the System Cloning tool . This System Cloning QFE provides additional functionality currently not available in Windows XP Embedded with SP1.

The System Cloning component has configurable settings that will help you control which aspects of the image are altered as part of the cloning process. By default, if you do not configure the System Cloning component in Target Designer before you build your run-time image, the system cloning tool starts at phase 12000 of FBA setup, (prior to the final boot of setup | the first user login), and will reset the following system attributes:

  • Computer SID
  • Computer Name
  • Automatic Logon Settings
  • Domain Participation
  • Network Settings
  • User Specific Settings
  • Mounted Devices (substituted drive letters, etc.)

You configure the System Cloning component through its Advanced properties in Target Designer. The System Cloning component does not have configurable DHTML Settings, so users must edit the component through the Advanced properties option of the component.

The following are some of the common configurable settings you will find in the System Cloning Tool's advanced properties:

  • cmiResealPhase
  • cmiRemoveAutologon
  • cmiGenerateComputerName
  • cmiUnjoinDomain
  • cmiRemoveNetSettings
  • cmiRemoveUserSettings
  • cmiRemoveMountedDevices

The cmiResealPhase flag is one of the most important flags embedded developers need to consider. This flag will determine when the cloning process will start during the setup process. There are only two supported settings for the cmiResealPhase flag: 12000 and 0.

As described earlier, the default setting for the cmResealPhase flag is 12000. This setting will start the System Cloning tool (fbreseal.exe) at the very end of FBA setup, just prior to the first user login. When the System Cloning tool is started, it will prompt the user to shut down the system and distribute the image.

When a cloned image is distributed to a target system, the cloning process will initialize and reset the system SID and user accounts on the first boot of the client. The entire cloning process will occur on the first boot of the client. System Cloning will never start again on subsequent boots of the client, and it is not possible to reseal a system more than once. If you try to use fbreseal.exe on a previously cloned system, expect to see nothing but errors.

If the cmiResealPhase flag is set to 0, this tells FBA not to fire at any phase of setup, but to include the system cloning tool in the Windows XP Embedded image so it is ready to be used after FBA setup completes. This is a very useful setting if you plan to install or preconfigure your Windows XP Embedded image after FBA setup has completed, such as adding applications, joining a domain or adding third-party drivers.

After the image is completely configured and is ready for the cloning process, launch the fbreseal.exe utility from the \Windows\System32 directory. This will spawn the cloning process, and it will prompt the user to shut down the system and distribute the image. There are a number of command-line switches that fbreseal.exe supports:

  • -keepall
    When specified, keeps all settings listed below during cloning.
  • -keepdomain
    When specified, leaves the currently joined domain during cloning.
  • -keepnet
    When specified, leaves any network settings intact during cloning.
  • -keepuser
    When specified, keeps user specific settings intact during cloning.
  • -keepAutologon
  • When specified, preserves the Automatic Logon settings
  • -keepmounted
    When specified, keeps mounted drive and drive letter setting intact during cloning.

Example syntax: FBRESEAL -keepall

System Cloning Options:

  • cmiResealPhase (INT)
    Default setting is 12000.
    Set to 0 to not clone during FBA setup.
  • cmiRemoveAutologon (BOOLEAN)
    Set to TRUE to keep the Automatic Logon feature enabled after the cloning process.
  • Set to FALSE to remove Automatic Logon after the cloning process.
  • cmiGenerateComputerName (INT)
    Default setting is 1. This tells the cloning process to generate a random computer name for the client. Example: OEM-HUDVHELDDYQ
    Setting to 0 tells the cloning process to preserve the existing computer name.
  • cmiUnjoinDomain (BOOLEAN)
    Set to TRUE to leave the currently set domain during cloning.
    Set to FALSE to retain the domain membership after cloning.
  • cmiRemoveNetSettings (BOOLEAN)
    Set to TRUE to remove all network settings, including network bridges, during cloning.
    Set to FALSE to retain all network settings after cloning.
  • cmiRemoveUserSettings (BOOLEAN)
    Set to TRUE to remove all user specific settings, including start menu customizations and most recently used file lists, during cloning.
    Set to FALSE to retain all user specific setting after cloning.
  • cmiRemoveMountedDevices (BOOLEAN)
    Set to TRUE to remove all references to mounted drives, such as floppy or CD-ROMs, including changing drive letters, during cloning.
    Set to FALSE to retain mounted drive settings after cloning.
  • cmiUnjoinDomain (BOOLEAN)
    Set to TRUE to remove all references to mounted drives, such as floppy or CD-ROMs, including changing drive letters, during cloning.
    Set to FALSE to retain mounted drive settings after cloning.

For more information about System Cloning, see the Windows XP Embedded documentation.

Image Deployment with SDI

Overview

In addition to System Cloning, Windows XP Embedded includes the System Deployment Image (SDI) feature, which enables you to manage your run-time images. With SDI you can create file-backed virtual disk drives that can be used as a staging area for your run-time images. The SDI feature simulates a storage medium by using a disk image file (.sdi) that is located on an existing file system. SDI gives you another way to deploy your Windows XP Embedded images.

When you install Windows XP Embedded on your development system, SDI loader is installed. With this tool you can create, mount, and dismount file-backed virtual disk drives through a graphical user interface (GUI). The SDI Loader application is well documented in the Windows XP Embedded online documentation, and is fairly straightforward to use.

SDIMgr is a command-line tool that manages and manipulates SDI files. The utility SDIMgr.wsf can be found in the \Program Files\Windows Embedded\utilities directory after installing the Windows XP Embedded tools. In addition, the first Windows XP Embedded Installation disc of is a bootable WinPE image, and in the \XPE folder off the root of the disc you can find SDIMGR.wsf.

Actions processed by SDIMgr are controlled by command line switches. These switches can be listed anywhere on the SDIMgr command line by issuing the /Help switches. Most switches, however, are "command" switches that cause SDIMgr to process a command. These switches are processed in strict left-to-right order as they are entered on the command line. Use the "/cmdhelp" switch for detailed help on command switch syntax and operation.

Create a SDI Disk

This SDI disk will be used to deploy a pre-FBA image to the client hardware.

  1. Launch SDI Loader and select Add Disk.
  2. Choose a new sdi file name such as "PreFBA.sdi". Confirm that you would like to create the new file.
  3. Select the size of the disk that you would like to create.
  4. Use "Disk Manager" to initialize the new SDI disk as basic.
  5. Use "Disk Manager" to create a small primary boot partition. Select the appropriate file system, such as FAT or NTFS, and be sure to format the SDI disk.
  6. Use "Disk Manager" to mark the partition as active.

The PreFBA.SDI file is now ready to be used. At this stage, we can use the SDI disk as a virtual disk, and simply copy embedded run-time images into the SDI disk, or even build directly to the SDI disk from Target Designer. Once you are done with the SDI file, use SDI Loader to dismount the virtual SDI disk via the "Remove Disk" option. Once unloaded, PreFBA.SDI is simply a file, and can be easily moved and distributed.

Deploying the Pre-FBA Image

This section details how to move the built Windows XP Embedded runtime to the target device. There are numerous techniques and mechanisms that could be utilized to accomplish this. In this example, the image is deployed from a network share using a WinPE boot disc and SDIMgr.

  1. Ensure that the target device and development computer are networked.
  2. Create a share on the development computer with the name SDI. Make this share accessible to everyone, with read-only permissions. This is the share that is accessed from the target device.
  3. Copy "PreFBA.sdi" to the SDI share.
  4. Boot the target device using the WinPE boot disc (Windows XP Embedded with SP1 installation disc 1).
  5. On the target device, map a network drive to the share that was just created. For example:
net use z: \\mydevmachine\sdi

Depending on how security was configured on this share, you may have to provide user credentials.

  1. On the target device, use SDI Manager to lay down the pre-FBA image. Do this by typing the following at the command prompt:
sdimgr z:\PreFBA.sdi /writedisk:0 /yes
  1. This command will write the SDI disk to the target device. SDI Manager performs a sector based copy so tools such as fdisk and format are not required.
  2. After SDI Manager is complete (the command prompt returns), reboot the target device. Be sure to remove the WinPE boot disk before the system boots into the new Windows XP Embedded runtime.

Capturing the "Golden" Image

After the image has been customized, configured and resealed, it is necessary to capture this image so each target device does not have go through FBA or any of the manual customizations. The tool "SDI Manager" is used to capture the final Windows XP Embedded runtime. Because this is the image that will be applied to all the target devices, it is referred to as the "golden" image.

  1. Boot the target device with the WinPE boot disk.

  2. Map a network drive to the share that was just created. For example:

    net use z: \\mydevmachine\sdi
    
  3. Create a new SDI file by typing:

    sdimgr z:\golden.sdi /new
    

    This command reads the physical disk specified (by number) into a disk blob into the SDI file specified. For Example:

    sdimgr z:\golden.sdi /readdisk:0
    

The target volume is written to a SDI file on the network share. The image is ready for mass-deployment.

Useful SDIMgr commands and sample syntax:

/writepart:DEST

This command writes the contents of a PART (partition) blob to the specified destination. The destination must be a logical drive letter followed by a colon, for example "E:".

sdimgr DriveE.sdi /writepart:e: /yes

/readpart:SRC

This command reads the partition specified by a drive letter into a partition blob in the SDI file. For example:

sdimgr DriveF.sdi /readpart:f:

/dump

This command displays information about the SDI file specified, including fields in the SDI file header and information related to the blobs (binary blocks) stored in the SDI file.

/pack[:ALIGN]

This command repacks the SDI file. Free space within the SDI file is compacted, and blobs are realigned as necessary to meet the specified alignment. The default ALIGN value is 1, which corresponds to a 4 kilobyte (KB) alignment. Specify alternate alignments in units of 4 KB. For example, use 2 to specify an alignment of 8 KB. Most SDI files use a 4 KB alignment.

To obtain a list of all SDIMgr commands and switches, make your own help files from SDIMgr.wsf. Use the following two commands:

Sdimgr /help > SDIMgr_help.txt
Sdimgr /cmdhelp >> SDIMgr_help.txt

After they are complete, you should have an SDIMgr_help.txt file that contains SDIMGr's online Help system for your reference.

PreBoot Execution Environment (PXE) Boot Image Deployment

Yet another way you can deploy your Windows XP Embedded runtimes is by using PXE boot technologies. This section details a solution for Windows XP Embedded image deployment using Remote Installation Services (RIS), WinPE and the golden SDI image that was prepared in the previous section. There are two steps required to set up a Windows XP Embedded image deployment infrastructure. The first step is to configure a bootable version of WinPE to deploy SDI images. The second step is to configure RIS to boot the customized version of WinPE.

WinPE and the RIS server will only be used for initial image deployment. After an image has been deployed to the target device, the device should be able to perform self servicing without requiring WinPE or RIS.

This section details how to configure WinPE to deploy SDI disks to the target devices. WinPE will be utilized for the sole purpose of laying down an SDI image. For more information about WinPE, see Microsoft Windows Preinstallation Environment Overview.

Placing a Bootable Version of WinPE on a RIS Server

After WinPE has been customized to deploy the SDI disk image, the bootable version of WinPE must be placed on an RIS server. This provides target devices (with PXE support) with the ability to boot WinPE from the RIS server. WinPE will then deploy the SDI disk to the device. This paper does not detail the process of setting up an RIS server. For more information about how to set up and configure RIS, see the RIS Installation Guide.

Using WinPE on a RIS server requires the following:

  • A Windows XP product disc and a WinPE disc of the same build number.
  • A properly configured Windows 2000 with SP2 installation.
  • The destination computers must have a PXE-enabled network interface card (NIC), or have a NIC that is supported by the RIS boot disk.
  • Windows 2000 RIS Server

To install on a computer running Windows 2000 RIS server, deploy the hotfix referenced in KB article Q299541.

To create a RIS image and boot from it:

  1. On the RIS server, open a command prompt and run RISetup.exe –add.
  2. When prompted for a source, point RISetup to the Windows XP product disc.
  3. Browse to the location where RISetup installed the image, such as: \\Server_name\Share_name\REMINST\Setup\Language\Images.
  4. Open the I386 folder in the folder of the image that was just created.
  5. Browse the Windows XP Embedded Service Pack 1 disc, which contains the WinPE files, and open the I386 folder.
  6. Copy the contents of the WinPE I386 folder into the Remote Install I386 folder that was just opened, overwriting all files if prompted.
  7. Open the Templates folder in the I386 folder that you just copied over.
  8. Open the RIStndrd.sif file in a text editor, and on the line that starts with OSLoadOptions, add the switch /minint.
  9. Copy sdimgr.wsf from the Windows XP Embedded folder on Windows XP Embedded disc 1 to the WINPE I386\System32 folder.

Start a RIS client, and select the operating system image that was created in Step 1. WinPE starts.
To automate the process of laying down the SDI disk (gold.sdi), modify startnet.cmd in the I386\System32 directory.

Additional Resources

For more information about Windows XP Embedded, see Windows XP Embedded home page.

For online documentation and context-sensitive Help included with Windows XP Embedded, see Windows XP Embedded product documentation.

© Microsoft Corporation. All rights reserved.