Full support for Internet Explorer 6 running on Windows 7.
ThinApp has been successfully used to help customers virtualize and isolate many browser related issues such as ActiveX controls and various versions of Java.
In January, we posted a guide on how to use ThinApp to virtualize IE6 for Windows 7 using Firefox IETabs as a container. This was very popular with our customers in the process of migrating to Windows 7. Our initial attempts to resolve the IE6 / Windows 7 issue focused on using IETabs because while virtualizing the IE6’s rendering engine was easy for ThinApp, completely virtualizing the browser frame and everything it can do was a bit harder. For example, when you use the File/Save dialog in IE6 it interfaces with system shell components that are not backward compatible from Win7 to XP. If you tried to do operations like File SaveAs, File Open, Print, Print Preview, New contact, Edit with Notepad, or modify various settings under Tools Internet Options you would probably get a crash or an error message. In addition you might have seen some cosmetic issues with icons being black or incorrect because of these same shell dependencies. We are happy to report we have now have IE6 fully virtualized and running on Windows 7 32bit and 64bit. Click here to see a video of this functionality in action.
ThinApp 4.6 adds the ability to “Harvest” Internet Explorer 6 from an existing Windows XP instance.
In the past, the process for creating an IE6 package with ThinApp was complex. It required capturing the IE6 install using a clean instance of Windows 2000 with its pre-IE6 native browser IE5 and performing an upgrade. If you captured on Windows 2000 using the IE6 download from Microsoft’s download page odds are you would not get all the latest security fixes and updates provided by Microsoft. Capturing using a Windows 2000 base also made capturing IE6 applications plug-ins a bit trickier, especially if the plug-ins only installs on XP+. With so many companies migrating to Windows 7 we knew this is a popular use case, so we’ve turned the process of capturing IE6 into a few clicks. ThinApp can now automatically “harvest” IE6 from of any Windows XP instance. This means you can use an XP instance that has the latest security fixes applied, and also capture any plug-ins you want in the same go!
ThinApp 4.6 adds a new “ThinDirect” feature which allows redirecting of URLs from native to virtual browsers.
Often customers want to use and maintain a native instance of Internet Explorer on their desktops to allow full integration with other non-virtualized applications and to utilize Window’s built-in update mechanisms. In many cases users need virtualized browsers to access web pages requiring legacy versions of the Java runtime or web pages requiring IE6. This dual browser scenario presents new challenges to user. With previous versions of ThinApp, users needed to know which browser they should use for each web page. This method works, but the process requires some user training and breaks up with normal work-flow. ThinApp 4.6 introduces the ability to associate web pages with different virtualized browser versions. With ThinDirect, users are automatically redirected to the appropriate browser (virtual or native and back again) as they navigate through different pages without interruption to their work-flow. This functionality works by installing a browser helper object in the native instance of IE which can then launch the virtualized browsers navigating to specific pre-defined URLs. This can be thought of as “file type association for browsers”. Because ThinApp executes entirely in user-mode and doesn’t install any system drivers, you can guarantee the native IE instance is completely unaffected by ThinApp (and remains fully supported by Microsoft). Virtualization only kicks in when the user navigates to specific URLs, and then only for the IE6 process instance. All other processes on the system are unaffected by ThinApp. This helps reduce the testing matrix complexity because ThinApp can be completely removed from the equation when testing the standard desktop experience before rolling out to users.
When capturing applications that register themselves as browsers, the following screen will appear in Setup Capture allowing you to redirect URLs from the native IE browser to the browser being captured.
By default a virtualized IE browser will automatically redirect back to the native browser if the user navigates away from URLs controlled by ThinDirect. This improves the user experience and ensures older browser cannot visit sites that might attempt to exploit browser based security vulnerabilities. You can disable this automatic redirection back to the native browser by adding the package.ini option “ThinDirectWhitelistOnly=0” to your virtual browser package.
ThinDirect works by installing a Browser Helper object in the native instance of IE. The installation of the browser helper object can happen in one of 3 ways:
- When performing an “All Users” install of a ThinApp .msi package for a virtualized browser that contains ThinDirect redirection entries.
- When running “Thinreg /a VirtualBrowser.exe”. (/a is all users)
- Deploying the “ThinDirect.msi” installer included with ThinApp 4.6 to target desktops.
Because of limitations in Internet Explorer, browser helper objects cannot be installed on a per-user basis so the install of ThinDirect’s browser helper object must be done on a per-machine.
Controlling URL redirection on a per-machine and per-user basis using config files
ThinDirect consults various locations to determine which URLs should be relocated to which virtual browsers. When a ThinApp containing ThinDirect.txt configuration entries is registered or installed, the ThinDirect.txt file is extracted to a per-machine or per-user location depending on weather the registration/installation was per-machine or per-user.
c:\Program Files\VMware\VMware ThinApp\ThinDirect
%AppData%\VMware\VMware ThinApp\ThinDirect folder
ThinDirect configuration files will also be removed when an application is unregistered or uninstalled. Administrators are free to add/remove/edit configuration files at these locations to configure how ThinDirect works post-installation. An individual ThinDirect.txt file format allows you to redirect sets of URLs to different ThinApp entry points.
Controlling URL redirection on a per-machine and per-user basis using Group Policy
We expect customers with large number of PCs will prefer to update URL redirection information via this method since Active Directory will automatically take care of replicating policy information to all PCs attached to managed domains.
Administrators can use the included Group Policy ADM file ThinDirect.adm located under C:\Program Files\VMware\VMware ThinApp\ThinDirect.adm to deploy ThinDirect configuration data to end-user computers with Active Directory based Group Policy. Under the covers, the ADM file is used push specific HKLM registry changes via Active Directory. The ThinDirect browser helper object will consult these registry settings locally to determine which URLs should be redirected to which virtual browsers.
ThinApp 4.6 adds support for registering virtual services as boot-time applications
Services typically fall into two categories:
1. Services which are installed with a particular application and generally meant to only be used by that application. For example, an application may install a database because it needs a local database to load and store configuration data. For these types of services, it is ideal to virtualize the service in such a way that each user launching a virtualized application will start their own isolated copy of a virtualized service and data for the service can be isolated on a per-user basis. This is the default behavior for ThinApp when capturing applications which install these types of services and this functionality has been available for several years. By design, per-user based services will not be visible to other processes on the system and not visible in the services control panel.
2. Services installed stand-alone and meant to provide a service to several applications on the same system or to other computers on the same network. For this type of service per-user isolation is not needed or wanted. ThinApp 4.6 now supports starting virtualized services at system boot time. Such services are visible as “real” services to all local and remote applications as well as the services control panel. The following demonstrates the steps to capture and deploy Apache as a boot-time virtualized service:
o Capture a normal installation on Apache HTTP Server using Setup Capture just like any desktop application
o After the capture process, find the [httpd.exe] entry in Package.ini change :
To deploy a virtualized apache to a target machine and have it registered as a boot time service, you can do either use “Thinreg.exe /a httpd.exe” or simply build a ThinApp MSI and run it on that target machine. If you plan to have the service run from a streamed location (network share), you need to make sure the network share gets authenticated/mounted prior to the service being started by the operating system.
Why would you want to virtualize a boot-time service?
- Fast Install/Uninstall on a machine. ThinApp packages can be registered in less a second on a machine regardless of the size of the service.
- Simplify service upgrades. Because ThinApped services are a located in single file or directory and all application specific data is sandboxed into a known folder, the application upgrade process can be simplified to xcopy operations.
- Reduce disk space for large services. Because ThinApp packages can be streamed directly from a network share, only one copy of a service-based package needs to be stored centrally while multiple computers can be executing it simultaneously.
- Reduce application conflicts between service and desktop/server image. For larger complex services, installation dependencies can create conflicts for other applications installed on the same system. A ThinApp’ed version of a service runs in isolation and does not need to modify the local filesystem or registry and can avoid such conflicts.
ThinApp Converter 1.0
ThinApp Converter is our first step in automating the ThinApp package creation process from other data sources. ThinApp Converter uses a robust mechanism for performing a conversion, running the application’s original installer in a VM and capturing the results of that installation. Past automated approaches that attempted use static analysis on MSI databases to create virtualized applications had a low success rate because most MSI files have custom action DLL files. Custom action DLLs contain arbitrary native code which runs during the time of installation, so their results are impossible to predict ahead of time. By running the actual application installer in a VM, the custom action code gets run and changes made by the custom action are correctly captured. A simple picture of ThinApp Converter’s process can be seen below:
The inputs to ThinApp Converter are a configuration file (Converter.ini) and a network share path containing the packages to be converted. ThinApp Converter then does the work of managing machine snapshots and dispatching the install/capture/build process to one or more virtual machines. The final result is placed on another output network share and contains both the pre-build project files and built binaries.
ThinApp Converter supports the following virtual machines as part of the capture process:
- VMware Workstation 7.0+
- VMware ESX Server version 4.0+
- vCenter Server 4.0+
ThinApp Converter should work well with application libraries that are already prepared for automated install such as those created by Wyse and Admin Studio. ThinApp can also convert EXE based setups and MSIs that require transform files or command-line parameters to do automated install, however these parameters must be specified in a file next to the application installer or in the Converter.ini file. For such applications, it makes sense to use automated conversion when it’s expected the application may need to be recaptured more than once in the future.
ThinApp converter provides detailed logging information under:
ThinApp Converter automates the operations usually performed to create packages:
- Distributing packaging work-load across multiple virtual machines
- Connecting to a named VM Workstations, vSphere, or ESX
- Taking snapshot of VM initial clean state
- Logging into Guest VM
- Mounting package source UNC share inside of VM.
- Mounting library output UNC share inside VM
- Running ThinApp pre-install snapshot process
- Running application installer in guest
- Waiting for application installer to complete
- Running ThinApp post-install snapshot process
- Generating application project from two ThinApp snapshots
- Building generated project into a package
- Saving both project and package in output library
- Reverting Virtual Machine to initial state
When username and password information is required to log into virtual machines or mount network UNC shares, credential details can be stored in plaintext or obfuscated format in a configuration file. Optionally you can be prompted for passwords each time ThinApp Converter is launched.
We will be demoing ThinApp Converter along with some other very cool things around ThinApp Converter and will help clarify our auto-conversion vision at VMworld. So stay tuned for more news!
Public availability of ThinApp Management SDK
ThinApp Management SDK enables package inspection and control of package inspection, registration, streaming, and updates. The ThinApp Management SDK has been publically released and is available as a download. While the SDK was available to selected partners in the past, now it is being made available to everyone here:
The ThinApp SDK is available as a dual-interface COM object so it can be used from C++, VBScript, .NET and most other programming lagnuages. The following vbs example (GetInventoryName.vbs) demonstrates how to retreive the inventory name from a ThinApp .exe, .dat, or .msi file.
Set Management = WScript.CreateObject("ThinApp.Management")
Set Package = Management.OpenPackage(WScript.Arguments(0))
WScript.Echo "Inventory name: " & Package.InventoryName
The above script can be executed as “wscript GetInventoryName.vbs package.dat” from the command-line. More examples and documentation can be found in the SDK download including descriptions of SDK objects such as :
- ThinApp.Managment - Main starting object to create other sub-objects. Determines package types, opens packages.
- ThinApp.Package - retreives options, shortcuts, icons, controls appsync, registration, install
- ThinApp.VFileSystem - determine which virtual drives and paths exist inside package
- ThinApp.VFile - Get hash and verify contents of individual virtual files
- ThinApp.VFolder - Obtains file files by specific extensions
- ThinApp.VRegistry - Opens virtual registry keys
- ThinApp.VRegKey - Obtains values and subkeys for a virtual registry key
- ThinApp.Option - retreive package options
Using the SDK, 3rd party DLLs can also retrieve notifications from ThinApp packages at the following events:
- OnFirstSandboxOwner, OnFirstParentStart, OnGetOption, OnFirstParentExit, OnLastProcessExit
AppLink now supports wildcard patterns for both directories and filenames
AppLink has been a popular way for customer to dynamically combine applications and their dependencies or plug-ins at runtime. ThinApp 4.6 allows greater flexibility in specifying target dependency locations by supporting wildcard patterns for directory names. For example, one can link virtualized Internet Explorer with an arbitrary set of plugins via a single package.ini setting such as "OptionalAppLinks=plugins\*\*.dat"
Go Get It!
You can download a free trial version of Thinapp here: