Thanks for your detailed responses Allan, been very enlightening. Generally you're correct - we don't move devices between relay servers (sites) all that often... the majority is for repair, since the device comes back with the same UUID most of the time, but we also have a pool of spares that are reserved for peak usage times (eg stocktake/christmas)... it's not that big a drama since we make sure they all check back in at head office when they're returned before putting them in the box, just means that when we unpack them a few months later they have a lot of catch up jobs to be reprocessed. I don't mean to imply MSP3 package delivery is unreliable - it is exceptional - but even 95% of 1000+ devices means we have to manually intervene on 50+ devices... with a reboot and automatic retry I would think we'd get much closer to a 99% success rate, and only have to intervene with a handful of devices with serious issues. We use SOTI for our non-Motorola devices, and I've been petitioning we move to the MSP generic client to manage those as well because in my experience MSP package delivery has been much more reliable.  The main issue prevening that move is there's no generic AppCenter included with MSP to let us lock them down, so we're stuck since SOTI has an integrated lockdown for generic devices. The pause/resume feature does sound interesting, maybe it will help... we do get a bunch of -811's and -813's though in my experience we have to warm boot the unit before they will successfully process the package... it's a bit weird but sometimes if I've left one our devices on my desk unused for a few weeks it just needs a reboot before the MSP agent will install packages - you can remote control it and ping it and force it to check in, but when it tries to download a package it just hangs there at 0% and eventually times out. Because it's difficult to reproduce I haven't logged anything - devices are MC5590 WM65 ( OS 3.38.04)  w/ 30agent ddp_7.06.19 - we just warm boot and away they go.  Has made me consider on occasion trying to figure out how to schedule automatic weekly reboot though. :)

Another semi-related question... some OSUpdates have .sig files, some .sig.gz ... in this instance I'm referring to MC55A v2.41.03 ... is there a way to .gz the 55A0w65HenOS024103.sig file to reduce our gold image size?

Your approach of not putting any files that might be in use in the GAR directly but instead renaming them and using a CPY file to copy them when they are not in use after the reboot seems sound.  Such an approach should be usable whether the files are already present or when the device is still fresh out of the box. Your point about a device moving from one Relay Server to another has always been an area where MSP 3 has been weak.  Improvements were planned in MSP 4 to this and many other areas, but logistics and resource constraints have delayed their roll-out.  And up until now, changes of Relay Server have been rare, although the return-from-service case you gave is the best one I have seen. Aside the issue with changing Relay Servers, it has not been my experience with any installation of any version of MSP 3.x onwards that Package delivery was anything other than very reliable.  I am curious as to why you have seen different.  It is certainly possible that if network connectivity is unreliable, that this could happen. MSP is designed to try installing a Package ONCE and then fail the Job because when things are working as expected, a failed Package Install is overwhelmingly caused by a badly constructed Package or a device problem, neither of which are likely to be fixed by retrying a failed Job.  Retrying in such cases will only waste network bandwidth. But to handle cases, such as WWAN, where connectivity may be poor, and where a Job may fail due to connectivity problems, MSP does offer the Pause/Resume feature.  When a Package Install fails due SPECIFICALLY to a communications-related error, then if the Job is marked as Pause/Resume, then after the normal retries, the Job will be paused, not failed.  On the next check-in, and every subsequent check-in until the Job completes or fails for a non-communications-related reason, the Job will be retried from the point it failed.  In fact, if the Relay Server supports Checkpoint Restart, it will even begin at the point in the file at which it failed.  This can significantly increase the likelihood of eventual completion of a Job over WWAN, but could also help in spotty WLAN situations.  It won't help with non-communications-related failures. But now that you have explained why you prefer NOT to rely on Package Installs, at least for "baseline" functionality, it does make sense.  And I think the approach you have taken is sustainable, although it is perhaps questionable whether it would be considered "supported".  But you are not very far off the main road, so perhaps it would be. As for which files can be compressed and which cannot, that you will have to take up with the specific Device Team.  I generally don't recommend using any files (except for a GAR file) in an OS update that didn't come from the Device Team.  If you can make a good case for a reduction in size, and if the file CAN be compressed, then they might be willing to supply them compressed.

