Module 4: Building and Deploying an Operating System Image

Transcription

1 Module 4: Building and Deploying an Operating System Image Contents Overview...1 Deployment Overview...2 Build Process...4 Preparing Target Media...18 Deploying the Operating System...28 Lab 4: Deploying an Operating System Image (Part 1)...48 Review...65 Module 4: Building and Deploying an Operating System Image

2 Information in this document, including URL and other Internet Web site references, is subject to change without notice. Unless otherwise noted, the example companies, organizations, products, domain names, addresses, logos, people, places, and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, address, logo, person, places or events is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation. Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property Microsoft Corporation. All rights reserved. Microsoft, MS-DOS, Windows, Windows NT, Visual Studio are either registered trademarks or trademarks of Microsoft Corporation in the U.S.A. and/or other countries. The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

3 Module 4: Building and Deploying an Operating System Image 1 Overview Deployment Overview Build Process Preparing Target Media Deployment Methods In this module, you will learn about the build options. You will learn about the steps involved in preparing for deploying Windows XP embedded system to a target device. You will also learn how to prepare target media to boot XP Embedded, transfer the operating system image and deploy to udiskonchip and CD-ROM. After completing this module, you will be able to: Explain the Windows XP Embedded build options. Identify the steps involved in preparing for deploying a Windows XP embedded system to a target device. Identify how to prepare Target Media to boot Windows XP Embedded. Deploy an XP Embedded operating system image.

4 2 Module 4: Building and Deploying an Operating System Image Deployment Overview Target Designer Rebuild OS Image OS Image SDI Image Deployment Server Remote Install and /or Clone, (WinPE/SDI, SDI2HD, Remote Recover, CD-ROM Boot) Remote Boot Remote Install & Clone (WinPE/SDI, SDI2HD) QFE, DUA,or Patch Post to Web Device Update Agent, SMS, and SUS Update Server Remote Copy There are three steps to deploy an XPe image: Build the operating system. Prepare the target media. Deploy the operating system. The last step, deployment, will be dependent on the type of target and target media to which you are trying to deploy. XPe supports several boot media types and comes with several technologies to deploy the operating systems. Deployment is not limited to the initial installation of the operating system. System updates are also critical to the life of an embedded system. XPe SP1 introduced Device Update Agent, which can update an entire OS image or perform an incremental update for a device driver or application.

5 Module 4: Building and Deploying an Operating System Image 3 Deployment Overview Storage Device Image (SDI) First boot agent Image cloning and reseal Remote boot Device update agent CD-boot WinPE Technology OS Image format and supporting tools Configuring and phasing online tasks Mass deployment of near identical images Allows booting from server via PXE Light-weight servicing client El Torito implementation uses read-only media for system Bootable XP Installation platform Deployment Device servicing Windows XP Embedded comes with a number of deployment and device servicing technologies. The technologies are combined together to support different deployment and servicing scenarios. There are also 3 rd party applications that can help with deployment.

6 4 Module 4: Building and Deploying an Operating System Image Build Process Build Options First Boot Agent (FBA) System Cloning Preparing to deploy an XP Embedded system on a device can be categorized into three steps: Build Operating System Image. First Boot Agent (FBA). System Cloning.

7 Module 4: Building and Deploying an Operating System Image 5 Build Options When building an XP Embedded image, Target Designer can build: Debug Build or Release Build Test Build When building an operating system image to deploy, the following steps must occur: Stamping - Provide necessary licensing information Windows Product Activation (WPA) Microsoft Licensing binding an operating system to hardware When building an XP Embedded image, Target Designer can build either a debug or a release build of the operating system. If you are building an image for testing purposes, it is not necessary to license the operating system by default test builds are created. If building an operating system image to deploy, it is necessary to stamp a build. Stamping is the process of providing the necessary licensing information to Target Designer before building the operating system. Windows Product Activation (WPA) is designed to reduce software piracy. The Windows Product Activation technology infrastructure, an integral aspect of the Windows XP Embedded system architecture, is included in each run-time image you create. Activation is designed to authenticate and activate the software package. This process does not require any personally identifiable information to be provided by the user.

8 6 Module 4: Building and Deploying an Operating System Image Debug vs. Release Build Release Build Free Build End-user version of operating system Debug Build Checked Build Debug information for operating system and kernelmode drivers Used to debug kernel-mode drivers When building an XP Embedded system, typically a release build is selected. A release build is also used when debugging applications. Each build can be specified as debug or release. A release build constructs a run-time image ready for manufacturing deployment. A debug build constructs a run-time image that includes special debug versions of files (where available) that can assist in application debugging and validation. Debug run-time images should never be deployed outside the development environment. To build a Release version of the run-time image: 1. In Target Designer, on the Configuration menu, click Build Target Image. 2. In the Build type box, click Release. To build a Debug version of the run-time image: 1. In Target Designer, on the Configuration menu, click Build Target Image. 2. In the Build type box, click Debug. Note: The database doesn t come with a full set of Debug components so a debug image will not boot properly. You should perform any low level driver debug using XP Pro.

9 Module 4: Building and Deploying an Operating System Image 7 Test Builds days test build Blue Screen after days STOP message during boot (Blue-Screen) Synchronize the real-time clocks on both development machines and target devices to prevent an XP Embedded operating system from expiring Target Designer creates test builds of XP Embedded. These are unlicensed builds of the operating system, intended to be used for testing purposes. Test builds run for days. After the test build period, you encounter a blue screen during the boot process, the system will not boot, and a STOP message will occur. It is important to synchronize the real-time clocks on the development machines and the target devices. This will prevent an XP Embedded operating system from expiring prematurely due to differences in system clocks.

10 8 Module 4: Building and Deploying an Operating System Image Stamping and Activation Windows Product Activation (WPA) is included in each run-time image Windows XP Embedded does not allow online product activation Test build unless valid Product ID (PID) If you enter a run-time product ID (PID) in Target Designer, the run-time does not expire You use PIDs: When you install the Windows Embedded Studio tools and component database. When you build your run-time image. You may not interchange PIDs Network is not required By default, Target Designer generates a run-time image that expires within days after the first boot. However, after you enter a run-time product ID (PID) in Target Designer, the run-time generated by Target Designer does not expire. Therefore, the Windows XP Embedded WPA infrastructure does not require enduser interaction. Windows XP Embedded product activation differs from standard Windows XP Professional in that it does not require online product activation. Rather, a run-time image of Windows XP Embedded is activated with a runtime product key in Target Designer before it is deployed. You use different PIDs when you install the Windows Embedded Studio tools and component database than you use when you build your run-time image. You may not interchange these PIDs. There are three types of product keys associated with Windows XP Embedded: tools product key. runtime product key. evaluation kit product key. A tools product key is a 25-character key that is required to install the Windows XP Embedded tools. The tools product key is included on the orange Product Key sticker on the back of your Windows XP Embedded media package. A runtime product key is a 25-character key that is used to activate a Windows XP Embedded run-time image. This key is added to your Windows XP Embedded configuration in Target Designer. Once runtimes are licensed by signing an OEM agreement with Microsoft, runtime product keys will be provided on a Microsoft Certificate of Authenticity (COA) sticker, which can be purchased from a Microsoft

