Horizon Flux

Install Horizon Mirage prerequisites via PowerShell

For the installation of the Mirage server components some specific Windows features are needed.

For the Mirage server, the the management server and the management console Microsoft .NET Framework 3.5 SP1 is needed. The installation of this feature can be accomplished via the Server Manager or via PowerShell.

To install .NET Framwork via PowerShell just start PowerShell as an administrator and then run the following two commands:

Import-Module ServerManager
Add-WindowsFeature NET-Framework-Core

To install the Mirage File Portal (WebAccess) also requires .NET Framework 3.5 SP1 but additionally it requires the Microsoft Internet Information Service (IIS) with some additional components like the IIS 6 Management Compatibilit feature.

Source: http://www.vmware.com/pdf/mirage-administrators-guide-4.pdf, Page 44

To install these features through the Server Manager can be a bit cumbersome and using the following PowerShell commands to install IIS and all the features required by the Mirage File Portal is much easier.

Import-Module ServerManager
Add-WindowsFeature Web-Static-Content, Web-Default-Doc, Web-Dir-Browsing, Web-Http-Errors, Web-Asp-Net, Web-Net-Ext, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Filtering, Web-Mgmt-Console, Web-Scripting-Tools, Web-Mgmt-Service, Web-Metabase, Web-WMI, Web-Lgcy-Scripting, Web-Lgcy-Mgmt-Console

If you haven’t installed .NET Framework before installing IIS just add the NET-Framework-Core at the end of the Add-WindowsFeature command for the IIS feature installation (and don’t forget to add a comma after Web-Lgcy-Mgmt-Console).

Mirage application layering 4.0 vs. ThinApp 4.7 – the differences

With Horizon Mirage application layering and ThinApp VMware has now two options to deploy applications to endpoints. The big difference between both products is that ThinApp is an application virtualization solution and Mirage Application Layering is not.

While this is the main difference there are still many, many differences between both products in terms of functionality and deployment options. In the following table I tried summarizes most of the differences.

Functionality / Product	Mirage application layering 4.0	ThinApp 4.7
Application isolation (running multiple version of the same application, prevent DLL conflicts, etc.)	No	Yes
OS independency (possibility to build a package on another OS version than it runs on)	No	Yes
Run different versions of the same application	No, only if application supports this natively.	Yes
Supports Internet Explorer virtualization / running multiple Version of IE	No	Yes
Supports application with (kernel) drivers	Yes	No
Supports applications with native shell extensions	Yes	No
Support for 64-bit applications	Yes	No
Require agent on the end point	Yes	No
Requires additional components on the end point	Yes, Microsoft .NET Framework 3.5	No
Endpoint is required to be managed by Mirage	Yes	No
Optimized deployment method for WAN environments	Yes, dedupe, compression and so on	No
Methods to deploy application updates	Yes, create new applayer with newest application build.	Yes, multiple options.
Change application after capturing	No	Yes
Deploy updates without user interruption	Yes	Yes
Application updates need reboot	Yes	No, but you need to restart the application for the update to be applied
Optimized deployment method for applicaliton updates for WAN environments	Yes, dedupe, compression and so on	Yes, when using AppSync (only block level delta are transfered)
Easy application rollback	Yes	Yes, but depends on the used update method
Easy application break fix	Yes	Yes, delete sandbox
User-based application deployment	No	Yes
Machine-based applicaton deployment	Yes	Yes
Restrict application access based on Active Directory groups	No	Yes
Sandboxes user settings	No	Yes
Run scripts on application start and stop?	No	Yes
Run script after application is deployed on the system?	Yes	No

This table only compares Mirage application layer version 4.0 and ThinApp version 4.7.x.

I hope this table may give you a better understanding on the differences between both products. If you found another point in which these products work or behave different you’re welcome to post a comment and I will update the table with your feedback.

If you want to learn more about Mirage application layering and ThinApp and how they compare please vote for our VMworld US 2013 session: 4863 Dare to compare: Mirage application layering and ThinApp

Vote now! VMworld US 2013 public voting has begun!

The public voting for the VMworld sessions started yesterday. There are many really good sessions in the voting and you should really have look and take the opportunity to vote for the sessions you want to see.

Christoph from thatsmyview.net and I submitted a few sessions and we are really glad that all of them are now online. If you want to learn about Horizon Mirage, Workspace, View and ThinApp it would be great if you vote for us.

Here is an overview of our sessions:

