Managing and Servicing your Distribution Share
Since you’d be using the distribution share (DS) provided with Windows Embedded Standard 2011 from RTM until the next service pack is out, it helps to consider how you are going to manage your DS. Well, firstly, here’s a hypothetical timeline on the changes that could happen to your DS. We’ll look at 4 different scenarios from the date of Standard 2011’s release to 5 years from now.
A. Time: Standard 2011 release (in H1 2010)
Your DS is in the initial state (the golden state). It contains all the Windows-Embedded feature packages plus all the embedded specific security updates that correspond to the Windows 7 security updates since Win7’s release.
B. Time: About a month later
New security updates are released by Embedded.
You can run PkgScn on these updates and decide if your runtimes need these security updates. If needed, you can import them into your DS. If not, then you need not import them.
What’s recommended: It is recommended to import all the security updates. Even if some updates are not applicable to your device, it doesn’t hurt to import them into the DS. That way, your DS will always be in a consistent, up-to-date state. The other advantage is that you don’t have to keep track of the updates that you didn’t choose to import. (I.e. you won’t face this scenario... “I think I ignored KB300000 since it was a Bluetooth security update and my device doesn’t contain Bluetooth. But am I sure that it was a Bluetooth update? Let me look up this Excel file to check. Wait a minute... is this Excel file up to date?”)
C. Time: About 3 months later; a new Out Of Band (OOB) package is released by Embedded, say .NET 4.0 or GoldDark (it’s hard to come up with cool OOB names! So something sounding like Silverlight should suffice for now)
The package is usually available on one of the usual websites (Out of Band updates, as well as Security updates can be downloaded from Microsoft OEM Online or the Mobile and Communications Extranet.). You import this package into your DS. You can now create embedded devices using this new OOB package. You again need not import this package if your device doesn’t have anything to do with .NET 4.0 or GoldDark
What’s recommended: To import the package for reasons similar to importing updates.
D. Time: About 5 months later; a bug fix is done in a package, say .NET 2.0. The updated feature package is released by the embedded team.
Why do we release an updated feature package instead of an update package?
Along with binary changes, a feature package also contains Windows-Embedded specific information which an update package doesn’t. For example, a feature package contains dependency information so that when you select a package in ICE, it tells you that it depends on package X, Y and Z. An update package doesn’t contain any Windows-Embedded specific information. It only contains logic and rules that allow the operating system’s CBS layer to install the update (more on CBS in another blog).
Since we have about 600+ feature packages, there is a remote possibility that one or more of these packages may have incorrect package dependency information. To rectify this, we need to service the Windows-Embedded specific information and this is done only through an updated feature package.
What’s recommended: Importing this package into the DS. Again, even though it is a package that your device isn’t currently using, it’s a good practice to import it into your DS.
Based on this timeline, here are some basic findings:
1. It is better to import all packages and updates that are released by the Embedded team
2. It is important to not remove or delete any package from the DS.
ICE and ImportPackage access the DS by using a binary index file. Whenever you import a package into the DS, this index file is updated by ImportPackage. So, if you manually delete a package from the DS, the index file goes out of sync, hence causing problems.
Why would somebody delete a package?
“Hey, I am developing a device that only needs a minimal runtime and the basic networking package. Why do I need all other packages? They take up too much disk space. That’s why I deleted them…”
Suggestion - Don’t bother about disk space. The DS doesn’t reside on the embedded device. It exists on developer machines or on a server. On these boxes, space shouldn’t be a big issue considering the problems you can avoid.
3. Since there are constant updates to the DS, it makes sense to have regular backups of the DS. Probably each time you decide to import update packages. You could consider a configuration management system to store your DS. A simpler and more efficient way would be to use a server share.
4. Since you may have to manage over a long duration, you could probably have a folder structure as follows
\\server\WES_DistributionShares
Gold
SP1
Backups
Gold
Sep-01-2010
Jan-01-2011
Feb-01-2011
SP1
Sep-01-20xx
Oct-01-20xx
Hope you find this useful... feel free to post your questions... till then, ciao.
Technorati Tags: XPe,Embedded Standard