11 Module 4: Building and Deploying an Operating System Image 9 Authorized Distributor (if you purchase from a distributor) or an Authorized Replicator (if you license directly from Microsoft Licensing Inc.). Note: Only runtime images built using the full Windows XP Embedded product accept a runtime product key. Runtime images built using an evaluation version of Windows XP Embedded cannot be activated. One unique runtime product key is provided on each Microsoft COA sticker, and one COA sticker is provided per runtime license. However, only one runtime product key is required to activate a run-time image, per device model/category. For example, a point-of-sale device requires a separate runtime product key from a set-top box. But 100 identical point-of-sale devices only require one product key. To activate a run-time image 1. Run Target Designer. 2. Choose Settings under your configuration. 3. Choose Run-time Image Licensing. 4. Under Run-time Image Licensing, choose Show. 5. In the Product Identification Key (PID) box, enter in the runtime product key for your run-time image. Evaluation product keys are only for evaluation versions of Windows XP Embedded and can be obtained from the Windows Embedded Evaluation Kit Registration Site, located at Evaluation versions ordered from Microsoft include the evaluation product key with the order confirmation. Note: The product key is not the Product ID (PID). The PID is used when contacting Microsoft Product Support Services. Licensing Q&A: Q: Do XP Embedded images require Product Activation, like my desktops? A: No, instead they require a product key in Target Designer when the image is being built. Q: What comes with each runtime image license? A: A COA sticker that displays a product key, unique for each license. Q: The sticker has two numbers. Which one is the product key? A: The product key has a picture of a key next to it. Q: Must each image use a unique product key? A: No, one product key (entered in the Target Designer build process) will work for all devices, in a single device model/category. Q: Can I convert a test build to a release build? A: No, the stamping and activation process is done at image build time. To produce a stamped release requires the image to be rebuilt with the runtime product key entered into Target Designer.

12 10 Module 4: Building and Deploying an Operating System Image Q: Which key do I enter into the Target Designer Product Identification Key field? A: Any one of the keys will work.

13 Module 4: Building and Deploying an Operating System Image 11 Build Operating System Image Target Designer: Initializes components Moves Files from Repository to Destination Creates Registry and dumps hive files to Destination: %SystemRoot%\Sy stem32\config Once an XP Embedded configuration contains all necessary components, the final step is to build the operating system image. Target Designer copies all files referenced by included components into the destination directory. Typically, the destination directory is a folder; in which case the operating system files would then be transferred onto the target media. In addition, Target Designer merges all component registry keys, and copies the registry resources into the target directory. Registry keys are stored in hive files which are located in the target directory under %SystemRoot%\System32\config. To build a run-time image: 1. On the Configuration menu, click Build Target Image. 2. In the Build type box, click either Release or Debug. 3. In the Destination box, type the full path where you want to store the runtime image. If an image already exists in the same folder, it is overwritten when you build the new image. 4. In the Log file box, type the full path and file name for the log file. 5. Click Build.

14 12 Module 4: Building and Deploying an Operating System Image Build Process after Deployment Target Designer builds the raw image Build Process is completed after image is deployed FBA First Boot Agent completes the build process Cloning Process to duplicate image and insure OS security features Target Designer builds the raw system image. The build process copies the files for each component to the specified run-time image directory and creates the necessary directory structure. Components are processed in an order that complies with their build order dependencies. The build process also creates the registry hives and any other subsidiary files that might be required by the OS. This raw system image is not ready to run as it is. PnP devices need to be installed for the image to run. On the first boot of the raw system, First Boot Agent runs to complete the build process. First Boot Agent performs any run-time tasks that could not be performed offline with the development tools. Currently, these tasks include security installation, catalog registration, Plug and Play detection, network configuration, dynamic-link library (DLL) registration, and profile initialization. XPe supports cloning of the operating system through the use of the System Cloning Tool component, which provides a mechanism for creating cloned images from a build with security identification information that is unique for each cloned image

15 Module 4: Building and Deploying an Operating System Image 13 First Boot Agent (FBA) Executes the first time the system boots Configures and initializes the operating system Resources are automatically added to a configuration Installs: Plug and Play devices Networking Support Registry Hives The XP Embedded operating system is not functional until the FBA successfully executes The First Boot Agent (FBA) executes the first time the system boots. Its role is to configure and initialize the operating system. Its resources are automatically added to a configuration. The FBA performs many of the same steps performed by the Windows XP installer such as: Security installation. Plug and Play device detection. Network configuration. Dynamic link-library (DLL) registration. Constructs registry hive files. The XP Embedded operating system is not functional until the First Boot Agent successfully executes. Because the First Boot Agent performs Plug and Play detection, it is important that the hardware on which the operating system is first run is identical to the hardware on which the system will be deployed.

16 14 Module 4: Building and Deploying an Operating System Image System Cloning Security ID (SID) All Windows (NT/2000/XP/XPe) Systems required to have a unique SID Used in Windows Networking (Workgroup environments) Used by NTFS permissions XP Embedded Solution: System Cloning Tool Component Every Windows XP Embedded operating system is required to have a unique Security ID (SID). SID is a unique identifier used to identify a user or group of users that exist on a particular computer or in a particular domain. SID plays an important role in Windows networking, as well as, other operating system areas which relate to users such as, disks formatted with NTFS using file permissions. Typically, SID is generated during the installation of Windows XP. However, since you are building the operating system manually, this step must be manually included. Windows XP Embedded provides a System Cloning Tool component which handles the SID issue.

17 Module 4: Building and Deploying an Operating System Image 15 System Cloning Component Generates a new SID for a system Two Phases: Reseal Phase Last phase of the FBA process Cloning Phase First time target boots Windows XP Embedded includes the System Cloning Tool component. The system cloning process is performed during manufacture to ensure that each device has a run-time image containing a unique SID. You must include this component in your configuration when you want to clone your run-time image for manufacturing purposes. You do not need the cloning component if each device undergoes the standalone FBA process separately. However, the standalone FBA process is time-consuming and therefore, impractical in a typical production environment. Copying the same image to every device without using the System Cloning Tool will cause every device to share the same computer SID. This presents a problem because every computer running Windows XP is required to have a unique computer SID. The solution is to include the System Cloning Tool component in your run-time image. The cloning process consists of the following two phases: Reseal phase Cloning phase The reseal phase occurs on the embedded device. This device is called the master. Typically, the reseal phase occurs just prior to the reboot that precedes the cloning phase. However, additional operations can occur between the reseal phase and the device reboot. After the reseal phase has completed, you must immediately power off the device before the subsequent reboot would normally occur. At this time, the on-disk image is ready for cloning. The cloning phase automatically begins the first time the image boots after the reseal. Typically, this occurs after the on-disk image from the master has been copied to another device, the clone. The clone device picks up where the master device has left off after the reseal phase. During the cloning phase, the

18 16 Module 4: Building and Deploying an Operating System Image computer SID from the master device is replaced with a unique computer SID everywhere the SID occurs. This makes each clone unique where it is required but identical to the master everywhere else.

19 Module 4: Building and Deploying an Operating System Image 17 System Cloning: Process Overview Obtain Master: Build OS Image New OS Transfer to "master device Boot Device FBA Executes System Cloning Reseal Phase Master Deploy Master: Master First Boot System Cloning Executes OS w/ Unique SID Target A Master First Boot System Cloning Executes OS w/ Unique SID Target B First Boot System Cloning Executes OS w/ Unique SID Target C The illustration demonstrated on the slide shows the process of creating a master image which can be deployed to multiple, identical target hardware platforms and each platform guaranteed to have a unique SID. The sequence is as follows: 1. Build Operating System Image The operating system image is first built with Target Designer. 2. Transfer to master device The operating system is then transferred to a master device. This device should be identical to the devices which will be used in the deployment phase. 3. Boot Device FBA Executes The First Boot Agent (FBA) is allowed to execute. 4. System Cloning, Reseal Phase The last step of the FBA is to execute the Reseal phase of the System Cloning Tools. When this has finished a message box is displayed stating: Machine Resealed! Click OK to reboot. 5. Now that the system has been resealed, an image can be made of the operating system to be copied to the target devices. 6. Transfer the master image to the target device. The first time the target boots with the cloned, resealed image, the system cloning process will continue, and a new SID will be generated for the target device.

20 18 Module 4: Building and Deploying an Operating System Image Preparing Target Media Media Structure Boot Process Media Preparation Bootprep.exe In this section, you will learn how a system boots on an x86 platform. You will learn about the media structure or layout of the target media. Then, you will look at how this relates to the overall boot process of Windows XP. You will identify the process of preparing the target media that includes the use of the Bootprep tool. The Bootprep tool configures a disk to boot Windows XP Embedded.

