What’s new in VMware Horizon Mirage 4.4 (Tech Edit)

Today VMware released version 4.4 of Horizon Mirage. Even if the official version is just a minor change there are major new features in this release.

In this article I try, like I did for ThinApp 5.0, to summarise and give an overview of all the new features included in version 4.4 from a technical point of view.

Windows 8 / 8.1 support for disaster recovery scenarios

First of all the installation of the Mirage client is now supported on Windows 8 and 8.1. While the full feature set, especially layer management and migrations, isn’t yet support the disaster recovery scenario is fully supported in Mirage 4.4. The disaster recovery scenario contains file/full system recovery and restore as well as self-service recovery using the Mirage file portal and client context menu. One thing important to know is that restore operations for Windows 8 devices can only be performed within the same operating system version, for example, Windows 8.0 to Windows 8.0 or Windows 8.1 to Windows 8.1. But using Mirage 4.4 you will be able to downgrade a Windows 8/8.1 device to Windows 7. This feature is more then welcome when you get new hardware preinstalled with Windows 8(.1) and want to deploy your corporate standard Windows 7 image using Mirage.

To support Windows 8 and Windows 8.1 Mirage now supports version 6.3 of the User State Migration Toolkit (USMT). Mirage now actually supports three versions of USMT:

  • USMT 4 or 5  for Windows XP to Windows 7 migrations and user data restores
  • USMT 6.3 for Windows 8 and 8.1 for user data restores

Mirage44USMT

The import function also was enhanced to block the import of USMT 4.0 if it does not include the Office 2010 hotfix.

Mirage DMZ edge gateway

The ability to connect external / roaming users to Mirage without VPN was request from many clients. While Mirage always supported to work via VPN most users aren’t connect to VPN all the time. Therefore Mirage 4.4 introduces the Mirage gateway. The Mirage gateway is a hardend Windows service which normally will be deployed in a DMZ and is made available over the internet. This allows the Mirage client to securely connect (SSL is a requirement) to the internal Mirage infrastructure, tunnel through the Mirage gateway, if the machine is successfully authenticated. The authentication is done by the user itself when the Mirage client connects to the Edge gateway the first time. When the username and password is validated a is token created and stored for future authentications. It is possible to set a time-out for the token so a re-authentication, to make sure the device is still allowed to connect to Mirage, would be required. A Mirage edge gateway supports up to 1000 end points per server and multiple edge gateways can be deployed.

One thing to mention is that the Mirage gateway allows features like file restore, layer management and centralisation to work for distributed users. But operations which require the end point itself to communicate with the Active directory, for example full system restores of domain joined computer or Windows migrations, are not supported using the gateway because it only tunnels Mirage specific traffic and nothing more.

Support for updating Horizon View agents via Mirage (app) layers

Following the support of managing full clone persistent desktops in Mirage 4.3 the newest release of Mirage now supports updating Horizon View agents from version 5.3 to future releases. As you can see the integration of View and Mirage proceeds further and makes managing persistent desktops much easier. The ability to do Horizon View agents upgrade via Mirage application or base layers makes migrations to newer View releases much easier as all persistent desktops can update using as simple 2-step process.

  1. Create an updated app or base layer containing a future View agent release
  2. Deploy the layer to all clients and after a reboot the update is done

Additionally, no 3rd party tools are required to manage full clone persistent desktops.

Do Windows migrations without centralising the end point

In Mirage 4.3 the ability to do layer management only was introduced. This allowed you to deploy application and base layers to desktops without centralising them. This way you can do central image management for all your end points without using Mirage backup / disaster recovery functionalities. In Mirage 4.4 this function was enhanced to support Windows 7 migrations without the need to centralising the client first.

While you will lose the possibility to revert your desktop to your old Windows version in the case something goes wrong the storage requirements are much less. Therefore the most complex part (storage) of a Mirage infrastructure design is no longer needed. You just need a small amount of storage to hold your base and application layers, drivers and USMT.

