VMware THIN4-CL-C Deployment Guide - Page 29
Package Replacement, Side by Side Update, AppSync
View all VMware THIN4-CL-C manuals
Add to My Manuals
Save this manual to your list of manuals |
Page 29 highlights
1. For deployed mode of execution only: Is the update of significant size? For deployed mode of execution it will be necessary to distribute the package to the end workstations. Should this be scheduled after hours due to network impact? 2. Once the update is deployed should users have a new sandbox created or re-use the existing sandbox configuration? User specific registry settings and preferences may be stored in the sandbox so in most cases re-using the existing sandbox is preferable. 3. For packages delivered via streamed execution, is there a change window where the administrator can make changes without user impact? If so, the package replacement method is an option. If there is no defined maintenance window then a side by side update will be required. (see next section for further explanation) 4. What is the capability for rollback if the application package is not functioning? Package Replacement The package replacement method for updating application packages can be used for either streamed or deployed execution mode. If you have created an updated package and have an administrative window where no users will launch the applications then you can simply replace the original .exe based package with the updated .exe. Make sure that the filename stays exactly the same: users depend on the shortcuts previously created to launch the applications. Side by Side Update The side by side method for updating application packages can be used for either streamed or deployed execution mode. There is no requirement for application downtime. This method works by placing the new application package in the same directory as the original application package and incrementing the filename extension to an integer number. Subsequent updates can be placed in the directories with extensions .2, .3, etc. The implementation of this update strategy follows a simple process. When a user launches an application from a shortcut that references the original .exe, logic built into the package automatically checks for identical package filenames with a numeric extension in the same directory. If an updated package, such as Mozilla Firefox.2, is found, the application launches using the file with the highest numeric extension. Always keep the original .exe that is referenced by the shortcut in place as it is a necessary pointer for the application to launch with or without updated packages. There is no downtime for the users with this method of update and no change window required for the administrator. Users will execute the updated package as they launch the applications and the original application packaged .exe directs them to the updated package. AppSync Application Sync provides updates to unmanaged machines that connect over networks with some degree of latency. AppSync provides a mechanism for a differential transfer over http to the endpoint, thus it is only used for application packages in deployed execution mode. When an application starts, Application Sync can query a Web server or fileshare to see if an updated version of the package 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 end user must have the rights to modify the packages. If not, then the AppSync utility can be run as a scheduled service as a user with sufficient rights to perform the update. The updated package is then used for future launches of the application. Settings that configure the location for Application Sync and detailed configuration are contained in the package.ini file. 29