Home > Blogs > VMware ThinApp Blog


AppSync Notes and Tips

General Information

This document provides general information around using the ThinApp AppSync parameters to download ThinApp updates.

Requirements

The following items and knowledge are required for use of this procedure:

  • Familiarization with instructions on how to virtualize a software product via ThinApp (see, “How to Make a ThinApp Application” on the VMware ThinApp Blogs at http://blogs.vmware.com/thinapp/2008/10/how-to-make-a-t.html).
  • Familiarization on how to configure and utilize AppSync within a ThinApp packaged application. See the VMware ThinApp User’s Manualfor information on AppSync parameters.

 

Getting Started with AppSync

To get started using AppSync, there are three things needed.

  1. A ThinApp project of the original (old) application.
    The ThinApp project of the original application must be in a configured state where the outcome is a known working application. We don’t want to throw AppSync in on top of an application where we’re troubleshooting other issues. So, in short, don’t attempt to configure AppSync until the packaged application is fully tested.
  2. A ThinApp project of the updated (new) application.
    Again, the ThinApp project of this new or updated application must be in a configured state where the outcome is a known working application. As mentioned in the previous paragraph, we don’t want to throw AppSync in on top of an application where we’re troubleshooting other issues.
  3. A web server or file share to use as a repository.
    If using a web server, any web server will work (i.e. IIS, Apache, Abyss, etc.). Keep in mind that some web servers may require additional configurations depending upon the file types and other settings. For example, IIS requires modifications to the default security settings in order for it to deliver DAT or EXE files (if that’s what you wish to name your AppSync packaged apps on the web server). See the
    Step-by-Step Instructions on How to Configure IIS to Allow Downloading of EXE and DAT Files.

    If using a file share, the user only needs to have READ access on the file, but may require FULL access on the share (NTFS is kind of funny about that sometimes).

 

Configuring the ThinApp Packages (Old and New)

To configure the original (old) ThinApp package to check a web site for updates, one only needs to enable the AppSyncURL and AppSyncUpdateFrequency parameters. When testing, to force an update immediately, set the AppSyncUpdateFrequency to a value of “0”.

Don’t forget to also configure the updated (new) ThinApp package with the same (or newer) update parameters. If you forget to set this in the newer (updated) ThinApp project before you build it, you could potentially update your remote users out of using AppSync settings.

Below are some standard AppSync configuration examples.

AppSync Web Site Example:
;——– AppSync Parameters ———-
AppSyncURL=https://appsync.mydomain.com/folder/myapp.exe
AppSyncUpdateFrequency=0

NOTE: Both HTTP and HTTPS are supported.

AppSync File Share Example to UNC:
;——– AppSync Parameters ———-
AppSyncURL=file://server/share/folder/myapp.exe
AppSyncUpdateFrequency=0

AppSync File Share Example to Hard Drive:
;——– AppSync Parameters ———-
AppSyncURL=file:///x:/folder/myapp.exe
AppSyncUpdateFrequency=0

 

Placing the ThinApp Package on the Web Server or File Share

Two things to keep in mind about the AppSync updates when placing the ThinApp package on the update repository (whether that is a web server or file share).

First, when working with an application suite where multiple entry points are made, only the data container is needed. As an example, let’s say we’ve packaged up Office and have a number of entry points and a data container file (in this case, a DAT file) named MICROSOFT OFFICE 2007.DAT. To update the remote copies of ThinApped Office, I only need to place the MICROSOFT OFFICE 2007.DAT on the web server and ensure it sits at the proper URL which the original ThinApp Packaged Office points to.

Secondly, and probably a bit more interesting, is the packaged application or data container sitting on the file repository (web or file share) does not need to be named anything specific for ThinApp AppSync to work. To expand upon the above Office example, let’s say I don’t want to use long file names within my URL because I don’t want to mess with them. I can rename that file to MSOFF07.DAT if I want. I could even use some unique name like MSOFF07.TAS – so long as the original ThinApp Office Package knows to look for a file of that name. The same thing goes for single exe packaged apps like Opera or Adobe Reader. If I don’t want people to know these are executables (and maybe I don’t want to configure my IIS server to allow EXE downloads) then I could use some other file extension such as VMW.

AppSync Web Site Long File Name Example:
;——– AppSync Parameters ———-
AppSyncURL=https://appsync.mydomain.com/folder/my%20app.exe
AppSyncUpdateFrequency=0

NOTE: The application above is “My App.EXE”. Some web sites require the use of a %20 instead of a space.

AppSync Web Site Renamed File Example:
;——– AppSync Parameters ———-
AppSyncURL=https://appsync.mydomain.com/folder/renamed.vmw
AppSyncUpdateFrequency=0

NOTE: The renamed file would still be “My App.exe” (where My App is a single executable packaged application such as Adobe Reader).

Forcing an AppSync Update to Occur Prior to Launching the App 

It is possible, primarily for testing purposes, to force a ThinApp AppSync update to occur PRIOR to the original (old) packaged application starting up.  This is done by adding in the AppSyncExpirePeriod setting with a valud of “0d

AppSync Website with Forced Update Example:
;——– AppSync Parameters ———-
AppSyncURL=https://appsync.mydomain.com:444/folder/myapp.exe
AppSyncUpdateFrequency=0
AppSyncExpirePeriod=0d

 

Using AppSync when Accessing a Password Protected Web Site

One can also easily use AppSync to access a restricted web sites by encoding the username and password within the URL. What’s nice about this is, while it may not be completely secure(depends upon web site folder security settings) unless using SSL, the username and password are obfuscated when set into the PACKAGE.INI of a ThinApp project once that ThinApp project has been built into a ThinApp packaged executable.

AppSync Website with User and Password Example:
;——– AppSync Parameters ———-
AppSyncURL=https://user:password@appsync.mydomain.com/folder/myapp.exe
AppSyncUpdateFrequency=0

It should be noted that if you need to troubleshoot this, you may need to reconfigure your test VM in accordance with Microsoft’s KB Article KB834489 – specifically the section on “Workarounds for application and Web site developers” as this will instruct you how to disable a Windows Security setting to test if your web server is configured properly.  Again, this is ONLY for testing and it ONLY is done on the workstation VM.


 

Using Alternate Ports for AppSync Web Site URLs

If desired, one can also use an alternate port for either HTTP or HTTPS (valid SSL certificate needed).

AppSync Website with Port Example:
;——– AppSync Parameters ———-
AppSyncURL=https://appsync.mydomain.com:444/folder/myapp.exe
AppSyncUpdateFrequency=0

This entry was posted in AppSync, Tips and tagged , on by .
Dean Flaming

About Dean Flaming

Dean is currently an EUC Architect and member of the VMware End User Computing Enablement and Lighthouse Support teams, working to develop communications and IP around VMware End User Computing products and solutions as well as support many various Lighthouse accounts with their own EUC practices. Prior to this, from 2008 through 2012 Dean was one of VMware's End User Computing Specialists. Throughout his time at VMware, Dean has also written and published various articles, videos, and podcasts regarding VMware's EUC Solutions.