21 Module 4: Building and Deploying an Operating System Image 19 Media Structure MBR Boot Sector XP-E OS Boot Sector Boot Sector Boot Sector Partition 1 Partition 2 Partition 3 Partition 4 Except for extended partitions which are optional, all disks used to boot any Windows operating system contain the following: Master Boot Record (MBR) The first sector on a hard disk, this data structure starts the process of booting the computer. It is the most important area on a hard disk. The MBR contains the partition table for the disk and a small amount of executable code called the master boot code. Boot Sector The boot sector is a critical disk structure for starting your computer located at sector 1 of each volume or floppy disk. It contains executable code and data that is required by the code including information used by the file system to access the volume. The boot sector is created when you format the volume. Partitions Partitions are logical division of a hard disk. Partitions make it easier to organize information. Each partition can be formatted for a different file system. A partition must be completely present on one physical disk, and the partition table in the MBR for a physical disk can contain up to four entries for partitions. Primary Partition A volume created using unallocated space on a basic disk. Windows 2000 and other operating systems can start from a primary partition. As many as four primary partitions can be created on a basic disk, or three primary partitions and an extended partition. Primary partitions can be created only on basic disks and cannot be sub-partitioned.

22 20 Module 4: Building and Deploying an Operating System Image Extended Partition An extended partition is a portion of a basic disk that can contain logical drives. To have more than four volumes on your basic disk, you need to use an extended partition. Only one of the four partitions allowed per physical disk can be an extended partition, and no primary partition needs to be present to create an extended partition. You can create extended partitions, only, on basic disks.

23 Module 4: Building and Deploying an Operating System Image 21 Boot Process BIOS Master Boot Record Boot Sector NTLDR NTDetect NTLDR Ntoskrnl Power On Self Test (POST) Boot.ini Ntoskrnl HAL.DLL The typical boot process is outlined below: 1. The BIOS is the first to execute performing various tasks such as Power-On Self Test (POST), Plug and Play initialization and detection, and finally it will look for a bootable device such as a hard-disk or CD-ROM. The BIOS boot sequence is typically configurable, and may need to be modified for a particular device, for example, enable booting from CD-ROM. 2. The BIOS then loads the MBR from the hard-disk. The MBR contains information about the partition structure of the disk (Master Partition Table), and also the Master Boot Code. This small piece of code is then given control, and it searches for a partition which is flagged as bootable. Once it finds such a partition, control is given to that partition s boot sector. 3. The boot sector then gives control to NTLDR, providing it with information about the disk. 4. NTLDR then performs the following tasks: a. Switches the processor into the 32-bit flat memory mode. When x86- based computers first start, they are running in real mode, like an 8088 or 8086 CPU. Because NTLDR is mostly a 32-bit program, it must switch the processor to 32-bit flat memory mode before it can perform any other functions. b. Starts the appropriate minifile system. The code to access files on FAT and NTFS volumes is built into NTLDR. This code enables NTLDR to read, access, and copy files. c. Reads the Boot.ini file, and displays the operating system selections. This screen is referred to as the boot loader screen.

24 22 Module 4: Building and Deploying an Operating System Image d. Allows the user to select an operating system from the boot loader screen. Note: By default the boot.ini options are not displayed with Windows XP Embedded because the default timeout is set to 0 in the boot.ini. 5. NTLDR executes Ntdetect.com to gather information about currently installed hardware. Ntdetect.com should be in the root of the disk along with NTLDR. 6. NTLDR loads Ntoskrnl.exe and HAL.DLL into memory. 7. NTLDR then loads all drivers which are configured to start at boot. 8. NTLDR finally passes the hardware information collected by Ntdetect.com to Ntoskrnl.exe, and then passes control to Ntoskrnl.exe.

25 Module 4: Building and Deploying an Operating System Image 23 Media Preparation Partition the drive so you have space required for the XPe OS and other possible partitions such as data or EWF Mark Active Partition Using either fdisk or Disk Administrator Format Media FAT or NTFS If formatted with MS-DIS, use the bootprep.exe tool to create a boot sector on the partition May require 3 rd party tools (udiskonchip or CF Manufacturer) Transfer Operating System If the partition does not already contain the XP Embedded operating system, transfer the operating system to the media In order to successfully boot Windows XP Embedded, the media must be prepared. The following steps are required: Partition the drive You will need to partition your boot media. Make Active Partition A partition can be marked as active or bootable using either fdisk or Disk Administrator. If the media is installed on a system which can boot Windows XP, then formatting the media can be done using Disk Administrator. Using Disk Administrator to Set the System Partition 1. Open Disk Administrator by opening the Administrative Tools folder and selecting Computer Management. 2. Click a primary partition or logical drive on the hard disk. 3. Click the Partition menu. e. If the partition is the system partition or is a logical drive in an extended partition, the Mark Active command is not available. f. If the partition is not the system partition, and you want to set it as the system partition, click the Mark Active command. If the disk is not accessible under Windows XP, then a DOS-bootable disk can be used to run fdisk.

26 24 Module 4: Building and Deploying an Operating System Image MS-DOS FDISK- Install a MBR on the Media This process is required for FAT file systems and will rewrite the disks Master Boot Code. Boot the system with DOS Execute: fdisk /mbr Format Media The boot media should be formatted. Windows XP Embedded supports FAT16, BIGDOS FAT16, FAT32, or NTFS file systems. Important: If FAT16, BIGDOS FAT16 or FAT32 file systems were creating using FORMAT under MS-DOS, bootprep.exe will be required to prepare the target media to boot to Windows XP Embedded. If you format under WinPE, Windows 2000, or Windows XP, the version of format under these OSes will lay down the correct boot sector, thus Bootprep is not required. Bootprep.exe If you format the drive with MS-DOS, you will need to use the Windows XP Embedded tool bootprep.exe to create the NT boot sector on the partition which contains the XP Embedded operating system. Transfer Operating System If the partition does not already contain the XP Embedded operating system, transfer the operating system to the media.

27 Module 4: Building and Deploying an Operating System Image 25 Format Disk Format lays down the boot sector Format with MS-DOS version (MS-DOS, Win95, Win98, WinMe) the Bootprep.exe is required to support XPe Format with NT/2000/XP, Bootprep is not required Format under NT/2000/XP lays down the appropriate boot sector for XPe Format lays down the boot sector for the media. Formatting with MS-DOS/95/98/ME If you format, a drive with MS-DOS/95/98/ME, Bootprep must be used to replace the DOS boot sector with the correct NTLDR boot sector. Formatting with NT/2000/XP If you format a drive under NT/2000/XP the NTLDR boot sector will be written to the first sector. Bootprep is not required.

28 26 Module 4: Building and Deploying an Operating System Image Bootprep.exe Prepares Target Media Installs partition boot sector File Systems FAT (FAT 16) BIGDOS FAT 16 FAT Bit application Run from DOS You use the BootPrep command-line tool, bootprep.exe, to allow media that can be booted in Microsoft MS-DOS to boot into Windows XP Embedded instead. Bootprep should only be run on FAT32, FAT16, or BIGDOS FAT16- formatted devices. NTFS devices do not require Bootprep. To prepare media so that it can be booted in MS-DOS, use existing MS-DOS media preparation utilities, such as FDISK and FORMAT, to prepare the MBR and one or more disk partitions onto target media. After you prepare your media, run Bootprep to allow the media to boot into Windows XP Embedded instead of MS-DOS. Bootprep modifies the boot sector on the media, and enables you to back up the MBR and boot sector contents. Note All removable media must be prepared as if it is non-removable media using MS-DOS, therefore containing a MBR. This is true even of removable devices, such as floppy disks and some flash memory devices, which are formatted without partitioning and do not require an MBR to become bootable in MS-DOS. BootPrep cannot prepare this type of configuration for Windows XP Embedded. To use the BootPrep commands, type the following syntax in a command prompt from MS-DOS: BootPrep /ddrive /mmbrbackupfilename /bbackupfilename /iexternaldatafile /r /y