4836 Managing Windows desktops is like playing with Lego (Disclaimer: But only if using Horizon Mirage and ThinApp)
Everyone loves the simple approach of Lego in terms of inventing and building new things. Just throw some Lego bricks together and build something completely new. And when you have a new idea you can simply build something completely different again. Wouldn’t it be nice if we could build Windows desktops as easy as building something with Lego? With VMware Horizon Mirage and ThinApp you can do exactly this. Just think about all these different components like drivers, operating system, applications, anti virus as different bricks which can be combined in every possible way you can imagine. We show you how you can accomplish this using Horizon Mirage and ThinApp.

4863 Dare to compare: Mirage application layering and ThinApp
This session compares Mirage application layering and ThinApp. We will start by examine how each of the products work and how they compare. We will discuss pros and cons of each product and show how we can offer the best of both worlds by combining them. As conclusion we will show different use cases and explain which product will the best fit.

4901 Horizon Suite and ThinApp – the perfect match
ThinApp is now an integral part of the Horizon Suite. It brings new functionalities and advantages to each product (i.e. Mirage, Workspace and View) included in the Horizon Suite.. Do you want to know how you can track the usage of your ThinApp packages? Or maybe you always wanted to use ThinApp in your branch offices but until now it was a hassle to deploy those packages to your branch office users? VMware Horizon View, Mirage and Workspace in combination with ThinApp can help you with that. Attend this session if you want to learn what this new match made in heaven has to offer and which benefits each of the products gains.

4960 Things you never thought were possible with ThinApp
Using ThinApp is a breeze, but did you ever wonder how you could do X or Y with ThinApp? Or did it seem impossible to do some specific task with ThinApp out-of-the-box? And what about the those features the other vendors promise but ThinApp allegedly doesn’t offer? We tell you some neat things you can do with ThinApp you never thought were possible. Stuff like:

Deploying delta updates using AppLink
Native shell integration with virtual packages
Check for prerequisites before running a package

Join our session to see how highly customizable and easily extendable ThinApp is.

Link to the voting: https://vmworld2013.activeevents.com/scheduler/publicVoting.do

Deploy ThinApp packages via Horizon Mirage

With the release of the new Horizon Suite, Workspace and the new version of Mirage ThinApp is now included in each and every one of these products. To be able to use ThinApp as part of Mirage is very helpful and you can do some nice things which wasn’t very easy to do with ThinApp in the past, for example deploy ThinApp packages to branch office. But ThinApp also brings all the benefits of application virtualization to Mirage’s application layering.

I talked about Mirage’s application layering in my last blog post so if I want to understand the basics of Mirage’s application layer I would recommend to read the article first. In this article I am going to show some options to deploy ThinApp packages thru application layering.

Using MSI

The easiest way to deploy ThinApp with Mirage is to create a MSI installer for your ThinApp package. Just remove the semicolon from the MSIFileName and MSIDefaultInstallAllUsers parameter in the package.ini and then rebuild your package. It is crucial that MSIDefaultInstallAllUsers is enabled and set to 1 if you want to deploy a ThinApp package using Mirage’s app layering. Mirage only records changes to the system and not changes made to a specific user profile during the application layer capturing process. Therefore you must enable the MSI package to install itself for all users and not only for a specific user.

Now you can create a new application layer like you would do it with a normal installation but instead of installing a native application you install your ThinApp MSI package. As you can see in the screenshot below the Mirage application capture process detects the application as it would be installed natively.

To update an application layer to a newer version of your ThinApp package you simply have to create a new layer and install your new ThinApp MSI into it. If you want your users settings to persist make sure both versions of your ThinApp package inside the application layer use the same sandbox name and location. If this isn’t the case all user settings are lost (they are not really lost but your new ThinApp package does not acces the old sandbox/settings) after you deploy the updated application layer.

Using thinreg.exe

Instead of installing a ThinApp MSI package during the application layer recording process you can also use thinreg.exe to deploy your application into the layer. This is done in two simple steps:

Copy your ThinApp package to a location on the reference machine
Run thinreg.exe /allusers to register the package on the reference machine

Example: If you want to deploy your VLC ThinApp package using thinreg.exe you first have to copy your VLC.exe ThinApp package to C:\ThinApp\VLC.exe and then run thinreg.exe /allusers C:\ThinApp\VLC.exe.

When using thinreg.exe make sure you specify the /allusers parameter for the same reasons you have to enable the MSI all user installation. Also make sure you don’t have the argument /noarp specified. This prevents the ThinApp package to be registered under Add/Remove Programs (Windows XP) or Programs and Features (Windows 7) and therefore from being detected by the application layering recording wizard.

To update your ThinApp package you have to follow the same procedure as when updating a layer created with an ThinApp MSI package. Just create a new layer using the two steps described above and make sure you packages are using the same sandbox name and location.

Using ThinApp out of the box deployment methods

Of course you can still use all of ThinApp out of the box deployment methods like placing ThinApp packages on a network share and then apply thinreg.exe. Or you could use Mirage deploy the first ThinApp package and then use AppSync.

Summary

Creating a Mirage application layer to deploy ThinApp packages is pretty straight forward. You just have to make sure everything is installed in the machine context (all users) and not for a specific user. When deploying ThinApp packages using Mirage you will gain great benefits when deploying ThinApp packages to branch offices as all the Mirage file- and block-level deduplication is also applied to application layers with ThinApp packages inside. Also when deploying ThinApps thru Mirage you still have most of the benefits an application virtualization solution brings to the table, e.g. isolation, portability and consolidation.

The only downside of deploying ThinApp packages with Mirage’s application layering technique today is that the user has to restart the computer for the new application layer to be applied. But while there are definitely use cases (remote and branch offices, mobile worker) to deploy ThinApp packages using Mirage application layers you still can use all the usual ThinApp deployment methods in combination with Mirage.

How does Horizon Mirage 4.0 application layering work?

With the release of Horizon Mirage 4.0 a new feature called application layering was introduced. This features enables Mirage administrators to deploy applications independent from the base layer.

Horizon Mirage Layers explained

If you want to learn more about the basic layering concept behind Mirage you should have a look at following article: Horizon Mirage Layers explained.

In this article I will focus on the application layering itself and explain how to create and update application layers. Creating and updating application layers is done in four simple steps:

I will cover these steps later, but first some general things you need to know about the Mirage app layering technique. App layering in Mirage works very different from the most application virtualization products. With app layering an application doesn’t get virtualized and therefore not decoupled from the operating system. This means applications aren’t isolated from each other and they aren’t portable as they depend on the underlying operating system.

But because Mirage doesn’t virtualize applications it can do some stuff using application layers which don’t work with application virtualization products. For example Mirage can deploy applications which depend on drivers (i.e. PDF creators or hand scanner software) and it can also deploy applications which integrate deeply into the OS (i.e. services, shell extensions).

All this is possible because, as already said, applications inside an app layer aren’t virtualized. Instead you can imagine an application layer as nothing more than a bunch of registry keys and files. If an app layer is assigned these registry keys and files are transfered (of course with all the fancy block- and file-level deduplication Mirage offers) to the client system and merged into the native system. As Mirage knows exactly whats contained in the application layer and in the base layer you can also remove an application layer as easily it was assigned before. The Mirage client then just removes all the content contained in the app layer from the native system.

Based on this fact you need to keep in mind that it is only possible to deploy application layers to a device which is fully managed by Mirage. This means it has to have a base layer deployed. Also the base layer has to contain the same operating system the application was recorded on. If you created an application layer on Windows 7 you can only deploy this to a client which runs Windows 7. Also the bitness of the operating system has to be the same. You can not deploy a layer captured on Windows 7 32-bit to a Windows 7 64-bit and vice versa.

The last thing you need to know, before we actually capture and update an app layer is that application layers are merged in sequential order. This means if you have two or more layer which contain for example an DLL file with the same name on the same location but in different versions, the DLL from the last layer applied wins.

As you can see in the diagram above the layer called “AppLayer 3″ was applied at last and therefore the “Horizon.dll v3″ and the “App.dll v2″ are overwriting the other versions. This is the case because the applications aren’t isolated from each other.

Prepare a reference machine

Preparing a reference machine for recording a Mirage application layer doesn’t really differ when compared to preparing a machine used for software repackaging or capturing ThinApp packages. All you need is a system, I recommend to use a virtual machine, which contains the same operating system as the base layer you later want to deploy the app layer to.

For example if you have two base layers deployed one with Windows 7 32-bit and one with Windows XP you need two reference machines. But you don’t need different reference machines if you have for example Windows XP SP2 and SP3.

Also you want to make sure that your reference machine is as clean as possible:

No anti-virus, malware or personal firewall installed
No additional software (*)
No Windows update or auto-updating in general

