Windows Embedded Change Management
**Updated 3/26/09 with preface
[The following article is authored by one of the Windows Embedded MVPs (Most Valuable Professionals). Our MVPs have a heavy background in Embedded systems and are a great repository of information on Windows Embedded products. We’re providing this space on our team blog as a service to our readers by allowing MVPs to share some of their knowledge with the rest of the community.]
To design and build a device are just the initial steps in the complete life cycle of a modern embedded system. Connected devices, especially, can and need to be updated, either to enhance their value while in field, or to guarantee their correct behavior by rolling out necessary patches to fix bugs or security holes.
In contrast to the enterprise, embedded change management scenarios are different because of the configuration of the image as well as the environment the devices may in deployed in.
To patch or not to patch
It is very important to evaluate this scenario. A thorough understanding of the device environment should be established before developing an embedded change management strategy.
First rule: Don’t panic
Due to the fact that Windows Embedded Standard is binary-compatible with Windows XP Professional, it is conceivable that the security and application fixes rolled out on Microsoft’s “Patch Tuesday” could be installed onto Standard devices as well. An overeager administrator could, therefore, have the idea of installing all of those patches as they come in, just to be on the safe side and keep the system in an apparently best possible health state.
But, in the case of embedded, what is good in the enterprise may not be good for embedded devices.
The main reasons for this are:
- Embedded (fixed function devices) are a subset of the desktop functionality. If there is e.g. no Media Player or Internet Explorer, no patches for this application should be deployed: Do not patch what is not there!
- The amount of available storage such as Compact Flash cards (for example in industrial automation) is not yet as extensive as on desktop systems. Therefore unnecessary patching increases the image size and takes up valuable disk space.: Keep the image footprint low!
- If the system runs well and the patch is adding functionality that is not directly in line with the device’s usage scenario, one should think twice before updating it: Never change a running system! (Well, at least if you are able to avoid it!)
These points have influenced Microsoft’s decision to disable the Windows Update service in Windows Embedded Standard (or previously XP embedded).
Just think of a small footprint embedded image getting every single update over a two year period. It would end up looking much more like an XP Pro image than the original small, embedded one.
Second rule: Have a change management strategy at hand
There are two basic types of updates. Partial upgrades of applications, drivers or the operating system and complete OS image updates. Unfortunately there is no golden rule when to use which strategy, because the benefits of each approach are closely related to the dedicated project situation:
- Partial upgrades (like applying security updates)are very bandwidth friendly and therefore much faster to deploy than large image updates. Nevertheless, partial upgrades do have drawbacks in terms of higher development costs associated which creating and managing multiple versions of an image and also greater testing effort.
- Complete image updates (also known as an image refresh) are very good in delivering larger patches such as service packs or major release updates, especially where the patch size comes close to the OS size, anyway.
Remember that you can apply Microsoft patches to the Windows Embedded Standard database, but these updates won’t be applied to your images in the field unless you implement an image update strategy.
It is impossible for anybody to foresee all the changes that may be needed to a device after it has been rolled out. Therefore it is a best practice to think about adopting either of the two basic scenarios beforehand. This means that you should include the required infrastructure to do both types into the Windows Embedded Standard image, as well as setting up any necessary back-end infrastructure.
In addition both approaches should be scoped, implemented and tested. Updating should just be a matter of what patch or image to roll out, not how. Not planning how to update the image could lead to unpleasant surprises in the long run.
Third rule: Think about scale
No, this is not an indiscreet hint about the increase of body weight during Christmas time!
The scale of the device deployment and the environment it is deployed in are considerations when managing these devices:
- For small groups of devices simple, or even custom, change management solutions might be the easiest to handle looking at cost and effort. The Device Update Agent, for example, does a great job in these cases, but offers just rudimentary support for reporting and debugging.
These solutions may not be appropriate if there are several hundred devices to manage at a site. - Enterprise solutions such as WSUS and SCCM scale well beyond hundreds of thousands of devices. Of course, due to the fact that they have been developed for enterprise customers, there are a number of dependencies in this kind of infrastructure, for example Active Directory.
- It is still a bit early, but looking into the future, we will have connected devices all over the Internet and we will be required to have systems that are able to do change management for millions of devices spread across the cloud (or the world).
Unfortunately, there is no current product helping OEMs scale into this area yet but if you plan to build such a device it may be a good idea to consider how to implement a custom solution for these scenarios.
In my next blog posts, I am going to have a closer look at the different change management scenarios as well as tools to use.
Alexander Wechsler
Wechsler Consulting