Exam Windows Embedded Standard Preparation Kit. Certification Exam Preparation utomation. Not for resale.

Transcription

1 MCTS i Exam Windows Embedded Standard 2009 Preparation Kit Certification Exam Preparation utomation Not for resale.

2 ii Table of Contents Contents at a Glance 1 Creating and Customizing the Configuration 2 Managing the Development Environment 3 Integrating Embedded Enabling Features 4 Creating Components 5 Generating and Deploying an Image 6 Adding Windows Functionality

3 Chapter 5 Generating and Deploying an Image After you have completed the tasks of designing your run-time image, configuring it with the necessary components and testing the configuration, you can continue with production deployment to your target devices. Production deployment entails reviewing the deployment scenario, preparing the image, and deploying it to devices for a final, retail-ready product. This chapter discusses key deployment scenarios for Internet- connected and unconnected devices including devices that start remotely or start from an onboard booting media. This chapter also covers the configuration dependencies you must complete to prepare your image for distribution. Exam objectives in this chapter: Generate the Pre-First Boot Agent (pre-fba) image Seal and clone the post-fba image Prepare target media for deployment Deploy the Post-First Boot Agent (post-fba) image to the target device Implement a remote boot solution Before You Begin To complete the lessons in this chapter you need the following: Microsoft Windows Embedded Studio for Windows Embedded Standard 2009 installed. Completed Chapters 1, 2, 3 and

4 146 Chapter 5 Generating and Deploying an Image Lesson 1: Generate the Pre-FBA Image FBA runs the first time your operating system starts after you configure and build an image. FBA completes the run-time image build process by running a sequence of tasks on the target system, such as Plug and Play (PnP) device detection, security installation, and DLL registration. You can add commands to the FBA process and specify when they will run. You can also add tasks to the FBA process by defining custom resources, referred to as FBA commands, such as RunOnce requests, application shortcuts, and populating the registry with service data. After this lesson, you will be able to: Include a product identification key (PID). Understand the FBA process. Create custom resources to customize the build process. Estimated lesson time: 20 minutes. Run-Time Image Licensing You must enter a PID for your retail image. Otherwise, the image that you create is an evaluation image and will stop working after the evaluation period expires 120 days after deployment. Windows Embedded Standard 2009 product activation does not require online access and is activated in Target Designer when you enter a run-time product key in the Run-time Image Licensing section of the image configuration settings. FBA Phases and Processing Order The Target Designer build process creates the raw system image, creates the necessary directory structure, and copies the files for each component to the specified directories. The build process also creates the registry hives and saves these in the \Windows\System32\Config folder. This raw system image is not ready to run as it is. On the first start of the raw run-time image, FBA runs to complete the build process. FBA performs any run-time tasks that could not be performed offline with Target Designer, including security installation, catalog registration, PnP device detection, network configuration, DLL registration, and profile initialization. The FBA process flows in a predefined, sequential order that is determined by phases and ordinal values to control the timing of various commands. FBA Generic

5 Lesson 1: Generate the Pre-FBA Image 147 Command, FBA DLL/COM Registration, and FBA OC Manager Requests all have ordinal values associated with them. FBA starts at 0 and continues through 65,535. Phases 0 through 8,500 are reserved for use by the system and you should not set a directive to run below 8,500. The phase values are double words, where the high word indicates the FBA phase and the low word indicates the ordinal value within an FBA phase. You can view a log (Fbalog.txt) of the FBA process in the Windows\FBA directory on the target device after FBA has run. If you have a kernel debugger attached while FBA executes, the logging information is forwarded to the debugger as well as written to the log file. Custom Resources You add custom resources to enhance the functionality of a component when you create a component in Component Designer. However, custom resources are also FBA commands, because FBA controls their execution. During first boot, FBA uses these commands to populate the registry, set up application shortcuts, specify replacements for end-of-life components, and perform actions that cannot be done during the building of a configuration, such as Component Object Model (COM) registration. You use Target Designer to add custom resources to a configuration. FBA DLL or COM Registration This resource is required for any component that needs to register a COM InProc server. FBA uses functions from the Win32 application programming interface (API), including LoadLibrary, DllRegisterServer, DllUnregisterServer, and DllInstall, to register and load the DLLs containing the COM objects. Component Branch This resource is used to specify a replacement component for a component that is set to an end-of-life (EOL) state. When an EOL component is replaced by multiple components, one branch resource is added to the EOL component for each replacement component. Branch resources are only used in EOL components. However not all EOL components require replacements in such a case there is no branch. In other cases there is only one branch which means that the EOL component is replaced by one new component.

6 148 Chapter 5 Generating and Deploying an Image PnP Device ID This resource is used to insert PnP information into a device component, and is required for PnP device drivers. As already mentioned in Chapter 4, you should not add PnP resources manually to a component, because these are created automatically when you import an INF file into Component Designer. RunOnce Request This resource is used to execute an application during the first start of the run-time image, after first boot, or after every logon. This functionality is added to the run-time image as one of three registry keys: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion \Run. The Run key is processed after every logon. The Explorer shell runs it if present, otherwise either Custom Shell, Command Shell, or Task Manager Shell run it. If FBA processes this key, it does so after every logon, not during first start as it normally would. Typically, this key is used to load system tray applications, launch services in executables, hide auto start applications, or hide background processes. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion \RunOnce. FBA processes the RunOnce key only once after PnP device enumeration and DLL registration processing have completed. The values of this registry key are deleted from the registry after it is processed, so that it will not run again. Typically, this flag is used when a restart is required, such as for a DLL or OCX registration. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion \RunOnceEx. The RunOnceEx key is processed only once, by the Explorer shell, after the first logon. The values of this registry key are deleted from the registry after it is processed, so that it will not run again. If the Explorer shell is not present, this key is ignored. Typically, this flag is used for a process that runs only once, and that either cannot be run correctly by FBA or requires the system to be fully operational.

7 Lesson 1: Generate the Pre-FBA Image 149 Service Data This resource is required for components that define a Windows service. Start Menu Shortcuts This resource is used to create shortcuts on the Start menu or on the desktop if these are part of your image. FBA Generic Commands This is a custom resource which is required for a component that needs programs executed during FBA on the run-time image. FBA calls CreateProcess from the Win32 API to run a program and optionally pass it command-line arguments. Prepare for Cloning Before you prepare to clone your image, make sure that the configuration accurately reflects the hardware of your target device and that you have verified its functionality on your target device. Then, add the System Cloning Tool component to your configuration, which is located under Software>System>System Services>Base folder in component browser. After you add it to the configuration, you can configure its settings or leave the default settings. The next lesson covers the settings for the cloning tool. Lesson Summary This lesson introduces the tasks you have to perform before you build and deploy your production image. You need to stamp your image with a PID key for the image to become a production image that does not expire after 120 days. You create all the custom resources you need for FBA to prepare your raw image to function as intended. Finally, you must plan for mass deployment by adding the System Cloning Tool to your configuration. You complete a final dependency check, build your image and save your configuration file.

8 150 Chapter 5 Generating and Deploying an Image Quick Check 1. What must be done in order to prevent a Windows Embedded Standard 2009 operating system from expiring? 2. Is it safe to run FBA on a development machine, and then transfer the operating system to a different machine for testing? 3. What do you add to your configuration to facilitate cloning of the operating system? Quick Check Answers 1. A retail run-time PID must be entered in Target Designer to prevent the runtime from expiring. 2. Only if the machine to which the operating system is being moved is identical to the development machine. FBA installs PnP devices, and therefore the hardware must be very similar. 3. The System Cloning Tool component.

9 Lesson 2: Seal and Clone the Post-FBA Image 151 Lesson 2: Seal and Clone the Post-FBA Image In order to deploy a Windows Embedded Standard 2009 image on multiple target devices, a unique System ID (SID) must be associated with each image that is deployed. SIDs play an important role in Windows networking and in NTFS file permissions. Unique SIDs are necessary for networked devices. Windows Embedded Standard 2009 includes the System Cloning Tool component to help you assign unique SIDs to your devices. You include this component in your configuration when you want to clone your run-time image for mass deployment purposes. See Figure 5-1 for an overview of the cloning process. Build OS raw image New OS Transfer to Master Master Run FBA System cloning OEM image customization Final Master Figure 5-1 System Cloning overview After this lesson, you will be able to: Understand the cloning process. Configure the System Cloning Tool component. Prepare for production deployment. Estimated lesson time: 15 minutes. System Cloning Tool Component The System Cloning Tool component contains the system cloning tools Fbreseal.exe, Setupcn.exe, and Setupcl.exe. This component also provides the minioc.inf file, which is an INF file that references the DLLs that are required to prepare components for duplication. After you add this component to your configuration you can configure its settings. In the details pane of the components settings, navigate to the System Cloning Tool tab, as shown in Figure 5-2.

10 152 Chapter 5 Generating and Deploying an Image Figure 5-2 System Cloning Tool There are three main sections in this settings page. The first is the Reseal Phase section, which enables you to select either Automatic (default and runs in phase 12,000 of the FBA process) or Manual, which sets the reseal phase to 0. With the Manual option, only the cloning tools are copied to the run-time image, the cloning phase does not occur, and you must manually use the Fbreseal.exe utility to start the reseal phase. The second is the Reseal Options section, which enables you to choose from the following reseal options: Generate New Computer Name Check to generate a random computer name for the client, for example: OEM-HUDVHELDDYQ. Unchecking tells the cloning process to preserve the existing computer name. Unjoin Domain (if joined) Check to unjoin the machine from a domain after cloning. Uncheck to retain the domain membership after cloning. Remove AutoLogon Settings Check to remove Automatic Logon after the cloning process. Uncheck to keep the Automatic Logon feature enabled after the cloning process. Remove Custom Network Settings Check to remove all network settings, including network bridges, during cloning. Uncheck to retain all network settings after cloning.

11 Lesson 2: Seal and Clone the Post-FBA Image 153 Remove Custom User Settings Check to remove all user specific settings, including start menu customizations and most recently used file lists, during cloning. Uncheck to retain all user specific setting after cloning. Remove Mounted Devices (such as network drives) Check to remove all references to mounted drives, such as floppy or CD drives, including changing drive letters, during cloning. Uncheck to retain mounted drive settings after cloning. The third section is optional and provides two more fields. The first enables you to enter the path and name of the DLL that provides the OnComplete function. The second enables you to enter the name of the function that runs after the reseal is complete (which by default is named OnResealComplete) and returns a Boolean value. Entering values in these fields enables you to display a custom message during reseal. You can leave these last two fields blank for reseal to display the default reseal message. If you enter any of these two strings incorrectly it will revert to the default message. Reseal Phase Typically, the reseal phase occurs just before the restart that precedes the cloning phase. After the reseal phase completes, you must immediately turn off the device before the subsequent restart occurs. The on-disk image is now ready for cloning. By resealing the run-time image, a subset of FBA runs when the image is deployed on other devices. This subset identifies new devices and resets the SID. Cloning Phase The cloning phase automatically begins the first time the image starts after the reseal phase, except if you checked the Manual reseal phase (0) in the System Cloning Tool settings in Target Designer. Typically, cloning occurs after the on-disk image from the master has been copied to a cloned device. The clone device picks up FBA where the master device left off after the reseal phase. During the cloning phase, FBA replaces the SID of the master device with a unique SID everywhere the SID appears. This makes each clone unique, yet preserves the other settings of the master image. See Figure 5-3 for an illustration of an overview of the cloning process.

12 154 Chapter 5 Generating and Deploying an Image Master Clone Master Master Master Clone Master Clone FBA Phases FBA Phase 1200 Copy master image to target devices Cloning Reseal and Reboot FBA Second boot FBA Figure 5-3 Cloning process overview Creating a Run-Time Image for Cloning You start the cloning process by building a run-time image in Target Designer for a device that closely matches the hardware being manufactured. Add the System Cloning Tool component to your configuration. In the configuration editor, select the component settings these are displayed in the details pane. To configure the component, see the System Cloning Tool Component section at the beginning of this lesson for a detailed description of the settings configuration. Save the configuration file, check dependencies, and build the image. After the image is built, copy it to the target device. Starting a Run-Time Image for Cloning One reason you might decide to select manual cloning is if you need to install additional applications after FBA runs. To do this, start the run-time image on the master target device, enabling FBA to run. After the FBA process completes, you can update your run-time image by installing additional applications. When the run-time image is ready to be deployed, run the Fbreseal utility. This utility resets FBA so that when a run-time image is deployed, a new computer name and SID are generated.

13 Lesson 2: Seal and Clone the Post-FBA Image 155 After the master run-time image is created, copy the master run-time image to your target device and start the device. After FBA completes, you can distribute the clone target device. Lesson Summary This lesson covers how to prepare your image for production deployment. You should not simply copy the raw image that you created with Target Designer to each device, especially if they are networked. Each device must have a unique SID if part of a network. The cloning process provides a solution that creates a unique SID for each device. However, you have to prepare your image configuration for the cloning process. You add the System Cloning Tool component that contains all the cloning tools. You can provide your own tool in the form of a DLL. This DLL must provide an entry point which is an exported function that is called when the reseal phase is completed. Quick Check 1. How does the cloning process assign a unique SID to each cloned device? 2. What is the default reseal phase of the cloning process? Quick Check Answers 1. The System Cloning Tool component resets the FBA phase so that when a run-time image boots for the first time a unique SID and computer name are assigned to the system. 2. The reseal phase occurs at the end of FBA on the master device and is used to reset a run-time image for cloning. The run-time image is typically resealed after the FBA phase has finished and resumes a subset of FBA actions on the cloned device, one of which is generating a new SID.

14 156 Chapter 5 Generating and Deploying an Image Lesson 3: Prepare Target Media for Deployment This lesson discusses the media structure: layout of the target media, how it relates to the overall start process of Windows Embedded Standard 2009, and the process of preparing the target media, including using the Bootprep tool. The Bootprep tool prepares a disk with a FAT file system partition that contains the boot sector. After this lesson, you will be able to: Understand the media structure needed to boot Windows Embedded Standard Understand the start process. Prepare the media. Use the Bootprep utility. Estimated lesson time: 30 minutes. Media Structure All disks used to start any Windows operating system contain at least a Master Boot Record (MBR), boot sector, and a primary partition. The MBR is located at sector 0 and is the most important area on a hard disk because it contains the partition table for the disk and a small amount of executable code called the master boot code. The boot sector is a critical disk structure for starting your computer, located at sector 1 of each volume. It contains executable code and data that the code requires, including information used by the file system to access the volume. The boot sector is created when you format the volume. The primary partition is a volume created using unallocated space on a basic disk. Windows operating systems 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. 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. See Figure 5-4 for a visual depiction of the structure of a FAT32 disk prepared to start a Windows operating system.

15 Lesson 3: Prepare Target Media for Deployment 157 MBR Boot Sector Windows Embedded Boot Sector Boot Sector Boot Sector Partition 1 Partition 2 Partition 3 Partition 4 Figure 5-4 Bootable disk structure 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 per physical disk can be an extended partition, and no primary partition needs to be present to create an extended partition. The Boot Process After you turn on your device, the boot process starts with the BIOS performing various tasks such as Power-On Self Test (POST), PnP initialization and detection, and looking for a bootable device. The BIOS boot sequence is typically configurable, and can be modified to start from any of the existing bootable devices. The BIOS then loads the MBR from the hard-disk. The MBR contains information about the partition structure of the disk the 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. The boot sector switches control to NTLDR, providing it with information about the disk. NTLDR first switches the processor to virtual memory mode. When x86-based computers first start, they are running in real mode. Because NTLDR is a 32-bit program, it must switch the processor to 32-bit flat memory mode before it can perform any other functions. It then starts the appropriate mini file 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. NTLDR continues to read the Boot.ini file, and displays the operating system selections. This screen is referred to as the boot loader screen and enables you to select an operating system. In Windows Embedded Standard 2009 the Boot.ini options are not displayed because the default timeout is set to 0 seconds. Then

16 158 Chapter 5 Generating and Deploying an Image NTLDR executes Ntdetect.com to gather information about currently installed hardware. Ntdetect.com should be in the root of the disk along with NTLDR. Then it loads Ntoskrnl.exe and Hal.dll into memory. NTLDR then loads all drivers which are configured to start, and finally passes the hardware information collected by Ntdetect.com to Ntoskrnl.exe, and then passes control to Ntoskrnl.exe. Preparing the Media You need to prepare the storage media to be able to boot Windows Embedded Standard 2009 on your device. This involves creating a primary partition on the media, marking it active, and then formatting the media for either the FAT or NTFS file system. If you format using MS-DOS tools, use the bootprep.exe tool to create a boot sector on the partition. Bootprep Utility Use the BootPrep.exe command-line tool when media is formatted under MS-DOS to boot into Windows Embedded Standard Bootprep can only be run on FAT32, FAT16, or BigDOS FAT16-formatted media. NTFS devices do not require Bootprep. Bootprep changes the boot sector from a MS-DOS boot sector to NT Boot sector. It also enables you to back up the MBR and boot sector contents. To get help on all the possible arguments BootPrep accepts type BootPrep /? at the command line. Lesson Summary This lesson introduced the structure of the media that is required for Windows Embedded Standard The media structure needs to have an MBR and a primary partition containing a boot sector marked as active. If you use CompactFlash as your storage media and set up EWF to store overlay data in disk mode or RAM mode, you need to remember to create a second partition for EWF. For details, see Chapter 3. The lesson also introduces the BootPrep utility to help prepare an MBR on media partitioned and formatted by MS-DOS tools. NOTE CompactFlash preparation You should not repartition your CompactFlash media with Windows XP Pro partitioning tools. If you want to partition your CompactFlash, contact your CompactFlash manufacturer for their supported CompactFlash tools. You can also create an MS-DOS bootable floppy disk with Windows 98 or Windows ME. This boot disk includes fdisk. You can use fdisk to partition your CompactFlash media.

17 Lesson 3: Prepare Target Media for Deployment 159 Quick Check 1. Bootprep modifies which region of a disk? Quick Check Answers 1. Bootprep installs a Partition Boot Sector onto the partition of the disk specified. This is the partition that contains the Windows Embedded Standard 2009 operating system.

18 160 Chapter 5 Generating and Deploying an Image Lesson 4: Deploy the Post-FBA Image to the Target Device You deploy your post-fba run-time image to your device during the production phase in the manufacturing plant, or deploy it to media that your customer installs. During the maintenance phase, you can deploy an update by replacing the run-time image already installed on a device with a newer version of that image. The Windows Embedded Standard 2009 run-time image is built in a folder tree that contains multiple folders and files; therefore you must deploy the entire tree to a bootable partition. This bootable partition can be on either a hard disk drive, CD, DVD, or Flash memory device, and must be visible to the device BIOS. This lesson discusses the possible ways you can deploy your image. After this lesson, you will be able to: Understand how to create a bootable CD. Understand how to create a bootable CompactFlash. Boot your device, if hardware permits, from a USB mass storage device. Understand and use the System Deployment Image tool. Estimated lesson time: 25 minutes. Bootable CD Using the El Torito Bootable CD-ROM Specification, you can create a single CD image and duplicate it for use on many target devices. Running the operating system from read-only media also protects the integrity of the file system from potential corruption. The El Torito specification supports the creation of a bootable CD as an image of a hard disk drive or a floppy disk drive. When you create an image of a hard disk drive, the CD will start as drive C and all hard disk drive letters are shifted down one letter. Preparing the Image Configuration for a Bootable CD Because bootable CDs are read-only media, you must include the EWF component, set to RAM REG mode, in your image configuration to redirect all writes made to the CD. You must replace the NTLDR component with the EWF NTLDR component. Because EWF must be disabled when FBA runs on the target device, you have to clear the Start EWF Enabled check box of the EWF component settings. Verify that Disk Number equals 0 and Partition Number equals 1 for the target disk volume and leave

19 Lesson 4: Deploy the Post-FBA Image to the Target Device 161 the default values for all other settings. You also have to add the El Torito CD component, leave the default disk signature, and build your image. To enable EWF after the FBA process completes, you must run this command: EWFMGR C: -enable Creating a Bootable CD To create a bootable CD, you must prepare the hard disk drive on which FBA runs. This hard disk drive must have a bootable FAT partition smaller than that of the target media as the first partition. A partition size of 625MB is recommended. You can use FAT32, FAT16, or NTFS. FAT32 is recommended. If you use FAT16, keep in mind you must use Bootprep.exe on your disk. At least 8 MB of raw, unallocated space must be available on the disk for FBA to configure EWF. After you run FBA, you have a bootable image on your hard disk. Use Hd2iso.exe to create an ISO-9660 image, which you can then burn to a CD to create a bootable CD. Bootable CompactFlash Windows Embedded Standard 2009 supports deploying run-time images to CompactFlash devices. Because the lifetime of a CompactFlash device is limited, it is recommended that you protect the device with EWF. Configure your run-time image to support EWF RAM REG mode and deploy it to the CompactFlash device. Bootable USB Flash Media Starting from USB media is possible only if your target device has a BIOS that supports booting from USB 2.0. Because of performance limitations, you should only use USB 2.0 devices. Your USB storage device must have an MBR and a formatted primary active partition. The UFDprep.exe utility is a complete format and partition utility for USB flash disks. This utility is located in Program Files\Windows Embedded\utilities folder. You have to add the USB Boot 2.0 component, located in the component browser under the Embedded Enabling Features folder, to your image configuration. This component forces the addition of two more related components a special version of NTDETECT, called USB NT Hardware Detect, and the USB Boot Mass Storage Device component.

20 162 Chapter 5 Generating and Deploying an Image System Deployment Image System Deployment Image (SDI) is a virtual disk format for storing and deploying Windows Embedded Standard 2009 run-time images. SDI files are mounted as virtual disks so that Windows Embedded Standard 2009 images can be copied to them. SDI files are used with Windows Embedded Standard 2009 tools to help in the deployment of the operating system. SDI files store a Windows Embedded Standard 2009 image in a single file that can be backed up to a file server 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. An SDI file is divided into two parts, a header and a set of four data blobs: Boot Blob, Loader Blob, Partition Blob, and Disk Blob. See Figure 5-5 for a visualization of the SDI file format. Header The Header Blob 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 RAM disk, and then boots the run-time image from the Partition Blob. Partition Blob The Partition Blob contains the run-time Windows Embedded Standard 2009 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. Disk Blob The Disk Blob is the virtual disk when mounted (on-line) by SDI Loader.

21 Lesson 4: Deploy the Post-FBA Image to the Target Device 163 Header Boot blob SDI signature Boot offset and length Extensible (4K) Disk blob Figure 5-5 Loader blob Partition blob SDI File format Boot program StartROM.Com Real mode executable file Call NTLDR.Exe Loader program NTLDR.Exe Mounts partition blob as RAMDISK Boots into RAMDISK Target run-time image Post FBA XPE image SDI provides three tools for building, editing and extracting images: SDI Loader Graphical interface 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 A 16-bit version of the SDI Manager tool, used only for deployment. Lesson Summary This lesson discussed some of the possible bootable media. For some media, such as a bootable CD or USB, you need to add specific components that provide the support needed. Others just need to be prepared correctly to be bootable. SDI is a virtual disk format designed for storing and deploying Windows Embedded Standard 2009 images.

