We have a high profile customer who is having issue with MSP and I need some pointers.
Devices MC9090S used in batch mode without wireless and communications via Ethernet cradle. Running idockit on device for communication
Devices have MSPA and report to MSP2.9 server
Device BSP ranges from 35 to 43
Client has issue where devices fail due to Nand Flash re-writes, fix available
Challenge
Have to upgrade all devices to BSP43. This has been tested using MSP2.9 and 3.2. However after osupdate reboot, Idockit does NOT launch and further connectivity to msp box is lost
The Nand Flash fix performs a cleanboot upon completion, again idockit is lost
My ask
Is there a way to preserve or to autoinstall idockit from the device itself? Basically we’d like idockit to persist a cold boot
Any pointers references would be helpful
3 Replies
StartUpCtl "built in" to a custom WM5 Application Image would allow the iDockit CAB to be installed upon a Clean Boot and then launched after install. Not sure about the config of iDockIt once installed. Perhaps a REG file with all the settings like eConnect used to work?
Hi Sanjay,
Sounds like another manifestation of the classic problem with OS Update - if you replace the \Application partition, then the terminal is left in a from-the-factory condition: It cannot rejoin the network, and it cannot rejoin the MSP community because all the stored settings have been lost. With WM5 (and WM6) we will continue to have a need to do one of two things:
1) use an OS Update that does not replace the Application partition so that the settings that allow the terminal to rejoin the network and the MSP community, or
2) build an OS Update with a CUSTOM Application partition into which we can build the necessary settings.
With CE5 (as opposed to WM), there is also a Platform partition to be considered, and since it is unsafe to update the OS without updating Platform, it is necessary to build a custom Platform partition if there are any data or settings in your current Platform that need to be preserved. (MSP agent upgrades may be installed there so this must be taken into account - there are a couple of ways to accomplish this).
Are you using the OS update APF from the support website, or one you have built yourself?
CAVEAT !! CAUTION !! DANGER !!! If you want to "push" an imaging package from MSP2 you have to watch out...
if the terminal "wakes up" from the imaging process and does not have the APD file for the image it just installed in its \Application\airbeam\pkg folder, the terminal will go into a cycle where it reinstalls the image, reconnects to the network, finds the imaging job still there, and reinstalls the image... ENDLESSLY !!! This can be hard to stop once it gets started. You have to cancel the job and/or remove the package from the FTP server(s) used by the terminal(s) involved.So it's REALLY important on MSP2 to make sure the image package is constructed so that the terminal will have the package APD file in \Application\airbeam\pkg when it finishes the OS Update process before allowing it to be pushed out. In fact, since any image imported to MSP2 and then "sent to sites" might be "pushed" by accident, best practice would be to make sure EVERY OS Update package imported to MSP has this protection built in!