29 Module 4: Building and Deploying an Operating System Image 27 Parameters /ddrive Uppercase drive letter without the colon (:), for example, /dc. The default is the C drive. /mmbrbackupfilename Name of the file for MBR SECTOR backup, for example, /mmbr.old. If /m is specified with no file name, no backup is created. The default is that no backup is created. /bbackupfilename Name of the file for PARTITION BOOT SECTOR backup, for example, /bbootrec.old. If /b is specified with no file name, no backup is created. The default file is Bootrec.old. /iexternaldatafile /r /y Name of the file containing data for the new PARTITION BOOT sector. The default is to use internal data. Read-only mode. Save output for MBR and BOOT sectors to their backup file locations. Answer Yes to all questions. Use caution with this parameter Code Example The following code sample shows a typical syntax. A:\>BootPrep This example copies the partition boot sector of the C drive to A:\Bootrec.old, and then replaces it with a new partition boot sector using internal data. The new boot sector is in read/write mode.

30 28 Module 4: Building and Deploying an Operating System Image Deploying the Operating System Deployment & Special Media WinPE/SDI SDI2HD / SDI Remote Recover CompactFlash CD-ROM Boot Remote Boot USB Flash XPe can boot from a number of devices such as CD-ROM, hard drive, Compact Flash, udiskonchip, etc. There are a number of deployment methods and technologies available to move the OS image from the development system to the target. This section covers the different technologies and steps to deploy the operating system.

31 Module 4: Building and Deploying an Operating System Image 29 Deploying the Operating System Image Two key issues in Deployment: Moving a larger image (>50MB) from host to target Long file names must be addressed Transfer Operating System Image to bootable media: XPe Deployment Technologies: SDI, WinPE, SDI2HD, and Network Boot Physically Removing Media CF, CD-ROM IDE Disk Swap Third-Party Tools Target Designer builds the image to a directory in the host system by default, but the goal is to get the OS to the target device. The size of the XPe image can be quite large to move and long file names need to be preserved. SDI files along with other deployment tools help to support different deployment scenarios. In this section, you will learn different deployment scenarios for different target media. Third-party tools that can also aid in deployment will be introduced and discussed.

32 30 Module 4: Building and Deploying an Operating System Image Dual Boot Deployment Deploy XPe OS to a separate partition on the development system Ideal for testing the tools Boot.ini file must be changed to support a dual booting to the development OS and XPE [boot loader] timeout=15 default=multi(0)disk(0)rdisk(0)partition(1)\windows [operating systems] multi(0)disk(0)rdisk(0)partition(1)\windows="microsoft Windows XP Professional" /fastdetect multi(0)disk(0)rdisk(0)partition(2)\windows="microsoft Windows XP Embedded" /fastdetect Many developers want to test out their OS image on a known, good, XP system, which makes the development machine a wise choice. To support running Windows XP Professional and Windows XP Embedded running on the same machine, you must consider the following: 1. XPe should be placed in a partition on the same drive as the boot partition. 2. The Boot.ini file in the active boot partition must be modified to support dual booting as shown: 3. You can build the image to the second partition, but you will have to empty the partition for each build by formatting the drive.

33 Module 4: Building and Deploying an Operating System Image 31 Dual Boot Deployment ARC Paths Disks start with 0, Partitions start with 1 Example 1: Boot from 2nd partition on 2nd IDE disk (Assume disk 0, partition 1 is the active partition) multi(0)disk(0)rdisk(1)partition(2)\windows="microsoft XP Embedded" /fastdetect Example 2: Boot from 3 rd partition on 4 th IDE disk (Assume disk 0, partition 1 is the active partition) Windows multi(0)disk(0)rdisk(3)partition(3)\windows="microsoft Windows XP Embedded" /fastdetect Check the drive letters Sometime the biggest challenge in a dual boot system is configuring the Boot.INI arc paths to point at the proper locations. The key is to understand the number values that each of the parameters need to start with. Disks start with logic 0, where partitions start with 1. Example 1 We first assume that the first partition on the first drive is an active partition, and will contain the boot.ini file. If you want to boot to the second partition on the second disk in the system you need to set the ARC path as follows: Mutli(0)disk(0)rdisk(1)partition(2)\WINDOWS= Microsoft Windows XP Embedded /fastdetect Example 2 We first assume that the first partition on the first drive is an active partition, and will contain the boot.ini file. If you want to boot to the third partition on the third disk in the system you need to set the ARC path as follows: Mutli(0)disk(0)rdisk(3)partition(3)\WINDOWS= Microsoft Windows XP Embedded /fastdetect Check the drive letters. If you format the partition using Disk Administrator, take note of the drive letter assigned to the partition, this must be used in the Configurations settings.

34 32 Module 4: Building and Deploying an Operating System Image Deploying to Hard Drive or Flash WinPE with SDI Boot the device using PXE, RIS, or a bootable CD-ROM, then lay down an SDI image on the hard drive/flash using SDI Manager; requires 32 meg OS (Win PE) SDI2HD Boot from floppy (or 16-bit CD boot) and lay down an SDI image using SDI2HD 3 rd Party Tools Boot the device (floppy, PXE), prepare the partition, and transfer the file system to the hard drive/flash using a copy command or 3 rd party utility There are different combinations of the XPe tools to deploy the OS to a hard drive or flash. There are also third-party tools that make transferring the image as easy as drag and drop.

35 Module 4: Building and Deploying an Operating System Image 33 WinPE WinPE is Windows XP Pre-install Environment Lightweight servicing OS XPe SP1 CD1 is bootable WinPE disk Deployment licensing in progress Development time on target hardware Boot WinPE and running TA Boot WinPE and copy image Boot WinPE and capture image Deployment time Remote Installation Services (RIS) with WinPE Bootstrap SDI Manager Install and boot a remote image The XPe CD-1 also doubles as a XP boot CD, a.k.a. WinPE or Windows XP Pre-installation Environment. WinPE is used in different ways: Can be used with Target Analyzer to develop a PMQ file for a target system. There are some limitations on device drivers for the latest hardware. SDI Manager and SDI driver are part of WinPE. Used with an SDI file, helps to deploy an image to a target system s hard drive. WinPE can also capture a Post-FBA image with SDI Manager to either preserve the image or for further deployment to CD-ROM. Remote Installation Service on Windows 2000 Advanced Server can download WinPE to a target system that has little access for addition removable media drives. Once WinPE is loaded, SDI Manager can be used to download and install an XPe image from a remote SDI file.

36 34 Module 4: Building and Deploying an Operating System Image System Deployment Image (SDI) Portable image format for XPE runtimes File backed virtual disk drive Supports partition, disk and boot BLOBs Sector based image Tools for building, editing and extracting images SDI Loader GUI tool Creating, mounting, dismounting SDI files as drives SDI Manager Command-line tool for manipulating SDI files off-line SDI2HD: 16-bit version provided for DOS deployment System Deployment Image (SDI) is a virtual disk format for storing and deploying XPe runtimes. SDI files are mounted as virtual disks so that XPe images can be copied to them. The SDI files can be broken into different disk blobs for use with the different SDI tools. SDI Loader Graphical tool for creating and mounting SDI files as disk volumes. Enables you to create, add, connect, remove, or disconnect virtual disk drives. The volume opens the Disk Blob of the SDI file for read/write access SDI Manager Command line tool for manipulating SDI files. This utility enables you to manipulate a disk image file in offline mode. You can query its contents and manipulate its BLOBs. Information can be transferred from one file to another and from one blob to another. The tool is also used in deployment. SDI2HD The 16-bit version of the SDI Manager tool, used only for deployment.

37 Module 4: Building and Deploying an Operating System Image 35 SDI Uses SDI is used with other tools to deploy the OS WinPE/SDI SDI2HD Remote Boot Managing large numbers of bootable images Target designer builds into mounted drives Image format for remote boot NTLDR has support for SDI images Remote boot manager allows configuration of SDI image to MAC address SDI files are used with different XPe tools to help in the deployment of the operating system, whether it is installing to a hard drive over a network, from a CD-ROM, or downloading and executing the image from RAM. SDI files also help store an XPe image in a single file that can be backed up to a fileserver or version control system for later use. SDI files are designed to support Remote Boot over a network. NTLDR supports the SDI file architecture to load and execute the image in RAM.

