Chapter 6. Servicing See also: Comparison of Servicing Solutions Introduction

Chapter 6. Servicing

Introduction

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

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.

Image ownership considerations

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 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.

Flowchart

The rest of this document explores your deployment options in more detail.

Servicing strategy

1. Replace the entire runtime image

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

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

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

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.

1. 
   Create an empty virtual drive
   
2. 
   Extract the partition data from the production SDI image and load it into the virtual drive
   
3. 
   Make the desired file changes on the image that is loaded on the virtual drive
   
4. 
   Write back the whole virtual drive, replacing the old partition data (blob) in the production SDI image
   

A detailed example follows.

1. 
   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
   
2. 
   Extract the partition from the final disk image partition using sdimgr /writepart:H: E:\FOOBAR.SDI /yes
   
3. 
   Make your required production image changes to H:
   
4. 
   Delete the partition in the final disk image using sdimgr /delete:PART E:\FOOBAR.SDI
   
5. 
   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

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.

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.