VMware THIN4-CL-C Deployment Guide - Page 25

When applications are deployed and installed as MSI's the desktop integration occurs automatically as ThinReg is run during the install. Exe-based Packages via ThinReg Packages that are created in the .EXE format will benefit from registration via the Thinreg.exe tool to provide seamless integration into the desktop. Applications will launch and run without registration, however, file type associations are often necessary for users who start with a data file and launch the application by association. The Thinreg.exe tool is a simple utility that can be run from a login script, from a local directory, or a file share. It provides the ability for administrators to register all of the packages at once using an asterisk (*) as a wildcard character. Administrators can use pre-made scripts that run based on group membership to only register packages that are valid for a certain group or for individuals. Also, ThinReg is aware of the Active Directory 'permitted groups' listing provided during the Setup Capture process. So if the user is not a member of the permitted groups ThinReg will not register the package. If you choose to deploy packages in .EXE format but wish to use an alternate method of creating shortcuts, you can use standard Microsoft Folder Redirection to place shortcuts on the desktop and in the Start menu. http://support.microsoft.com/kb/232692. Controlling Access The process of deploying virtualized applications offers administrators control and flexibility over which machines and users receive either the application packages or access to the packages. Utilizing Active Directory or an alternative software deployment solution for distribution allows an organization to use the existing processes and controls. In addition to these organizational controls, VMware ThinApp allows an administrator to embed access control into the package. This access control mechanism is obfuscated from the end user when the package is built so it is impossible to identify or remove before the application is launched. In this way, the access control travels with the package if it is moved between devices after deployment. This mechanism can also be used when packages are hosted centrally on a file share as a secondary control in addition to file share permissions. There are three mechanisms described in the following sections, which are available to use for access control functions. Active Directory Permitted Groups You can control access to applications using Active Directory groups. When the administrator specifies PermittedGroups in the setup capture process or manually places the SIDS in the package.ini file they are embedded into the package during the build process. The PermittedGroups entry in the Package.ini restricts usage of a package to a specific set of Active Directory users and provides the administrator a way to customize the error message to the user if they are not allowed to launch the application. For a desktop that is offline, the PermittedGroups function will utilize cached credentials to determine if the user has permission to launch the application. Custom Scripting Options VMware ThinApp allows for the execution of custom scripts before starting an application packaged with ThinApp, during the application's use, or after an application exits. Callback functions allow you to specify when blocks of code execute. Using the OnFirstParentStart function allows an administrator to check for a condition when the application is launched. To add scripts to your application, you can create an ANSI text file with the .vbs file extension in the root project directory for an application (the same directory in which Package.ini is located). During the build process, ThinApp adds all of the script files to the application package and then at runtime it 25