On top of what Matt and Rafael have said in their posts, maybe I can add a little bit.

In general, MDM administrator control has more control of .pcg package mechanism (e.g. when and which files to  deploy and remove, etc.) as mentioned by Rafael.   It is well suited for data files that don't changes too often and requires MDM administrator to decide and control the deployment.  Profile filter can be used to smartly determine which devices (e.g. of certain brand/model/firmware version, etc)  should be targeted.

File-sync rule can be used to handle such cases, but there are more data traffic OVERHEAD & computational loading for the MobiControl server to determine which files needed to be synced according to preset schedule and sync criterion.  Besides, profile filtering mechanism should be replaced by filter on virtual device group targeted by the policy.   Moreover, there can be more deployment delay (unless the file-sync interval is set very small, or the administrator explicitly initiate the "sync file now" device action) compared to .pcg package policy.  

However, file-sync rule can be used to handle some cases difficult/inefficient for the .pcg package policy approach.  For example, if the data files are generated/updated manually by some other colleague or automatically by some corporate software at unpredictable time frequently (e.g. every few hours or days), then it might not be feasible for the MDM administrator to generate .pcg packages and  modify corresponding profile policies all the time.  File-sync rules can be used in such cases, in which the files to be deployed are put into the appropriate server source directory by the related colleague/corporate-software.  MDM administrator just set up the file-sync rule once, and which updated files to be transferred will be automatically determined by MobiControl server  Examples of such type of data files include delivery-note/service-order assigned to be handled by the staff member holding the device, latest inventory level/trend or other statistical market data, company special notices to targeted employees, brochure or other information related to hundreds of products from different vendors, etc.  Files of the same name but with different timestamp or content can also be smartly handled  with proper parameters in the file-sync rule.  The mechanism of course still has many limitations ,and cannot match a tailored-made client-server app system.  I always advise my clients to take this virtually free feature as it is if it fits their purposes/requirements (or possibly with some compromises or small local adjustments).  Otherwise, spend money/effort to develop their own perfect custom distribution solution.. 

I like Packages for most small files like config files for an application and File Sync for large files like an OS Update Zip. Packages have better version control and rollback since each package is stored on the server and versioned. Packages will also allow you to remove the files automatically when the Profile is unassigned from the device. File Sync rules will leave the file in place on the device even after it has been unassigned. File Sync rules are good for large OS update Zips however as they download a tmp file directly to the destination folder on the device which will gracefully resume downloading if there are any interruptions during the download process. My experience in using Packages in the past is that they will restart the download from the top if there is any major interruption. Another reason to use File Syncs for large update Zips is the files are stored in the file system of the server whereas packages are stored in the database. SOTI's database is considerably smaller than the available storage in the server file system.

Edit: Adding on that File Syncs have an advantage in being able to target them at a Virtual Group, whereas Profiles containing Packages cannot. We take advantage of that capability to target very specific devices with very specific criteria to get OS updated using File Sync delivered and executed update .zips. 

HI Matt, Rafael and Raymond 

I really appreciate all of you valuable contributions, some great points there and certainly will be taking these into account in the future.

I have 2 silly questions:

For a given File Sync rule (download to device) whose schedule is periodically every day. Is the behaviour, don't download if file on device = file on server, download (overwrite) if there's a difference and download if the file no longer exists?

Version control of Packages is referenced here, I assume this refers within the console. Within Mobicontrol Package Studio, I see that everytime I update a package, change version number and build. The old package .mcp file is overwritten and no roll back is possible. I assume that a version controlled downloaded .pcg file cannot be somehow read into Package Studio to regenerate the .mcp ?

Thank you all again

Hi Adam,

Which  file-sync transmit option to choose depends on the use case and data file nature.  I tend to avoid the "always transmit"  option to conserve network bandwidth and traffic charges.  In the most general case, two down-link file-sync rules with exactly the same server source directory and device target directory, but one using the "Destination File Does Not Exist" option and the other using the "Files are Different" option,  may be used to save administrative effort to determine which files are newly added and which have data content modified.  If one is sure that there is no filename conflict, and timestamps are always accurate, the "Source File is Newer" option may be used instead of "the Files are Different" option, so as to save some CPU computation loading on both server and device sides, which can be substantial if there are lots of devices and lots of files to synchronize.  Always test thoroughly with test devices on hand based on your OWN server/agent versions before mass-scale deployment. 

Regarding version control of packages,  I myself is referencing to possibility of deployment different package versions (based on "version string" of .pcg  generated with package studio) to different groups of devices, and not the conventional source-level version control in software development.   Ever since MobiControl v10.x, I've  always advised  my clients to use simple "version string" (e.g. major version and minor version separated by a single dot, all digits with no other characters. e.g. 1.0, 1.1, 2.0, 2,1, 2.2 ...) to allow correct version conflict resolution within MobiControl.  The .pcg file generated should usually be manually renamed to reflect the version, at least in one's backup archive.  Different versions of  source codes (e.g. .mdp file, the pre- and pos- script(s) used ) should be backed up with other version control tool or the whole project directory tree zipped into a back-up file.  

Hi Adam,

Thank you for your posting.

Please feel free to mark any of the detailed responses as solved if your question has been answered.

Thank you.

Kind Regards,

Technical Support, SOTI | Call Us | SOTI.net | Discussion Forum | Log a Case Online | Facebook | LinkedIn | Twitter |