Application Updates That the End User Triggers
ThinApp provides the Application Sync and Application Link utilities to update applications with new versions or new components. The Application Sync utility updates an entire application package. The Application Link utility keeps shared components or dependent applications in separate packages.
Application Sync Updates
The Application Sync utility keeps deployed virtual applications up to date. When an application starts with this utility enabled, the application queries a Web server to determine if an updated version of the executable file is available. If an update is available, the differences between the existing package and the new package are downloaded and used to construct an updated version of the package. The updated package is used for future launches.
The Application Sync utility is useful for major configuration updates to the application. For example, you might update Firefox to the next major version. Remote users or users who are not connected to the corporate network can make use of the Application Sync utility by embedding update settings within the package and using any Web server to store the updated version of the package.
Using Application Sync in a Managed or Unmanaged Environment
If you use virtual applications that update automatically in a managed computer environment, do not use the Application Sync utility because it might clash with other update capabilities.
If an automatic update feature updates an application, the update exists in the sandbox. If the Application Sync utility attempts to update the application after an automatic application update, the version update stored in the sandbox take precedence over the files contained in the Application Sync version. The order of precedence for updating files is the files in the sandbox, the virtual operating system, and the physical machine.
If you have an unmanaged environment that does not update applications automatically, use the Application Sync utility to update applications.
Update Firefox 2.0.0.3 to Firefox 3 with Application Sync
This example shows the Application Sync update process for Firefox.
The update process involves modifying the Package.ini file. The AppSyncURL parameter requires a URL path. ThinApp supports HTTP, HTTPS, and file protocols. For information about all Application Sync parameters, refer ThinApp Package.ini Parameters Reference Guide.
Update Firefox 2.0.0.3 to Firefox 3
1
2
The primary data container, determined during the setup capture process, is the file that contains the virtual file system and virtual registry. If you have a Firefox 2.0.0.3 package that has Mozilla Firefox 2.0.0.3.exe as the name of the primary data container, and you have a Firefox 3 package that has Mozilla Firefox 3.dat as the name of the primary data container, change the name in the Shortcut parameter to a common name. For example, you can use Firefox.exe as a name.
3
Modify the Package.ini file in each package.
a
Open the Package.ini file located in the captured application folder.
For example, a Firefox 2.0.0.3 path to the Package.ini file might be C:\Program Files\VMware\VMware ThinApp\Captures\Mozilla Firefox 2.0.0.3\Package.ini.
b
You must uncomment the AppSyncURL parameter to enable the utility.
c
For example, you can copy an executable file of the latest Firefox version to a mapped network drive and type a path to that location as the value of the AppSyncURL parameter. If Z: is the mapped drive and Firefox is the name of the directory that stores the executable file, a sample path is file:///Z:/Firefox/Firefox.exe.
Make sure that the AppSyncURL path is the same in both Package.ini files and points to the updated version.
4
In the captured application folder, double-click the build.bat file to rebuild the application package.
For example, a Firefox 2.0.0.3 path to the build.bat file might be C:\Program Files\VMware\VMware ThinApp\Captures\Mozilla Firefox 2.0.0.3\build.bat.
5
To update Firefox 2.0.0.3 to Firefox 3, start the executable file, such as Mozilla Firefox 2.0.0.3.exe, in the \bin directory.
When you start the application before the expiration time set in the AppSyncExpirePeriod parameter of the Package.ini file, ThinApp downloads the update in the background as you work with the application. The next time you start the application, you can see the updated version.
When you start the application after the package expires, ThinApp downloads the update in the foreground and prevents you from working with the application. When the download is ready, ThinApp restarts the application with the new version.
Fix an Incorrect Update with Application Sync
If you have multiple Application Sync download updates, such as multiple Microsoft Office updates, and a certain update has an adverse effect or needs to be withdrawn, you can address the problem.
Fix an incorrect update
Place the correct update on the server that ThinApp can access.
The update is applied the next time the application is started on a client machine.
Application Sync Effect on Entry Point Executable Files
The Application Sync utility updates entry point executable files. For example, assume you deploy a Microsoft Office 2007 package that does not include Microsoft PowerPoint. The Microsoft Office PowerPoint 2007.exe entry point does not exist for the original package. If you rebuild the Microsoft Office 2007 package to include Microsoft PowerPoint, and you use the Application Sync utility to update client machines, the end users can access an entry point executable file for Microsoft PowerPoint.
Updating thinreg.exe Registrations with Application Sync
If you register virtual applications on the system using thinreg.exe and update applications with the Application Sync utility, you can update registrations by placing a copy of thinreg.exe, located in C:\Program Files\VMware\VMware ThinApp, alongside the updated package on the server.
Maintaining the Primary Data Container Name with Application Sync
The Application Sync utility requires that the name of the primary data container, the file that stores virtual files and registry information, is the same for the old and new versions of an application. For example, you cannot have an old version with Microsoft Office Excel 2003.exe as the primary data container name while the new version has Microsoft Office 2007.dat as the primary data container name. To verify the name of the primary data container, see the ReadOnlyData parameter in the Package.ini file. For more information about the primary data container, see Defining Entry Points as Shortcuts into the Virtual Environment.
Completing the Application Sync Process When Applications Create Child Processes
When a captured application creates child processes, ThinApp cannot complete the Application Sync process.
For example, you might create Microsoft Office 2003 and Microsoft Office 2007 packages, modify the AppSyncURL parameter in the Package.ini file for both packages, and copy the Microsoft Office 2007 package to a Web server and the Microsoft Office 2003 package to a client machine.
If you start the Microsoft Office 2003 package before the expiration time set in the AppSyncExpirePeriod parameter of the Package.ini file, ThinApp can download the update in the background as you work with the application but is unable to show the updated version the next time you start the application. If you start the application after the package expires, ThinApp is unable to download the update in the foreground and restart the application when the download is ready.
Microsoft Office 2003 and Microsoft Office 2007 are examples of applications that create child processes. ThinApp cannot complete Application Sync updates until all child processes stop. You can perform one of the following tasks to resolve the issue:
For example, you can create a script to end the ctfmon.exe and mdm.exe child processes associated with Microsoft Office 2003 and Microsoft Office 2007.
Prevent the startup of the child process, such as the ctfmon.exe process associated with Microsoft Office and Internet Explorer applications.
Prevent the Startup of the ctfmon.exe Process for Microsoft Office and Internet Explorer
Preventing the startup of the ctfmon.exe process requires knowledge of the ThinApp sandbox and sbmerge.exe utility. For information about the sbmerge.exe utility, see Updating Applications with Runtime Changes.
Prevent the startup of the ctfmon.exe process
1
If you did not activate the cmd.exe entry point during the capture process, set the Disabled parameter for the cmd.exe entry in the Package.ini file to 0 and rebuild the package with the build.bat utility.
This generates an executable file for the cmd.exe entry point in the /bin directory.
2
Copy the /bin directory in the captured application directory to a clean virtual machine or delete the sandbox for the Microsoft Office package.
3
Double-click the cmd.exe entry point.
4
5
In the Languages tab of the Regional and Languages dialog box, click Details.
6
In the Advanced tab of the Text Services and Input Languages dialog box, select the Turn off advanced text services check box.
7
Click OK in all the open dialog boxes and leave the Windows command processor open.
8
Unregister the MSIMTF.dll and MSCTF.dll files with the REGSVR32.EXE/U <DLL_file> command.
See knowledge base article 282599 in the Microsoft Web site.
9
10
The default sandbox location is %APPDATA%\Thinstall.
11
From the standard command prompt on the packaging system, use the sbmerge.exe utility to merge the updated sandbox with the package.
A sample command is SBMERGE APPLY ProjectDir "C:\Program Files\VMware
\VMware ThinApp\Captures\Microsoft Office Professional 2007" SandboxDir "%APPDATA%\Thinstall\Microsoft Office Pro 2007".
12
Application Link Updates
The Application Link utility connects dependent applications at runtime. You can package, deploy, and update component pieces separately rather than capture all components in the same package.
ThinApp can link up to 250 packages at a time. Each package can be any size.
The Application Link utility is useful for the following objects:
Large shared libraries and frameworks – Link runtime components, such as .NET, JRE, or ODBC drivers, with dependent applications.
For example, you can link .NET to an application even if the local machine for the application prevents the installation of .NET or already has a different version of .NET.
If you have multiple applications that require .NET, you can save space and make a single .NET package and point the multiple applications to the .NET package. When you update .NET with a security fix, you can update a single package rather than multiple packages.
Add-on components and plug-ins – Package and deploy application-specific components and plug-ins separately from the base application.
For example, you might separate Adobe Flash Player or Adobe Reader from a base Firefox application and link the components.
You can deploy a single Microsoft Office package to all users and deploy individual add-on components for each user.
If you capture Microsoft Office and try to access a PDF attachment in the virtual Microsoft Outlook environment, you can set up Microsoft Office to detect a linked Adobe Reader package on the network when Adobe Reader is not available within the immediate virtual or physical environment.
Hot fixes and service packs – Link updates to an application and roll back to a previous version if users experience significant issues with the new version. You can deploy minor patches to applications as a single file and reduce the need for rollbacks.
The Application Link utility provides bandwidth savings. For example, if you have Microsoft Office 2007 Service Pack 1 and you want to update to Service Pack 2 without Application Link, you would transfer 1.5Gb of data per computer with the deployment of a new Office 2007 Service Pack 2 package. The Application Link utility transfers just the updates and not the whole package to the computers.
View of the Application using Application Link
View of the System, Base Application, and Linked Components Using Application Link shows the running application with a merged view of the system, the base application, and all linked components. Files, registry keys, services, COM objects, and environment variables from dependency packages are visible to the base application.
View of the System, Base Application, and Linked Components Using Application Link
Link a Base Application to the Microsoft .NET Framework
Review this sample workflow to link a base application, MyApp.exe, to a separate package that contains the Microsoft .NET 2.0 Framework. Make sure that the base application capture process does not include the Microsoft .NET 2.0 Framework. For information about the process of capturing an application, see Capturing Applications.
For information about required and optional Application Link parameters and formats in the Package.ini file, refer ThinApp Package.ini Parameters Reference Guide.
Link an application to Microsoft .NET
1
During the capture process, you must select at least one user-accessible entry point.
2
Rename the.exe file that ThinApp produces to a .dat file.
This renaming prevents users from accidentally running the application.
The name of the .dat file you select does not matter because users do not run the file directly. For example, use dotnet.dat.
3
Save the .NET project to C:\Captures\dotnet.
4
5
Save the project to C:\Captures\MyApp.
6
Open the Package.ini file in the captured application folder for the base application.
7
Enable the RequiredAppLinks parameter for the base application by adding the following line after the [BuildOptions] entry.
RequiredAppLinks=dotnet.dat
Application Link parameters must reference the primary data container of the application you want to link to. You cannot reference shortcut .exe files because these files do not contain any applications, files, or registry keys.
8
a
Double-click the build.bat file in C:\Captures\MyApp.
b
Double-click the build.bat file in C:\Captures\dotnet.
Running these batch files builds separate ThinApp packages.
9
a
Copy C:\Captures\MyApp\bin\MyApp.exe to \\<end_user_desktop>\<Program_Files_share>\MyApp\MyApp.exe.
b
Copy C:\Captures\dotnet\bin\cmd.exe to \\<end_user_desktop>\<Program_Files_share>\MyApp\dotnet.dat.
Set Up Nested Links with Application Link
ThinApp supports nested links with the Application Link utility. For example, if Microsoft Office links to a service pack, and the service pack links to a hot fix, ThinApp supports all these dependencies.
This procedure refers to AppA, which requires AppB; and AppB, which requires AppC. Assume the following folder layout for the procedure:
For information about setting up required and optional Application Link parameters in this procedure, refer ThinApp Package.ini Parameters Reference Guide.
Set up nested links
1
2
In the Package.ini file, specify Application B as a required or optional application link.
For example, add RequiredLinks=\AppFolder\AppB\AppB.exe to the file.
3
4
In the Package.ini file for Application B, specify Application C as a required or optional application link.
For example, add RequiredLinks=\AppFolder\AppC\AppC.exe to the file.
5
If you start Application A, it can access the files and registry keys of Application B and Application B can access the files and registry keys of Application C.
Affecting Isolation Modes with Application Link
ThinApp loads an Application Link layer during application startup and merges registry entries and file system directories. If ThinApp finds a registry subkey or file system directory that did not previously exist in the main package or layer that is already merged, ThinApp uses the isolation mode specified in the layer being loaded. If the registry subkey or file system directory exists in the main package and a layer that is already merged, ThinApp uses the most restrictive isolation mode specified in any of the layers or main package. The order of most restrictive to least restrictive isolation modes is Full, WriteCopy, and Merged.
PermittedGroups Effect on Linked Packages
If you link two applications and you specify a value for the PermittedGroups parameter, the user account used for starting the application must be a member of at least one of the Active Directory groups for this parameter in the Package.ini files of both applications. For information about the PermittedGroups parameter, refer ThinApp Package.ini Parameters Reference Guide.
Sandbox Changes for Standalone and Linked Packages
Sandbox changes from linked packages are not visible to the base executable file. For example, you can install Acrobat Reader as a standalone virtual package and as a linked package to the base Firefox application. When you start Acrobat Reader as a standalone application by running the virtual package and you change the preferences, ThinApp stores the changes in the sandbox for Acrobat Reader. When you start Firefox, Firefox cannot detect those changes because Firefox has its own sandbox. Opening a .pdf file with Firefox does not reflect the preference changes that exist in the standalone Acrobat Reader application.
Import Order for Linked Packages
ThinApp imports linked applications according to the order of applications in the RequiredAppLinks or OptionalAppLinks parameter. If either parameter specifies a wildcard character that triggers the import of more than one file, alphabetical order determines which package is imported first.
The OptionalAppLinks parameter might appear as OptionalAppLinks=a.exe;b.exe;plugins\*.exe.
Using a.exe and b.exe as sample executable files, ThinApp imports linked packages in the order described in Imported Linked Packages.
Import Order
For information about nested links, see Set Up Nested Links with Application Link.
File and Registry Collisions in Linked Packages
If the base application and a dependent package linked to the base application contain file or registry entries at the same location, a collision occurs. When this happens, the order of import operations determines which package has priority. The last package imported has priority in such cases and the file or registry contents from that package are visible to the running applications.
VBScript Collisions in Linked Packages
VBScript name collisions might prevent scripts in other imported packages from running. If you link packages with Application Link and those packages have scripts with the same name, ThinApp places the VBScripts from the linked packages into a single pool. For scripts with the same name, ThinApp runs the script from the last imported package and disregards the other scripts.
For example, a base package might contain the a.vbs and b.vbs files and a dependent package might contain the b.vbs and c.vbs files. Because a filename collision exists between the b.vbs files, the VBScript in the last imported package specified in a RequiredAppLinks or OptionalAppLinks parameter overrides any previously imported scripts with the same name. In this case, ThinApp condenses the pool of four .vbs files into a single pool with the a.vbs file from the base package and b.vbs and c.vbs files from the dependent package.
VBScript Function Order in Linked Packages
In a pool of VBScripts for packages linked with Application Link, functions in the main bodies of the scripts run in alphabetical order of the script names. ThinApp callback functions in the scripts run in reverse alphabetical order of the script names in the pool.
Storing Multiple Versions of a Linked Application in the Same Directory
If the directory holds a linked package, and you add an updated version of the linked package in the same directory, the Application Link utility detects and uses the updated version.
Using Application Sync for a Base Application and Linked Packages
If you use Application Link to link packages to a base package, and you start the base package, Application Sync can update only the base package. For example, if you build a Microsoft Office 2007 package with Application Sync entries in the Package.ini file, build an Adobe Reader package with Application Sync entries in the Package.ini file, use Application Link to link the two packages, and start Microsoft Office 2007, Application Sync only updates Microsoft Office 2007. You can update both Microsoft Office 2007 and Adobe Reader by starting each application separately.
If you do not update all the applications and link a base application to an expired plug-in, the base application can still load and use the plug-in.