38 36 Module 4: Building and Deploying an Operating System Image SDI File Format Disk blob Header Boot blob Loader blob Partition blob SDI signature Boot offset and length Extensible (4K) Boot program STARTROM.Com Real mode executable file Call NTLDR.Exe Loader program NTLDR.Exe Mounts partition blob as RAMDISK Boots into RAMDISK Target runtime image Post FBA XPE image An SDI file is divided into two parts: a header and a set of data blobs. The data blobs are further divided into 4 blobs: Boot Blob, Loader Blob, Partition Blob, and Disk Blob. Header The Header contains the SDI signature. SDI Loader uses the header to mount the SDI file as a disk. The SDI header contains the BOOT CODE OFFSET and BOOT CODE LENGTH, which point to the BOOT BLOB within the SDI file. Boot Blob The Boot Blob contains the StartROM.com file that will call the NTLDR.EXE program. The Boot Blob is used for Network Booting. StartROM.com is a real mode executable file. Loader Blob The Loader Blob contains the NTLDR.EXE program. The program executes, mounts the Partition Blob as a RAMDISK, and then boots the run-time image from the Partition Blob. Partition Blob The Partition Blob contains the runtime XPe image. The Partition Blob can be used to contain the Pre or Post- FBA image. A Pre-FBA image is downloaded to a system for the first time to run and perform the final configuration. The Post-FBA image can be used for mass deployment, such as remote network boot and cloning. Boot, Loader, and Partition Blobs are used together to support remote booting.

39 Module 4: Building and Deploying an Operating System Image 37 Disk Blob The Disk Blob is the virtual disk when mounted (on-line) by SDI Loader.

40 38 Module 4: Building and Deploying an Operating System Image SDI Tools, Blobs, and Deployment Tool SDIMGR SDILoader SDI2HD Remote Network Boot SDI Blob Partition Blob for deployment Header & Disk Blob Disk Blob Boot blob, Loader blob, & Partition blob Detail SDIMGR works with all blobs, but partition blob is used for deployment Mounts the SDI file as a disk Copies directly from the Disk blob to the harddrive RNB require the Boot and Loader blobs to load the image into RAM The table illustrates how the SDI tools and Remote Boot Manager work with different blobs in the SDI file. It is important that the OS is in the correct blob when deploying with one of the SDI tools.

41 Module 4: Building and Deploying an Operating System Image 39 Using WinPE with SDI to Download to Hard Drive Build XPe Image and place into Partition Blob of an SDI file Two step process: 1. SDILoader to create one SDI file, copy the Pre-FBA image to the mounted SDI disk 2. Use SDIMGR to take image in the first SDI file s Disk Blob and transfer the image to the Partition Blob of the a new SDI file Copy second SDI file to a network share XPe CD1 doubles as a XP bootable CD: WinPE Diskpart used to partition a drive & Format to format the partition SDI driver supported & Networking supported Connect to the network share SDIMGR to download the image to the target hard drive The process to deploy an XPE image with SDI and WinPE is as follows: 1. Create and build your image with Target Designer. Copy the image to a mounted SDI volume. 2. Close the SDI volume and use SDIManager to create a new SDI file and copy the image from the first SDI file disk blob to the partition blob of the new and final SDI file. C:>sdimgr /new c:\myfinal.sdi C:>sdimgr c:\myfinal.sdi /readpart:<drive letter>: Where the drive letter is the mounted SDI volume containing the XPE image 3. Boot the target with WinPE, DiskPart and format utilities can be used to prepare the hard drive for the OS. 4. Use NET.EXE to access a file share on the network contain the final SDI file. C:>net use z: \\<computer name>\<share> 5. Finally, use SDIManager in WinPE to download the image to the target. D:\xpe>sdimgr z:\ex11c.sdi /writepart:c: /yes

42 40 Module 4: Building and Deploying an Operating System Image SDI2HD.EXE / SDI SDI2HD.EXE - 16-bit SDI manager Great for environments where WinPE cannot be used Hot it works: Create CD with SDI2HD and SDI file or place SDI file in a network share Boot target to DOS Connect to local CD-ROM or connect to network share Run SDI2HD SDI2HD is a DOS utility that can deploy an XPE image from an SDI file s disk blob. This utility is used when WinPE or other deployment scenario is not available. Because of the XPE image size, there are two methods for using SDI2HS / SDI file: DOS networking Accessing a CD-ROM drive under DOS

43 Module 4: Building and Deploying an Operating System Image 41 Winternals: Remote Recover TCP/IP Host Client software used to connect a remote PC and mount the hard drive to a host Client hard drive can be partitioned, formatted, and image copied just like a regular hard drive Boot the client with MS-DOS Requires NDIS DOS driver and Network Client from Windows NT Server 3.5, 3.51, or Winternals Remote Recover was designed to help IS departments recover files from a system that fails to boot. As a side benefit, Remote Recover allows you to transfer files over a network to a target system without loosing long file name support. The NT HOST system sees the target system s HDD as another drive in the system. Remote Recover is a Host/Client solution. You will need MSClient disks, which can be found on Windows NT Server CDs, and you will need the NDIS2DOS network driver including OEMSETUP.INI for your target s Ethernet controller. An MS-DOS client disk or PXE/RIS image is created using the remote recover host application. The client image or disk is booted on the remote target. The host application connects and mounts the remote client so the targets disk looks like a disk on the local system. Once mounted the disk can be partitioned and formatted just like another disk in the system. Also, files can be copied to the disk.

44 42 Module 4: Building and Deploying an Operating System Image Deploying to Compact Flash CompactFlash is pined out to interface to IDE controller IDE-to-CF adapter required FAT file system recommended - MS-DOS, FDISK, FORMAT, Bootprep to prepare the disk CompactFlash requires manufacture utility to change media from removable to fixed EWF recommended to protect flash Compact Flash (CF) is one of the more popular media from which to boot XPe. Small light-weight and solid state makes it ideal for embedded systems. Flash can wear out faster over time than their IDE counterparts, so it is a good idea to implement EWF when booting from Compact Flash. EWF works best with fixed media providing more options for overlay. Because Compact Flash is identified as removable media, a manufacturer s utility is required to convert the Compact Flash from removable type to fixed media type. Please contact your Compact Flash manufacturer for more information. The CF device is prepared as an IDE hard drive. With the CF device connected to the IDE controller, boot the system to MS-DOS and use the FDISK, Format and Bootprep utilities to prepare the CF device to boot XPe.

45 Module 4: Building and Deploying an Operating System Image 43 Deploying to CD-ROM Requires the Enhanced Write Filter (EWF), Plug-N-Play Device Enumerator, and El-Torito CD components HD2ISO utility used to create ISO images Must run in Win32 environment - WinPE There are several Steps to create a XPe Bootable CD Split a CD between OS and Data partitions is possible DVD boot is also possible Alternative is to boot from CD and load SDI image into RAM Disk MSDN Article: RAM Boot Using SDI in Windows XP Embedded with Service Pack 1 Windows XP Embedded includes the El Torito component. This component implements the El Torito specification, which provides a standard for creating bootable CD-ROMs. The El Torito specification supports the creation of bootable CD-ROMs as an image of a hard disk drive or a floppy disk drive. When you create an image of a hard disk, the CD-ROM will boot as drive C and all hard disk drive letters will be shifted up one letter. When running the operating system from CD-ROM, there is no place for a page file to be created. By default, every Windows XP Embedded system will not use a pagefile. To modify the pagefile: 1. Locate and select the hardware abstraction layer (HAL) component. For example, the Standard PC HAL Component. 2. Expand the tree for the HAL component, and then click Settings. 3. Edit the System Pagefile settings that appear in the right pane. The Enhanced Write Filter must also be included in the configuration to redirect all writes made to the CD-ROM. Note: For more information on the enhanced write filter and the El Torito Image Preparation Tool, see Module 5, Windows XP Embedded Enabling Features in Course 2545C, Developing Embedded Solutions for Microsoft Windows XP Embedded.

