VMware Horizon Mirage driver library best practice

Mirage offers many great functionalities which can be applied to different types of hardware. With Mirage you are able to do hardware migrations (e.g. from a hardware vendor to another), single image management (one image for different types of hardware), disaster recovery (e.g. from a hardware to a VM) and of course Windows migrations.

But all of these operations need one crucial thing to work: device drivers.

Without the correct drivers for your hardware many operations will fail. For example, Mirage will not be able to migrate a client to a new hardware if no suitable drivers are available. The good thing though is that Mirage will never render a system unbootable as it actively checks if all boot critical drivers are available. But Mirage will not check if you have, for example, the proper network or sound card drivers available instead Mirage will warn you if you do not have a matching driver profile for your hardware.

Driver profile

What is a driver profile? Mirage uses driver folders and driver profiles to dynamically provide drivers to a type of hardware.

A driver profile consists out of two things: (1) matching rules to specify to which hardware / endpoint drivers should be provided and (2) which drivers out of the driver folders should used.

From my experience driver profiles should be created with matching rules that are as specific as possible because wrong driver profile rules may result in unnecessary traffic (drivers will be downloaded to devices which do not require them) and wasted disk space on the endpoint. Also you want to make sure that each device only get the drivers meant for this specific device. This is to prevent that untested/unwanted drivers may be installed on a device.

Most of the time I use a combination of the following rules:

  • Vendor (e.g. Hewlett-Packard)
  • Model (e.g. HP Compaq 8200 Elite)
  • Version / Part of the serial number (if you have the same hardware model in different revisions)
  • Operating system (e.g Win7 (x64))

driverlibrary4

As profile name I use a combination out of the values above, for example: HP Compaq 8200 Elite – Windows 7 x64.

driverlibrary3

Driver folders

Driver folders are more or less the same as a folder structure in your file system to sort and store your drivers. My personal preference is to set up the folders in the following format:

  • Vendor
    • Model
      • Operating System
        • audio
        • graphics
        • network
        • storage

If you use Mirage only for Windows migrations you can disregard the operating system folder as you are only using one OS. A productive structure may look something like this:

driverlibrary1

Of course the driver library is also deduplicated. So if you import a driver more than once it will not consume more space on the Mirage volume because of dedupe.

Drivers

For Mirage you need “raw” device drivers with an inf and a cat file. Most of the times, if the customer does not provide some specific drivers, I rely on the the SCCM driver packs offered by the hardware vendors. Most vendors, including Dell, Lenovo and HP, offer ready to go driver packs. While these driver packs are designed to be used with SCCM/MDT they are in “raw” format and can also be used by Mirage.

Driver profile, driver folders and drivers combined

If you combine all three components the result is called the driver library.

Source: Driver Library Architecture

Mirage driver library at work

The driver library is downloaded in almost all Mirage operations. To be specific:

  • Centralisation
  • Windows migration
  • Hardware migration and restore
  • Machine cleanup (Layer enforcement with remove user applications option set)
  • Base layer assignment, update and provisioning
  • Apply driver library

When a driver library download is triggered the drivers, which are dynamically matched using the driver profile, are downloaded to the endpoint to the following location: %windir%WDLDrv. This folder is also added to the DevicePath registry key (For more information see Configure Windows to Search Additional Folders for Device Drivers).

Now, when Mirage starts the plug and play driver detection (e.g. during a migration, base layer update, etc.) Windows first looks in the Windows driver store for suitable drivers. If no driver was found it looks for a suitable driver in the locations listed in the DevicePath registry key. In this case %windir%WDLDrv.

By the way, the “Apply driver library” option only triggers the download but no plug and play driver detection. Also every driver library download operation is optimised. If the drivers already downloaded they will not be downloaded again because Mirage’s deduplication functionality is used.

Prioritise drivers in the Mirage driver library

Sometimes, even if the correct drivers are available in the driver library, Windows does not detect/install the driver provided by the driver library and instead uses a basic Windows driver. This happens because for some drivers it is specified that the basic driver is sufficient and therefore after a driver is found in the Windows driver store no search will be done in the DevicePath locations.

