From what I understand, that is what Thomas is saying. By using AirBEAM package builder, you are essentially creating an .apd by the name rather than and installing it on the RS. Same concept as doing a legacy install of package for legacy staging. Hope this helps,

Dan     I would recommend rebuilding the package and then upload it to the msp server.  I have seen the access error many times before.  Make sure the FTP user has correct permissions on the folder

Dan, just one other thing you might want to look at. If I use the MC17 as an example the OSupdate image that you can download from the support web site for OS 2.19.01 does not work. On closer inspection the install command line begins like this \windows\OsupdHblvd ............ I rebuilt the package with OPB (selected MC17 as device type) and now the install command reads \windows\osupd17.......... and that resolved the issue. In this case it appears that the wrong device may have been selected when building the OS package and hence the wrong Osupdate exe was used. Again not sure if this is what you are seeing but worth a quick check or send me the apf you are using. Sean.

Hi, first check that your package name is not too long. Double click on your OSupd apf file and check the install command. Seems everything to be correct? Second it is possible that the OSupdater cannot find your package content, because it is looking in a different component directory name on the relay server. Check the FTP log to see which directory will be accessed by the osupdater. MSP3 stores the package components in a sub folder with the following format. __. It might be possible that the osupdater will retrieve the package components from folder . Is this is the case install your Osupd package with the Airbeam Package Builder on the FTP server. Hope this helps. Thomas

If you build a package in OPB (example.apf) and send to FTP using that tool you get a folder by the same name and a definition file (example.apd). If the same apf file is instead imported into MSP and deployed to its Relay Server the resultant folder may look something like this....example_1_233 As Thomas mentioned MSP adds the package version and its own version index. I got around this today by logging onto the RS and renaming the folder and that also solved the problem. I think the path in the apd file is not being set correctly in MSP.

I have seen this error as well, and it was using an Osupdate provided by Motorola support which was definitely created properly. I was doing this on a WS2000 acting as a relay server when I noticed the error. Not sure what solved the problem, but I re-formatted the CF card as well as updated the firmware to version 2.3.2. I also re-created the relay server. Seemed to have fixed it. But I still do get a ton of disconnection/synchronization problems with the OSupdate...but it eventually completes.

Look at the osupdate response txt file and check that the filenames referenced there match exactly the actual files you are updating the terminal with. Particularly the partition table because it looks like it fails there. I've seen at least one occasion with Motorola supplied Osupdate images on the web site that have not been built correctly which had a naming error. It may not be the same issue here but worth a check or comment out the line with the partition table in the txt file to test.

Team, I've had problems in the past with CE 5.0 in general with VC5090 and found that I had to add a command line in my OSUPDATE Builder "-n" option to make the radio stay on (resets radio in between package files).  Once I did that I had no problems pulling down the rest of the packages.  You might want to give that a try. Hope this helps. Cheers, Mark Mann

Due to the variations in OS Updates, I usually recommend trying an OS Update manually on a single device, via local mode and an SD card, before attempting to do it with an OS Update Package.  Once you know you have all the right bits put together in the right ways, then it makes sense to try the same bits with an OS Update package.  Have you done that?

Dan, Since you're updating a CE device, it's downloading one partition at a time from the FTP server during the OSUpdate process.  I would verify that it's able to retrieve the files from the server.  If you're using FileZilla as your FTP server, it should be easy to look in the FileZilla log to see if the client is not able to find a file.