Chapter 6. Servicing 
See also:

Comparison of Servicing Solutions
Introduction

Chapter 6. Servicing
See also:
Comparison of Servicing Solutions
Introduction
This chapter includes techniques that the OEM can leverage to update and/or service their deployed images. It also contains suggestions regarding Security Updates.
In order to maintain the content integrity of your target device media, any changes made by the end user must be closely supervised and/or specifically approved by the OEM. This ensures that the OEM retains full control of the device media content.
Servicing Methods Objective
You, as the OEM, must maintain 100% “ownership” of your deployed Standard 2009 image. As stated in Microsoft’s OEM Client License Agreement (CLA), you are solely responsible for end user support.
If your end user needs service of any kind regarding your deployed device, they must contact you for support. Microsoft Technical Support cannot support your customer because only you have the knowledge of what your product has been designed to do.
You should ensure that your image is serviceable after it has been deployed to the end user. This includes having in place a fully-tested process for updating the image or applying hotfixes.
The update mechanisms for Standard 2009 images are different than the mechanisms used to update Windows XP Professional.
A common method that is used to update Windows XP Professional is to connect to the Internet and browse to www.windowsupdate.com. From there, the user is prompted to pick and choose the desired updates. This mechanism does not work for Standard 2009. The following blog link explains further.
Why can't I use Windows Update with XPe?
Standard 2009 images are directly managed and maintained by the OEM who created the image. There are two fundamental update approaches.
Componentized update.
Update the Standard 2009 Component Database with updated components, and then rebuild your image using the updated database and Target Designer.
Run-time update.
Directly update the image that is already deployed (do not update the Component Database and then update and deploy a new image).
Image ownership considerations
Every Standard 2009 image is a “sub-platform” of Windows XP Pro. As such, it has been custom tailored to fulfill exactly one target device scenario; as defined by you, the OEM. In contrast, Windows XP Professional serves as an operating system platform designed to accommodate any third party application that adheres to MSDN XP Platform development guidelines.
Any attempt for an end user to add a third party application to a Standard 2009 device, such as something an end user might find on the web, has a good chance of failing, because some XP operating system component that the application requires might be missing.
It is critical (and required) that you, as the OEM, fully specify the anticipated usage by the end user, and fully test those scenarios. This is typically the main application for the device (the “limited runtime scenario”). You must test, in advance, any new applications that you (the OEM) deem that the end user is allowed to install, today or at a later time. This testing is required to ensure that their Standard 2009 O/S sub-platform fulfills all the requirements of the application.
Thus you are 100% responsible for defining the functional specification of the Standard 2009 device. Further, any modifications to the Standard 2009 image must be performed by you so you can follow up with complete functionality tests (regression testing) before releasing the updated image.
Consider the situation where an end user decides to add applications or security updates to the Standard 2009 device, and suppose this causes the functionality of the device to fail.
Now you have the situation where multiple “owners” have made changes to the image. Would you, being the OEM, feel obliged to debug this? Probably not. So the customer goes to Microsoft support. Microsoft doesn’t own the image, and Microsoft does not own the set of tests used by the OEM to ensure that the image meets the OEM spec. So there isn’t a whole lot Microsoft can do without becoming yet another “owner” of the image, blurring the issue even further.
In contrast, Microsoft is necessarily the “owner” of all Microsoft’s supported full desktop platforms, such as XP Home and XP Professional.
For Standard 2009, you, being the OEM developer of the device, are the “owner”. All management of the image must go through the OEM. Microsoft is available to assist in supporting the Standard 2009 OEM. Microsoft is happy to assist the end user too, as long as the OEM works with Microsoft and retains true ownership of the Standard 2009 OS image. The OEM is responsible for deploying any subsequent updates and conducting the appropriate regression testing of that image.
Since the Standard 2009 image is a sub-platform, sometimes security updates appear that are not applicable to that image (for example, because it may be an update for some component that is not present), and hence there is some risk that installing such an update will cause the image to fail.
Only the OEM has the unique Standard 2009 configuration file information required to make such decisions.
Device deployment and servicing options
The following chart lists the most common hardware scenarios and possible servicing methods.
The boot partition of a Standard 2009 device may be serviced either online or offline. Online servicing refers to servicing the image while the device is currently running and using the partition as the live system volume. Offline servicing refers to a process that involves booting up to an alternate operating system partition, which allows you free access to the runtime boot partition volume, because it is offline. Offline servicing offers the ability to replace the entire partition image.
Device scenario
|
Update mechanism
|
Offline servicing method
(minor modifications or complete replacement of image)
|
Online servicing method (only minor modifications of image are possible)
|
Fixed disk boot device with one partition
network connectivity
|
Network via Remote Boot
|
Boot to Ramdisk using Remote Boot. Then service the image located on the fixed disk.
|
After booting to RamDisk, use scripts to update or replace the image on the fixed disk.3
|
Fixed disk boot device with one partition
network connectivity
|
Network via Device Update Agent
|
Not applicable
|
Push DUA script file to the device via networking, or use DUA’s HTTP mechanism.
|
Fixed disk boot device with one partition
removable storage device
|
Inserting removable storage media as a secondary device (floppy, CDROM, USB storage device etc.)
|
Not applicable
|
Insert storage media and then launch the scripts contained within, to update the live image.
|
Fixed disk boot device(s) containing two or more bootable partitions.
Network connectivity
|
Network
|
Via network, edit BOOT.INI to change boot partition. Reboot from the alternate partition, and then service the primary partition. Switch back when done.
|
Use the offline method, or use DUA or command scripts deployed via removable storage media, that take into account the fact that the image being updated is live (reg.exe, inuse.exe etc.)
|
Fixed disk boot device(s) containing two or more bootable partitions.
Removable storage device
|
Inserting removable storage media (floppy, CDROM, USB storage device etc.)
|
Via command files, data files etc. found in removable storage media, edit BOOT.INI to change boot partition. Reboot from the alternate partition, and then service the primary partition. Switch back when done.
|
Use the offline method, or use DUA or command scripts deployed via removable storage media, that take into account the fact that the image being updated is live (reg.exe, inuse.exe etc.)
|
Fixed disk boot device(s) containing one partition
CD-ROM device; used to boot an El Torito maintenance image
|
Inserting El Torito CDROM boot device, then rebooting to the CDROM drive.
|
Via command files, data files etc. found in a Standard 2009 image on the CDROM that you designed for maintaining your image.
|
Use the offline method, or use DUA or command scripts deployed via removable storage media, that take into account the fact that the image being updated is live (reg.exe, inuse.exe etc.)
|
Boot media can be physically removed
|
Physical replacement
|
Physically swap out the media, to replace the old image with the new image.
|
Not applicable
|
Remote Boot (diskless system)
|
Remote Boot Server
|
Update the SDI image found on the Remote Boot Server
|
Not applicable
|
El Torito (diskless system)
|
Physical replacement of CDROM media
|
Physical replacement of CDROM media
|
Not applicable
|
Fixed disk containing one partition
SUS Client4
|
SUS or WSUS client
|
Not applicable
|
SUS or WSUS offer the ability to manage incremental image updates from a central server location.
|
Fixed disk containing one partition
SMS or SCCM Client5
|
SMS or SCCM client
|
Not applicable
|
SMS offers the ability to Manage incremental image updates from a central server location.
|
Booting to Ramdisk from a storage device (including USB storage)
|
Update the SDI file via network or via transport of media.
|
Update the SDI image found on the storage device
|
Update the SDI image found on the storage device
|
USB Boot
|
Booting from an inserted USB storage device that is used for servicing the fixed storage device.
|
Insert a USB storage media and then reboot the device. This will cause booting from a USB media servicing image that is in turn used for servicing the fixed storage media.
|
Not applicable.
|
If your boot device is Flash storage media and you are using EWF-RAM to protect the device from excessive writes and/or to ensure that the system is “stateless” across reboots, EWF must be disabled before servicing the image, and then re-enabled after servicing it.
SCCM 2007 Prereq Macro is Fully Tested with CTP!
Macro Pre-Requisite Component for SCCM Client is Now Available
Flowchart
The following flowchart outlines the major choices you need to make when deploying or updating your device image. Note that SP1 is no longer formally supported and you should only apply the SP1 portion of the flowchart if you are using it to maintain updates to deployed XPe SP1 devices.
The rest of this document explores your deployment options in more detail.
Servicing strategy
Consider the major servicing strategy categories:
1. Replace the entire runtime image
If you choose this strategy, you must replace the runtime 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 (Remote Boot), this is the only servicing strategy 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.
You can replace a whole runtime image by replacing the physical boot media.
Alternatively, you can reformat existing boot media, and copy across a new image of the operating system.
In order to replace an entire image, it is necessary to set it into the “off-line” state, meaning you must boot the system up on an alternative boot volume, with a separate copy of an operating system (WinPE, DOS, Windows XP Pro, a Standard 2009 image used for servicing purposes, etc.).
You can use the SDI feature of Standard 2009 to package your replacement disk volume image into a convenient file form, making it easier to package and deploy.
Here are some implementation scenarios.
“Ping-pong” hard disk image update method
Configure your hard disk with two partitions of identical size, both configured to be bootable. Configure the boot.ini file so that the system initially boots up on the first partition (containing your current embedded image). When a new image becomes available, your custom image update agent receives an SDI file, and deploys it into the second partition. Once the new image is successfully copied to the second partition, the boot.ini file is modified to indicate that the second partition is the boot partition, and the system is rebooted. When a future update arrives, you deploy it to the first partition, then modify boot.ini so it will subsequently boot from the first partition, and so on.
Dedicated servicing partition method
Use method (1) above, except dedicate one partition to contain an operating system dedicated to servicing the other. Boot into the servicing partition whenever you wish to update the normally live partition.
You can edit BOOT.INI regardless of whether it is located on an on-line or offline partition. Any changes to BOOT.INI will be observed by the boot loader the next time the system is restarted.
If you choose this strategy, you must replace the runtime 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 (Remote Boot), this is the only servicing strategy 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.
Advantages and disadvantages to replacing the entire runtime image follow.
Advantages (replacing the entire runtime image) Image is tested and managed in a 100% known state.
When you replace a whole runtime image you ensure that all dependencies have been satisfied and you can more effectively test and manage the completed image before deployment.
Simplified image management.
You update your Target Designer database with the latest Standard 2009 hotfixes, then rebuild your image using the new components (from Target Designer, choose Configuration->Upgrade Configuration, and then rebuild.) You do not need to do any additional work to rebuild the runtime image and deploy it to the device. The runtime image will contain the updated files and registry keys. No need to create and test an update package for every discrete update. All updates occur in the Target Designer database which is easier to maintain, secure and back up. You know exactly what is being deployed for each target device, compared to many incremental updates where there is a greater potential for error.
Useful when there are many image updates.
If you are adding a major application or an update rollup to the image, it frequently makes more sense to replace the entire image.
No need to deploy Device Update Agent; this is a tool that is specifically designed to update individual files and registry entries. Disadvantages (replacing the entire runtime image) Might require significant network resources.
The large size of some runtime images might require a lot 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 the size of a PC Card, or for devices with traditional hard disks.
Might require significant human resources.
Because the entire runtime image is replaced, a new runtime image must be generated. This might require significant development and test efforts.
Entire runtime image replacement is the only viable strategy for devices that start from read-only media, including:
"El Torito" CD-ROMs. (El Torito is the standard for creating bootable CD-ROMs on the Intel platform). For more information about El Torito, see "El Torito" in the Microsoft Windows XP Embedded documentation, available online via this link:
Bootable CD-ROM
Network-based images from Remote Boot servers.
For more information about the Remote Boot service:
Remote Boot Overview
Deploying Windows XP Embedded Remote Boot
2. Incrementally update files or the registry (or both) automatically
Typically, an update involves selective modification or addition of files and registry keys. A Microsoft update for Standard 2009 contains package file and registry key updates together with an installer application to form a servicing package. These servicing packages can be applied automatically or manually to a device or set of devices.
If you choose this strategy, you must run an agent on the embedded device that replaces files or registry keys, or both. 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 Standard 2009, 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.
Advantages (incremental automatic updating) Offers a single package format. Offers centralized delivery through automatic servicing. Offers small servicing packages.
All updates for a particular Microsoft technology work in the same way, regardless of their contents, which might be operating system updates, application patches, or new device drivers.
By enabling servicing clients on the device, a single central server can be used to provide a delivery mechanism for all Standard 2009 devices with a single update.
A typical servicing package consists of the files to update and a script containing registry key updates and instructions on where to copy the files. The payload can be compressed, reducing network load during delivery and time to service.
Disadvantages (incremental automatic updating) Requires a server in order to automate.
In order to properly service a device automatically, a server is required to manage the delivery process.
Might require custom-made servicing packages.
In order to deliver an update, a servicing package must be created. Due to the variety of network architectures and device configurations, servicing packages sometimes must be custom crafted by you or your customer to suit a particular environment.
Might require different implementation methods for different technologies.
Updates to non-Microsoft or custom applications might be packaged by using Microsoft Windows® Installer or other technologies, while operating system updates are packaged using a special update installer. Device drivers might or might not use an installer. This variety challenges you to make sure that all the necessary implementation methods are supported by your devices.
3. Incrementally update files or the registry (or both) manually
If you choose this strategy, your service personnel must manually update devices one by one. While this strategy is the most labor-expensive of the three servicing strategies, it can allow you flexibility in delivering and implementing updates. In some cases you may need to manually implement updates.
Advantages (incremental manual updating) Most customizable option
Manually updating a device allows you to customize the update procedure for each specific device, taking into account the operating environment of the device, user and application data stored on the device, and any special requirements to update the device.
Disadvantages (incremental manual updating) Requires touching each device
In order to manually update a device, someone must visit each device individually and perform the procedures on each.
Manual updates are prone to user error
Performing the same steps over and over for a set of devices can lead to errors during the process, which can lead to device failure. Very costly to implement
Depending on the location of the devices and the personnel involved, manually updating each device can be very costly in terms of man-hours, resources consumed, and device downtime. Any errors during updating may repairs up to replacement of the device, which adds to the total cost of servicing. 4. Replace the runtime image on a Remote Boot server
With Remote Boot, the image is maintained on a server and the remote client devices each copy the image from the server to the client into a RamDisk, and then boot themselves up. You deliver an update by simply replacing the image on the server with a new image.
If you are deploying Remote Boot, then any updates need to occur on the SDI run time image file located on the local server. In this case it usually makes sense to rebuild the entire image.
However it is possible to deploy updates only to the SDI image file. This allows you to patch/update the SDI incrementally locally without resending the entire image out.
Here is the overall process for updating an SDI file.
Create an empty virtual drive
Extract the partition data from the production SDI image and load it into the virtual drive
Make the desired file changes on the image that is loaded on the virtual drive
Write back the whole virtual drive, replacing the old partition data (blob) in the production SDI image
A detailed example follows.
Use SDILoader to create a blank disk (H:) large enough to hold the partition to be extracted from your final disk image E:\FOOBAR.SDI
Extract the partition from the final disk image partition using sdimgr /writepart:H: E:\FOOBAR.SDI /yes
Make your required production image changes to H:
Delete the partition in the final disk image using sdimgr /delete:PART E:\FOOBAR.SDI
Write out the H: drive with all your changes using sdimgr /readpart:H: E:\FOOBAR.SDI /yes
5. Using the USB Boot feature: Physically replace the USB device
USB Boot is convenient from a servicing standpoint because you can update the whole image by unplugging the old image and replacing it with a new one. USB storage devices can be physically small and hence easy to mass distribute.
6. Using the USB Boot feature: Create an image for servicing purposes that boots from the target device USB port and then updates the fixed storage media.
In this scenario, your target device has a fixed IDE or SATA device that serves as the normal boot device. When you need to service the device image, you reboot the device using a USB storage device that you pre-configured for servicing the device. After boot completes, the IDE or SATA drive can be serviced at the file level or it can be completely replaced, using a script and new replacement image contained in the USB boot (servicing-only) image.
Note that you must include the USB Boot components in the servicing image, but do NOT include the USB Boot components in the normal run time image, because in normal operation, the boot device boots via IDE or SATA.
|