Building Serviceable Devices
Microsoft® Windows® XP Embedded
Summary: To help ensure that your devices running Microsoft® Windows® XP Embedded work correctly and meet your performance standards, you should keep them current with the latest updates from sources such as Microsoft, device manufacturers, and other companies. Installing updates on devices running Windows XP Embedded in a uniform and scalable manner is increasingly important to your success as an OEM. A well-planned servicing strategy for devices saves you a significant amount of time and money that you would otherwise spend to react to a security compromise. This document helps provide general guidelines on how to create a servicing strategy.
To help ensure that your devices running Microsoft® Windows® XP Embedded work correctly and meet your performance standards, keeping them current with the latest updates from sources such as Microsoft, device manufacturers, and other companies is important. In this document, the term "update" refers to one or more of the following items:
- Hotfix. A single cumulative package that is composed of one or more files used to update a product. A hotfix addresses a specific customer situation and cannot be distributed outside the customer organization. The terms Quick Fix Engineering (QFE), patch, and update have been used as synonyms for hotfix.
- Security update. A broadly released fix for a product-specific, security-related vulnerability. Microsoft security bulletins use the Microsoft Security Response Center Security Bulletin Severity Rating System to rank security vulnerabilities based on their severity. The ratings are, in descending order, critical, important, moderate, and low.
- Update rollup. A tested, cumulative set of hotfixes, security updates, critical updates, and updates packaged together for easy deployment. A rollup generally targets a specific area, such as security, or component of a product, such as Internet Information Services (IIS).
Updates address security vulnerabilities in operating systems and in applications. Some operating system updates that Microsoft releases might include new functionality that is required for devices to work correctly, but have no security impact. Like operating system updates, application updates can range from those that focus on simple functional improvements that are not related to security, to those that address vulnerabilities.
Regardless of where you get updates, installing them on devices running Windows XP Embedded in a uniform and scalable manner is increasingly important to your success as an OEM. A well-planned servicing strategy for devices saves you a significant amount of time and money that you would otherwise spend to react to a security compromise. This document helps provide general guidelines on how to create a servicing strategy. Note that the concepts that this document describes do not apply to all devices.
Servicing consists of two distinct steps: delivery and implementation. Delivery refers to how updates reach a device. Implementation refers to how updates are installed on a device. Delivery strategies include "pull" methods, in which a device initiates the update process by requesting an update, and "push" methods, in which a server initiates the update process by delivering an update to a device. Regardless of the method that you choose, you can use both Microsoft and non-Microsoft solutions to put it in place. Typically, you must build support for both delivery and implementation into your devices before you deploy them.
Strategies for servicing devices can be organized into the following categories:
- Replacing the run-time image. If you choose this strategy, you must replace the run-time image on a device with a new image that incorporates an update. For certain devices, such as those that start from a CD-ROM or a network-hosted image, this is the only servicing strategy that is available. You deliver updates either by distributing a CD that contains the new image or by refreshing the network image. You can implement updates by restarting the device.
- Updating files or the registry (or both) automatically. If you choose this strategy, you must run an agent on a device that replaces files or registry keys or both. The agent runs according to a script. Typically, you must have a server that can host the updates, and you must perform some tasks manually to create and serve the scripts. Proprietary servicing systems, including Device Update Agent (DUA) in Windows XP Embedded, fall into this category. You deliver updates by putting the appropriate scripts and files on a network server that a device can access. These scripts and files then implement the updates.
- Updating devices manually. If you choose this strategy, your service personnel manually update devices one by one. Although this strategy is the most expensive of the three servicing strategies, it can allow you flexibility in delivering and implementing updates. Your service personnel can deliver updates manually by transcribing them from a document. They implement the updates through keyboard entry.
The following sections describe the advantages and disadvantages of the different types of servicing strategies.
Replacing the Run-Time Image
You can replace a whole run-time image by using new boot media, as required by devices that start from a CD-ROM. Alternatively, you can reformat existing boot media and deploy a new image of the operating system.
Advantages to replacing the run-time image include:
- Satisfies all dependencies. When you replace a whole run-time image, you ensure that all dependencies have been satisfied and that the image is complete.
- Can use Windows XP Embedded hotfixes in their original state. Because Windows XP Embedded hotfixes update the component database, you do not need to do any additional work to rebuild the run-time image and deploy it to the device. The run-time image will contain the updated files and registry keys.
Disadvantages to replacing the run-time image include:
- Might require significant network resources. The large size of some run-time images might require a large amount of network bandwidth.
- Requires new or reformatted boot media. Typically, you must replace or reformat the boot media. This requirement might create a problem for CompactFlash–based devices (which are approximately one-third of the size of a PC Card) or for devices with traditional hard disks.
- Might require significant human resources. Because the entire run-time image is replaced, you must generate a new run-time image. Generating a new run-time image might require significant development and test efforts.
Updating Files or the Registry (or Both) Automatically
Typically, you have to update only the files and registry keys that are associated with an update to then apply and enable the update. Microsoft security updates for Windows XP Embedded package file and registry key updates together with an installer application to form a servicing package. You can apply servicing packages automatically or manually to a device or a set of devices.
The advantages to updating the files or the registry (or both) automatically include:
- Offers a single package format. All updates for a particular Microsoft technology work in the same way, regardless of their contents, which might be operating system updates, application updates, or new device drivers.
- Offers centralized delivery through automatic servicing. By enabling servicing clients on the device, you can use one central server to deliver an update to all Windows XP Embedded–based devices.
- Offers small servicing packages. A typical servicing package consists of the files to update and a script that contains registry key updates and instructions on where to copy the files. The payload can be compressed, reducing network load during delivery and reducing time to service.
The disadvantages to updating the files or the registry (or both) automatically include:
- Requires a server. To properly service a device automatically, you must maintain a server to manage the delivery process.
- Might require custom-made servicing packages. Because of the variety of network architectures and device configurations, you or your customer must sometimes create custom servicing packages to suit a particular environment.
- Might require different implementation methods for different technologies. Updates to non-Microsoft or custom applications might be packaged through Windows Installer or other technologies, whereas operating system updates are packaged through a special update installer. Device drivers might or might not use an installer. This variety challenges you to make sure that your devices support all the necessary implementation methods.
Updating Devices Manually
The advantage to updating devices manually is that you can customize the update procedure for each device to account for the operating environment, stored user and application data, and any special requirements of each device.
The disadvantages to updating devices manually include the following:
- Requires physically touching each device. To manually update your devices, you must perform the update procedures on each device.
- Prone to user error. When you repeat the same steps for a set of devices, you can make mistakes that might cause your devices to fail.
- Expensive to implement. Depending on the location of the devices and the personnel involved, manually updating each device can be expensive in terms of time, resources consumed, and device downtime. Any errors during updating may require repair or replacement of the device, which adds to the total cost of servicing.
If you decide to use incremental updates rather than replacing the run-time image, you can deliver and implement the updates either automatically or manually.
If you choose to apply updates automatically, you must use two different technologies: one that delivers the updates to the device, and one that implements the changes that are contained in the updates. You should think of these two technologies as separate operations.
If you choose to apply updates to a device manually, you must consider the nature of the device and its network environment. If the operating system that the device is running is using the files that need to be updated, you must take the device offline and then copy files to it. In this case, you can update registry keys by directly loading and modifying the hive files—the files that contain the registry—while the device is offline. If the operating system is not using the files that need to be updated, you can perform the update on the device.
You can also update registry keys by using Registry Editor (Regedit.exe) in the Windows XP Embedded operating system of the device, or by using Registry Editor in the operating system on a different computer to remotely connect to the registry of the device. For more information about editing the registry of a device remotely, see the Help in Registry Editor.
There are two major Microsoft technologies that deliver updates to devices running Windows XP Embedded.
Device Update Agent in Windows XP Embedded
DUA is a solution for delivering scripts from a server to a client device running Windows XP Embedded. It has a small footprint and low memory overhead.
DUA scripts are compiled files that you can use to copy, move, and delete files; update registry keys; and manage a device in other ways, such as restarting it, copying files to it while it is in use, and running arbitrary files on it. For more information about the DUA scripting language, see Device Update Agent Script.
You can deliver DUA scripts to a device manually or automatically. If you choose to deliver the scripts automatically, you must use a server to host the script. The device can then pull the script from the server on a schedule that you set, or the server can push the script to the device when the script is ready. For more information about configuring the DUA client, see Device Update Agent.
Systems Management Server 2003
Microsoft Systems Management Server (SMS) 2003 is a complete network management solution for enterprises. A component of Windows XP Embedded makes it possible for SMS 2003 to manage devices. For more information about SMS 2003, see SMS 2003 Product Information: Overview and SMS 2003 Advanced Client for Windows XP Embedded.
Whether you deliver updates automatically or manually, you must have a way to implement the updates on the device. There are a number of ways to implement updates, including:
- DUA scripting. Because DUA scripts can copy files and make changes to the registry, delivering a DUA script that contains file and registry changes implements the updates automatically. Each Windows XP Embedded update that Microsoft publishes includes information about the file and registry changes that are required to apply the update. You must obtain file and registry information for non-Microsoft updates from the companies that issue those updates.
- SMS scripting. SMS provides a method of packaging custom updates for the devices that you manage through SMS. For more information about how SMS packages updates, see Systems Management Server 2003 Product Documentation.
Updating your devices frequently can be expensive. However, servicing can prevent security compromises, which can be even more expensive. This section provides general guidelines on how to reduce the risk of a security compromise.
Assessing Your Security Risks
When you assess your potential security risks, consider the following factors:
- Network environment. Devices that are connected to a network might be vulnerable to network-based attacks, especially if these devices have unrestricted access to the Internet. You can help to mitigate this risk by connecting your devices to a corporate network, or—even better—by restricting both incoming and outgoing Internet traffic. For more information about technologies that can help you to mitigate the risk of exposure to network-based attacks, see "Building in Windows Security" and "Securing the Network" later in this document.
- Physical environment. Any kind of direct physical access to your devices by a malicious user—a user who intentionally accesses a system with the intent to cause harm to the system or to use it in an unauthorized manner—presents an obvious risk. For more information about technologies that can help you to reduce this risk, see "Securing Physical Storage Media by Using Enhanced Write Filter" later in this document.
- Data storage. Storing critical or sensitive data directly on the embedded device poses a security risk because a malicious user needs only to gain access to the device to gain access to the data. Instead, store critical data on a different computer or on a server that is connected to the network, where it can be shielded behind another layer of security. Limit the amount of data that you store on a device running Windows XP Embedded so that the device works normally and achieves your performance goals. For more information about technologies that can help you to mitigate the risk to stored data, see "Securing Physical Storage Media by Using Enhanced Write Filter" later in this document.
Mitigating Your Security Risks
Ways that you can help mitigate security risks to your devices include the following:
- Building small images. An embedded operating system that has a small footprint has less surface area that exposes a mobile device to attack. Choose an operating system that has the smallest footprint possible and can still meet your needs. Devices running operating systems that have small footprints also tend perform faster because of the small size of the media that they use and the small number of files that they must process, load, and catalog. For more information about building these devices, see Finding and Eradicating Big Footprint.
- Selectively implementing features. The more services and features that you enable on a device, the more vulnerable that device is to attacks. Choose the minimum set of features and functionality that meets your needs.
- Managing nonessential services. Services are processes that run in the background on Windows XP Embedded. If some services that are built into the operating system are unnecessary on certain devices, you should turn off or disable them. You can also configure services to start either automatically or manually. You can configure a service to start manually, or to be managed by the device itself, if the service must be installed on the device but poses a potential security vulnerability. For more information about managing base services in Windows XP Embedded, see Services.
- Using built-in security features. You can use Windows Firewall (formerly called Internet Connection Firewall), Winlogon, Group Policy, and access control lists (ACLs) to help secure computers running Windows XP and also devices running Windows XP Embedded. In Windows-based systems, an ACL is a list of access control entries that apply to an entire object, a set of the object's properties, or an individual property of an object, and that define the access granted to one or more security principals. The Windows Firewall feature is especially helpful in protecting devices from network-based attacks. For more information about this technology, see Windows Firewall.
The following sections further discuss technologies that you can use to mitigate security risks.
Building in Windows security
Security features in Windows XP Embedded can help reduce potential data loss or compromise by communicating directly with a device or by communicating with a device over the network. Consider using the following security features:
- Minlogon. Windows XP Embedded recognizes two basic security models: the Minlogon service and the Winlogon service. The Minlogon service, which is unique to Windows XP Embedded, provides faster startup times and a smaller operating system footprint at the expense of built-in security features. There are no users on a device that runs the Minlogon service: Programs run in the Local System context, which provides all users with complete control over the operating system. Security features such as Group Policy settings, logon rights, and ACLs are neither necessary nor available in this context, because there are no users. For more information about this technology, see Introduction to MinLogon.
- Winlogon. The Winlogon service is the standard logon context in Windows XP. Devices that run Winlogon are somewhat larger and slower to start than devices that run Minlogon. However, they use the full spectrum of Windows security features, including Group Policy settings, user logon rights, and ACLs. For more information about Winlogon, see Responsibilities of Winlogon.
- Active Directory® directory service. Active Directory provides a centralized, distributed computing infrastructure with built-in security. Devices running Windows XP Embedded can participate in an Active Directory infrastructure by including the appropriate Active Directory components. For more information about this technology, see Using Active Directory and Active Directory Security.
- Group Policy. If your devices run the Winlogon service, you can manage users and security groups by configuring Group Policy settings in Windows XP and Windows XP Embedded. For more information, see About Group Policy.
- Application programming interfaces (APIs) for credential management. Windows XP Professional and Windows XP Embedded provide APIs that you can use to implement custom applications for managing user credentials, instead of relying on users to type their user names and passwords. For more information about using APIs, see Credential Manager.
- Smart cards. Windows XP Embedded supports smart cards, including integrated management of smart card security and support for smart card readers. For more information about this technology, see The Smart Card Cryptographic Service Provider Cookbook.
Securing the network
You can use the following technologies in Windows XP Professional and Windows XP Embedded to help protect your devices from network-based attacks:
Windows Firewall is a port-based firewall service that blocks incoming traffic to your device on specific ports. Windows XP Embedded contains a Windows Firewall component that implements this functionality. For more information about this technology, see Windows Firewall.
The IP Security Tools and User Interface component provides Internet Protocol security (IPSec) policy management and diagnostic capabilities for both IPv4 and IPv6. You can use the IP Security Policies Microsoft Management Console (MMC) snap-in to configure and view both locally based and Active Directory–based IPSec policies. The IP Security Monitor MMC snap-in displays the details about the active IPSec policy and the security state.
The Ipseccmd command-prompt tool for IPSec provides an alternative to the console-based management and diagnostic capabilities that the IP Security Policies and IP Security Monitor snap-ins provide. You can use the ipseccmd command to configure IPSec policies and to display details about the state of the active IPSec policy.
For more information about IPSec, see How To Use IPSec.
The Kerberos protocol defines how client computers communicate with a network authentication service. Client computers get tickets from the Kerberos Key Distribution Center (KDC), and then present these tickets to servers to establish connections with those servers. Kerberos tickets are the network credentials of client computers. For more information about this technology, see Microsoft Kerberos.
Securing physical storage media by using Enhanced Write Filter
Protecting the physical storage media of your devices is critical to avoiding data corruption from outside sources and computer viruses. Windows XP Embedded provides the Enhanced Write Filter (EWF) component to help protect your physical storage media.
EWF helps to protect the contents of a volume on the physical storage media by redirecting all writes to a different storage location, called an overlay. In this context, an overlay is similar to a transparency overlay on an overhead projector. Any change made to the overlay affects the picture as seen in the aggregate, but if the overlay is removed, the underlying picture remains unchanged. EWF can protect one or more bootable and non-bootable disk volumes, including (but not limited to) hard disk drives, flash ROMs, and CDs formatted in the El Torito format.
EWF presents a servicing challenge, however. To service the underlying operating system or application that EWF helps to protect, you must first disable EWF. You can use the EWF API, which provides programmatic control of EWF from inside your own applications, to disable EWF.
The following tips can help you to successfully complete servicing tasks, and can help make these tasks less time consuming and less costly.
Servicing should not be an afterthought. When you design your devices, think about servicing by considering the following questions:
- Will your devices be able to connect to the Internet and communicate with a server?
- Will your devices use modem access?
- How many servers do you need to handle the load of servicing?
Create a Clear and Consistent User Experience
Invest the time required to design a clear and consistent user experience for servicing. For example, a set-top box periodically downloads a program guide. It can also download updates—a capability that represents a simple design solution that improves the user experience.
Test Your Servicing Solution
Test your servicing solution thoroughly so that you are sure that it works correctly. By the time you deploy your devices in the field, it is too late to fix major issues. If you thoroughly plan your testing and then test against your plan, you can potentially save time and money. Include scalability testing (tests that ensure that servicing scenarios work the same way, regardless of the number of devices) and corner cases (tests that introduce small deviations in sets of devices).
Have a Back-up Plan
Make sure that you create a back-up plan in case your primary servicing solution fails. If you typically service devices by using a broadband connection, you might also want to be able to dial up by using a modem. In addition, you might want to be able to service devices through a CD-ROM or a universal serial bus (USB) storage device, and be able to replace media and devices in case of failures.