Here is some more information that people may find useful. In CE 5.0 and before, and in WM2003 and before, we used NOR flash with a file system whose format was known and where we had PC-resident drivers that could construct pre-built images of that format.  This meant that the TCM utility could pre-construct a file system with all its contents intact and create HEX file from it.  Such a HEX file could then be loaded as just one more image in an OS Update.  When that was done, the file system would be pre-loaded with the content of the "Gold Image". Beginning with WM5 and in CE 6, we are now using NAND flash and a file system whose format is not known and for which no PC-resident drivers exist.  Hence, there is no way to pre-build an image with the contents of such a file system.  There is therefore no way to load such an image it as part of an OS Update. By popular demand, we created a new mechanism, called a CAR/GAR files which provides a SIMILAR but often more limited mechanism.  A CAR/GAR file is essentially a CAB file containing an archive of the \Application folder contents in a folder on the PC.  We then made it possible to include such a file in an OS Update Package.  When the Package is applied, the CAR/GAR file is processed before the actual OS Update.  The Application partition is first erased and then the CAR/GAR file is unpacked into the \Application partition.  Then, the actual OS Update is performed. This mechanism works fine, so long as the OS Update itself does not REQUIRE that the Application partition be reformatted.  Whether the Application partition must be reformatted depends on the OS you are going from and the OS you are going to (typically based on whether the size of position of the Application partition changed between the two OSes). If the Application partition is preserved across the OS Update, then erasing and unpacking the CAR/GAR file into the Application partition will achieve the desired result.  If the Application partition is reformatted as a result of the OS Update, then everything done by unpacking the CAR/GAR file will be lost. It is most common that going from the one BSP to another of the same OS version (e.g. WM 6.1 to WM 6.1) will NOT require the Application partition to be reformatted.  When going from different major versions of Windows, it is much more common that the size or position of the Application partition will change and hence it will need to be reformatted.  Only the device team that produces the OS can tell you for sure whether it will or won't be able to update from some other OS without losing the Application partition.

 

The upshot is that SOMETIMES it IS possible to implement a Gold Image approach for WM5+ or CE6 devices.  But the mechanism is very different than it was for devices that supported TCM.  And unlike devices that supported TCM, since there is no way to pre-build a pre-populated image of the Application partition to be loaded as part of the OS itself, the mechanism depends on the fact that the Application contents can be loaded BEFORE the OS Update and will survive across the OS Update.  When this is not the case, then a Gold Image approach is NOT possible for such devices.  And the determining factor is the FROM and TO OSes themselves, NOT anything that can be controlled from outside those OSes.

 

We have in some cases produced special OS Updates procedures that can save a MINIMUM of stuff to keep manageability via MSP (e.g. save and restore network and relay server settings) across an OS Update from two major OS versions (e.g. WM 5 to WM 6.1 and WM 6.1 to WM 6.5).  In such cases, we can stash a few key things across a 2-stage OS update and get the device back on the network and manageable by MSP afterwards.  But the amount we can save is very small and hence such solutions rely on MSP to put back most everything that was in the Application partition, since it was completely lost when it was reformatted. Each such solution is custom to a pair of OSes and a limited set of devices.  We make these solutions available, when they exist, so if you have a specific need, please ask.  And in the less extreme cases described above, you can use CAR/GAR files to do the job more easily.  The latest OS Update Package Builder, version 1.56 supports CAR/GAR file and documents their use.  It can be found at: http://support.symbol.com/support/product/AirBEAMBeta.html

I have a number of customers applications where the MSP is enabled after OS Update using customized OS builds by the OS Package Builder - for all variants : CE5 and CE6 and WM5 and 6 MC30xx, MC31xx, MC75, MC70, MC90xx Requirements: - an airbeam.reg in \Application where the SERVERIP, FTPUSER, FTPPASSWORD have the right values for an FTP-Server (=The Relay-Server) and ENABLE30=1, SCHEDULEMODE30=1 and a SCHEDULEINTERVAL30=1  (would checkin every minute) - and install the required ABUP (either via TCM-approach or via restore-procedure (install cab) or provisioning via MSP) in some cases the OS Package is staged and then via an ongoing-provisioning-policy further packages/settings are installed automatically onto a device which got just this package. there are different procedures on getting customized OS builds - via TCM (CE

It is not really a matter of whether we have the ability for "MSP to store context info".  There is NO PLACE in a device to store context info except the Application partition.  MSP stores information persistently in the Application partition.  So long as that is kept intact, the context information wil be preserved. When doing an OS Update, you can choose whether to replace the Application partition or not.  If you replace the Application partition, then all information MSP needs is lost and there is nothing MSP can do about that.  You can either leave the Application partition intact, or you can replace it with an Application partition that has the context information in it (a so-called 'Gold Image' created using TCM from a device that has the context information in it). In some cases, the size of position of the Application partition changes from one OS to another.  When that happens, the Application partition CANNOT be preserved across the OS update and hence the ONLY choice you would have is the 'Gold Image' approach mentioned about.  In other words, since the prior contents of the Application will ALWAYS be lost in such cases, the only way to deal with it is to load an Application partition that has the required context information built-into it. I don't want to infer that such an approach is EASY - in fact it is quite challenging to get right.  I am just saying it is possible and sometimes it is the ONLY way to accomplish the desired result.  In general, what you would want to do is load the new OS on a device manually, Stage that device with a minimum of information required to get it manageable, capture the Application partition of that device, then build an Application hex using TCM that allows other devices to be loaded with the same Application contents.  Then build an OS update Package that contains that Application hex and deploy to a new device to verify that it works as expected.  Once that works, then you can update many devices using it. We have been asking the device teams for YEARS for a way to be able to store some context information somewhere OTHER than the Application partition.  So far, they have never done so.  We have explained WHY we need it, but they have never wanted to increase cost of devices to make it possible. It is also worthwhile to note that there is a major difference between WM and CE devices in the way OS update is handled.  In particular, there is NO WAY to pre-build an Application partition for WM devices that can be used to pre-populate the Application partition in situations where the Application partition contents are unavoidably lost as a result of an OS update.  This means that when this situation occurs on a WM OS update, there is NO viable solution.  It is also important to note that starting with CE6, there will also be NO WAY to pre-build an Application partition, so the same problem may apply to such devices. We have been continuing to push the device teams to provide a way to save context across an OS update and it looks like it WILL be supported on new devices starting from CE6 and WM6.5.  The amount of such information that can be preserved is quite small since it requires that a separate partition be allocated that can NEVER be used for ANYTHING else.  The plan is to allow OS Updates to use this area to save the MINIMUM amount of information to be able to get the device manageable again (e.g. Certificates, WLAN settings, Relay Server settings, Agent settings, etc.) so that even if the Application partition is BLANK following an OS update, the device can be manageable again and MSP can the redeploy anything that is needed.  This new capability will be coming, but it is NOT available on ANY device yet.