22 164 Chapter 5 Generating and Deploying an Image Quick Check 1. Why do you have to add the EWF component to an image that will boot from CD? 2. What must be done to boot Windows Embedded Standard 2009 from a USB 2.0 mass storage device? 3. What is System Deployment Image? Quick Check Answers 1. Because bootable CDs are read-only media and cannot be written to. 2. USB 2.0 Boot and USB NT Hardware detect must be part of the image. The target system must support USB 2.0 flash disk boot. The drive needs to be formatted with ufdprep.exe. 3. SDI is a virtual disk format for storing and deploying Windows Embedded Standard 2009 run-time images. SDI files can be mounted as disk volumes on the development workstation or a target device, and the Windows Embedded Standard 2009 run-time image can be copied to such a volume.

23 Lesson 5: Implement a Remote Boot Solution 165 Lesson 5: Implement a Remote Boot Solution The Remote Boot service for Windows Embedded Standard 2009 is an implementation of Preboot Execution Environment (PXE) and enables a suitably configured Windows Embedded Standard 2009 device to start using a PXE server. The remote boot process transfers the image to the client device using the Trivial File Transfer Protocol (TFTP) on a connected device. This solution is ideal for diskless devices, with no persistent storage. The remote boot solution requires that your client device have a PXE-compatible BIOS, PXE-compatible network adapter, and enough RAM to store and run your Windows Embedded Standard 2009 run-time image. A general rule is that the RAM must be twice the size of the Windows Embedded Standard 2009 image. After this lesson, you will be able to: Create a Remote Boot image for deployment over a network. Setup and configure the Remote Boot Service. Configure a Dynamic Host Configuration Protocol (DHCP) server for Remote Boot Service. Estimated lesson time: 20 minutes. Creating a Remote Boot Image First, you must verify that the available RAM for the client computer accommodates the size of the run-time image and required run-time RAM to be copied to the RAM disk. Also, check that the available RAM provides enough free space for the image to operate once it has been installed. Using Target Designer, create a run-time image for your Remote Boot device. Configure the run-time image to start from drive C. Include the Windows RAM Disk Driver component in your image. Verify that your image is smaller than the total available RAM to ensure that additional free space is available for temporary files, such as Internet Explorer cache files. You then add the System Cloning Tool component to your image. You must verify that you did not add any custom components that will cause a restart of the client computer after the cloning operation has completed.

24 166 Chapter 5 Generating and Deploying an Image Preparing a Remote Boot Image for Deployment The FBA service requires one or more system starts, making it unusable with the Remote Boot service. Therefore, you must run FBA before creating the deployable Remote Boot image. Copy the run-time image to the C drive of your target system. Run your run-time image on the target system to let FBA complete. If you installed the System Cloning Tool component, FBA will complete operation when the Machine Resealed message appears. Preparing a Remote Boot Image for Deployment In the BIOS setup utility of the client computer, configure the BIOS to start from the network. Install the SDI Driver on your development system. Create an SDI virtual disk of the appropriate size using the SDI loader utility. Format the SDI virtual drive using Disk Management Console, Diskmgmt.msc. When prompted, do not choose to create the volume as a dynamic disk. Copy your run-time image to the SDI volume. It is not necessary to copy the Ntdetect.com, Ntldr.exe, or Boot.ini files to the SDI volume because they are automatically downloaded from the server during an early phase of remote boot. Create another SDI image that will contain the partition for the SDI disk you created. This will be the final SDI image that will reside on the remote boot server. The following command line example shows how to create the new SDI image using the SDI manager command line utility. sdimgr /new c:\ramdisk.sdi sdimgr c:\ramdisk.sdi /readpart:e: Copy the SDI image to the \Windows Embedded\Remote Boot Server\Downloads folder of the server. If you wish to use a Boot.ini file that resides on the server, you must add the /rdimageoffset=4096 switch to the Boot.ini file to accommodate the structure of your SDI file. This step is not necessary if you are using the Remote Boot manager and not a Boot.ini file with an SDI image that uses an SDI extension. 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. Configuring the Remote Boot Service The Remote Boot manager is a tool that edits the policy list parameter information stored in \Windows Embedded\Remote Boot Service\Rbsprov.ini for the Remote Boot service and the registry. This enables you to quickly set up the Remote Boot service and configure it according to your specifications.