Setting the following registry entry on your endpoint (or base layer) will enable driver search in both locations (Windows driver store and DevicePath) regardless if the driver configuration specifies that a basic driver out of the Windows driver store is sufficient.

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\DriverSearching] "SearchOrderConfig"=dword:00000000

Release: VMware Horizon Mirage 4.3

Today VMware released the new version 4.3 of Horizon Mirage.

This release includes major improvements of the interoperability between Horizon Mirage and View and therefore officially supports image management of full clone virtual desktops.

The new release includes:

  • Support for image management of VMware Horizon View full clone desktops
  • Ability to do image management only (without the need to centralizing an endpoint first)
  • Ability to deploy app layers during a Windows 7 migration process
  • A bunch of tools for synchronizing (export and import) layers, CVDs and the driver library between different Mirage server clusters
  • Enhancements to the Mirage volume for better exclusion support in regards to Anti-virus solutions
  • A new web-based console with support for the Protection Manager role, which allows you to do all the tasks needed for protecting and synchronizing your endpoints.

Also there are many bug fixes included in this release.

Because covering each new features would blow up this article so much I decided to cover each feature in a separate article over the next few weeks.

Release Notes | Documentation | Download

Release: VMware Horizon View Client for Windows 2.2

In preparation of the Horizon View 5.3 release VMware released a new View client for windows. First of all the version number changed from 5.4 to 2.2. This change was done to better align the client version numbers. Also the version 2.2 sports a new look and feel (like the new View iOS client does).

View22Win

The new client also includes:

  • Support for Microsoft Windows 8.1 as client system
  • Support for VMware Horizon View 5.3 and therefore support for Windows 8.1 and Windows Server 2008 R2 as desktop
  • Windows 7 Multimedia Redirection
  • Flash URL Redirection enhancements

For more information about this new release have a look at the release notes or the official announcement blog article.

Release Notes | Documentation | Download

 

What’s new in VMware ThinApp 5.0 (Tech Edit)

Today VMware made ThinApp 5.0 generally available. While there is a lot of information out there on what’s new spread across multiple announcements, release notes and blogs I want to summarize the most critical information on what’s new in VMware ThinApp 5.0 from a technical point of view.

End-of-availability canceled

Even if this isn’t a technical point it is still pretty important to know. With the announcement of the VMware Horizon Suite it was also announced that after December 15th, 2013 ThinApp would not be available as standalone product anymore. Shortly after this announcement was made is was pretty clear that our customers where not amused and VMware clearly had underestimated on how many customer count on ThinApp – one of the leading application virtualization products – as a standalone product.

Therefore with the announcement of ThinApp 5.0 VMware also announced that the end-of-availability is canceled. This means VMware will continue to offer ThinApp as a standalone product and you will be able to get at least five more years of service and support for ThinApp.

Re-architecture

In version 5.0 much was changed on the internal plumbing of ThinApp. From a very technical point of view VMware is moving away from import address table hooking of Win32 API to inline hooking of the Windows Native API (NTDLL.dll). As you can see in the figure below this hooking takes place in a much earlier stage and therefore increases the overall application compatibility.

Image source: http://technet.microsoft.com/en-us/library/cc768129.aspx
Image source: http://technet.microsoft.com/en-us/library/cc768129.aspx

Also it greatly reduces the number of hooked API. Because instead of hooking all the high-level Win32 API functions ThinApp now hooks low-level functions of the Windows Native API, which are also used internally by all the Win32 API functions.

The following screenshots are showing the DLLs used by a virtualized instance of Notepad++. As you can see there are a lot more DLLs in play with ThinApp 4.7.3 as  there are with ThinApp 5.0.

HookedDLLsThinApp

All in all the number of of hooked APIs are reduced from about 600 to 200. Which results in a much smaller code base of ThinApp 5.0 and therefore decreases the number of potential bugs. Also, as already mentioned, it should boost the already very good application compatibility of ThinApp to a new level.

64-bit support

ThinApp always supported 64-bit operating systems and was always able to run virtualized 32-bit applications on top of Windows 64-bit versions. But with ThinApp 5.0 finally the virtualization of 64-bit applications is  possible. This was one of the most requested feature by our customers.

The ability to virtualize 64-bit applications opens up many new use cases, i.e. the virtualization of 64-bit version of Office and Internet Explorer but also the virtualization extensive CAD/CAM applications.

