This is why you will see many packages (such as AppCenter) deploying themselves straight into \Application and putting REG/CPY/RUN files as a part of installation process. This way you do a persistent package install: * All files are stored in \Application * all that has to be installed on clean/cold boot is installed due to MPA persistence mechanisms * APD is stored, so MSP is aware of the fact that the package is installed Actually, enabling MSP Agent to process APF files seems a very valuable feature, as this whole persistent deployment process you be simplified to just two steps: 1. Download APF into \Application 2. Instruct MSP Agent to "process" APF (which could be a part of MSP Agent self-restore functionality as well). And now we follow the MSP persistence guidelines down to a letter! :) So far, as far as I'm aware, MSP agent can provide persistence only in "Always connected" scenarios.

Arsen; I don't think it is accurate to state that 'MSP agent can provide persistence only in "Always connected" scenarios'.  The MSP Agent provided Persistence of Settings Content in many scenarios, since the Settings are stored Persistently and automatically re-applied.  Non-Settings Content is not inherently Persistent in MSP Windows Devices because ultimately the builder of the Package controls where content is placed.  If the content is placed into a Perisistent location, and if anything that cannot be Persisted that way is handled using proper techniques (e.g. .REG or .CPY files), then a Package can be made fully Persistent. Similarly, if content is delivered via a .CAB file in a Package, and if the Package uses CAB mode, then the .CAB file will be stored in a Persistent location and will be re-installed as needed. All of the above examples of Persistence rely on the content installaed by a Package being stored Persistently, and perhaps re-applied from that Persistent location.  What you seem to be talking about is Persistence that actually re-applies the Package itself.  As it stands now, MSP does NOT do that since it would require a "double footprint" as it would require the content installed by the Package and the Package itself to both reside continuously on the device.  When considered in that light, you are correct, that MSP does not do that. The MSP Agent currently has NO ABILITY to process APF files - it can only process the exploded contents of an APF file.  It is the MSP Server that knows how to process an APF file, and it explodes the APF file when it deploys it to a Relay Server.  The MSP Agent then pulls the exploded content from a Relay Server as directed.  So, as it stands, you are correct that complete re-installation of a Package can currently only occur when connectivity is maintained since the only way a Package can be re-installed is to re-pull it from a Relay Server. While it would be possible to add code to process APF files directly to the MSP Agent, it is unclear whether it would be worth doing so.  In particular, it is unclear how it would enhance the MSP deployment model as there are already mechanisms to achieve Persistence that do not require double footprint.  Please file a GRIP if you believe that you have a sufficient business justification for such a new feature. Allan

Thanks Alan! Anyway, I was not trying to do an OS update -just fully staging a device with several "heavy" packages. I did the following test, which worked on MSP 3.2: 1) Stage a MC75 with GetAdapters module (simple one to test with). This saves GetAdapters.apd on \Application\airbeam\pkg and GetAdapters.exe on \Application\MSP\Control\GetAdapters. 2) Copy GetAdapters.apd to, say, \Temp whatsoever. 3) Delete this package from RD (or Agent). This erases both apd and exe files and unsinstalls the module. 4) Copy back GetAdapters.apd from \Temp to \Application\airbeam\pkg 5) Copy RhoElements.exe (for instance) as GetAdapters.exe on \Application\MSP\Control\GetAdapters. This file is about 600 KB or so. 6) Re-Stage the device with GetAdapters module. This will download (just looking at Filezilla log screen) the apd file, but NOT GetAdapters.exe: it is not logged on FTP server, and, more important, GetAdapters.exe size still is 600 kB, and not 20 kB as it should have been if downloaded. Obviously, when trying to uninstall the package I get a RhoElements error! This is what I was looking for, preventing downloading certain huge files. Not all, of course.

Just to be clear.  What you desribe worked because the APD file was saved and restored and the that APD matched the Package RD was causing to be pulled.  The RD Client pulled the APD and compared its version to the version in the APD on the device.  Since they matched, and since the Bundle did NOT have Force Install set, NOTHING in that Package (aside from the APD for comparison) was downloaded.  It was completely irrelevant whether the files in the Package were present or not.  The RD Client did not and WOULD NOT detect if any were missing and replace them.  The sole determination of whether files are loaded or not is based on the comparison of the APD files.  If they match, then NOTHING is downloaded.  If they don't match, then EVERYING is downloaded.  So, if you are going to restore an APD file, thus telling the RD Client that a Package is present, you are also responsible for copying restoring everything that Package loaded.  Otherwise, you would have an invalid state where a Package was shown as present but was not really fully present.