25 Lesson 5: Implement a Remote Boot Solution 167 Configuring DHCP for Remote Boot Services The Remote Boot service requires a configured DHCP server to be present on your network. The DHCP server initiates the communication between the PXE client device and the Remote Boot server, enabling the client device to retrieve necessary image information from the server. The DHCP server must be configured with a static IP address. The DHCP server must have an assigned IP address range. Exclusion ranges for all devices on the network that do not support DHCP should be entered. IP address reservations should be created as needed. If you choose to configure Remote Boot service and DHCP to reside on the same server, you must configure the Remote Boot service to communicate using a port that does not conflict with DHCP. Starting and Stopping Boot Services By default, the Remote Boot Setup Wizard automatically starts both the Remote Boot service and TFTP service and configures them to start automatically. However, you can stop or start any service manually by using either a command prompt or by running the Services.msc snap-in. For example, to stop the Remote Boot service you enter at the command prompt: Net stop rbspxe Alternatively, you can use the services console and right-click Remote Boot Service, and then select Stop. Boot.ini File in a Remote Boot Environment You can use the Boot.ini file instead of the settings within the Remote Boot manager to start the appropriate image on a client device. You can create a custom Boot.ini file to present the client device operator with a choice of images to load. If the default Boot Image and Boot Parameters fields on both the device and in Remote Boot manager are left empty, the remote boot client will download a Boot.ini file from the \Windows Embedded\Remote Boot Server\Downloads directory to determine the run-time image to be used. You can force each remote boot device on your local network to start using your custom Boot.ini file by verifying that the Use default settings to boot unspecified clients option has been selected in the Remote Boot manager. You must run the image through the FBA process to complete the build process before the image can be used for remote network boot.

26 168 Chapter 5 Generating and Deploying an Image Here is an example of boot.ini for a remote boot client operator: [boot loader] timeout=30 default=ramdisk(0)\windows [operating systems] ramdisk(0)\windows="myremoteclient" /fastdetect /rdpath=net(0)\mrc.sdi /rdimageoffset=4096 ramdisk(0)\windows2="myremoteclient2" /fastdetect /rdpath=net(0)\mrc2.sdi /rdimageoffset=4096 Lesson Summary This lesson discussed the remote boot option for deploying a Windows Embedded Standard 2009 operating system image. A Windows Embedded Standard 2009 image can be downloaded over a TCP/IP network using the target s PXE boot agent support and the Remote Boot Manager provided in Windows Embedded Standard 2009 to configure Remote Boot service. The remote boot option is ideal for thin clients with no local storage devices or point-of-sale devices. You need a Windows 2000 Advanced server or later to act as the remote boot and DHCP server. The image stored in an SDI file is downloaded and runs in the targets RAM. Quick Check 1. Is Remote Network Boot used to install the Windows Embedded Standard 2009 image on a remote system? Quick Check Answers 1. No. Remote Network Boot is used for remote download of an image over Ethernet and boot/run from RAM. One could create an image that allows the downloaded image to pull down a separate image that gets installed on a hard drive, if present.

27 Lab 5: Implementing Remote Boot 169 Lab 5: Implementing Remote Boot In this lab you practice the creation of a USB bootable image and a remote boot implementation. Practice 1: Booting from a USB 2.0 Flash Disk In this practice, you create an image to start from a USB 2.0 flash disk. The target system must be able to support USB 2.0, and its BIOS must support starting from a USB. Create the Image 1. Before beginning, you must create a Platform Macro component by capturing the PMQ file with TAP on the target system and importing it to your configuration. The Platform Macro component contains the hardware components for this configuration. 2. Open Target Designer and create a new Windows Embedded Standard 2009 configuration called WESUSB. 3. Add the following components to the new configuration: NT NTLDR. Minlogon. Task Manager Shell. FAT. NTFS. CMD (Windows Command Processor). English Language Support. USB 2.0 Boot. 4. Add the Platform Macro component to the new configuration. 5. Check dependencies, resolve any errors, and re-check dependencies. 6. Build the image. Prepare the USB Flash Disk and Transfer the Image Windows Embedded Standard 2009 Studio comes with a flash format utility (ufdprep.exe) that can prepare the USB flash disk to boot Windows Embedded Standard 2009.

28 170 Chapter 5 Generating and Deploying an Image 7. Insert the USB flash disk into an open USB 2.0 port. Note the drive letter assigned to the flash disk. 8. Open the command prompt. 9. Change directories to the \Program Files\Windows Embedded\utilities. 10. Run the ufdprep.exe utility for the USB flash disk: C:\>ufdprep <drive letter> 11. Close the command prompt when finished. 12. Open File Explorer. 13. Transfer (copy and paste) the Windows Embedded Standard 2009 image from C:\Windows Embedded Images to the USB flash disk. 14. When the transfer is completed, eject the USB 2.0 flash so you can safely remove the drive from the development machine. BIOS Setup and Test 1. Make sure that your target is powered off. 2. Insert the USB Flash disk into an open USB 2.0 port. 3. Power on the target and access the BIOS setup utility. Depending on your system, it may post a BIOS message stating it found the USB Flash disk during boot. 4. 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 flash disk needs to be set for hard drive emulation. c. The system boot order must include the USB Flash disk. 5. Save the BIOS changes and let the system boot to the USB flash disk. Once FBA completes, the system should boot to Task Manager Shell.

29 Lab 5: Implementing Remote Boot 171 Practice 2: Implementing Remote Boot In this practice you create a remote boot image. Because the Windows Embedded Standard 2009 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. Create the Image for Remote Download 1. Open Target Designer and create a new configuration called RemoteThinClient. 2. Add the following components to the new configuration: a. Thin Client macro. b. Explorer Shell. c. NT NTLDR. d. NT Hardware Detect. e. FAT. f. CMD. g. English Language Support. h. System Cloning Tool. 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 the 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 twice the size of the image. 4. Add the platform macro component to the new configuration. 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 the Image folder is not empty, 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.

30 172 Chapter 5 Generating and Deploying an Image Run the Image on the Target System 1. Restart the target to run the FBA process. 2. In order for the image to download and run on the target, the image must run through the complete FBA process to finish setup of the image. Create the SDI Files 1. Install the SDI Driver on your development system. 2. On the development computer, open SDILoader and create a new SDI file called RBTC.sdi. The partition size should be slightly bigger than the image size. For example: If the image size is 208 MB make the partition size 256MB. The target s RAM must be twice the size of the partition size or the image will fail to load. See Figure 5-6 and 5-7 for a visual description. Figure 5-6 Specifying the disk size 3. Format the SDI virtual drive for FAT using Disk Management Console, Diskmgmt.msc. When prompted, do not choose to create the volume as a dynamic disk. See Figure 5-7 for a visual depiction.

31 Lab 5: Implementing Remote Boot 173 Figure 5-7 The created SDI disk 4. When the target completes the FBA process, copy the post-fba image from the target to the new mounted SDI disk. It is not necessary to copy the Ntdetect.com, Ntldr.exe, or Boot.ini files to the SDI volume because they are automatically downloaded from the server during an early phase of Remote Boot. The System Volume information folder cannot be copied to the SDI drive. 5. Using Sdimgr.wsf, create a new SDI file that will be used for the remote download, and copy the contents of the Rbtc.sdi into the final SDI file: cscript sdimgr.wsf /new C:\Users\Admin \Documents\rbtcram.sdi cscript sdimgr.wsf C:\Users\Admin \Documents\rbtcram.sdi /readpart:f: 6. Copy RBTCRAM.sdi to the Windows 200x Server, and place the file in the \Program Files\Windows Embedded\Remote Boot Service\Downloads directory. Un-mount the Rbtc.sdi drive and close SDI Loader. 7. Un-mount the Rbtc.sdi drive and close SDI Loader.

32 174 Chapter 5 Generating and Deploying an Image Setup Remote Boot Manager and Download to the Target 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: a. MAC address of the target network adapter b. Description: Anything you want c. Action: boot d. Boot Server: (default) e. Boot Program: startrom.n12 NOTE Unattended Boot Process This step enables starting from an unattended remote image. This does not require the user to press the F12 key to initialize the Remote Boot service. f. Boot Image: RBTCRAM.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 addresses. 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. 6. The image loads into RAM, boots to Windows Embedded Standard 2009, and runs the Explorer Shell.

33 Chapter 5 Review 175 Chapter Review Key Terms Production means that you may have to install your system on hundreds of devices, or more. Unless each of these devices is a standalone device not connected to a network, you have to perform the task of assigning a unique SID to each device you produce. If you just copy the same post-fba image to each device, each device would have the same computer SID. Every computer running a Windows XP-based operating system should have a unique computer SID. Alternatively, you can run FBA on each device, but this is impractical in a typical production environment. The system cloning process is used during manufacture to ensure that each device has a run-time image containing a unique computer SID and computer name. Windows Embedded Standard 2009 offers a variety of media for deploying a correctly configured image that has been cloned and resealed: Bootable CD. Compact Flash. Bootable USB 2.0 mass storage devices. Remote boot. Do you know what these key terms mean? You can check your answers by looking up the terms in the glossary at the end of the book. FBA. Reseal and Cloning. System Deployment Image (SDI). Remote Boot. Preboot Execution Environment (PXE). Suggested Practices To help you successfully master the exam objectives presented in this chapter, complete the following tasks.

34 176 Chapter 5 Review Use Kernel Debugger During Boot This is of particular interest to you if you are going to create a headless device. A headless system does not require a keyboard, mouse, or video graphics adapter (VGA) card during operation. Therefore, you must be able to gain access to the headless system so that it does not require user interaction at a local console. First create a run-time image. Before FBA runs for the first time, add the appropriate parameters to your Boot.ini file. The following example shows the parameters. For example: /debug /debugport=com1 /baudrate= Connect a remote debugger to your target system using a serial cable. Use the debugger to monitor FBA status of the headless system. The headless system reboots one or more times during this process. When the message "[FBA] Leaving Run Mode" is displayed, FBA has completed, and the OS has installed and is running on the headless system. To view the drivers that are loaded, use the debugger to break into the OS, and then use the!drivers command. Confirm that the Tsddd.dll driver is loaded on your headless system instead of Vga.sys.