The following tables shows the supported capture and deployment scenarios of ThinApp 5.0.

As you can see ThinApp supports pretty much every available scenario with the exception of the following two:

  1. ThinApp 5.0 does support capturing 32-bit applications on top of 64-bit operating systems but only if you build and deploy it to 64-bit machines only. If you want to run a 32-bit package on top of 32 and 64-bit operating systems you need to create the package on top of a 32-bit operating system.
  2. ThinApp still supports the virtualization of 16-bit applications on top of 32-bit operating systems but does not and never will support 16-bit applications on top of Windows 64-bit. You can blame – or in my opinion thank – Microsoft for that. See 64-bit versions of Windows do not support 16-bit components, 16-bit processes, or 16-bit applications

VMware supports the following operating systems for running virtualized 64-bit applications:

  • Windows 7 64-bit
  • Windows Server 2008 R2
  • Windows 8 64-bit
  • Windows Server 2012
  • Windows 8.1 64bit
  • Windows Server 2012 R2

Not supported are:

  • Windows XP 64-bit
  • Windows Server 2003 64-bit
  • Windows Vista 64-bit
  • Windows Server 2008 64-bit

ThinApp 5.0 of course still support these platforms for running virtualized 32-bit applications on top of them. And of course all other 32-bit platforms (like Windows XP, Vista, 7 and so on) are still supported.

Office 2013 and Internet Explorer 10 support

With ThinApp 5.0 you can virtualize the latest Microsoft applications like Office 2013 and Internet Explorer 10. While Office 2010 was a pain to virtualize in prior version of ThinApp, ThinApp 5.0 includes many fixes to make packaging much more reliable. Also VMware provides official packaging guidelines for Office 2010 (See KB 1022287) and 2013 (See KB 2062691).

Unfortunately support for both products is limited at the moment. While virtualizing Internet Explorer 10 with ThinApp 5.0 is supported up to Windows 8 (but not 8.1), virtualizing Office 2013 is only supported up to Windows 7 (but not Windows 8 / 8.1).

This is likely to change within a future version of ThinApp.

Compatibility

One big advantage of ThinApp’s agent- and client-less architecture is that you are able to run multiple versions of the ThinApp runtime at the same time. Therefore integrating a new version of ThinApp is easy as pie. Still there are some things to consider when bringing ThinApp packages in version 5.0 in to an existing ThinApp environment.

AppLink: with ThinApp 5.0 we support linking ThinApp 5.0 packages with ThinApp 4.5 (and later) packages. There is only one gotcha: The parent package always has to be packaged with ThinApp 5.0. So if you for example have Mozilla Firefox virtualized and several AppLink packages like Flash and Java connected you first have to update the Mozilla Firefox package to ThinApp 5.0 in order to update any linked package (Flash or Java) to ThinApp version 5.0.

In-place update: With ThinApp it was always possible to update current ThinApp packages to a newer version of the runtime or the application it self by copying the new package side-by-side with the old package and adding integer at the end of the package.

For example: If the user is currently using Notepad++ 6.0 as a ThinApp package called Notepad++.exe and you want to deploy Notepad++ 6.5. Just copy the new ThinApp package as Notepad++.exe.1 side-by-side to the original Notepad++.exe ThinApp package and as soon as the user launches or relaunches (yes, you can do this while the user is using the application) he will get the new Notepad++ 6.5 package.

When doing an in-place update to a 5.0 package that contains the new .alt file this file should be named as *.n.alt where n is the integer you choose for the base .dat or .exe file. In this case it would be Notepad++.exe.1.alt.

AppSync: Of course you can also update your applications using the AppSync mechanism but only 32-bit packages. Also see the following article: When you perform Appsync from 4.7.2 to 4.7.3. AppSync displays the following error message “The operating system cannot run”.

MSI: Updating ThinApp packages from prior versions of ThinApp to version 5.0 is done the normal way. (See Upgrade a deployed ThinApp package with the help of MSI) There are no special considerations necessary.

Sandbox: It it worth mentioning that the sandbox (if the sandbox names are identical) will be reused during an upgrade. So if you updating your packages to ThinApp 5.0 all application settings are available after the update. Please keep in mind that updating to a newer version of an application or even a different application bitness (32-bit vs. 64-bit) may result in loss of the application settings as they are probably  saved in a different location in the registry. In this scenario it would be advisable to use a new sandbox and not to reuse the existing sandbox.

ThinDirect enhancements

ThinDirect in ThinApp 5.0 was update to support newer browsers like Internet Explorer 10 and also 64-bit versions of Internet Explorer.

Also the ThinDirect policies – that controls which URL should be opened in which virtual browser – are now available as ADMX template.

Updated SDK

The ThinApp SDK was also updated with version 5.0. It now includes a separate 64-bit DLL (ThinAppSDK64.dll) and therefore eliminates the need of the ThinAppSDKSrv.exe on 64-bit operating systems.

You can use the new SDK and all your scripts/programs without any change with existing ThinApp packages prior version 5.0. If you want to enable your scripts/programs to support ThinApp 5.0 packages you actually have to change them.

Have a look at the release notes to get more details on this particular point.

VMware Horizon View and Workspace integration

ThinApp is an integral part of VMware Horizon View, Workspace and Mirage. While you can start using ThinApp 5.0 in your Mirage deployments right away as there is no direct link between Mirage and ThinApp you have to be aware of some limitations when it comes to the View and Workspace integration.

The current releases of Horizon View will support ThinApp 5.0 32-bit packages out of the box. Support for 64-bit ThinApp 5.0 packages will be introduced in future version of Horizon View. Horizon Workspace 1.5 does not support ThinApp 5.0, neither 32-bit nor 64-bit.

In regards to Horizon View you of course have always the possibility to use ThinReg or the SDK to register ThinApp 5.0 64-bit packages using a logon script or deploy them via MSI. This is fully supported and this way you can enjoy 64-bit ThinApps from day one.

For more information see the official knowledge base article: Horizon View and Horizon Workspace support for ThinApp 5.0 applications

AppSense Environment Manager integration

While it was always possible to manage the personality of a ThinApp package using Environment Manager from AppSense by copying the sandbox at logon and logoff. With VMware ThinApp 5.0 the Environment Manager from AppSense can actually look into the sandbox and therefore do all the amazing cross-application personalization stuff. So you can for example configure your local Office 2010 on your laptop and when you connect to your virtual VMware View desktop you have the same settings in your Office 2010 ThinApp package.

More information on the integration can be found in the following blog post by AppSense: AppSense Environment Manager Integrates with VMware ThinApp 5.0

As you can ThinApp 5.0 contains many major improvements and new features. I hope you will enjoy working with ThinApp 5.0 as much as I do.

Release Notes | Documentation | Download

Disable touch input in VMware Fusion or Workstation

SwipeWin81Since last years release of VMware Workstation (9.0) it is possible to pass through touch input to your virtual machine. While this definitely is a nice feature if you’re using a touch-enabled computer it isn’t particular useful on a non-touch system.

By default the touch input is only enabled for touch-enabled operating systems like Windows 8. Normally this is fine but with Windows 8.1 Microsoft has introduces some annoying help dialogs to get you to know all the swipe gestures available. Unfortunately I can’t “Swipe in from the edge to go back to the lsat app you were using” on my MacBook.

You can of course disable those messages using some Windows setting but why not disable the touch input completely if it isn’t used after all?

To disable touch input you have to open the .vmx file of your virtual machine and change the parameter

touchscreen.vusb.present = "TRUE"

to

touchscreen.vusb.present = "FALSE"

This also applies to VMware Fusion.

Use a dedicated network for storage traffic in a Mirage cluster

For optimizing the performance and stability of a Mirage cluster it is highly recommended to use a dedicated network interface for the SMB storage traffic. The following article will guide you through the process of getting an dedicated storage network up and running and how to move your existing Mirage volumes to the dedicated network.

Please validate this guide in an test environment before applying any chances to your production environment.

Create dedicated network

It is recommended to use a dedicated network for just the storage traffic. In this example a dedicated virtual switch is created which is only used for storage traffic.

s1

In a productive environment you can use a dedicated network switch, or VLAN. If VLAN is not an option the physical separation of the storage network is the best option. For this scenario you need a minimum of four NICs (2 for storage network and 2 for client network)

