Thomas; It seems that I gave you slightly incomplete information.  The abup30 package detects devices where the built-in MSP Agent is stored in Platform and where there is sufficient room in the Platform partition to update the software in there.  So, what you saw does make sense. The only way we can think of to address this situation is to "fill up" the Platform partition on the device you use to build your gold image.  If you ensure that there is insufficient space on Platform BEFORE you install the abup30 Package, it will install everything on Application.  Then you can capture the contents of Application and make a GAR file. Allan

Allan, that is the trick. Works perfect now. Thomas

Allan, makes sense and I agree to what you pointed out. Due to the fact that creating a gar file for the platform partition is not possible to preserve the content it prevents me to create an pre-configured MSP system as part of a Gold Image for the device. Thomas

Thomas; I am not sure why you think that is the case.  If you take a device and Stage it using MSP to the point where it is managed by MSP, you will find that everything MSP has loaded into the device is stored in Application NOT in Platform.  This includes updates to the MSP Agent as well as Persistent Settings, etc.  If you then extract the contents of the Application partition on that device, using Remote Control or ActiveSync, and make a GAR file, you can apply that as part of an OS Update and have the device be ready to manage with MSP after applying that OS Update. The only time when that is NOT the case is when you are updating from one OS to another where Application is unavoidably cleared as part of the OS Update.  Such a situation is usually rare, but it does happen, usually when going from one major version of the OS to another.  The typical reason this happens is that the size of the OS has grown and it was impossible to fit everything without reducing the size of Application, this requiring it to be reformatted. In such a case, there is no solution because of an inherant inability of the device to preserve ANYTHING across such an OS Updated.  This is an inherant limitation of MPA 2.0 and below that I have been complaining about for a long time.  Note that MPA 3.0 will be providing an extra area where it will be possible to preserve JUST ENOUGH across even the most extreme OS Update for a device to maintain manageability.  But MPA 3.0 is still a ways off.

Allan, I am confused now. I started from scratch on my MC3190/CE6 (factory default). I am scanning my staging profile to connect the MC3190 to my network and relay server and start downloading the following packages: - abup30_ddd (7.03.46) - debug30 (2.0) - GetAdapters (2.71) - MotoRemoteControl (2.1.0.3005) - network setting (Fusion30.publicsettings.xml) - StartSmartStaging (6.1) (Force Install) Staging done. Connect via Remote Control Session to the MC3190 and I will find MSP related files in both application and platform partition. The MSP Agent is stored in "\platform\airbeam". See attached screen shots. I created an application.gar file from the content of the application partition, created an whole OSUpdate package including the CleanPlat.hex. The OSupdate package was applied successfully on my MC3190. MC3190 restarts with the following results: - MSP Agent falls back to build in version - Network is set - Relay Server is set - MotoRemoteControl works. Attribute identy.clientversion shows "7.03.14" Attribute inventory.abup30 shows "ddd_7.03.46" My MC3190 is still working but a little messed up. Thomas

...and now the 1 Million Dollar question: Why are the MSP components (Agent, Control Module, etc.) installed in "application" and in "platform" partition? Makes it not more sense to have it installed in "application" partition only? This is what already happens on Windows Mobile 5, 6, 6.1 and 6.5. Thomas

Thomas; I am not sure the exact intent of your question.  When you talk about MSP Agent components being installed in both application and platform, do you mean when built into the device, when updated, or both? On devices that have a platform partition (e.g. CE devices), the MSP Agent files need to be loaded into the platform partition (but copied and run from Windows) out of the box because the application partition, being ultimately under the control of the customer, may be cleared and replaced.  Hence, if we loaded the MSP Agent into the application partition, it could go away and there would be no way to put it back.  On devices that do not have a platform partition (e.g. WM devices), the MSP Agent files are in the OS image and appear in Windows. But in either case, when an update of the MSP Agent is done, it is done to the application partition in such a way that the files will be copied over the files in Windows that may have come from the platform partition or OS.  If the application partition is ever cleared, the updated MSP Agent will be lost, and the device will revert to the version of MSP Agent that was built-into the device (in platform or OS). This was not always the case.  Back when we only had ONE version of abup30 Package, it tried to update things into the platform partition on devices that had one.  But that often ran into space issues.  And in those days, we also copied the files into Windows on WM device, which meant that the update did not survive a clean boot.  So, now, MSP Agent updates always go to the application parition and things work as close to the same across all devices as is practical given the inherant differences in devices. Allan