There is no supported way to do what you are requesting.  If you play around with it long enough, you might be able to get it to work, but you would have an unsupported solution when you get done. Is there a reason why you couldn't/wouldn't use Rapid Deployment to kick this off instead of Remote Control? Normally, what I would recomend in such a case would be to have the Bundle that Installs the OS Update Package first have Uninstall Package Steps for any Packages that MIGHT have files in Application that could be in use, including Remote Control.  It is completely benign to Uninstall a Package that is not present on a device, so it is safe to include Uninstall Steps for lots of Packages.  When doing an OS Update, Remote Control is not the only thing that can cause problems.  Any file in Application that is in-use AND included in the GAR file would cause the same problem.  So, it is a good idea to uninstall any Package that is questionable. When an OS Update runs, it first attempts to clear off the Application folder completely, although it is forgiving and ignores any errors due to attempts to delete files that cannot be deleted.  Then it unpacks the GAR file into Application.  During that process, it will fail if it cannot write to any file that is in the GAR, such as if the file is in use.  Such a failure will stop the process and prevent the actual OS from being updated.  The safest thing to do is make sure that any files that might be in use have been removed BEFORE the OS Update process is started. In your specific case, the delete of MRC will fail, but be ignored.  Then if the GAR file includes MRC, then it will fail since the file is in use and cannot be overwritten.  So, if the GAR file did not include MRC, then it would succeed since it would make no attempt to overwrite the in-use copy of MRC.  Keep in mind that legally you cannot use MRC without a license for MSP Provision Edition or MSP Control Edition, so the device should be manageable by MSP.  So, if you elect to NOT include MRC in the GAR file, then it would not attempt to overwrite it.  After the reboot following the OS Update, MRC would NOT launch, even though it was present, since the files that launch it would have been deleted.  Hence MRC would not be in-use.  Once the device becomes manageable by MSP, you could have a Policy redeliver MRC which would write over it and make it active again. You could probably make the above work, but I would still recommend the Uninstall approach and then have MSP re-deliver any removed Packages that are needed, when the device checks back in after the OS Update.

Technically using OSUpdate/GAR files aren't officially supported either... not scared to step out of the box a little... I have been developing software/solutions for the Symbol kit since the good old days of the PDT3100 so am well aware of officially supported vs what has to be done to make something work :) We don't allow the Rapid Deployment client on our devices - we load the company gold image via a 'rebuild' application which works over ActiveSync by copying that gold image to the SD card and executing the update via RAPI - 90% of our rebuilds are done this way - but sometimes we run into a device which won't ActiveSync which is where the rebuild via remote control comes in... we'll copy the files over the air and kick the rebuild off via MRC.  The only time I use RD is to build the gold image device. We're licensed for MSP Control Edition and our incidental updates are maintained by provisioning rules.  We tend to release a new company image every six months or so, to minimize the amount of provisioning that needs to be done after a full rebuild.  I suppose some of the other MSP components might be in use if they were doing a check-in at the same moment as doing the rebuild, but that's not as problematic because you can just click retry and they should be free again... it's only MRC and AppCenter that run continuously from the Application directory. I might try a work around where instead of including MRC.EXE directly, I'll include it as MRC.EXX and have a .cpy file restore it since it shouldn't be running at the time .cpy files are processed... it's probably easier than mucking around with the MRC package and trying to get all the files to install to \Program Files\ As a side note regarding the suggestion to uninstall - and maybe it's more reliable in MSP4 (we haven't upgraded) - but we've had issues with packages failing to install and have to manually 'reprocess' the job multiple times before some devices get it.  Specifically there's two main problems: 1) With a fleet of over 100 relay servers - if a device has 'last checked in' at relay server #1, gets sent off to repair, then re-appears at relay server #2, any jobs that happened in the week or so it was away will have been sent to relay server #1 and the device will never get them until you manually reprocess. 2) Sometimes a package may fail to install, we find that a warm boot and telling it to reprocess the job will usually fix it... so it would be nice if there was a way for MSP to automatically warm boot and retry... give it three strikes and then let us know by going to the failed column.  It's not an issue if you're managing a small fleet, but in a fleet of 1000+ it takes a long time to manually investigate each failure, remote control in, warmboot, reprocess the job, then monitor to make sure it succeeds. Anyway, it's a little off topic, but is the reason why I don't want to rely on uninstall/reinstall, since I know that we'd have devices with missing packages after the update that have to be manually fixed.

Well, the .EXX trick didn't work at first until I discovered that MRCAES.DLL was also in use... so now I have an .EXX and .DLX and the .CPY file restores them both after rebuild.  It's far from ideal, but it seems to work ok - and is probably easier/more supportable than trying to get MRC to run from a non-standard location...