A new network card, connected to the dedictated network, was added to each Mirage server.

Mirage server configuration

As a new network card was added to each Mirage servers this cards need to be configured correctly.

First of all the order in which the network cards are accessed by network services needs to be correct.

The primary network card which is used for the general communcation (Active Directory, Mirage server, Backup, Management, etc.) needs to be the first card in the list.


s2

This option can be found under Control Panel -> Network and Internet -> Network Connections –> Advanced -> Adapters and Bindings.

After configuring the order of the new network card for the dedicated storage the network needs to be configured.

In this example the IP range 192.168.89.0/24 is used for this cluster network. Therefore the first Mirage server gets the IP 192.168.89.1.

s3

The use of DNS isn’t necessary and it is not recommended to configure an additional default gateway. The storage network should be a none routed network with direct connect tot he storage, if possible.

s4

It is also necessary to leave the services „Client for Microsoft Networks“ and „File and Printer Sharing for Microsoft Networks“ checked for the storage interface. If these services are disabled no access to the network share is possible.

Network share configuration

To use a network share as Mirage storage volume the account used for the Mirage services needs to be granted full permissions on the share.

s5

Also, if a Windows file server it used, it also has to have full permissions granted at NTFS level.

s6

If the network share used for the Mirage storage is provided by the Mirage servers itself, no additional configuration steps are needed. Windows automacially binds network shares on all network interfaces which have the „Files and Printer Sharing for Microsoft Networks“ enabled.

If a dedicated Windows file server or network filer (like NetApp) is used additional configuration steps are necessary to make the used network share available on the dedicated cluster network. These configuration steps are not covered in this article. Please contact your Windows file server administrator or storage vendor for further information on this topic.

Change path of an existing volumes to use the dedicated network

Before the current path of the Mirage volume can be changed the volume needs to be unmountend first. Unmounting a volume places the volume in a non-operational status but retains the CVD and Base Layer data on the volume. This means for time the volume is unmounted CVDs placed on this volume aren’t centralized or backed up.

s7

As unmounting and changing the path of the volume only takes a few moments this shouldn’t be a problem.

s8

When the storage is unmounted the path can be changed to the dedicated network. In this example the path is change from \mirage2.fluxhorizon.commiragelocalstorage$ to \192.168.89.1miragelocalstorage$.

s9

After the path is changed the volume needs to be mounted again.

s10

These steps need to repeated on each Mirage volume which should be placed on the dedicated network interface.

s11This article was originally published by Tim Arenz (@timarenz) at horizonflux.com.

Horizon Mirage Layers explained

With the newest release of Horizon Mirage everyone is talking about layers, base images, application layering and so one. If you never have worked with Mirage or another layering technology before you may have seen something like this in the past:

OldLayers

With this layer cake vendors explain and show the benefits of virtualization. Virtualization, as everybody should know by now, is a technique to abstract the logic from the physical ressource. Well-known examples are:

  • You can abstract the operating system from the physical hardware by using virtual machines (e.g. VMware ESXi).
  • You can abstract applications from the operating system by using application virtualization (e.g. VMware ThinApp).
  • You can abstract the user profile from the application and operating system by using user virtualization (e.g. AppSense Environment Mananger)

When using a virtualization product you not just simply abstract the logic but you put something between the logic and the physical ressource to get the abstraction done, products like ESXi or ThinApp for example. At the beginning of the virtualization boom every product had major limitations but today virtualization technologies got mature and most of the limitations are gone. Still there are some types of virtualization which got some limitations, for example you can’t virtualize drivers with any application virtualization products or the big penalties you have to pay in terms of hardware compatibility, performance and end user experience when it comes type-1 client hypervisors.

Horizon Mirage doesn’t use any virtualization product to abstract the logic from the physic, but we still abstract the logic. With Mirage the layers look something like this:

MirageLayersDetailedTo abstract all these layers from each other Mirage uses some clever engineering work. Simply put Mirage takes all the files, registry keys and drivers and puts them in the right layer. Of course this is done differently for each type of layer. The following list describes how this is done for each layer:

  • Driver layer
    For the driver layer the administrator has to import the drivers he wants to deploy manually. Download the driver package from vendor, extract it and import it into the management console. Drivers then can be combined to driver profiles. So for example you could import all drivers you need for your Dell E6500 laptop and then create a driver profile called “Dell E6500” which contains all the drivers you need for this laptop. Drivers then can be assigned to your managed computers based on a variety of matching rules, for example operating system, hardware vendor and model.
  • Base layer
    A base layer is created by installing the Mirage client on a reference machine and then centralizing this machine. A reference machine is a computer installed with an operating system you want to manage and it also contains your core configuration, infrastructure software (e.g. anti virus) and core apps. When you have configured your reference machine with all the software and settings as needed you can create a new base layer. By default the entire content of the reference machine is saved in a base layer. This however can be modified to exclude specific subsets of content.  Also there are some factory rules applied. The base layer is the first thing deployed to a client machine if its completely managed by Mirage.
  • App layer
    As the name says an application layer contains an application. An application layer is not limited to one application, you can also install multiple applications into an application layer. Even ThinApp packages can be distributed via a Mirage app layer (more on this in another post). An app layer is created using a snapshot technique. You install the Mirage client again on a reference system, create a snapshot before you install your application you want to put in a layer, than you install your application and afterwards Mirage creates another snapshot and compares the differences and compiles them into an app layer. An application layer contains everything detected as delta except for changes written to a specific user profile and again some factory rules.
  • User layer
    The user layer contains all the content a user creates on top of the base layer and app layers. This layer is automatically created for every computer managed by Mirage. Mirage knows, based on the base layer and the app layers assigned to the particular computer, what it needs to save in this layer automatically.
Factory rules and policies
Factory rules and policies are set in place by VMware to ensure that nothing is included or excluded in a specific layer which could hinder Mirage or the layers (operating system, applications, etc.) deployed by Mirage to work probably. An administrator can see what factory rules and policies are applied using the Mirage management console.

The miragcle miracle Mirage now performs is to bring all these layers to your computer and merge these layers as if they were never separated. After you deployed the base and app layers to a device you can basically just uninstall the Mirage client and everything will still work as expected.

As you can see Mirage works like a virtualization solution on the management site. You can separate apps, operating system, drivers and user settings/apps in different logical layers but on the end point, the users desktop, everything is merged back together and works like a native system.

This has obviously many advantages compared to solutions like application virtualization products and typ-1 client hypervisors, for example:

  • The user always gets full native performance.
  • There is no hardware compatibility list. As long your device runs Windows everything is fine.
  • The application is installed locally and so apps with drivers and shell integration can be easily deployed.

Besides the centralized image management and provisioning functionalities Mirages can do much more thanks to the layering approach, for example Windows migrations, hardware migrations, and backup and recovery.

Mirage overlaps with many solutions on the market such as software deployment systems, backup and recovery and image management tools. The good thing about Mirage is that you can combine it with other solutions but you can use it also as a standalone product. There is no either or.

If you want to learn more about Mirage have a look at the Horizon Mirage 4.0 Reviewer’s Guide or the product page.

Sources: VMware, VMware (2), VMware (3)

Release: VMware Horizon View Clients 2.0

To support the latest VMware Horizon View 5.2 release and Unity Touch VMware release a wave of new and improved VMware Horizon View clients. The following list shows you all the latest client releases and what they are bringing to the table in terms of new features.

VMware Horizon View Client for Windows 5.3

  • Microsoft Lync support on Windows 7 client systems
  • Enhanced support for 3D applications
  • Localization support for Traditional Chinese
  • Optional customer experience improvement program (CEIP)

VMware Horizon View Client for Mac OS X 2.0

  • Support for multiple monitors
  • Retina Display support
  • USB redirection enhancements
  • Localization support for Traditional Chinese

VMware Horizon View Client for Linux 2.0

  • Support for Windows 8 Horizon View desktops
  • Localization support for Traditional Chinese

VMware Horizon View Client for Android 2.0

  • Support for Unity Touch
  • Android 4.x Dictation with Windows Applications
  • Full screen mode
  • Optimizations for VMware Horizon View 5.2
  • Localization support for Traditional Chinese