Yes it is right. Upgrading from WM61 to WM65 with one Gold Image is not possible. My mistake. Back to the initial question. Any experience in the field how to include the content of the platform folder into a Gold Image??? Thomas

Regarding WM6.1->6.5 upgrade via MSP, have you tried the brute-force method, which is making an AB "normal" package with all the 18 files (whose dest'on folder is \Temp) and executing WM6_Update.exe as the installing application, then uploading this package to MSP, them making a bundle with it?

On CE6 devices, just like on all WM devices, it is no longer possible to pre-build File System partitions for loading as part of an OS update.  This is because the file system changed and there are no available tools (ala TCM) to build file system images offline.  So, on CE6 devices, there is no way to include a custom Application or Platform image as part of the OS update. That said, when doing an OS Update on CE6 devices, we did provide a capability similar to that previously provided on WM devices. On WM devices, we have supported a capability where you can include a CAR file into the OS Update Package.  Before the actual OS Update is done, if a CAR file is present, the Application partition is completely CLEARED and the CAR file is unpacked into the Application partition.  Then the OS Update is done.  This mostly achieves the desired result IF AND ONLY IF the Application partition is preserved across the actual OS Update. For CE6 devices, we could NOT support CAR files since they relied on APIs that were only present in WM devices.  So, we added a new capability that was very similar that used GAR files.  GAR file support was added for both WM and CE6 devices so a single approach could be used on both.  Aside from the specific APIs used to create and unpack the files, CAR and GAR files provide the same capability.  But while both CAR and GAR files can be used on WM devices, only GAR files can be used on CE6 devices. Note that GAR files can ONLY populate the Application partition, but using CPY files in the Application partition, you could populate files into the Platform partition as well.  Although in most cases, it is NOT recommended to change Platform and this should not be required. But the limitation remains that if the Application partition is cleared as a result of the OS Update, then this approach will NOT help, since there is no way as part of the actuak OS Update for the Application partition to be populated.

Excuse me beforehand the silly question but... is this not somewhat contradictory talking about Golden Image AND MSP? I mean, is not "easy and on-the-fly" staging one of MSP's features? So golden images are not a real need anymore? I might have misunderstood the concept though :( . Sorry this does not help, but I feel curious about.

Hi, agree to your statement. But there are some situations were it would be usefull to have an Image which contains a pre-defined MSP configuration. Think about situation where you have to ensure that the OS revision for all devices should be the same and want to avoid processing two staging profiles. One for up-/downgrade the OS and one for getting MSPAgent started. Another situation is to upgrade the OS from WM61 to WM65. Thomas  

I agree with Thomas. I also have a customer that uses gold images even though they have MSP - basically for the same reasons.  However Thomas, I think you will find you have an issue when you try to use the OS package builder to upgrade from 6.1 to 6.5. I  have recently tried this and found it is NOT possible.  To do the upgrade you must use the OS upgrade package. Once upgraded to WM6.5 you can then have a gold image to reload WM6.5.  If you do find a way I would be very interested, but I  have been told by the engineering group it cannot be done without changes that they cannot justify - a CPR would be required.

Do you mean building a platform hex with DCP? I thought that support for DCP was dropped with the MC3190.

Hi Sean, yes DCP is not available so cannot create any hex file. The OS Package Builder allows me only to create an application.gar file. Currently I dont know how to convert the content of the platform folder into a file that can be processed by the Moto OS Update tool.