46 44 Module 4: Building and Deploying an Operating System Image Remote Network Booting TFTP Service and Remote Boot Manager added to SP1 Remote Boot Manager is PXE and PXE is Remote Boot Manager Support Thin Clients A DHCP server is needed to complete the network setup DHCP only available in Win2K Adv Server Configure DHCP port 60 on the W2k Adv Svr PXE can handle only one provider Do not install RIS on Win2K Adv Server, conflicts with Remote Boot Manager Only one PXE provider should exist on a network Install Remote Boot Manager on Win2K Adv Server An XPe image can be downloaded over a TCP/IP network using the target s PXE boot agent support and the Remote Boot Service provided in XPe. A Windows 2000 Advanced server or greater is needed to act as the remote boot and DHCP server. The image stored in an SDI file is downloaded and runs in the targets RAM. A general rule is that the RAM must be twice (2X) the size of the XPE image.

47 Module 4: Building and Deploying an Operating System Image 45 Remote Network Booting Image Creation Image Creation Steps Create an image with RAMdisk driver component Download and run on the target to get past FBA Copy target contents to SDI drive, and use SDIMGR script to create a final partition Locate the SDI file in the remote boot target image directory Windows 2000/XP Development System TFTP Service and Remote Boot Manager Switch/Hub DHCP Server Target Platform The image must run though the FBA process to complete the build process before the image can be used for remote network boot. 1. Download the image to the target or equivalent 2. Run FBA and copy the Post-FBA image back to the target 3. Two SDI files are needed. The first is to be used as a separate mounted volume and the second is the final SDI file for deployment. 4. The final SDI file must be copied to the deployment server. Other RIS or PXE servers can exist on the same network as Remote Boot Server.

48 46 Module 4: Building and Deploying an Operating System Image Remote Network Booting Remote Server Setup Remote Server setup Get MAC address of target system - IPCONFIG /ALL Setup Remote Boot Manager Example: MAC: 00-D0-B7-92-A5-12 Description: my client Action: boot Boot Server : Boot Program: Startrom.n12 or Startrom.com Boot image: mydisk.sdi Remote Boot Manager is a graphical utility that creates the device policy list. Each remote system is identified by their Ethernet s MAC address. You can use IPCONFIG utility or Ping to find the MAC address of your target system. Each listing contains the MAC, whether the image is going to boot, the file image name, and boot program.

49 Module 4: Building and Deploying an Operating System Image 47 Deploying to udiskonchip M-Systems udoc = USB 2.0 flash disk designed for embedded systems Developed software solution to boot XPe from USB flash drive Copy the image over to the USB flash drive TrueFFS wear-leveling technology - EWF not required Built-in security features Requirements USB 2.0 Boot device support in system BIOS (Most system have USB 1.1 Boot support) Special configuration utilities and drivers available from M-Systems - XPe doesn t support booting from USB devices out of the box. The USB driver doesn t get loaded until much later in the boot cycle for the kernel to access the drive. M-Systems has developed an embedded version of the USB2.0 flash key called the udoc. They have also created a special driver and utility to allow XP Embedded to boot from the udoc. Because the udoc uses M-Systems TrueFFS flash technology, EWF is not required to protect the life of the flash, unlike CF cards. The udoc also offers security and encryption technologies to protect the data on the device. The udoc operates just like another USB flash key, so transferring the image is as simple as copy and past the XPe image to the USB flash drive. udiskonchip Requirements The target system must support USB 2.0 booting in the BIOS. Many systems boot USB 1.1, but the transfer rate is to slow to boot XP Embedded. Please, contact your hardware manufacture to see if USB 2.0 booting is support in your target s BIOS. Important: You will need to contact M-Systems for the setup software and XPe components for the udoc

50 48 Module 4: Building and Deploying an Operating System Image Lab 4: Deploying an Operating System Image (Part 1) Objectives After completing this lab, you will be able to: Configure Target Designer to build an XP Embedded operating system. Boot an XP Embedded operating system. Configure a dual-boot system for testing. Prerequisites Before working on this lab, you must have: Knowledge about Target Designer. Understanding of dependencies in Target Designer. Estimated time to complete this lab: 60 minutes

51 Module 4: Building and Deploying an Operating System Image 49 Exercises, Lab Setup To complete this lab, you must have the following for each exercise: For Exercise 1 & 2 Completed the exercises in Lab3 For Exercises 3, 4, and 5 you will need a separate target system. Your instructor will talk about the details for the external target. Exercise 3 A copy of the WinPE boot CD. Exercise 4 A Windows 2003 server with Remote Boot Services installed. A method to transfer the OS to and from the target system and the desktop. Your instructor will talk about how to transfer the OS. Exercise 5 A 256MB udoc and the M-Systems udoc utilities

52 50 Module 4: Building and Deploying an Operating System Image Exercise 1 Building the Operating System (Dual Boot) In Lab 3, you created an XP Embedded configuration for an Information Appliance. You will now configure Target Designer to build the operating system. If you are using the Virtual PC skip to the next section. For a dual boot system prepare the testing partition 1. To open a command prompt, click Start, and then click Run. It opens the Run dialog box. 2. Type cmd.exe and click OK. 3. From the Command Prompt, execute the following command to format the D: drive with the FAT file system. format D: /FS:FAT32 /Q /X A dialog box appears that prompts you that all data will be lost from the Drive D. 4. Type New Volume as current volume. 5. Type Y to proceed. 6. Type exit to exit the command prompt. To configure Target Designer The operating system will be built to a subdirectory. You will later copy the image to the second partition. 1. Open the TAPBASE.SLX configuration with Target Designer if it is not already open. 2. On the Tools menu, click Options. 3. On the Build tab, make sure the Default Image Folder is set to c:\windows Embedded Image 4. Click OK. To modify the configuration settings in Target Designer 1. In the Configuration Editor, click Settings. 2. In the Details Pane, click Target Device Settings. 3. Under Target Device Settings, click Show to modify the values. 4. Change the values as follows: For more information on each value, click on the more info link next to each value. Setting: Boot drive D: Windows folder Program Files folder Documents and settings folder Value: D:\Windows D:\Program Files D:\Documents and Settings

53 Module 4: Building and Deploying an Operating System Image 51 Boot ARC Path Boot partition size (MB) 1024 Partition cluster size (bytes) 4096 To build the operating system Multi(0)disk(0)rdisk(0)partition(2) 1. On the Configuration menu, click Build Target Image. 2. Select a Release build type. 3. Verify the destination directory to be c:\windows Embedded Images. 4. Click Build. 5. If prompted to run the dependency checker again, click Yes. 6. Target Designer will warn that all files on c:\windows Embedded Images will be deleted. Click Yes. 7. Click Close. 8. Once the build is complete, save the configuration. 9. Exit Target Designer. 10. Copy the image from c:\windows Embedded Data to the d:\ partition. To modify the systems boot.ini In order to dual-boot the development machine, you will modify the boot.ini file found in the root of the primary active partition: 1. To open the boot.ini file s properties, in the root of the C:\ drive, right-click the boot.ini file and then click Properties. You may need to change the view options in order to see the hidden OS file. 2. Deselect read-only if the file is read-only. 3. Open the boot.ini file. 4. Add the following line to the boot.ini: multi(0)disk(0)rdisk(0)partition(2)\windows= Microsoft Windows XP Embedded The final boot.ini file should look like the following: [boot loader] timeout=30 default=multi(0)disk(0)rdisk(0)partition(1)\windows [operating systems] multi(0)disk(0)rdisk(0)partition(1)\winnt="microsoft Windows XP Professional" /fastdetect multi(0)disk(0)rdisk(0)partition(2)\windows ="Microsoft Windows XP Embedded" /fastdetect 5. Save and close the boot.ini file. 6. Reboot the system. 7. When the boot.ini options are presented, select Microsoft Windows XP Embedded.