(*) Obviously if you want to package an application which depends on another application you need to have the application your app depends on installed in the reference machine. Let’s say I package an application which needs Office 2010 which is integrated in by base layer then I need to install Office 2010 into my reference machine before I start the recording process. I highly suggest to create a snapshot before the installation of the prerequisites as you then can easily go back to your clean machine state.

That said after you made all the configuration and optimization needed on your reference machine you have to install the Mirage client on it. When this is done you can shut down the machine and take a snapshot labeled ”clean state” or something similar. It is crucial to take this snapshot as it enables you to reuse the virtual machine to capture another app layer.

How to create an app layer

The process of creating an app layer is pretty straight forward. I will not cover this in a step by step manner as this already done as part of the official documentation. I will however talk about some things which are good to know respectively some gotchas everyone should be aware of.

Official VMware Horizon Mirage Documentation

VMware Horizon Mirage Administration Guide
The purpose of this document is to guide System Administrators through the installation and deployment of VMware® Horizon MirageTM.

Source: http://www.vmware.com/pdf/mirage-administrators-guide-4.pdf

VMware Horizon Mirage Application Layers Guidelines
This guide describes the VMware® Horizon Mirage™ application layer concept and provides guidelines to ensure successful application layer creation.

Source: http://www.vmware.com/pdf/mirage-app-layer-capture-guidelines-4.pdf

Before starting the capturing process make sure you’re reference machine contains everything you need (preinstalled software, installer, license files, etc.). I personally copy everything over to C:\temp and use a specific upload policy for my reference machines which excludes this directory.

When you are finished prepping your machine start the capture process by using the “Capture App Layer” wizard. When the wizard is finished initializing the app layer recording you can start installing your application. In this step it is crucial that you install and configure everything the way you want. You will not be able to edit your application layer after you finished recording.

It is also worth mentioning that the recording process only captures changes made to the machine and discards everything which is specific to a user. So you are not able to preconfigure an application if this data is saved in the user profile, for example %AppData% or HKCU.

Example: if you create a Mozilla Firefox app layer and you configure a different start page this setting isn’t retained in the application layer as Firefox saves all its settings under %AppData%\Mozilla.

Once you finished the capture process your new application layer in ready to be assigned to a managed device. Keep in mind you can only assign an app layer to a managed device which uses the same operating system the application layer was capture on.

How to update an app layer

Let me say this first, there is no way to update the content of an application layer. As already said you can not modify an application layer once the recording is completed.

When you want to update an application layer you have rerecord the particular layer. So if you want to update your Mozilla Firefox 18.0.1 application layer to Mozilla Firefox 19.0.2 for example you basically have to record a new application layer with the newer Firefox version.

The difference between creating a new application layer and updating an app layer is how it is saved. While a new application layer gets a new name an updated layer is saved under the name of an existing layer and only the version number is incremented. This allows an administrator to easily push this update to all clients which already had assigned this app layer.

With the exception of this point there is really no technical difference between creating and updating an application layer. Therefore the same rules apply.

Post-app layer deployment script

There is one neat little function when deploying an application layer. It is possible to launch a script after an application layer is deployed. This may come in handy when you want to deploy a device specific license or copy the newest configuration file to the local machine after the layer is deployed.

To apply a post-app layer script you have to save the script during the capture process in %ProgramData%\Wanova\Mirage Service. The script needs to have .bat as file extension and also it requires a unique name. I would recommend a name like “post_layer_update_appname_appversion_layerversion.bat”. Of course you can use this script only as bootstrap for another script (e.g. PowerShell, VBScript, etc.).

After an application layer is deployed the Mirage client checks if a script is available and then executes it.

Summary

With Mirage 4.0 VMware released the first version of the powerful application layering feature. While some things definitely need some work (e.g. update process) application layering works really well and is definitely worth a try. You just have to keep the following things in mind:

Application layering is not application virtualization
Application layering supports applications which depend on drivers and integrate deeply into the OS (i.e. services, shell extensions).
Application layers can only be deployed to Mirage clients which have a base layer deployed
Application layers depend on the operating system and therefore can only be deployed to the same operating system they were captured on
Application layers are applied sequentially
An application layer does not contain any user specific settings
Application layers can’t be edited after the recording process
Updating an application layer is the same as creating a new application layer

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:

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:

To 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.

Source 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

Release: VMware Horizon View 5.2 Feature Pack 1 including HTML Access and Unity Touch

One the release day of VMware Horizon View 5.2 may asked for the long awaited HTML desktop access feature. The wait is over and the Feature Pack is now available to download!