Enhancements to the file portal and web management

The most prominent change to the Mirage file portal and the web management is the requirement of a SSL certificate. Access to both services is now only possible through a HTTPS connection. This decision was made to protect user (and admin) credentials and data accessed using both portals. So please make sure when you upgrade to version 4.4 to have a SSL certificate ready to use on your IIS hosting the file portal and web management.

The file portal was enhanced to allow users to allow multiple file portal at once.

Mirage44FilePortalMultiSelect

The web management  got some minor face lifting and also a new mass centralisation functionality which allows you to centralise many clients at once by simply selecting them or applying a rule.  The mass centralisation functionality can be access by clicking the “pending devices” tile on the dashboard.

Mirage44WebMgmtMassCentralization

Better client identification

Last but not least in Mirage 4.4 the client identification was enhanced. In prior version of Mirage the client was identified by using the clients UUID and BIOS identifier. Unfortunately sometimes, when these value were not available or could not be read, Mirage misbehaved. To solve this issue all clients are now identified not only by the UUID and BIOS identifier but also using a attribute, an auto-generated GUID.

Release notes, documentation and download

Using the buttons below you find direct access to the VMware Horizon Mirage 4.4 release notes, the documentation and the download (requires a MyVMware account). With Mirage 4.4 also a nice new VMware Horizon Mirage Getting Started Guide (PDF direct link) is released.

I hope you enjoy this release as much as I do and if you have any comments or questions just leave them below.

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

Network adapter disappears when migrating a virtual machine from Windows XP to Windows 7

One of the key Horizon Mirage’s use cases is the migration from Windows XP to Windows 7. Testing and optimizing the migration process using physical PCs and notebooks can be cumbersome so you may want use virtual machines for this task.

VMware ESXi, Workstation and Fusion are emulating different hardware (network adapter, disk controller) for virtual machines based on the operating system. As you can see in the picture below a standard Windows XP VM does have other hardware than a Windows 7 virtual machine.

VMHardwareXPvs7

Windows XP is using the “Flexibel” network adapter by default while a Windows 7 VM is using the “E1000” adapter.  Now, if you deployed your VM using the default settings and you try to migrate from Windows XP to Windows 7 your virtual machine ends up having no network adapter.

Normally Mirage is capable migrating Windows across different hardware platforms and thanks to the driver layer it is even possible to inject new drivers during the migration process. In this case it is unfortunately not a missing driver but rather an incompatibility between Windows 7 and the “Flexibel” network adapter which causes the problem.

To fix this problem and getting the migration process to work is pretty straight forward. Just choose a network adapter which is compatible with Windows XP and Windows 7. The following network adapters will work on both operating systems:

  • VMXNET3
  • E1000

For each of this adapter you have to consider one additional step.

VMXNET3

When using the VMXNET3 adapter the VMware Tools have to be installed on your Windows XP VM and your Windows 7 base layer you want to test.

E1000

Unfortunately Windows XP doesn’t include drivers for the E1000 out of the box. You have to download the driver from Intel and install them inside your VM.

On a Windows XP Professional 32-bit guest, the e1000 NIC driver is not automatically available even though the e1000 vNIC is supported
The e1000 vNIC is supported and can be selected for the Windows XP Professional 32-bit guest. However, Microsoft does not provide the e1000 driver with the Windows XP 32-bit releases. The driver must be downloaded separately.
Source: http://kb.vmware.com/kb/1016456

When installing the driver on Windows XP you only need to install the driver itself. You don’t need to install the Device Manager or Advanced Network Services feature.

E1000DriverWinXP

After choosing the right network adapter migrating virtual machines from Windows XP to Windows 7 using Horizon Mirage works like a charme. This guide should also work with 64-bit versions of Windows, but I haven’t tested it yet.

Sources: VMware, VMware (2)

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.