Supporting Windows XP Embedded-based Devices
by Katherine Enos
Applies to Microsoft® Windows® XP Embedded
This white paper provides an overview of how to support Microsoft® Windows® XP Embedded-based devices. Supporting embedded devices involves servicing devices and supporting embedded device users. This white paper explains changes to the update process for servicing devices using Windows XP Embedded with Service Pack 2, and summarizes the servicing mechanisms by which updates can be deployed. This white paper also provides recommendations for supporting the users of embedded devices.
Embedded devices range from small-footprint Windows-based Terminals (WBT) to ATM devices that are managed side-by-side with other devices and computers in an enterprise environment. Devices of the same type may use different hardware, and a different run-time image that is customized for a specific application. This means that support staff must learn each device anew, and that an IT department must usually devise a support strategy that is tailored to an embedded device.
Device servicing is an essential component of the support task. Embedded device supporters are responsible for ensuring that their customers receive the updates that they require. Part of supporting embedded devices is developing an effective strategy for the deployment of updates.
To provide good support for an embedded device, you should begin with a baseline level of knowledge about that device and about the servicing mechanism that it was designed to use. Every embedded device should have been designed to include a security strategy, and no security strategy is complete without a servicing solution.
The Microsoft Windows XP Embedded product team works closely with customers to help them deliver on their servicing strategies. An essential part of the team's efforts is delivering quality security updates to customers as soon as quickly as possible.
This white paper provides a discussion of servicing embedded devices and reviews Microsoft's own strategy for supplying updates to those who administrate and support.
The update deployment process for Windows XP Embedded-based devices can differ substantially depending on the device type to be serviced and the composition of the deployed run-time image. The effective deployment of updates takes into consideration factors including:
- Device type
- Composition of the run-time image
- Whether the device is networked
- What servicing solutions are available
- Type of update to be deployed (whether it is a security update, for example)
- Footprint of the applied update
These factors are interrelated and must be considered together. For example, the impact of an update on the footprint of your device run-time image is probably less important than correcting a vulnerability that can expose a networked device to an Internet worm. If your device was designed to use a small footprint, it may include Device Update Agent (DUA) as a servicing solution. DUA is a small-footprint solution that polls for updates on a preset schedule. Automated polling will help to ensure that a critical security update is quickly deployed. But the need to preserve the small footprint of your run-time image could require that you open and inspect the update package before deployment to make sure that you do not deploy unnecessary files to your devices.
This section provides information about updates and update support for Windows XP Embedded with Service Pack 2. This section also reviews update terminology and explains how security updates are classified in terms of importance.
Windows updates are classified according to their purpose. The following table reviews Windows update terminology for Windows XP Embedded with Service Pack 2 and later versions of the operating system.
|Update||A security bulletin that is issued to a wide audience.|
|Hotfix||A fix that is designed to resolve a specific customer issue. Hotfixes are not released to the public.|
|QFE (Quick Fix Engineering update)||A fix that is not related to security and that is issued to a wide audience.|
|SP1 XPE QFE||Any type of fix that is not associated with a major software release.|
Windows updates are further classified according to their level of urgency. The following table describes these levels.
|Critical||A vulnerability whose exploitation could allow the propagation of an Internet worm without user action.|
|Important||A vulnerability whose exploitation could result in compromise of the confidentiality, integrity, or availability of user data, or of the integrity or availability of processing resources.|
|Moderate||Exploitability is mitigated to a significant degree by factors such as default configuration, auditing, or difficulty of exploitation.|
|Low||A vulnerability whose exploitation is extremely difficult, or whose impact is minimal.|
Updates for Windows XP Embedded are further classified by how they are deployed. The following table describes these types of updates.
|Desktop update||An update that is applied, in part or as a whole, to an embedded device. Desktop updates are updates that are released for Microsoft® Windows® XP Professional. A servicing strategy that is based on desktop updates is a strategy of incremental updates to the run-time image.|
|Database update||An update that is applied to the component database from which the OEM takes Windows components to create a run-time image. A servicing strategy that is based on database updates requires that a run-time image be rebuilt or "reimaged," and then redeployed to apply the update to the embedded device.|
For more information about security updates, see the Microsoft Security Web site.
A Windows XP Embedded database update is run on the computer of the device developer so that the Windows Embedded Studio component database is updated with the new or changed binary files. A database update ensures that all future run-time images that are created on the development computer include the update by default.
Updates that are made to the database cannot be uninstalled from a run-time image that was created to include them.
To deploy a database update, the run-time image must be reimaged after the update is made to the database. Installing a reimaged run-time image is the only way to apply updates to devices that boot from read-only media. The basic process that device developers use to reimage a run-time image is:
- In Target Designer, open the .slx file for the run-time image configuration to be updated.
- On the Tools menu, select Update to update the configuration with the changed component.
- Complete a dependency check and build a new run-time image that includes the new or changed component.
Even if the run-time image will not be reimaged and redeployed to distribute the update, the component database should be updated with the update to ensure that run-time images that are generated in the future use the correct components.
There are some practical advantages to distributing an update by reimaging. For example, you can more effectively test a reimaged run-time image for missing dependencies and other problems. It can also be more practical to reimage when you have a number of updates to apply and want to avoid the time involved in scripting and administering a series of incremental updates.
The technique of reimaging to include an update limits the means of deployment that are practical to use to install the update on devices. Servicing solutions are not generally intended to be used to deploy entire run-time images and the mass deployment of a run-time image over a network demands a lot of resources, even under the best of circumstances. Distributing an update in a reimaged run-time image also means that the boot media must be replaced or reformatted.
Database updates are typically released about five days after the Windows XP Professional update is made available. The Windows XP Embedded product team is committed to providing high-quality updates as quickly as possible. However, there may be instances where it will take more than five days for an update to be released for use on Windows XP Embedded-based devices. Database updates are available on the Windows Embedded OEM restricted access Web site before they are publicly released.
Updates should always be tested for the specific device to which they will be deployed before deployment is made, regardless of whether the update is implemented in a reimaged run-time image or by deployment directly to the device.
Database updates are made only for critical and important updates.
Changes to How Database Updates Are Packaged
Effective in early 2005, database updates for Windows XP Embedded Service Pack 1 and Windows XP Embedded Service Pack 2 will be issued monthly for each release. Updates will no longer be issued on an individual basis; instead, updates will be collectively distributed as a package. The update packages will have the following characteristics:
- Each update package will include all updates that have been issued for that release up until the date of the release of the update package. For example, the Service Pack 2 update package will include all updates that have been released for Service Pack 2 since the time that Windows XP Embedded with Service Pack 2 was released.
- Each update package that is issued for a release will be programmed to install the included updates in the order in which they were issued. For example, an update package for Service Pack 1 will automatically install the updates it contains in the correct order, beginning with the first update made to Service Pack 1 after its release and ending with the last update made to Service Pack 1. These updates may include updates to Service Pack 1 that were made after the release of Service Pack 2.
Microsoft believes that this update distribution strategy will help to eliminate difficulties in tracking which updates have been made and in applying updates that are issued as separate packages in the required order. Customers who were asked for feedback about this new way to package and distribute updates agreed that it would benefit them.
Desktop updates are updates that are released by Microsoft for Windows XP Professional. Because Windows XP Embedded is a componentized version of the Windows XP Professional operating system, Windows updates can run on Windows XP Embedded run-time images that include the required dependencies.
Desktop updates are typically made available for Windows XP Embedded about five days after they are released for Windows XP Professional. The Windows XP Embedded product team has recently been able to get desktop updates released for embedded customers in as little as 48 hours after their release for Windows XP Professional customers.
Desktop updates are used to apply incremental updates to a run-time image. Combined with good testing, the incremental application of desktop updates reduces the size of the update package and the cost of deploying them.
Device servicing is the deployment of new and changed binaries to embedded devices. A Windows XP Embedded-based device can by serviced by:
- Reimaging: Updating the Windows Embedded Studio component database with the new and changed binaries, and then rebuilding and redeploying the run-time image.
- Making incremental updates: Updating the run-time image on the device by deploying the new and changed binaries.
Servicing plays a critical role in any device security strategy but is not the sole component of a security strategy. For more information about how to build more secure devices, see Add Security Features to a Run-Time Image in the Windows XP Embedded documentation.
Using the /x Switch to Avoid an Excessive Run-Time Image Footprint
In addition to testing updates, it is good practice to expand them and inspect their contents. This practice makes it possible to learn what changes the update implements and to use this information to locate and deploy only the necessary files to devices in the field. You can also inspect the information (INF) file that is contained in an update package and used to configure it on the target device to learn what actions it executes. Updates can contribute to an excessive footprint if they are not applied with care.
There are several command-line switches that determine the location to which an extraction is made and whether user prompts appear during the extraction process. The
/x switch causes the update package contents to be extracted without running the Update.exe package installer. For example:
Or, to specify a path to which the extraction should be made:
c:\test>Update-name.exe /x:"foldername" (path_name)
If no folder is specified, the extraction is made to a randomly named folder.
In addition to helping to maintain a minimum footprint in a run-time image, distributing only the files that are required for a particular update minimizes scripting and speeds deployment.
For more information about the command-line switches and the Update.exe package installer, see the white paper entitled Inside Update.exe - The Package Installer for Windows and Windows Components, on the Microsoft Web site.
Servicing solutions include mechanisms for patching and updating embedded devices, as well as mechanisms for deploying reimaged Windows XP Embedded-based operating systems. This section provides an overview of some of the servicing solutions that Windows XP Embedded supports for making incremental updates to a run-time image. These solutions include:
- Microsoft Windows XP Embedded Device Update Agent (DUA)
- Microsoft Software Update Services (SUS)
- Microsoft Systems Management Server (SMS)
For a comparison of these servicing solutions, see Servicing with Windows XP Embedded with Service Pack 2, on the MSDN Web site.
The following table describes the device types for which each servicing solution is best suited. The following subsections describe each servicing option in greater depth.
|Solution||Best suited to...|
|Device Update Agent (DUA)||Any networked device. Ideal for small-footprint devices or smaller environments.|
|Software Update Services (SUS)||Any device on a closed network. Ideal for medium to large enterprise environments.|
|Systems Management Server (SMS)||Well-suited to RPOS, WBT, and ATM devices. Ideal for enterprise environments that require management capabilities.|
Device Update Agent
Windows XP Embedded provides a servicing solution in Device Update Agent (DUA), a robust, small-footprint service for updating deployed devices. The DUA service performs administrative tasks including copying files, creating registry keys, and executing processes. DUA was created by the Windows XP Embedded product team specifically for small-footprint embedded scenarios.
DUA works by polling a remote or local path for a script file and then executing it. You can build your own scripts or redistribute the DUA script compiler. Many Microsoft customers create scripts for their devices at a central office and post them to the Web for pickup.
The Device Update Agent component is included in the Windows Embedded Studio component database. The documentation for Windows XP Embedded with SP2 provides detailed supporting information for DUA, including how-to topics and a tutorial.
For more information about DUA, see Device Update Agent in the Windows XP Embedded documentation.
Software Update Services
Windows XP Embedded with SP2 provides support for Microsoft® Software Update Services (SUS). SUS provides a complete servicing solution for the distribution of Windows updates to Windows clients, including Windows XP Embedded. SUS scans deployed devices and then downloads the necessary security updates to those devices. You can configure this process to work automatically, and can manage it remotely.
To use SUS as your servicing solution, you must set up and configure a SUS server on the intranet at your enterprise location. Windows Automatic Update must also be enabled. The configured SUS server component provides you with a Windows Update Server that polls the Microsoft Windows Update Web site and downloads the available updates. SUS uses Internet Information Services (IIS) and Background Intelligent Transfer Service (BITS) to download updates to clients.
Note that the distribution capabilities of SUS are limited to security updates. SUS does not distribute device drivers or other updates from the Windows Update Web site at http://www.windowsupdate.com.
For detailed information about using SUS to service embedded run-time images, see the white paper entitled Using SUS with Windows XP Embedded Service Pack 2, on the MSDN Web site.
For general information about SUS, see the Microsoft Software Update Services Web site.
Systems Management Server
Microsoft® Systems Management Server (SMS) provides security patch management and servicing capabilities. Embedded developers can now use SMS to manage the deployment of security patches to Windows XP Embedded-based devices. Client and server components for SMS are not included in the Windows Embedded Studio component database and must be separately obtained.
SMS includes useful capabilities for certain scenarios, making it possible to:
- Manage embedded devices as though they are desktop machines and servers.
- Monitor the update installation process.
- Generate a single status report tracking updates on all clients, servers, and embedded devices.
- Deploy remote-boot images to a server.
SMS provides flexible support for applying any kind of update package that the run-time image can execute, including desktop updates, custom scripts, and application-specific executables. If the Windows Installer Service component is included in the run-time image, you can also use SMS to deploy Microsoft Windows Installer (MSI) packages for installation.
Systems Management Server can be particularly useful for the embedded applications that are described in the following table.
|Retail Point-of-Sale (RPOS)||SMS is often used to manage POS devices that have a PC architecture. SMS is generally used to inventory devices and to make updates to operating system and applications.|
|Windows-based Terminal (WBT)||Complex WBT implementations often use SMS in combination with Microsoft® Internet Explorer and line-of-business applications. SMS is particularly helpful in this implementation for inventory and patch management.|
|Automated teller machines (ATM)||ATM implementations use SMS for software management and inventory.|
For more information about SMS, see the Microsoft Systems Management Server Web site.
To support embedded devices and their users, administrators should have a good understanding of the issues that affect embedded devices. This section explains issues that are specific to embedded devices that administrators need to know to be effective in their work. This section also reviews some common best practices for IT departments that can be applied to the support of embedded devices as well as to the support of desktop computers.
Know Your Run-Time Image
Windows XP Embedded provides a componentized version of the Windows XP Professional operating system. Device developers pick and choose from more than 10,000 components that are supplied by the Windows Embedded Studio component database to create a customized operating system for a target device. This means that any given Windows XP Embedded-based run-time image could include a unique combination of components. The result is that supporting a Windows XP Embedded-based run-time image is usually different than supporting Windows XP Professional.
The distinguishing factor in the design and development of most embedded devices is footprint — the size of the Windows XP Embedded-based run-time image. Footprint concerns strongly influence how an embedded device is supported. For example, to maintain a small footprint in the run-time image of a fixed-function device, the device developer might choose to limit the Windows features and third-party applications that are included in the run-time image. The developer might disable certain services or exclude them entirely. The run-time image might support only a single-user environment and might support only a single servicing option that meets the small-footprint requirements for the device.
The strategy of including only the components that the device requires in the run-time image helps to ensure that the footprint of the run-time image is as small as possible. An added benefit of footprint reduction is that it limits the surface area of the Windows XP Embedded-based operating system that is vulnerable to intrusion on a networked device. Footprint reduction can also benefit the administrator: the smaller the footprint of the run-time image, the fewer the components in the run-time image that require security and feature updates over the life of the device.
The security measures that are added to the device during the design and implementation phases also affect how the device is serviced. For example, the run-time image may not support networking or include networking components. This both lowers the risk of intrusion and reduces the number of components that must be serviced. Eliminating network capabilities from a device also means that all servicing must be accomplished manually, by CD-ROM disc or media such as USB disk-on-key. The run-time image might also be write-protected by the Enhanced Write Filter (EWF) feature of Windows XP Embedded. An EWF-protected run-time image may require the use of EWF Manager or the EWF application programming interface (API) to temporarily disable the EWF feature before installing updates. For more information about EWF, see Enhanced Write Filter in the Windows XP Embedded documentation. For information about the EWF API, see Enhanced Write Filter API in the Windows XP Embedded documentation.
The following table provides a list of what administrators who support Windows XP Embedded-based devices should ideally know.
|What hardware is included in the device||Administrators may need to troubleshoot hardware problems, to update device drivers, and so on.|
|What files does the run-time image include||Administrators must be able to identify the files on their run-time image so that servicing solutions such as DUA and SMS can update them.|
|What are the default settings of the installed features in the run-time image||Administrators need to know what ports are available for applications to use, whether Windows Firewall is enabled in the run-time image, and so on.|
|What services does the run-time image support||Administrators need to know what Windows services are installed, and whether they are enabled or disabled.|
|What applications does the device run-time image support||Administrators may need to troubleshoot the problems of users who cannot run certain applications.|
|What are the available users and groups for the device||Administrators need to know whether the device has an Administrator account, or if it is using a less secure single-user environment.|
|What servicing solutions are supported by the run-time image||Administrators need to know how device servicing will be accomplished.|
|Whether the run-time image uses disk write-protection||Administrators may need to temporarily disable disk write-protection before updates can be installed on the device.|
|If users are able to customize settings, what is the user interface of the device||Administrators need to know whether users can change device settings and how users make those changes.|
If this information is not supplied with the device, ask the device developer for any available information. If this information is not available, much of it can be learned over time through examination of the device and through the experiences of in-house technical support and device users. Additional information can be gathered by using the
/x switch to expand update packages before deploying them to devices. As much as possible, information about the device and about user experiences with the device should be documented and tracked over the device lifecycle.
Know Your Device User
Administrators of embedded devices also need to know about their users. For example:
- What level of expertise does the user have
- What kind of support resources does the device include (for example, documentation or phone support)
If you are providing support to device users, be sure to provide them with a single point of contact for their support questions. In general, many support issues, including intrusions, can be quickly resolved or even avoided with good two-way communication between administrators, support teams, and device users. Consider issuing a monthly communication to users about recent support issues. In the event of a security intrusion, worm or virus, it may be appropriate to send an alert to users immediately.
General Guidelines for Supporting Embedded Devices
The user perception of an IT department can change markedly in environments where embedded devices are used. This is often the result of a support strategy that is not fully developed for or extended to embedded devices.
User complaints and sourcing difficulties can also result when embedded equipment that is unusual or unique must be repaired or replaced. In general, standardized equipment simplifies replacement issues and reduces the time that equipment remains out of service after a failure.
There is also the problem of balancing business requirements with technical need. For example, testing an update for compatibility and proper functionality on an embedded device can protect against a later crisis but slows the deployment of the update to the devices that need it. A strategy of waiting for a database update and then installing it into the component database, updating the run-time image, and redeploying it can result in additional delay before the update is installed on devices in the field. In such a case, it may be useful to communicate with embedded device users and advise them that an update will be on the way as soon as testing is complete. Another technique that you can use to speed the test phase is to obtain and begin your testing on the copy of the update that is released for Windows XP Professional. Again, you can use the
/x switch in combination with examining the INF file to find out what the update does, and to get started on your deployment plan. You should not deploy the Windows XP Professional version of the update, however, and must instead use the embedded version of the update after it is released from the Windows Embedded OEM restricted access Web site.
Some key issues in supporting embedded devices include:
- Updates that are not tested before they are distributed.
- Updates that are not distributed to customers in remote locations.
- Difficulty in supporting custom hardware or configurations.
- Failure to educate users about unusual or unique devices.
The administration and support team should not just develop and implement a servicing strategy, they should create a backup plan to use in the event that there is a failure in the servicing strategy.
The Microsoft Operations Framework (MOF) provides operational guidance to help companies to improve their information technology (IT) practices. This includes information about proven team structures and operational processes.
The IT Infrastructure Library (ITIL) is a collection of resources published by the United Kingdom's Office of Government Commerce (OGC). MOF expands ITIL to include operational guidance based on the experiences of Microsoft operations groups, partners, and customers.
For more information about MOF, see Microsoft Operations Framework on the Microsoft Web site.
For more information about device servicing, see the Windows XP Embedded documentation in the MSDN Library.
For more information about EWF, see Enhanced Write Filter in the Windows XP Embedded documentation. For information about the EWF API, see Enhanced Write Filter API in the Windows XP Embedded documentation.
For a general discussion about the servicing solutions that Windows XP Embedded supports, see the white paper entitled Servicing with Windows XP Embedded with Service Pack 2, in the MSDN Library.
For a detailed discussion about using SUS as a servicing solution with Windows XP Embedded, see the white paper entitled Using SUS with Windows XP Embedded with Service Pack 2, in the MSDN Library.
For information about SMS, see the Microsoft Systems Management Server Web site.
For information about SUS, see the Microsoft Software Update Services Web site.
To learn more about Microsoft's approach to patch management, see the white paper entitled Understanding Patch and Update Management: Microsoft's Software Update Strategy, on the Microsoft Web site.