Horizon View 5.2 Feature Pack 1 provides the following features and components:

Remote Experience Agent installer - The Remote Experience Agent installs Feature Pack components on Horizon View desktops, enhancing the remote desktop experience provided by View Agent 5.2. In Feature Pack 1, the installation program installs Unity Touch and the HTML Access Agent on Horizon View desktops. Both components are installed by default when you run the installer.

HTML Access Agent - HTML Access allows users to connect to virtual desktops from their Web browsers without having to install Horizon View Client software on their client systems. The HTML Access Agent, which runs on Horizon View desktops, is the component that enables users to use HTML Access to connect to their desktops. You must install the Remote Experience Agent with the HTML Access Agent on the desktops that you want to be accessed via HTML Access.

Unity Touch - Unity Touch enhances the way that mobile client users access a desktop. Instead of trying to manipulate a full desktop image on a small device screen, users can browse between apps and documents in a native mobile user interface without seeing the desktop. The VMware Horizon View Client documents for mobile devices provide more information about end user features provided by Unity Touch.

HTML Access installer - This installer configures View Connection Server instances to allow users to select HTML Access to connect to desktops. After you run the HTML Access installer, the View Portal displays an HTML Access icon in addition to the View Client icon.
You must run this installer if you want to use HTML Access to connect to desktops in a Horizon View deployment. Running this installer is also required if your users go through Horizon Workspace and select HTML Access to connect to desktops.

Source: https://www.vmware.com/support/view52/doc/horizon-view-52-feature-pack-1-release-notes.html

To use the Unity Touch feature you need to install the latest Horizon View clients for iOS, Android and Kindle which are already available in their respective app stores.

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.

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.

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.

Source VMware VMware

Does ThinApp run on Windows RT?

The short answer: No, ThinApp doesn’t work on Windows RT.

The long answer: It depends on the version of Windows the particular tablet is running.

Source: http://www.microsoft.com/en-us/news/ImageDetail.aspx?id=B763681267E9CED7F6D7E962E9306C02A1106B80

The Microsoft Surface RT or Windows tablets like the Dell XPS 10, Lenovo Yoga 11 are sporting Microsoft’s new operating system called Windows RT. While Windows RT seems to be very similar to Windows 8 it isn’t. In fact Windows RT is specially developed to run on mobile platforms and therefore is using a completely different architecture called ARM. ThinApp doesn’t work on this platform.

On the other hand there are tablets running Windows 8 like Microsoft Surface Pro, Dell Latitude 10 or the HP ElitePad 900. These tablets are running a full blown version of Windows 8. This is possible as all these tablets are based on the Intel x86 platform. As this platform isn’t different from any installation of Windows 8 on a classical desktop PC and ThinApp officially supports Windows 8, ThinApp will just run fine on these tablets.

Why does ThinApp doesn’t work on Windows RT?

Both platforms are using different instructions sets and therefore application code may be interpreted different on each platform. While it would be possible to port x86 applications to the ARM platform by optimizing the code so that it behave the same on each platform this isn’t the cause why ThinApp does not work on Windows RT.

The problem with Windows RT is that Microsoft only supports a subset of the Win32 API on this platform and most of the Windows applications out there relying on this API, ThinApp does too. Also Microsoft doesn’t support porting x86 desktops apps to Windows RT.

Metro style apps in the Windows Store can support both WOA and Windows 8 on x86/64. Developers wishing to target WOA do so by writing applications for the WinRT (Windows APIs for building Metro style apps) using the new Visual Studio 11 tools in a variety of languages, including C#/VB/XAML and Jscript/ HTML5. Native code targeting WinRT is also supported using C and C++, which can be targeted across architectures and distributed through the Windows Store. WOA does not support running, emulating, or porting existing x86/64 desktop apps. Code that uses only system or OS services from WinRT can be used within an app and distributed through the Windows Store for both WOA and x86/64. Consumers obtain all software, including device drivers, through the Windows Store and Microsoft Update or Windows Update.

Source: http://blogs.msdn.com/b/b8/archive/2012/02/09/building-windows-for-the-arm-processor-architecture.aspx

Thats the cause why ThinApp isn’t supported and will not work on Windows RT and probably never will. Even if ThinApp would work on Windows RT most of the applications you want to virtualize wouldn’t work, as these applications simply don’t work on Windows RT. They have the same problems ThinApp has, the lack of Win 32 API functionality and support on part of Microsoft.

Page 1 of 312 3 »