This blog post is for Configuration Manager SP1 administrators who are looking to manage Windows Embedded devices that use write filters. It includes the following information:
- An overview of write filters and implications for a device management solution, such as Configuration Manager.
- Our design intentions and assumptions to better support write filter-enabled devices in Configuration Manager SP1.
- The changes that were implemented in Configuration Manager SP1 to support the design intentions.
- Tips for managing write filter-enabled devices.
Overview of Write Filters
Write filters are a component of Windows XP Embedded and Windows Embedded Standard 7 operating systems. Write filters write data to another medium instead of being physically written to the volume itself. Write filters allow the writes to be discarded or committed to the physical volume later (either directly or when another action causes the changes to be committed). As this minimizes writes to a specified hard disk, the write filters have become popular as a way to decrease wear of solid state drives on embedded devices. Because write filters allows the run-time image to maintain the appearance of a writable run-time image without committing the changes to the storage media, you can reduce the number of disk writes on your devices.
In addition, you can use write filters as an easy to way return operating system images to a known state, to reduce help desk and administrative overheads that might otherwise be required to check for and remediate configuration drift.
Starting with Windows XP Embedded Service Pack 2 Feature Pack 2007, the following write filters are available:
- File-Based Write Filter (FBWF), which operates at the file level. For more information, see File-Based Write Filter in the MSDN library.
- Enhanced Write Filter (EWF), which operates at the sector level. For more information, see Enhanced Write Filter in the MSDN library.
When write filters are enabled, you cannot persist or commit any changes that you have made. For example, if you have installed an application, the installation will not persist after you restart the device. When the device restarts, the device goes back to its original state and it’s as if the application was never installed. Because of this behavior, we need to manage these write filters if changes and applications must persist after a restart, and this can be challenging for administrators. It involves the following steps:
- Disable the write filters: The first step is to disable the write filters, which can be done by using a command-line operation or a script.
- Restart the device: The device must restart to complete the disabling of the write filter and for it to take effect.
- Install the application or apply any changes: Now that the write filter is disabled, you can install an application or make any changes that you require, and your changes will be persisted.
- Enable the write filters: After you have finished making all the required changes, you re-enable the write filter, so that any further, unwanted changes can be restricted. This again can be accomplished by using a command line operation or a script.
- Restart the device: Similar to step 2, you must now restart the device for the write filter to be enabled.
That’s a lot of administrative overhead, especially if you’re managing multiple embedded devices. It’s even more challenging if you must do this remotely.
Before Configuration Manager SP1, administrators had to devise their own methods to achieve the required steps. We wanted to help make this easier for you, so that you could continue to have all the advantages of write filters but manage these devices similarly to how you manage other devices on the network.
Our Design Intentions for Write Filter Management in Configuration Manager SP1
As we looked at extending Configuration Manager to better manage these write filter-enabled devices, we had the following design goals and assumptions in mind:
- In situations where embedded devices use write filters, we know that for operational and security reasons, administrators are generally averse to all changes. We wanted to optimize Configuration Manager to allow administrators to easily apply their intentional changes while also honoring the safety measures that write filters provide to keep their businesses running in a safe and secure manner. We wanted our changes to provide the best compromise between traditional device management and protection against unwanted changes.
- On the assumption that all changes that the Configuration Manager administrator makes are “good changes”, these changes should eventually persist to disk.
-
Implement two ways to persist administrator changes:
- Forced persist : The Configuration Manager administrator wants the change persisted immediately and Configuration Manager takes care of the required disabling, restarting, re-enabling of the write filters.
- Opportunistically persist : The Configuration Manager administrator wants to apply the change at an appropriate time, and apply this change in memory only (on the overlay). Then, at the next “forced persist” action, Configuration Manager will persist this change as well.
Configuration Manager will allow for opportunistic persistence for all actions, and forced persistence for major actions such as application deployment, software update installations, and task sequences. And, for all opportunistic persistence actions, our goal was to make sure that until these changes could get force persisted, they would be applied quickly enough to reduce the time when the device might be out of compliance, and with minimal system interruption.
Write Filter supports “exceptions” so that changes can be applied to a device without using the administrative steps in the previous section. However, these exceptions can be difficult to create and manage, and somewhat defeat the goals of the write filters. Our design goal is that for most of the time, administrators will be able to use Configuration Manager to manage write filter-enabled devices without having to use exceptions.
- In line with user-centric management, we wanted Configuration Manager administrators to think user first, rather than force them to think about the device first. The changes introduced to support write filters allow administrators to think about their primary deliverable (application, software update, etc.) first, and then they can make modifications if needed to support write filter-enabled devices.
- Use maintenance windows to support controlled scheduling. Our assumption for most write filter-enabled devices is that administrators have a good degree of predictability and control in the way they will force persist changes to write filter-enabled devices. Because of this, we’ve optimized many of our behaviors for write filters, which get the greatest benefits when used in conjunction with maintenance windows.
- We assumed that most write filter-enabled devices will not require or want user interaction in the way they allow forced persisted changes. To support this assumption, we made some design changes to the end-user experience behaviors.
- When write filters are disabled, the device is in a state whereby unwanted changes could be applied. To help protect the device when write filters are disabled, we ensure that only administrators can log on.
- Because managing write filters to allow changes to persist requires numerous restarts, we’ve optimized some of the behaviors and provide recommendations to provide for the smallest number of restarts while still allowing changes to be persisted in a timely manner.
Changes Implemented in Configuration Manager SP1
Building on our design intentions and assumptions, these three main areas encapsulate the changes we made to help you manage write filter-enabled devices.
- Forced persist and opportunistically persist options
- Servicing lock mode
- End user experience behaviors
Forced Persist and Opportunistic Persist Options:
Configuration Manager SP1 lets you force the persistence of an installation that you want to commit to the disk. However, we also wanted to accommodate administrators who require business continuity and cannot immediately restart the device. To accommodate both requirements, Configuration Manager lets you either persist the change immediately, or temporarily write it on the overlay and then opportunistically persist it later when another change is made that is tagged to be persisted.
You make this choice when you create a deployment. On the User Experience page of the Deploy Software Wizard, select the check box Commit changes at deadline or during a maintenance windows (requires restarts) , as shown in the following screenshot. If you want the deployment to persist, make sure that this check box is selected.
By default, this check box is selected, with the exception of the Automatic Deployment Rule Wizard when you select the Definition Updates template for Endpoint Protection. If you do not want to initiate a write filter restart to persist this content, make sure this check box is not selected.
When the check box is not selected, you will not initiate a restart, but the deployment will be applied to the overlay at the deadline schedule, or during a configured maintenance window. The drawback with this choice is that your installation might not persist after a restart. For applications, software updates etc. the software will get reinstalled when the device next downloads client policy, completes evaluation and then remediation. Obviously, this introduces a delay and there is a further delay because the device must restart each time before the required changes are re-applied to the overlay.
The following table provides information about whether Configuration Manager supports an opportunistic persist and a forced persist to manage write filters. None of these features require or support write filter exceptions.
|
Management feature |
Opportunistically persist |
Forced persist |
|
Applications |
√ |
√ |
|
Software updates |
√ |
√ |
|
Packages and programs |
√ |
√ |
|
Task sequences |
√ |
√ |
|
Compliance settings |
√ |
X |
|
Software update definitions |
√ |
√ |
|
Endpoint Protection client installation |
√ |
√ |
|
Power management |
√ |
X |
|
Client settings |
√ |
X |
As shown in the previous screenshot, the forced persist option for a software deployment is a check box called Commit changes at deadline or during a maintenance window . For the Endpoint Protection client setting, it is called For Windows Embedded devices with write filters, commit Endpoint Protection client installation .
Servicing Lock Mode
Although we need write filters to be disabled so that we can apply required changes, we also want to limit any unwanted writes to the disk while the write filters are disabled. New in Configuration Manager SP1, when Configuration Manager disables write filters, it prevents all users except administrators from logging on to the device. If users try to log on, they see a servicing lock screen when they try to log on to their embedded device. The following screenshot shows what this looks like for Windows Embedded Standard 7.
End User Experience Behaviors
The world of embedded devices has a wide variety of usage scenarios when it comes to end users, some of which are as follows:
- Headless devices: Devices that run with no monitor.
- Devices with no users touching it: For example, digital signage devices.
- Devices with users as guests: For example, kiosks in a restaurant, hospital, or shopping mall.
- Devices with users using it like their own PC: For example, a user using a Thin PC.
The changes we made in Configuration Manager were to ensure reliable operation for the scenarios where there is no user interaction during management actions, such as software installations.
So what does this mean if you plan to use Windows Embedded to deliver a Thin PC solution to your users? This scenario is supported, but the following user interactions are not available:
- Available Software Deployments :
Configuration Manager does not support software deployments that have a purpose of Available . If you target a software deployment to an embedded device, it does appear in Software Center but if users try to install it when write filters are enabled, they see an error message that they do not have permissions. You can interactively install the software when write filters are disabled, but remember that if Configuration Manager disables the write filters as part of another deployment, only administrators can log on to the embedded device.
- Configuration of Business Hours :
Software Center lets users configure their business hours and select an option to only install software outside their specified business hours. If we made these options available to users on embedded devices that had write filters disabled, their configuration choices would not persist after a restart. That’s very unintuitive and frustrating for users, and help desk calls in the making. So rather than offer choices that wouldn’t persist, we disabled these options when Software Center runs on embedded devices that have write filters enabled.
However, note that if the embedded device was imaged when write filters were disabled, and these options were configured, the image would include these settings and users will not be able to change them. This end result might be suitable for your environment, or it might not. If you plan to image embedded devices, consider this behavior before you capture the image.
- Postponing Deployments to Non-Business Hours :
In line with disabling the configuration of non-business hours in Software Center, we also disabled the user notification option to postpone a software deployment to non-business hours. If a user cannot configure their business hours, it doesn’t make much sense to give them an option to postpone to a period that they cannot configure.
Another scenario to plan for when deploying software to embedded devices, is software installations that require user interaction. Make sure that you script the installations to remove all user choices. However, one to watch out for here, is installations that require the user to accept the license terms. This will not work on an embedded device, because only administrators can log on when the write filter are disabled. In this scenario, the installation will still try to install, but fail, and the device will be reported as out of compliance.
If you deploy software that requires the end user to accept license terms or similar end user interaction, use the list of applicable platforms in the deployment properties to exclude the Windows Embedded operating systems that you use. Then use alternative methods to install this software on the embedded devices, such as manually logging on as an administrator to install the software.
Tips for Managing Write Filter-Enabled Devices
Use maintenance windows for all management actions and use batch deployments for software updates to help improve the operational efficiency of embedded devices that use write filters. These configuration choices will help to minimize restarts and increase uptime for these devices.
For additional best practices, see Best Practices for Client Deployment in Configuration Manager in the TechNet library.
Use Maintenance Windows
A maintenance window in Configuration Manager is a period of time you reserve to perform management tasks. Specifically, when you target software deployments, software update deployments, or operating system deployments to a collection that has a maintenance window defined, the software installs only during the maintenance window period. Do not confuse maintenance windows with non-business hours. For a primer about the differences between these two, see the Business Hours vs. Maintenance Windows with System Center 2012 Configuration Manager blog post.
For an embedded device, it’s important to minimize random restarts and maximize productivity and uptime of the device. This is especially important in the case of devices like digital signage in an airport, ATM machines etc. where these devices cannot afford the device to be unavailable to users.
To configure a maintenance window in Configuration Manager, you configure the properties of a device collection. If you manage write filter-enabled devices, we strongly recommend you use maintenance windows for these devices. Before you do this, look at your enterprise business model to work out the best time for the devices to be offline for servicing.
We recommend you use maintenance windows for all software deployments, with the exception of software definition updates for Endpoint Protection. These software deployments check for and install signature downloads and anti-malware updates, and for security reasons, you want your device to be as up-to-date as possible for these rather than waiting for the next maintenance window.
For this to happen, the check box we showed earlier must not be selected so that the software definition updates can be installed immediately, on the overlay. If you use the Definition Updates template, this is the default configuration.
For Software Updates, Batch Deployments by Using Client Settings
Another way to minimize restarts for embedded devices is to use the following software update client settings, in conjunction with maintenance windows:
- When any software update deadline is reached, install all other software update deployments with deadline coming within a specified period of time
- Period of time for which all pending deployments with deadline in this time will also be installed
These settings let you configure a period of time for which all pending deployments with a deadline will also be installed. This can be set for a period of 1 to 23 hours, and from 1 to 365 days. By default, this setting is not enabled. When it is enabled, it defaults to 1 hour.
Using these settings with maintenance windows lets you service embedded devices and apply all required software updates, even if they haven’t reached their deadline minimizing. This configuration minimizes downtime and any restarts required for disabling and enabling the write filters.
For more information about these client settings, see the Software Updates section of the About Client Settings topic in the TechNet library.
Summary
I hope you’ve found this blog post useful in providing an overview of write filters and how they are used in Configuration Manager, the changes we made in Configuration Manager SP1 to help you manage write filter-enabled devices, how we accomplished this by introducing new options and changes, and some tips to help minimize restarts and increase uptime.
For more information, see the following documentation in the TechNet library:
- For an overview of write filter support and changes in Configuration Manager SP1: The Deploying the Configuration Manager Client to Windows Embedded Devices section in the Introduction to Client Deployment in Configuration Manager topic.
- For an example scenario using the configuration options to support write filter-enabled devices: Example Scenario for Deploying and Managing Configuration Manager Clients on Windows Embedded ... .
This posting is provided "AS IS" with no warranties and confers no rights.