Quite right, Allan! This is actually the idea. By the way, I forgot to mention a few more detailed steps: 1) Stage a MC75 with GetAdapters module. Verify after a while that GetAdapters is shown on MSP's status Packages section. 2) Backup GetAdapters.apd and GetAdapters.exe. 3) Delete this package from RD (or Agent).   Verify after a while that GetAdapters has gone on MSP's status Packages section. 4) Restore GetAdapters.apd and GetAdapters.exe. 5) Run \Application\MSP\Control\GetAdapters\GetAdapters.exe -U. This will install it, as seen in GetAdapters.apf as Install Command line. 6) Re-Stage the device with GetAdapters module. This will not download the exe, for the reason you well stated, neither install it (that's why I installed "manually" it at step 5). 7) Verify after a while that GetAdapters is shown on MSP's status Packages section. So I get what I wanted: staging a terminal without downloading the exe (in this case) file, installing the package the way RD would have done and reporting MSP that this package is installed on this unit. So, if its version changes, then yes, MSP will eventually update it.

I have the same requirement from a customer: Users are drivers which only have 3G connectivity. All the terminals must and will be provided with a SD card as an application requirement. So since SD card is to be installed, they want to leverage this fact to save sending lots of megabytes via 3G, just by having the right files already copied in the SD card. Then, those files could be somehow copied to the place RD downloads them from RS via FTP (i.e, "simulate" FTP download). Copied but  not installed!! Now, if users read a staging barcode instructing RD to download those very same files from a RS to a folder they have already been copied to, will RD still download (hence overwrite) them or will simply skip this step and proceed to install them? This is my concern.

The simple answer is YES, RD WOULD download them again, since NOTHING in AirBEAM or MSP Package processing has, or likely ever will, be based on the contents of FILES that are in the device, only on Packages that have been deployed to the device. But I think you may be looking at this the wrong way.  RD can do as little or as much as the Staging Profile you apply tells it to do.  So, if you KNOW that the files needed to do an OS Update are already on the device, in the SD Card, then you could just have the Staging Profile direct the RD client to initiate the OS Update using those files.  There is no reason to tell RD to download them if they are already there.  If you are trying to handle BOTH cases, where the files are and are not there, then you probably would have to have 2 Staging Profiles.

Daniel; I would need to know more about exactly what you are trying to accomplish to help you.  An APD file is sort of like a manifest, it defines WHAT is in a Package, but it does not CONTAIN any of the files that are in the Package.  An APF file contains the APD file and all the CONTENTS of the Package. When you create a Package, you create an APF file, and that is what you import into MSP.  When MSP delivers the Package to a Relay Server, it takes the Package apart and places the APD on the Relay Server and the other contents of the Package into a sub-folder of the same name as the APD file. When the MSP Agent downloads a Package, it downloads the APD file to know what's in the Package.  It then downloads the contents of the Package.  The APD file is stored in the folder \Application\AirBEAM\pkg as a record of what Packages have been loaded into the device.  When an inventory of Packages is needed, it simply enumerates what APD files are in that folder.  Note that the Package could have stored its CONTENTS anywhere, not just in Application.  So, in the event of a cold/clean reboot, the APD file will remain, but some of the contents may not.  But as long as the APD file remains, the Package will be considered to be "present" in the device. No mechanisms are currently provided to process APF files in the device, which would be the analog to the WceLoad scenario you mentioned.  You could store the APD file on an SD card and arrange to copy it back to Application\AirBEAM\pkg and it would cause the Package to show up in the Package inventory, but it would NOT put any of the CONTENT of the Package back.  The whole MSP Package process is designed to be an OTA mechanism, NOT a local one.  So, at present, the ONLY way to get the CONTENT of a Package onto a device is to have the MSP Agent PULL that Package from a Relay Server. Allan