File Based Write Filter (FBWF)
Link to main on-line content:
File-Based Write Filter
Note: Do not apply both EWF and FBWF to the same volume. If both are included in a design, they should be applied to different volumes.
FBWF and EWF
Free disk space display options
You can configure FBWF to display either actual disk size or virtual disk size.
FBWF Disk Size Display Modes
You can turn on virtual size display mode in Designer component settings, or via fbwfmgr after the image has built:
To have explorer and dir display actual sizes:
fbwfmgr /setsizedisplay 0
reboot
For virtual sizes, use a value of 1 in step 1 above.
Use virtual size display mode if you wish to place emphasis on the limited free space available for FBWF file cache area. If this area runs out of space the system will likely crash. When virtual size is chosen, system low disk notifications will pop up when this critical area is almost out of space.
Registry Filter
This component is only used in conjunction with either Enhanced Write Filter (EWF-RAM) or File Based Write filter (but not both at once).
Its purpose is to ensure that two specific registry keys are persisted across system boots (normally FBWF or EWF prevents all registry keys from being persisted across boots).
Persisted keys:
Enable TSCAL persistence
Used to enable a Server to properly keep track of Terminal Services Client Access Licensing.
Enable Domain Secret Key persistence
For XPe devices connected to a domain server, this key needs to persist for the server to manage participation of clients on its domain. If this key is not persisted across system reboots, then updates from the server can fail after the default 30 day life span Secret Key has expired. This will cause the device to fail to connect to the domain after 30 days.
Some users have inspected the registry keys owned by the Registry Filter component, and then added their own entries, in order to persist additional keys of their own. This is not guaranteed to work for all registry keys. For example:
Some registry keys are dynamically created by the operating system during the boot process (such as HKEY_CURRENT_USER and HKEY_CURRENT_CONFIG). These keys cannot be persisted across boots owing to their nature.
Some registry keys are read or written by the operating system at early boot phases, before the Registry Filter service has had a chance to start up. Registry Filter will only work for registry keys that are used for the first time after the Registry Filter service has loaded and fully initialized.
Aside from the two documented registry keys that are supported, there is no published list that specifies the registry keys that will persist correctly when Registry Filter is used.
Regarding the Domain Secret Key persistence problem, here are three distinct solutions:
1. Run the image with EWF disabled. However if using Flash based storage this is likely not a valid solution because Flash storage can wear out when they are written to frequently.
2. As explained above, include the component named "Registry Filter" in the design. Note that if you do have Registry Filter installed, and still have the problem, make sure the devices are being powered down in an orderly manner instead of a surprise power loss (such as unplugging the device while it is booted up). The latter will prevent the registry entries from being properly persisted across reboots.
3. Apply the workaround KB 154501 (How to disable automatic machine account password changes) locally on the XPe clients before EWF is enabled.
Next, set the maximumpasswordage value (under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters) to a very high value (e.g. 1000000) along with setting disablepasswordchange to 1.
Additionally, set the corresponding GPO (the “Domain member: Maximum machine account password age" policy) to the same value.
An alternative to directly setting the values in the registry is to set it through local group policies. The corresponding group policies are:
Disable machine account password changes:
Domain member: Disable machine account password changes)
Set password age:
Domain member: Maximum machine account password age)
Additionally, as a double guard, set the following policy on the domain controllers machines:
Domain controller: Refuse machine account password changes.
This will instruct domain controllers to not accept any password change requests from any of the domain members. Also ensure domain administrators in your organization do not override any of the above policies in active directory in which the XPe clients accounts are maintained.
Before making any changes to the Standard 2009 device, make sure you have disabled the Enhanced Write Filter before doing so, to make sure your changes persist.
Links:
MSDN: Registry Filter
MSDN: XPe Component: Registry Filter
Developing an image bootable from a CDROM Background
Please consider using USB Boot instead of El Torito because USB Boot:
is more reliable because there are no moving parts
is generally faster
media is smaller and can be more convenient to use
does not require a CD drive; it only requires an available USB port.
USB Boot
The following article has been superseded by later documentation. There is a macro component named El Torito CD Support that facilitates the process. Please use the following on-line links as the principal source of documentation:
Bootable CD-ROM
El Torito How-To, redux
Advanced Scenario, USB El Torito (Booting from USB CD-ROM)
The documentation below may be useful as a walk through that can help you to better understand the whole process in greater detail.
El Torito is the name of a standard for formatting bootable CD-ROM media. Use the Standard 2009 El Torito component to enable a CD-ROM to manifest itself as the XPe system volume.
Since CD-ROM is read-only storage, EWF is included in the configuration, in order to convert the system volume from read-only to read/write. All writes are diverted to the EWF RAM overlay (RAM-based disk sectors are dynamically allocated from system memory). This data is lost the next time the system is rebooted. As a result, the system contents are “stateless” across reboots; the system always reboots in the same state as any prior reboot.
The differences between SETUPLDR CDROM boot and El Torito (NTLDR) Boot
SETUPLDR
On WinPE and normal OS install CDs, the loader (setupldr) is written to specifically boot from CD and thus no El Torito HDD emulation is required.
El Torito (using NTLDR):
The HD2ISO tool used in the following Standard 2009 walkthrough, in order to create an ISO image, is hardcoded to produce type 4 (HDD Emulation) CD boot images.
The boot loader is NTLDR. NTLDR expects to see a hard drive with an MBR on sector 0. In this case the CDROM must emulate a hard disk drive and hence El Torito HDD emulation is required (and the BIOS has to support El Torito).
Development environment System requirements
The following are necessary to get started:
Windows Embedded tools and database.
A CD Burner.
A minimum of 2 blank CDR media.
A hard drive containing a partition that is boot prepped with a total capacity no larger than a CD (650MB).
Because you will deploy a RAM-based EWF 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.
| 