You could certainly file a GRIP and we could consider it.  But keep in mind that such an option would require the Agent to ASSUME that the operation is going to succeed.  The reason the Agent does not indicate that the step has completed until the install command returns is because the install command may fail and return an error.  If we mark the step as complete and save that state, then after the reboot, we will proceed with the next step of the Bundle, if any, and have no way of knowing or reporting whether the step of the Bundle that was marked with that option succeeded or not.  So, if such an option were added, it should only be used in situations where you KNOW that the install command of the Package is unlikely to ever fail. And please note that in such cases, there is already a way to make that happen, although it can be a bit complicated and tricky to implement.  In the install command, you can choose whether to wait or not and whether to check for an error or not.  If you launch the CAB file without waiting for it to return, then the Agent will mark it complete and move on to the next step and/or report the Job as complete if there are no more steps.  This effectively causes the install command to run in parallel with the Agent continuing with its processing of the Job.  That is where it can get tricky since you don't know how long the install command may take to finish, in this case, the RIL firmware update.  If it finishes very quickly, it may cause a reboot before the Agent has completed its end-of-Job processing and uploaded Job status to the Relay Server.  So, what I usually do to make sure it works is have the install command launch another application that delays for a while before doing whatever the install command wanted to do.  As mentioned earlier, though, this kind of approach is based on the assumption that the install command WILL SUCCEED.  Moving on without waiting to see what happens is a risk if it could ever fail since then you have no way of reporting the actual results.  But this is the same risk whether it were a new option as requested or if the manual brute force method described is used.

I have a more compelete explanation now.  When the CAB file causes a warm boot, it prevents the install command for the package from returning to the MSP Agent.  The MSP Agent only updates its record of the step last executed in the Bundle just before a reboot that the MSP Agent knows about (such as a reboot step explicitly placed into a Bundle).  The record of the step last executed is ONLY required if a reboot is done, to allow the MSP Agent to continue processing the Bundle from the next step after the reboot. The MSP Agent COULD have updated the record of the last step processed in the Bundle every time a step was executed, but that would create a potentially tremendous amount of additional overhead.  The record of the step last executed is stored in a file in the persistent file system.  This is critical to ensure that it will survive a reboot.  Every write to that file will cause background activity to update the flash, which will use extra CPU cycles, reduce battery life, and increase wear on the Flash. So, as a general rule, you should NOT have a reboot that is initiated by a Package install command since it will cause the Job to stop with that Bundle step and will cause the Job to be marked as an orphan.  In this specific case, the best way to avoid the Job becoming orphaned is the method proposed by Herbert.  Change the CAB file to not do the warm boot and then follow the Package containing the CAB file with a warm boot step in the Bundle.  Then the MSP Agent will know that the reboot is going to happen and will ensure that processing of the Job continues after the warm boot.

This sounds rational. Still, since we don't have control over all the CAB files we have to install, it might be viable to implement an additional option "This package causes reboot" to the dialog that adds packages to bundles. This would allow MSP agent to set a specific flag that indicates that job must be continued after warm boot. GRIP?

Since cabfile, although effective, does not provide status on wether it installed successfully or not, perhaps in this case content from RIL 1.1.5.9 cab, as Herbert outlined, should be packaged up with MSP package builder. That is to say, not the cabfile but its content. This would not only provide control as to when to warm-boot the device but also furnish MSP console the desired job status. To note, a registy.reg file would need to be created and added to the package in order to set skipcopy and regmerge flag to 0 Herbet, just curious what tool do you use for editing cabfiles?

Peter, i use the WinCE Cab Manager 2.0  from OCP  see www.ocpsoftware.com this RIL 1.1.5.9 cabfile has the skipcopy and skipreg registries set to 0 already, so just removing the setup.dll from cab and from the package this will prevent the device from warmbooting by it self. if you want i can supply you with a modified cabfile, drop me a email.

Hi Allen, this cab does a reboot after install - but there is no clean boot. I am aware of orphaned jobs with os updates - this is ok. but here there is no osupdate and no cleanboot just a reboot - so the mspagent should find back to his job, isn´t it ?

Christian; It all depends on what the CAB file does.  Given that it is updating the RIL, my guess would be that it probably Clean Boots the device from within the CAB without returning to the Package Install Command that invoked the CAB file.  That would mean that the Job cannot be marked complete.  And if the record of the fact that the Job was being processed is cleared due to the Clean Boot, then an Orphan Job error will result since the MSP Agent will see that the Job was started but it has no idea where it left off. This is not uncommon with OS Updates as well.  There is only so much MSP can do when you pull the rug out from underneath it in a Package that does something severe like update the OS or Clean Boot the device.  You can sometimes work around this by launching an application that delays before installing the CAB, which can give enough time for the Job to complete before the CAB is launched.  The problem with that is that if the CAB doesn't work, for some reason, you will never know it. This is basically an unsolvable problem in the general case.  By default, we wait for EVERYTHING the Package does to be completed successfully before we indicated it is complete, so we can indicate failure if anything goes wrong.  But if you have a Package where some step never returns, then waiting for it to complete is not going to work.  In such a case, the only other option is to NOT wait for it to complete, which means you risk marking it complete without knowing whether it worked or not. You might ask why the MSP Agent couldn't simply "pick up where it left off".  Well, there are two problems with that.  First, it has to keep the record of where it was somewhere, and that really needs to be in the device in case connectivity is not available after a reboot.  If that record is wiped, it cannot know where to pick up and continue from.  Second, since it executed the CAB file and the CAB file never came back, what would it do even if it knew where it was?  It cannot assume the CAB file has completed successfully, since it didn't come back.  So, does it repeat the CAB file and then do the next step or just proceed to the next step assuming the CAB file succeeded even though it did not return.  There is no one answer that would work for every case.  A lot would depend on how "smart" the CAB file was.  If the CAB file was smart enough to detect that it had already done what it needed to do on the previous execution and hence it does nothing (especially NOT reboot), then repeating the execution of the CAB file might be the right thing to do.  Assuming that nothing needs to be done after the CAB file, in most cases, it may be easier to just delay the execution of the CAB, as described above, to allow the Job to complete before the CAB launches and just assume and hope that the CAB file will always work and live with the fact that we get a Job completion regardless of the success or failure of the CAB file. Allan

FYI there is no cleanboot involved with this cabfile. this RIL 1.1.5.9 cab file is doing the following: will place needed RILGSM.dll and Multiplx.dll and cpy and some regfiles on application folder will set skipcopy and regmerge flag to 0 and then a setup.dll placed on cache disk will invoke a warmboot. because of the skipcopy and regmerge will be invoked after this warmboot the cpy and reg files will be merged. i think this setup.dll is the problem it will not allow to report back to MSP that the cabfile was installed correctly. if this RIL has a need to be installed over MSP the best way is to rebuilt it without this automatic setup.dll invoking a warmboot and have the warmboot invoked by MSP christian let me know if that is what you want i can strip out the warmboot out of the RIL cabfile