The official blog of the Microsoft System Center Configuration Manager Product Group
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:
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:
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:
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.
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:
Building on our design intentions and assumptions, these three main areas encapsulate the changes we made to help you manage write filter-enabled devices.
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.
Packages and programs
Software update definitions
Endpoint Protection client installation
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.
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.
The world of embedded devices has a wide variety of usage scenarios when it comes to end users, some of which are as follows:
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:
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.
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.
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.
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.
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.
Another way to minimize restarts for embedded devices is to use the following software update client settings, in conjunction with maintenance windows:
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.
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:
This posting is provided "AS IS" with no warranties and confers no rights.
Rinku - This was a great write up. Thanks for giving such a great overview of the features for managed embedded devices. I look forward to working with this in production once SP1 hits the streets.
How about OS-deployment on Windows Embedded this was a typical scenario with ConfigMgr 2007 + WEDM ? Any documentation regarding that ?
Hi Marius, You will be able to find this info here - www.microsoft.com/.../details.aspx