54 52 Module 4: Building and Deploying an Operating System Image Note: The First Boot Agent (FBA) must execute before we can run our Windows XP Embedded operating system. It is common for the FBA to reboot the system multiple times before it has completed its tasks. 8. Test the XP Embedded operating system. 9. Launch Task Manager (Ctrl+Alt+Delete).

55 Module 4: Building and Deploying an Operating System Image 53 Exercise 2 Building the Operating System (VPC) In Lab 3, you created an XP Embedded configuration for an Information Appliance. You will now setup the VPC to boot the XPe image. Prepare the XPETARGET VM 1. Open Virtual PC Start the XP Pro VM. The XPETARGET virtual hard drive should be a second hard drive in the XP Pro VM. 3. When the VM finally boots, open Explorer in the VM and format the second virtual hard drive. To configure Target Designer You will now configure the image to build to a subdirectory. Later we will drag and drop the whole image into the second hard drive of the XP Pro VM. 1. On the desktop system, open the TAPBASE.SLX configuration with Target Designer if it is not already open. 2. On the Tools menu, click Options. 3. On the Build tab, make sure the Default Image Folder is set to c:\windows Embedded Images. 4. Click OK. Verify modify the configuration settings 1. In the Configuration Editor, click Settings. 2. In the Details Pane, click Target Device Settings. 3. Under Target Device Settings, click Show to modify the values. 4. Make sure the values are set as follows: For more information on each value, click on the more info link next to each value. Setting: Boot drive C: Windows folder Program Files folder Documents and settings folder Boot ARC Path Value: Boot partition size (MB) 1024 Partition cluster size (bytes) 4096 To build the operating system C:\Windows C:\Program Files C:\Documents and Settings Multi(0)disk(0)rdisk(0)partition(1) 1. On the Configuration menu, click Build Target Image. 2. Select a Release build type. 3. Verify the destination directory to be c:\windows Embedded Images.

56 54 Module 4: Building and Deploying an Operating System Image 4. Click Build. 5. If prompted to run the dependency checker again, click Yes. 6. Target Designer will warn that all files on c:\windows Embedded Images will be deleted. Click Yes. 7. Click Close. 8. Once the build is complete, save the configuration. 9. Exit Target Designer Testing the image. Now we will shutdown the XPPro VM and boot into the XPETARGET VM. 1. On the desktop, open Explorer 2. Make sure that you have Explorer open to the second hard drive in the XP pro VM, drag and drop the image found in the desktop under c:\windows Embedded Image and copy it to the root of the second hard drive of the XP Pro VM. 3. Once the image copy has completed close Explorer in both system. 4. Shutdown the XP Pro VM 5. Start the XPETARGET VM. This will boot the XPe image and start running FBA. Note: The First Boot Agent (FBA) must execute before we can run our Windows XP Embedded operating system. It is common for the FBA to reboot the system multiple times before it has completed its tasks. 6. Once the OS has completed the FBA process and has booted to XPe, from the Action menu select Ctrl+Alt+Delete Launch Task Manager. 7. Shutdown the Virtual PC.

57 Module 4: Building and Deploying an Operating System Image 55 Exercise 3 (Optional) Deploying with WinPE and SDI WinPE provides a Windows 32-bit environment to connect to a network, prepare the target s hard drive, and install an XPe image from an SDI file. WinPE uses DHCP client to obtain an IP address. Create an Image 1. Open Target Designer and create a new XPE configuration called XPEWINPE. 2. Add the following components to the new configuration: NT NTLDR Minlogon Task Manager Shell FAT NTFS CMD Windows Command Processor English Language Support (Or your local language) 3. Add your target system s platform macro component to the new configuration. Your instructor will point you to the correct component. 4. Check Dependencies, resolve any errors, and re-check Dependencies. 5. Click on the Build button to build the image to c:\windows Embedded Images. 6. If prompted to run the dependency checker again, click Yes. 7. Target Designer will warn that all files on c:\windows Embedded Images will be deleted. Click Yes. 8. Click Close. 9. Once the build is complete, save the configuration. 10. Exit Target Designer Create SDI File SDI has many uses in deploying XPe images. The SDI tools were installed during the XPe tools installation process. In this exercise, we will install the SDI driver and create an SDI disk for use in the following exercises. 1. Run SDILoader.EXE: Start->All Programs->Microsoft Windows Embedded Studio->SDI Loader. 2. A dialog box will appear if the SDI driver hasn t been installed. Click Yes, and follow the steps to install the SDI driver. 3. After the driver is installed, SDI Loader will launch. Click on the Add Disk button. 4. Set the directory to c:\xpe_data and Type XPESDI in the File Name edit box and click the Open button. 5. Another dialog box will appear asking you to create a new file? Click Yes.

58 56 Module 4: Building and Deploying an Operating System Image 6. A second dialog appears asking for the size of the disk. Enter 250 (250MB) and click OK. 7. The disk is mounted and listed in the SDI Loader display. Now lets partition and format the new drive. Go to Disk Manager (Control Panel- >Administrative Tools->Computer Management->Disk Management). 8. A Disk Wizard will appear to assist in initializing the disk. Click Next. 9. Screen 2 of the Wizard will list the drives to be initialized with a check. Click Next. 10. Screen 3 will ask for the drivers you want to convert to a dynamic disk. SDI doesn t support dynamic disks. MAKE SURE THAT THERE IS NO CHECK NEXT TO THE SDI DISK, and click Next. 11. The summary screen will appear, click Finish. 12. Back in Disk Manager, right click on the SDI disk, and select New Partition from the pop-up box. 13. Another Wizard starts, click Next 14. The 2nd wizard screen appears, make sure that the primary partition is selected and click Next. 15. The 3 rd screen will ask for the size of the partition, the default should be the whole partition 243MB, click Next. 16. The 4 th screen will ask to assign a drive letter, make sure the Assign the following drive letter: is selected, and click Next. 17. The 5 th screen asks you to choose the format type. You can format the SDI drive to any file format: FAT, FAT32, or NTFS. For this exercise we will use FAT. Select to format the disk with FAT, and click Next. 18. The summary screen appears, click Finish. The partition is created and the disk is formatted as FAT. Now the disk is accessible in Explorer. Files can be copied from and to the SDI drive. 19. Close Disk Manager Create the Deploy SDI File and Download the image to the target 1. Boot the target system with WinPE. 2. On the development platform, copy all of the files in c:\windows Embedded Image folder to the mounted SDI drive. 3. After the copy is complete, open a command window, and change directory to \Program Files\Windows Embedded\Utilities

59 Module 4: Building and Deploying an Operating System Image 57 C:\>cd \program files\windows embedded\utilities 4. Run SDIMGR to create a new SDI file: C:\:>sdimgr /new c:\xpe_data\deploy.sdi 5. With the XPESDI mounted, use SDIMGR to read the contents into the partition blob. C:>sdimgr c:\xpe_data\deploy.sdi /readpart:<drive letter>: Where driver letter is the drive of the mounted XPESDI.sdi file. Note: You may have to run the above command twice if an error occurs. 6. Close the Command Window and remove (un-mount) the XPESDI drive/file and close SDI Loader. 7. Make C:\XPE_DATA a shared directory. Set the share name to XPEA, and permissions set for everyone with Full Control. 8. On the Target Machine, which is now booted to WinPE, you will have to partition and format your hard disk. Diskpart and Format are part of the WinPE image. Use Diskpart to create a primary active partition. Once the partition is created reboot the target, and then format the drive FAT or NTFS. Here are the steps: a. Run Diskpart to delete all partition volumes and create a 200MB primary partition To delete a partition: A. C:>diskpart B. Diskpart >select disk 0 C. Diskpart>detail disk <View all the partitions on the disk. D. Diskpart >select partition 1 E. Diskpart >delete partition Repeat parts D & E to delete any other partitions. To create a primary bootable partition of 200MB: A. Diskpart >select disk 0 B. Diskpart >create partition primary size=250 C. Diskpart >select partition 1

