**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:
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:
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:
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.
Embedded devices quite often have special footprint requirements that have direct effects on the way