VMware Horizon View Client for iOS 2.0

  • Support for Unity Touch
  • Optimizations for VMware Horizon View 5.2
  • iOS Dictation with Windows Applications
  • Enhancements to presentation mode
  • Localization support for Traditional Chinese

VMware Horizon View Client for Windows Store 2.0 (Tech Preview)

  • Support for Windows 8 Pro client systems and Horizon View desktops
  • Pin to Start
  • Smart card support
  • User interface and documentation available in 7 languages
  • URI (Uniform resource identifier) support
  • Optional customer experience improvement program (CEIP)

The iOS and Android clients are already available in their respective app stores. All other clients can be downloaded here: vmware.com/go/viewclients

To use Unity Touch on Android and iOS you need to deploy the Feature Pack 1 for VMware Horizon View 5.2 first.

Documentation | Download

ThinApp Setup Capture doesn’t capture file type associations

Together with my friend Sebastian Stein (@BERSFO) from tempero.it we discovered a little problem with the ThinApp Setup Capture. When capturing an application, in our case we captures ACDSee, it may happen that the Setup Capture wizard doesn’t record the file type associations registered by the application.

You can easy fix this using the commandline tools assoc and ftype to reregister the file type associations during the capture process. For a detailed description see Sebastian’s article.

Virtualize ACDSee with ThinApp and register File Types

ThinApp, OS migrations and application compatibility

StarkWinXPEoS
Image source: http://memegenerator.net/instance/34382526

A picture is worth a thousand words.

We all know that the official support for Windows XP ends on April 8, 2014.

Therefore many customers starting to look at ways to migrate their legacy applications from Windows XP to a newer version of Windows. While many applications may run on Windows 7 (or later) without any hassle there are still some apps which aren’t working on Windows 7 out of the box. As always exactly these apps are most likely declared as business critical or at least very important.

Many people see ThinApp as the silver bullet when it comes to OS migrations and application compatibility issues. To a certain degree they are right, ThinApp can definitely help to solve many application compatibility issues and ease the pain of a Windows 7 migration. But ThinApp unfortunately can’t perform magic.

There are many reasons why applications won’t run on Windows 7. To understand if ThinApp can help or not we first have to analyse why applications may not run on a newer version of Windows.

Common Compatibility Issues
  • Deprecated .dll files, executable (.exe) files, COM objects, registry keys and application-programming interfaces (APIs)
  • Hard-coded locations (file locations, directories, registry keys)
  • User Account Control (UAC)
  • Operating System Version Changes
  • Dependencies to a specific Internet Explorer version
  • 64-bit versions of Windows do not support 16-bit components, 16-bit processes, or 16-bit applications
  • Source: http://technet.microsoft.com/en-us/library/cc766242(WS.10).aspx

    Some of these issues can easily be fixed even with built-in Windows functions. For example an application may check on which operating system it is running (see Operating System Version Changes in the source link above) and refuses to run if not running on top of Windows XP. You can easily fool the application to think it is running on Windows XP even if it is really running on Windows 7 using the compatibility mode option.

    However other issues aren’t fixable at all. If an application relies on 16-bit components or is a 16-bit application itself and you want to migrate to a 64-bit version of Windows you are out of luck. The application simply will not work. You could however use VMware Workstation or View to deploy 32-bit virtual Windows machines for your legacy 16-bit applications. Another example for an application which will probably not work if it depends on APIs which are deprecated or undocumented and therefore not available or working different in Windows 7.

    Where ThinApp can’t help
  • Running applications which depend on deprecated APIs
  • Run 16-bit applications on 64-bit Windows.
  • Other reasons why an application might fail to work on Windows 7 like deprecated .dll files, hard-coded locations and dependencies to specific versions of Internet Explorer are a perfect fit for ThinApp!

    With ThinApp you are able to:

    As you can see there are many cases in which ThinApp can provide help running legacy Windows XP applications on Windows 7 even if they wouldn’t work when installed natively. However there are no guaranties this will work and it may require some effort to get it working. Still it is worth a try considering all the benefits you gain when using ThinApp especially when migrating to a newer version of Windows.

    If you want to know exactly when support for Windows XP will end you should try the official Windows XP End Of Support Countdown Gadget.