The Enhanced Write Filter
When considering the Enhanced Write Filter component, first review these on-line MSDN resources:
Enhanced Write Filter
Controlling EWF by Using the EWF APIs
Using CompactFlash (CF) with the Enhanced Write Filter (EWF)
Using the Enhanced Write Filter (EWF) in Windows XP Embedded
How to use Enhanced Write Filter (EWF) on removable media
Dismounting Volumes in a Hibernate Once/Resume Many Configuration
Building and Deploying Windows XP Embedded Images
Enhanced Write Filter API
Configuring a Hard Drive with Diskpart and Windows PE
Hibernation and EWF
What Is the Typical Amount of RAM Required for RAM-based EWF?
The Enhanced Write Filter (EWF) is an Embedded Enabling Feature (EEF) included as a part of Standard 2009. EWF provides a means of protecting a volume from disk writes.
Comparison between RAM and Disk-based Enhanced Write Filter (EWF)
RAM: After you reboot, all changes to the protected volume are gone. This is referred to as stateless because the system comes up in the exact same state post-boot.
Disk: After you reboot, all changes still exist. Changes can be committed to the protected partition. The disk-based EWF has the ability to have different levels of changes. The partition can be restored to different levels of changes or back to original.
Deployment considerations
Be sure to use the Enhanced Write Filter (EWF) version of NT Loader (EWF NTLDR) if you are using EWF to maintain disk-based overlays to protect your system volume.
The Enhanced Write Filter and Hibernation
The Enhanced Write Filter (EWF) does not allow hibernation if hiberfil.sys resides on a protected volume. If the hibernation file is not on a protected volume, EWF functions as expected.
EWF Applications
Included here are common EWF usage scenarios.
Conversion of read-only storage so it appears to be writable
Converting read-only storage media such as flash media, CD-ROMs and write-protected hard disks, into read/write media, allows you to use read-only storage media as the system boot device for Standard 2009. This is particularly helpful with respect to extending the life of write-wear-limited storage devices such as devices that use flash memory.
A volume that resides on read-only media can be “converted” into a read-write media because EWF copies sectors that have been modified into a special data cache referred to as an overlay. The overlay can reside in system memory, or it can reside in writable storage, within a specially prepared storage partition called the “EWF partition”.
Establishment and maintenance of disk volume state snapshot checkpoints
If the volume being protected is located on writable media, and the overlay resides in the EWF partition (also located on writable media), EWF offers the ability to (1) revert to an arbitrary restore point, and/or (2) to “commit” (i.e. collapse) the disk changes contained in all overlays, back to the original volume being protected.
You can protect a maximum of 9 volumes. Each volume can have a maximum of 9 overlay snapshot levels.
Using EWF to limit writes to flash by batching the writes (EWF RAM or EWF RAM-REG)
If you want changes persisted yet do not want to shorten the write lifetime of the flash, you can use EWFMGR c: –commit followed by a reboot, to persist all the current session changes in one batched write operation.
Alternately, you can use EWFMGR c: -commitanddisable -live without requiring a reboot.
Protecting the device against surprise power removal
You can use EWF-RAM to protect disk drive content against any corruption such as that caused by surprise power loss. The system always boots up in the exact same state as prior reboot(s).
EWF-DISK is not as useful as EWF-RAM in protecting the disk against surprise power removal. The current overlay risks getting corrupted, so you risk not being able to boot up to a functional operating system after surprise power removal. If you do manage to boot up successfully, you can then use EWFMGR to revert to the prior overlay level in order to eliminate the corruption.
For more information:
File system and/or disk media content corruption issues
EWF Functional Modes; defined
Throughout this document the following terms are used to reference the three basic functional modes of EWF:
EWF-DISK mode
In this implementation, modified disk sectors are redirected to disk overlay in a (required) EWF partition. This protects data on a disk from being altered or corrupted.
Media must be capable of being configurable with more than one partition, i.e. it cannot be marked as a removable media type. This is required to accommodate the EWF partition where EWF stores its cached sectors.
After reboot, changes still exist (in the EWF partition). Changes can be committed to the protected partition. EWF has the ability to maintain up to 9 overlay layers per protected volume, depending on the number of checkpoints established. When a checkpoint is created, this (1) snapshots the current state, persisting it in an overlay level, and (2) starts a new overlay level. The protected drive can be restored to different levels of changes or it can be restored to its original state. You can use the commit command to cause all overlays to collapse (write) themselves back into the original volume. This action results in all the overlays being deleted after all their contents have been copied back into the protected volume. Note that the commit command collapses ALL existing overlays; you cannot perform a selective commit down to a particular overlay level.
Be sure to use the EWF version of NT Loader if you are using EWF to protect the system boot volume.
EWF-RAM mode
In this implementation, modified disk sectors are redirected to a volatile RAM overlay in system memory. An EWF partition is required, but contains no overlays; it is only used to retain EWF state information.
Only one RAM overlay per protected volume is allowed.
Media must be capable of being configured with more than one partition, i.e. it cannot be marked as a removable media type.
After rebooting all changes are gone. Changes can be committed to the protected volume however, using specific commands for that purpose.
Since the volume always boots up in the exact same data configuration state as the prior boot, this is sometimes referred to as “stateless” operation.
EWF-RAM configured to boot from a Hibernation File
You can use EWF-RAM combined with a hibernation file, to improve the boot time of a system. Resuming the system from a hibernation file is typically faster than normal system startup. More information about this feature is available at MSDN online:
Hibernation and EWF
Mixing EWF-RAM and EWF-DISK
It is possible to configure EWF to simultaneously support both EWF-RAM and EWF-DISK when multiple volumes are being protected.
A minimum requirement is that the target device must support multi-partitioned media (i.e. the media is flagged as fixed type), hence allowing a configuration EWF partition to exist.
However, to save on RAM requirements, consider this alternative deployment:
Use only DISK overlays
Set up a small service that runs on startup and issues a restore
(rundll32 ewfdll.dll EwfMgrRestore) on the partition that you don’t want persisted. This allows a partition to be “stateless” without requiring lots of RAM. Another advantage to this method is it supports paging to the non persistent volume, which means you can use a page file if desired.
EWF-RAM-REG mode
This implementation uses volatile RAM overlay in system memory, similar to EWF-RAM mode. The key difference is that there is no EWF partition; EWF configuration information is maintained in the registry instead.
This mode is commonly used for media that is flagged as Removable type and hence only allows the creation of a single partition within the media; an example of such media is Compact Flash (CF). Some CF vendors, such as SanDisk, offer a tool that allows you to change their media to Fixed type, thus allowing multiple partitions; meaning you can use EWF-RAM instead if desired.
EWF management functionality is reduced when EWF configuration information is maintained in the registry; the only functions available are:
EWFMGR :
EWFMGR : -commitanddisable
EWFMGR : -enable
EWFMGR : -commit
The command EWFMGR : -disable without a corresponding –commit will not work because the “disable” state is maintained in the registry; since the registry is not committed it will never be saved before the next boot.
If you attempt to type the command EWFMGR by itself it will report an error because there is no EWF partition. This is normal and expected.
Media can be marked as either removable or fixed type; only one partition is required.
As with EWF_RAM mode, only one RAM overlay per protected volume is allowed.
El Torito CD-ROM uses the EWF-RAM-REG technique; however, the implementation for El Torito is not included in this document; refer to a separate document for details.
Deployment considerations Functional mode vs. Storage Media selection chart
Use the following chart to help you identify which EWF Functional modes are appropriate for your application, depending on the type of storage media used:
|
ACCEPTABLE STORAGE MEDIA
|
EWF Functional Mode
|
Conventional Read-write, i.e. media that is not considered write wear sensitive
|
Read/Write but is write-wear limited (such as Flash)
|
Read-only
Such as ROM or write-protected media)
|
Read-only per El Torito
CD-ROM Specification
|
EWF-DISK
|
|
|
|
|
EWF-RAM
|
|
2
|
|
|
EWF-RAM-REG
|
|
|
|
|
Note that there is another way to boot from read-only or write-limited storage media, using SDI. See the following section in this document: “An alternative to RAM EWF using SDI”.
Runtime maintenance considerations
EWF can affect the method(s) that you use to service and update field-deployed runtime images.
Consider the following maintenance scenarios. In each case, the objective is to be able to update a protected volume with your desired changes. This involves disabling EWF, making the changes, and re-enabling EWF.
Updating an EWF-DISK protected volume
Run EWFMGR C: -disable then reboot.
Make any required changes to your runtime images. This may require an additional reboot, if updating system components or other locked components.
Run EWFMGR C: –enable then reboot.
Updating an EWF-RAM protected volume
Run EWFMGR C: -disable then reboot (alternatively, reboot, and then immediately run EWFMGR C: -commitanddisable -live).
Make any required changes to your runtime images. This may require an additional reboot, if updating system components or other locked components.
Run EWFMGR C: –enable then reboot.
Updating an EWF-RAM-REG protected volume
Reboot (to ensure RAM overlay will be set in its initial post-boot state).
Run EWFMGR C: -commitanddisable then reboot (alternatively, run EWFMGR C: -commitanddisable -live without needing to reboot).
Make any required changes to your runtime images. This may require an additional reboot, if updating system components or other locked components.
Run EWFMGR C: –enable then reboot.
Installation and Implementation Target System Requirements
If deploying a RAM based overlay, ensure that you have sufficient system memory to accommodate normal operating system memory needs, as well as additional memory to accommodate the RAM-based overlay. Consider limiting the size of the protected volume, thereby placing a ceiling on the maximum amount of RAM that can be consumed by the RAM-based overlay. You should configure the protected volume’s unused disk space so that it runs out of space before system memory is entirely consumed.
If deploying a DISK based overlay, the EWF partition should be large enough to accommodate the worst case disk write scenarios. For example, if you deploy a single 250MB protected volume that is configured with 100MB of free space, and you anticipate that up to 30MB out of the preexisting 250MB of program or data files will be modified in the future, then the EWF partition should be 100MB+30MB = 130MB in size. This will prevent overlay space from being filled up before free sector space is fully consumed. The EWF partition size never needs to be any larger than the sum of the total capacity(s) of the protected drive(s).
Embedded Database prerequisites
Minimum requirement: Windows XP Embedded Service Pack 2 or greater.
Recommended: use Standard 2009.
Setup procedure for EWF-DISK or EWF-RAM
See also:
MSDN: EWF Disk Mode
MSDN: EWF RAM Mode
Use this procedure if you plan to deploy an EWF partition on the media being protected. Note that the setup procedure for EWF-RAM-REG, which uses registry entries instead of an EWF partition in order to persist EWF state, is described later.
If you wish to deploy Hibernate Once / Resume Many (HORM), you should follow the steps below, and then study the SP2 documentation on this subject, in order to learn how to enable HORM. You can also read about it on MSDN:
Hibernation and EWF
1. Using Target Designer, include the following components in your runtime image, along with all other components you require for your specific runtime image:
EWF Manager Console application
EWF NTLDR (if EWF-DISK; otherwise you can use conventional NTLDR).
Enhanced Write Filter; uncheck (turn off) Start EWF Enabled, especially if using the System Cloning Tool
(Optional) Enhanced Write Filter API (EWF API)
Registry Editor (usually required when troubleshooting)
(Optional) System Cloning Tool
If you are planning to use the System Cloning tool in order to generate a unique computer id (SID) for each deployed runtime, be sure to also include the System Cloning Tool and then set its Advanced Property of cmiResealPhase to zero (0), or under Settings, set Reseal Phase to Manual. This setting disables automatic FBA cloning deployment, which allows you the opportunity to make custom changes to the image before the cloning step. You must manually activate the cloning tool using FBRESEAL.EXE at a later step. If you included the Automatic Logon component in your image, note that you must configure FBRESEAL so it does not overwrite the automatic logon information. To retain the settings you specified in the Automatic Logon component, set the extended property "cmiRemoveAutoLogon" in the System Cloning Tool to FALSE.
2. Edit the Enhanced Write Filter component settings, depending on whether you are configuring EWF for RAM or DISK overlay:
EWF Volume Configuration
|
(Typical EWF-RAM Overlay Configuration)
|
(Typical EWF-DISK Overlay Configuration)
|
Number of Protected Volumes
|
1
|
At least 1
|
Maximum Number of Overlay Levels
|
1
|
At least 1
|
EWF Partition Size in Kbytes
|
0 (will auto configure 32KB)
|
Large enough to accommodate all volumes and overlays.
|
Disable Background Disk Defragmentation
|
Checked
|
Checked
|
Enable Hibernate-Once-Resume-Many Mode (HORM)
|
Checked if HORM is desired
|
Un-checked
|
Protected Volume #1 (configure the entries below for each protected volume)
|
Start EWF Enabled
|
No (because you typically need to make custom modifications after FBA completes; start it later manually via EWFMGR)
|
No (because you typically need to make custom modifications after FBA completes; start it later manually via EWFMGR)
|
Enable Lazy Write
|
No
|
No
|
Disk Number
|
0
|
0
|
Partition Number
|
1
|
1
|
Overlay Type
|
RAM
|
DISK
|
Optimization Option
|
Optimal Performance
|
Optimal Performance
|
3. Choose the file system to be used in the volume you intend to protect.
The FAT file system consumes less overhead than NTFS, particularly when used with smaller volumes such as seen in flash devices. Note that FAT does not support NTFS features such as file encryption, and security features such as file permission control.
4. Implement the suggestions here: EWF Performance Considerations.
5. From Target Designer, run Check Dependencies (F5) and resolve all dependency issues.
6. Check for the following issue:
Page file support
If your configuration has Page File enabled, the page file should be located on a volume that is not protected. By default there is no pagefile in a Standard 2009 runtime. You can add support for this by checking the configurable settings in your HAL component. Examples of the HAL component are "Standard PC" component, "ACPI Uniprocessor", "Advanced Configuration Power Interface", etc.
Adjust the following registry key to relocate or rename the page file:
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management
Name: PagingFiles
Type: REG_MULT_SZ
Data: C:\pagefile.sys 150 500
Within that Data field you can adjust the NAME of the pagefile, its LOCATION and its MINIMUM & MAXIMUM values.
Note however that the pagefile must be on the System volume, for kernel dumpfiles to work.
7. From Target Designer, run Build Target Image (F7) and resolve any build issues.
8. Partition the media that you plan to run FBA on. For details, refer to the section titled Preparing storage media for EWF.
9. Copy the runtime image to the volume within the target media that you plan to use to run FBA.
10. Boot the device and allow FBA to complete. This typically requires several (automatic) reboots.
11. Inspect the file \windows\fba\FBALOG.TXT. Ensure that the EWF partition was created successfully.
If you used the kernel debugger (Windbg) and you configured for EWF-DISK, you would see output similar to the following on the second boot. This is similar to that which is seen in FBALOG.TXT except it contains a bit more information, particularly if installation fails:
14:43:29 PM - ConfigureEwf() Start.
ConfigureEwf() Start.
14:43:29 PM - Getting EWF config parameters from registry.
Getting EWF config parameters from registry.
14:43:30 PM - Non El Torito disk configuration.
Non El Torito disk configuration.
14:43:30 PM - EWF Partition Size = 32000 (KBytes), Levels = 1, Volumes = 1.
EWF Partition Size = 32000 (KBytes), Levels = 1, Volumes = 1.
14:43:30 PM - Protected Volume Config #0 :
Protected Volume Config #0 :
14:43:30 PM - Disk= 0,Part= 1,DiskType= IDE,Type= Disk.
Disk= 0,Part= 1,DiskType= IDE,Type= Disk.
14:43:30 PM - Enable= Disabled, Optimize= 0, LazyWrite= N.
Enable= Disabled, Optimize= 0, LazyWrite= N.
14:43:30 PM - Found 2 Hard Disks.
Found 2 Hard Disks.
14:43:31 PM - Deleting EWF Partition #3, disk#=0, type=69
Deleting EWF Partition #3, disk#=0, type=69
14:43:31 PM - Disk #0 layout info:
Disk #0 layout info:
14:43:31 PM - PRIMARY partition,start=0x0000000000007e00, len=0x000000007d040000, type= 7
PRIMARY partition,start=0x0000000000007e00, len=0x000000007d040000, type= 7
14:43:31 PM - PRIMARY partition,start=0x000000007d047e00, len=0x000000005da3fe00, type= 7
PRIMARY partition,start=0x000000007d047e00, len=0x000000005da3fe00, type= 7
14:43:31 PM - FREE partition,start=0x00000000daa87c00, len=0x00000000263d9c00, type= 0
FREE partition,start=0x00000000daa87c00, len=0x00000000263d9c00, type= 0
14:43:32 PM - Allocating EWF in PRIMARY partition, start=0x00000000daa87c00, len=0x0000000001f41000.
Allocating EWF in PRIMARY partition, start=0x00000000daa87c00, len=0x0000000001f41000.
14:43:32 PM - Created EWF partition on Disk = 0, partition = 3,size = 0x0000000001f41000 .Created EWF partition on Disk = 0, partition = 3,size = 0x0000000001f41000 .
14:43:33 PM - ewfOpen.
ewfOpen.
14:43:33 PM - EWF Volume Config on Disk#0, Partition#3:
EWF Volume Config on Disk#0, Partition#3:
14:43:33 PM - Segments = 499, Max Volumes = 1, Max Levels = 1
Segments = 499, Max Volumes = 1, Max Levels = 1
14:43:33 PM - ewfAdd.
ewfAdd.
14:43:33 PM - Protected Volume Config on Disk0\Partition1 :
Protected Volume Config on Disk0\Partition1 :
14:43:33 PM - Type = DISK, State= DISABLED.
Type = DISK, State= DISABLED.
14:43:34 PM - ewfClose
ewfClose
14:43:34 PM - ConfigureEwf() End, status = 0x0.
ConfigureEwf() End, status = 0x0.
14:43:35 PM - [CallEntryPointThread] C:\WINDOWS\system32\ewfdll.dll, ConfigureEwf
12. At this point the image is booted up and operational, with EWF disabled. Make any additional custom modifications to the operating system such as registry tweaks, patches, etc.
13. Enable EWF (without rebooting).
14. If you took the earlier step of including the System Cloning Tool in your configuration, and you have set its Advanced property of cmiResealPhase to 0 (or under Settings, set Reseal Phase to Manual), you reseal the image at this step (if testing; if ready to mass deploy the image, run FBRESEAL only after you have thoroughly tested the image for deployment)
Run FBRESEAL along with its optional command-line arguments; refer to
FIX: Windows XP Embedded system cloning may reset runtime information
for argument details.
15. Shut down your system and do NOT re-boot up on the XPe image; instead, save this XPe image as your Master image.
16. Partition and format the target media. The media type must be “fixed” type, in order to accommodate two or more partitions on the media. If you are using Compact Flash, refer to a discussion later in this article, describing how to change CF media type.
See also Preparing storage media for EWF for details.
17. Copy your master XPe image to the target media. You may need to use imaging tools such as Ghost to copy the EWF Partition (if used).
18. Boot up the image on the intended target device, allowing the System Cloning Tool to execute in order to uniquely identify the computer (if System Cloning Tool is used).
19. If your partition copying tool was not capable of copying the EWF Partition (partition type 0x45), you can have it created automatically, using the following technique:
19.1. Make sure there is no EWF partition on the target clone; use FDISK or run DISKMGMT.MSC from XP Pro, for example, to test this.
19.2. Generate a new EWF partition after cloning, onto the target clone, with the following command line script:
"rundll32 ewfdll.dll ConfigureEwf"
Note that if the kernel debugger is running when you execute this, you will see something like this on your kernel debugger application (such as WinDbg):
ConfigureEwf() Start.
Getting EWF config parameters from registry.
Non El Torito disk configuration.
EWF Partition Size = 32000 (KBytes), Levels = 1, Volumes = 1.
Protected Volume Config #0 :
Disk= 0,Part= 1,DiskType= IDE,Type= Disk.
Enable= Disabled, Optimize= 0, LazyWrite= N.
Found 2 Hard Disks.
Disk #0 layout info:
PRIMARY partition,start=0x0000000000007e00, len=0x000000007d040000, type= 7
PRIMARY partition,start=0x000000007d047e00, len=0x000000005da3fe00, type= 7
FREE partition,start=0x00000000daa87c00, len=0x00000000263d9c00, type= 0
Allocating EWF in PRIMARY partition, start=0x00000000daa87c00, len=0x0000000001f41000.
Created EWF partition on Disk = 0, partition = 3,size = 0x0000000001f41000 .
ewfOpen.
EWF Volume Config on Disk#0, Partition#3:
Segments = 499, Max Volumes = 1, Max Levels = 1
ewfAdd.
Protected Volume Config on Disk0\Partition1 :
Type = DISK, State= DISABLED.
ewfClose
ConfigureEwf() End, status = 0x0.
20. Make any per-clone-unique custom modifications, such as registry tweaks, files that have no component owner, files unique to the particular clone, machine name, etc.
21. An additional reboot may be necessary in order to allow some components, such as IIS, Microsoft Distributed Transaction Coordinator (MSDTC) and Terminal Services, to resynchronize with the new computer ID (SID). Some customers have observed occasional failure of these services during or after the cloning phase. This may occur owing to the timing of the various services that are starting up. The workaround for this is to either minimize the number of services that are started during the cloning process, and/or start the SID-sensitive services after cloning completes, via script that is launched via the RunOnce section of the registry.
22. Repeat steps 16-21 for each desired image copy.
Setup procedure for EWF-RAM-REG
See also:
MSDN: EWF RAM Reg Mode
Use EWF-RAM-REG if you require RAM overlay and do not or cannot use an EWF partition on the media being protected. For example, CF media that are marked as “removable” type will only accommodate a single partition, thus preventing you from including both a volume partition and an EWF partition.
With EWF-RAM-REG, the EWF settings are stored in the registry. Although it avoids the problem of partitioning the flash media to accommodate more than one partition, it does impose a few restrictions on your configuration. One restriction on this type of configuration is that there can only be one protected volume. There is no way for EWF-RAM-REG to protect multiple volumes. If you need to protect multiple volumes, you will need to find a way to configure your flash media with more than one partition, and use EWF-RAM or EWF-DISK. Another restriction is that the "disable" command cannot be used. This is because the EWF settings are stored only in the registry, which is write-protected by EWF. Instead, you need to use the "commit and disable" command. This ensures that the “disable” registry state change gets persisted to real storage before the system reboots.
The basic difference between this procedure and the standard procedure (EWF-DISK or EWF-RAM) follows:
Build your image as you normally would, using Target Designer.
In the Enhanced Write Filter settings, uncheck "Start EWF Enabled", and select Overlay type as RAM (Reg).
Build the image, run First Boot Agent (FBA), enable EWF and then optionally run FBRESEAL if using the System Cloning Tool.
Procedure
1. Using Target Designer, include the following components in your runtime image, along with all other components you require for your specific runtime image:
EWF Manager Console application
EWF NTLDR
Enhanced Write Filter; uncheck (turn off) Start EWF Enabled, especially if using the System Cloning Tool
(Optional) Enhanced Write Filter API (EWF API)
Registry Editor (enables you to manually activate EWF via registry change, at a later step)
(Optional) System Cloning Tool; be sure to set this component's Reseal Phase to Manual.
If you are planning to use the System Cloning tool in order to generate a unique computer id (SID) for each deployed runtime, be sure to also include the System Cloning Tool and then set its Advanced Property of cmiResealPhase to zero (0) (or under Settings, set Reseal Phase to Manual). This setting disables automatic FBA cloning deployment, which allows you the opportunity to make custom changes to the image before the cloning step. You must manually activate the cloning tool using FBRESEAL.EXE at a later step. If you included the Automatic Logon component in your image, note that you must configure FBRESEAL so it does not overwrite the automatic logon information. To retain the settings you specified in the Automatic Logon component, set the extended property "cmiRemoveAutoLogon" in the System Cloning Tool to FALSE.
2. Edit the Enhanced Write Filter component settings:
EWF Volume Configuration
|
(EWF-RAM-REG Configuration)
|
Maximum Number of Protected Volumes
|
1
|
Maximum Number of Overlay Levels
|
1
|
EWF Partition Size in Kbytes
|
0 ( will always auto configure to 32KB if all EWF protected volumes are set to RAM )
|
Disable Background Disk Defragmentation
|
Checked
|
Enable Hibernate-Once-Resume-Many Mode (HORM)
|
Checked if HORM is desired
|
Protected Volume #1 (note that EWF-RAM-REG supports only one volume)
|
Start EWF Enabled
|
No
|
Enable Lazy Write
|
No
|
Disk Number
|
0
|
Partition Number
|
1
|
Overlay Type
|
RAM (Reg)
|
Optimization Option
|
Optimal Performance
|
3. Choose the file system to be used in the volume you intend to protect.
FAT offers less overhead than NTFS, particularly when used with smaller volumes such as seen in flash devices. Note that FAT does not support NTFS features such as file encryption and security features such as file permission control.
4. From Target Designer, run Check Dependencies (F5) and resolve all dependency issues.
5. Check for the following issue:
Page file support
If your configuration has Page File enabled, the page file should be located on a volume that is not protected. By default there is no pagefile in a Standard 2009 runtime. You can add support for this by checking the configurable settings in your HAL component. Your HAL will be "Standard PC" component, "ACPI Uniprocessor", "Advanced Configuration Power Interface", etc.
Adjust the following registry key to relocate or rename the page file:
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management
Name: PagingFiles
Type: REG_MULT_SZ
Data: C:\pagefile.sys 150 500
Within that Data field you can adjust the NAME of the pagefile, its LOCATION and its MINIMUM & MAXIMUM values.
6. From Target Designer, run Build Target Image (F7) and resolve any build issues.
7. Partition the target media that you plan to run FBA on. For details, refer to the section titled Preparing storage media for EWF.
8. Copy the runtime image to volume within the target media that you plan to use to run FBA.
9. Boot the device and allow FBA to complete
10. Inspect windows\FBA\FBALOG.TXT. It should not report any reference to configuring an EWF partition, since it was disabled.
11. At this point the image is booted up and operational. Make any additional custom modifications to the operating system such as registry tweaks, patches, etc.
12. If you took the earlier step of including the System Cloning Tool in your configuration, and you have set its Advanced property of cmiResealPhase to 0 (or under Settings, set Reseal Phase to Manual), you reseal the image at this step.
Run FBRESEAL along with its optional command-line arguments; refer to
FBRESEAL Commands.
13. Shut down your system and do NOT re-boot up on the XPe image; instead, save this XPe image as your Master image.
14. Partition and format the target media. The media type may be either removable or fixed. Removable media will only accommodate one partition. See also Preparing storage media for EWF for details.
15. Copy your master XPe image to the target media. Note that since you are using EWF-RAM-REG, there is no need to copy the EWF partition.
16. Reboot the target media in its target hardware. This step lets the System Cloning Tool complete its cloning operation, creating a unique SID for the XPe device.
17. Make any per-clone-unique custom modifications, such as registry tweaks, files that have no component owner, files unique to the particular clone, machine name, etc.
18. A second reboot may be necessary in order to allow some components, such as IIS and Terminal Services, to resynchronize with the new computer ID.
19. Repeat steps 15-19 for each desired image copy.
Preparing storage media for EWF
The first time you run FBA, you can run it on the storage device you intend to use. Or, you can run it on a storage device other than your final chosen device. For example you can run FBA on a conventional hard drive, then copy the post-FBA image to your final CF storage device. However, the CF device must appear as the same IDE drive letter in order to work, and it must be formatted and prepared properly.
Three Microsoft tools are available for preparing your storage media:
Windows XP Disk Management utility (diskmgmt.msc)
This is the preferred tool, and is included in standard Windows XP. Some compact flash (CF) devices may fail if you attempt to repartition them with this tool. This is because they report the incorrect disk geometry information to the operating system. For such devices, use WinPE/DISKPART or MS-DOS/FDISK instead.
WinPE (Windows XP Preinstallation Environment) & DISKPART
You can boot from CD1 of Windows XP Embedded, and use the DISKPART tool to partition your media.
MS-DOS, Fdisk, Format & Bootprep
If the media does not allow itself to be partitioned using the above tools, you can partition the media by booting to MS-DOS, using MS-DOS tools, and as a last step use the Standard 2009 Bootprep tool to modify the boot sector so that media can boot to Standard 2009. Think of Bootprep as a last resort, typically only required when using older and smaller capacity disk drives with unusual disk geometries. Bootprep.exe is a command-line tool to create media that can boot into Standard 2009. Specifically, Bootprep changes the Master Boot Record (MBR) from an MS-DOS format into a format recognized by Windows XP or Standard 2009.
First, you must prepare the media by using MS-DOS tools such as FORMAT and FDISK to prepare the MBR (Master Boot Record) and at least one partition. Prepare your media, the active partition of which has been formatted and made bootable with either FAT16, BIGDOS FAT 16, or FAT32 for booting into Windows Embedded. Run Bootprep to replace the partition boot sector code that would normally boot into DOS by loading IO.SYS and MSDOS.SYS with the code that loads NTLDR.
This tool only works when run from MS-DOS, and is only required if you are starting with a storage device that cannot be recognized as configurable by Windows XP.
If your target device uses multiple physical storage media, please note that when the EWF partition is being created (for example via “rundll32 ewfdll.dll ConfigureEwf”), EWF searches all disk volumes, starting with the lowest physical device number, for the first piece of unallocated disk space that will accommodate the size of your EWF partition. If you have two disk drives, and both have unallocated disk space, the EWF partition will choose the first one. If you require that the EWF partition reside on the second disk, it is important that you do not leave any free disk space on the first disk.
Also keep your drive letter mapping as simple as possible. Windows XP allows you to remap the drive letters to arbitrary partitions; if you do so, this might confuse the EWF initialization process.
You should abide to the following rules and constrictions, when partitioning and formatting your disk(s):
When preparing the partition for the first time, set up no more than 1 primary partition on the target disk media, because there is a known issue during the EWF initialization process when it creates the EWF partition. The symptom is an intermittent failure to open the EWF partition after it is created (see the end of your FBA log for details). After the EWF partition is created successfully, you can add primary partitions to the disk afterwards if required. If you require additional logical drives, instead of creating multiple primary partitions you can create an extended partition that consumes remaining disk space and contains the desired logical drives. Leave enough free sectors in the extended partition to accommodate the EWF partition.
Unallocated disk space should be less than 4GB.
Do not fragment unallocated space. Configure all unallocated space so that it is always at the end of the physical disk.
When formatting, specify the file system(s) to match the file system(s) that you included in your Target Designer configuration. If you format a partition for NTFS, but your configuration contains only the FAT file system, FBA will fail.
If your disk contains an extended partition, EWF will always attempt to create the EWF partition in the free space within the extended partition. In this case, if the physical disk also has unallocated space, this space is always ignored and never used. So you must ensure there is enough free space in the extended partition to accept the EWF partition. Another requirement is that the extended partition must be the last partition on the physical disk; there must not be a physical partition located after an extended partition.
Preparing flash-based storage media
One of the benefits of using Standard 2009 is the ability to create devices that boot to Compact Flash™ (CF). There are many advantages to using CF, most notably creating solid-state devices. These devices are usually more reliable as they have no moving parts. The downside of using CF is that CF is "write wear limited". In other words, there is a limit to the number of times that can be written to a given CF storage location. If a CF device is periodically written to, eventually the CF media will fail. The Enhanced Write Filter (EWF) provides a way of protecting the underlying volume from writes. This avoids wearing out the media but imposes the restriction of running protected volumes as stateless. This article will describe a means for building a Standard 2009 image and deploying it to CF with EWF enabled.
Storage devices that are marked by the IDE controller as “Removable” are allowed to contain only one partition.
Most Compact Flash (CF) storage devices are marked as removable. However, there are software utilities available from some CF vendors that can mark the vendor’s media as non-removable; this enables you to configure the media with more than one partition. Where possible, it is usually better to mark the media as non-removable, which enables you to reserve unallocated space on the media to accommodate an “EWF partition”, in addition to the volume being protected. An EWF partition provides better support for disabling and storing persistent data. If you cannot mark the media as non-removable, you cannot install an EWF partition. When this happens, RAM-based EWF can still be configured by persisting key information in the registry instead of the EWF partition, using EWF-RAM-REG.
If your target embedded device uses Compact Flash instead of hard disk as the storage device, you typically include the Enhanced Write Filter (EWF) with a RAM-based overlay, in order to protect the operating system from any changes. This is an effective means of prolonging or indefinitely extending the life of the CF by reducing or eliminating write cycles to the CF.
For a truly “stateless” system, all your mass storage is protected in this way. Each time you shut down and reboot your system, it will revert to the same system state as the prior boot (and all previous boots).
If you want to protect the system volume but still want to be able to save information so it is retained when the system reboots, you need to set up an additional partition that is not EWF protected. Here are some examples of how this can be accomplished using CF:
Configure a single CF storage device that contains multiple partitions. The only way you can include more than one partition in a CF storage device is that it must first be flagged as a “fixed” type storage device. By default, most CF storage devices are flagged as “removable”. SanDisk and some other CF device manufacturers supply a utility that allow you to change this flag to “fixed” type, to enable multiple partitions on one CF.
Configure more than one CF storage device in your design. Set up one of them as EWF protected (usually the system volume), and the other as unprotected.
How to initialize CF media for Standard 2009
There are two ways to accomplish this. The technique chosen depends on whether the CF media can be marked as “non-removable” (i.e. fixed disk type) using a program tool supplied by the CF media vendor.
Use the following procedure if you are able to mark the CF media as “non-removable”.
Insert the CF media into an IDE->CF adapter installed into your computer as the primary IDE device (you cannot use a USB->CF adapter for this step).
Run the manufacturer’s utility to mark the CF media as “non-removable”. For example, if you are using SanDisk CF, boot up from a floppy disk using MS-DOS and then run this tool:
NDCFWCHG /P /F
Consider checking with the CF vendor for more information about their default factory settings and their recommendations.
Boot up into Windows XP Professional with the CF media installed into the IDE->CF adapter (do not use a USB adapter as it typically reports the CF as being removable even when it is marked as non-removable).
Run the Disk Management tool (DISKMGMT.MSC).
Right click on the disk to obtain the context menu, then select Delete Partition from the menu. Perform any partitioning activity as required. Use right-click again to create a Primary Partition. If you want more than one partition, create an Extended Partition, then populate the Extended Partition with one or more Logical Drive(s).
Mark the first partition as Active (again, use the right-click context menu).
Let First Boot Agent complete in a standard IDE drive on your target embedded hardware. Be sure EWF was initialized as disabled to ensure all changes are persisted.
Copy your (post-FBA) embedded image to the CF device
Deploy the CF in your target embedded hardware.
Use the following procedure if you are unable to mark the CF media as “non-removable”, i.e. it can only appear as a removable disk type.
Insert the CF media into an IDE->CF adapter installed into your computer as the primary IDE device (you cannot use a USB->CF adapter for this step).
Prepare a floppy disk to contain MS-DOS (version 6.22 or later preferred but not required), FDISK and FORMAT. Locate the BOOTPREP.EXE tool, on the computer where you installed the Standard 2009 Tools, in folder Program Files\Windows Embedded\Utilities\ and copy BOOTPREP.EXE to the prepared floppy disk.
Use FDISK to format the flash as a single partition. Since the CF is marked as removable, you cannot create more than one partition.
Use FDISK to mark the partition as the Active partition
Run the BOOTPREP tool. Refer to the System Design Guide documentation in Microsoft Windows Embedded Studio for usage details.
You can format the CF partition using MS-DOS, or you may boot the computer into Windows XP and then format the CF using the DISKMGMT.MSC tool.
Let First Boot Agent complete in a standard IDE drive on your target embedded hardware. Be sure EWF was initialized as disabled to ensure all changes are persisted.
When booted into Windows XP, copy your embedded image to the CF device.
Deploy the CF in your target embedded hardware.
If you have difficulty formatting the flash device using DISKMGMT.MSC, you may need to use the MS-DOS FORMAT utility (and BootPrep), or the manufacturer’s formatting utility, because sometimes Windows reports the wrong drive geometry to FDISK for flash drives.
Consider using a CF Card Duplicator when mass deploying.
An alternative to RAM EWF using SDI
You can configure a boot volume so that it copies itself into a Ram Disk, then the system boots directly from the Ram Disk. Refer to this section:
Booting from an SDI file
|