60 58 Module 4: Building and Deploying an Operating System Image D. Diskpart >active E. Diskpart>exit b. After partitioning the drive, reboot the machine c. Use Format to format the partition to FAT. C:>format c: /fs:fat 9. Now that the partition is created and formatted, use NET.EXE to access the share on the development system (You may want to use ping to make sure that you can access the host machine): C:>net use z: \\<computer name>\<share> where computer name is the name of the student machine. Enter a user name and password for the host machine when asked. 10. SDIMGR will be use to install the image to the hard drive as follows: D:\xpe>sdimgr z:\deploy.sdi /writepart:c: /yes 11. The image will be written to the primary partition. When complete, reboot the target and remove the WinPE CD. The system will boot into XPe and start the FBA process, reboot, and then login as administrator and launch the Task Manager Shell.

61 Module 4: Building and Deploying an Operating System Image 59 Exercise 4 (Optional) Remote Boot Since the XPe image runs in the client s RAM, the image must go through the FBA process first before the image can be used for network download. The following diagram explains the process to build the remote boot image: Create the Image for Remote Download 1. Open Target Designer and create a new XPE configuration called XPEREMOTE. 2. Add the following components to the new configuration: NT NTLDR Minlogon Task Manager Shell FAT NTFS CMD Windows Command Processor English Language Support (Or your local language) 3. Add the Windows RAM Disk Driver component to the configuration:. Hardware->Other->Windows RAM Disk Driver. Make sure that the target s settings are for C drive. Also take note of the size of the uncompressed image shown in the status bar, and make sure that the target s RAM is at least 2x the size of the image. 4. Add the platform macro component to the new configuration. Your instructor will point you to the correct component. 5. Check Dependencies, resolve any errors, and re-check Dependencies. 6. Click on the Build button to build the image to c:\windows Embedded Images. 7. If prompted to run the dependency checker again, click Yes. 8. Target Designer will warn that all files on c:\windows Embedded Images will be deleted. Click Yes. 9. Click Close. 10. Once the build is complete, save the configuration. 11. Exit Target Designer Run the image on the Target System 1. In order for the image to remote download and run on the target, the image must be run through and complete the FBA process to complete the setup of the image. Use WinPE/SDI or a method or your instructors choosing to download the image to the target. 2. Reboot the target to run the FBA process.

62 60 Module 4: Building and Deploying an Operating System Image Create the SDI Files 1. On the development machine, open SDI Loader and create a new SDI file in the c:\xpe_data directory called RemoteX.sdi (where X is your student number). The partition size should be slightly bigger than the image size. For Example: If the image size is 110 MB make the partition size 150MB. The target s RAM must be 2x the size of the partition size or the image will fail to load. 2. Using Disk Management, create a new partition and format the drive to FAT. 3. When the target completes the FBA process, copy the post-fba image from the target to the new mounted SDI disk using Remote Recover. Your instructor will show you how this is done. Don t copy the System Volume information to the SDI drive. 4. Now using SDIMGR create a new SDI file that will be used for the remote download, and copy the contents of the RemoteX.sdi into the final SDI file: C:>sdimgr /new c:\xpe_data\remotex2.sdi C:>sdimgr c:\xpe_data\remotex2.sdi /readpart:<sdi drive>: Where SDI drive is the driver letter for the mounted SDI drive, and X is your student number. 5. Copy remotex2.sdi to the Windows 200x Server, and place the file in the \Program Files\Windows Embedded\Remote Boot Service\Downloads directory. The instructor will point you to the correct location. 6. Un-mount the RemoteX.sdi drive and close SDI Loader. Setup Remote Boot Manager and Download to the Target The last step is to setup Remote Boot Manager. 1. Find the MAC address for the target system s network adapter. You can use IPCONFIG /ALL under WinPE to obtain the address. 2. Start Remote Boot Manager on the server. 3. On a single line in the policy table enter the following: MAC address of the target network adapter Description: StudentX (where X is the student number) Action: boot Boot Server: (default) Boot Program: startrom.n12 Boot Image: remotex2.sdi 4. Click Save to save the policy table. 5. Make sure that the target s BIOS is set to boot from LAN or PXE server, and then boot the client. The target with a PXE-enabled network card boots to the PXE client. The PXE client broadcasts a request for a DHCP address. The DHCP server responds to the request from the pool of TCP/IP address.

63 Module 4: Building and Deploying an Operating System Image 61 The PXE client looks for a TFTP service to use to download the OS from the server. Remote Boot Sever checks incoming PXE traffic and compares the MAC addresses with the policy table set up by Remote Boot Manager. When a client s MAC matches a MAC listed in the policy table, a boot program loader is downloaded to the client and then SDI file containing the OS is downloaded and booted in RAM. The Image loads into RAM, boots to XPe, and runs the Task Manager Shell.

64 62 Module 4: Building and Deploying an Operating System Image Exercise 5 (Optional) Booting from M-System s udoc The M-Systems USB flash solutions involved a special USB driver that loads early in the XPe boot process. This allows the kernel to access the drive and load the rest of the OS. In this exercise, we will walk through the steps to create an image for the udoc and boot the target with the udoc. Part 1: Create the Image 1. Open Target Designer and create a new XPE configuration called XPEUSB. 2. Add the following components to the new configuration: NT NTLDR Minlogon Task Manager Shell FAT NTFS CMD Windows Command Processor English Language Support (Or your local language) USB udiskonchip component (found at Hardware\Devices\Diskdrives) 3. Add the platform macro component to the new configuration. Your instructor will point you to the correct component. Note: Due to the GUID, the import of TAP may pick up the USB udiskonchip component when you don t want it. The udoc boot driver at the time of this writing takes over as the primary boot device in XPe. You will have to disable the component when booting from other devices 4. Check Dependencies, resolve any errors, and re-check Dependencies. 5. Build the image. Part 2 Prepare the udoc and Transfer the Image The M-Systems udoc Partitioning Utility offers two functions. The first is the ability to partition, format, and add the MBR to the udoc, and the second is the ability to duplicate the udoc image for production. 1. On the development machine, insert the udoc either directly to a USB pin header or attached to a USB adapter for a standard USB connector. XP should recognize the new drive and install the driver. 2. Start the udoc Partition Utility.

65 Module 4: Building and Deploying an Operating System Image The utility comes up as shown below, and provides the two functional options, either hit F5 or click on the icon to partition the udoc. 4. This will start a wizard to prepare the udoc for XPe. Step 1 asked to partition the udoc. You can have up to 4 partitions on a drive. Leave Partition 0 as the only partition on the udoc. Check the Show Advanced Options, and click NEXT. 5. Step 2 asks to choose the file system for the partition. Select FAT32 for this exercise and then click NEXT.

66 64 Module 4: Building and Deploying an Operating System Image 6. Step 3 provides a summary of your selections. Click Next. 7. Step 4 preps the udoc based on your selections. Click on Exit when it is finished. 8. Keep the utility open. Transfer (copy and paste) the XPe image from c:\windows Embedded Images to the udoc. 9. When the transfer is completed, go back to the udoc Partitioning Utility and click the eject button or F9. This will eject the udoc so you can safely remove the drive from the development machine. Part 3 BIOS Setup and Test 1. Make sure that your target is powered off. Insert the udoc into an open USB 2.0 port. 2. Power on the target and access the BIOS setup utility. The system may post a BIOS message stating it found the udoc during boot. This will vary per system. 3. The BIOS settings required for USB 2.0 boot will be different for every system. Here are the general things to look for: A. USB 2.0 Support Enabled and set for Hi-speed. B. USB udoc needs to be set for Hard drive emulation. C. The system boot order must include the udoc. 4. Save the BIOS changes and let the system boot to the udoc. Once FBA completes, the system should boot to Task Manager Shell.