11 min read

(For more resources related to this topic, see here.)

What is Horizon Mirage?

Horizon Mirage is a Windows desktop image management solution that centralizes a copy of each desktop image onto the Horizon Mirage Server infrastructure hosted in the datacenter. Apart from copying the image, Horizon Mirage also separates and categorizes it into logical layers. It’s like adding a level of abstraction but without a hypervisor. These layers fall into two categories: those owned and managed by the end user, and those owned and managed by the IT department.

This allows the IT managed layers, such as the operating system, to be independently updated while leaving the end users’ files, profiles, and applications which they have installed all intact. These layers are continuously synchronized with the image in the datacenter, creating either full desktop snapshots or snapshots based on the upload policy applied to that particular device. These snapshots are backed up and ready for recovery or rolled back in case of failure of the endpoint device.

So, the question that I get asked all the time is, “How is this different from VDI, and does that mean I don’t need Horizon View anymore?”

To answer this question there are a couple of points to raise.

Firstly, Horizon Mirage does not require a hypervisor; it’s an image management tool that can manage an image on a physical desktop PC or laptop. In fact, one of the use cases for Mirage is to provide a user with an IT-managed Windows desktop when there is limited connectivity or bandwidth between the datacenter and the local site, or the end user needs to work offline.

The latest version of Horizon Mirage (4.3) launched on 19 November, 2013 also supports a managed image running as a persistent VDI desktop on Horizon View.

To summarize, Horizon Mirage has the following three key areas it will deliver against:

  • Horizon View desktops allowing management of VDI-based desktop images
  • Physical desktop and laptop image management and backup and recovery for Microsoft Windows-based endpoints
  • The Bring Your Own Device (BYOD) feature delivering a virtual Windows desktop machine onto a device running VMware Fusion Professional or VMware Workstation

The following diagram illustrates the three areas of Horizon Mirage integration:

The second and the biggest difference is where the image executes. By that I mean where does that desktop actually run?

In a VDI environment, the desktop runs as a virtual machine centrally on a server in the datacenter—central management and central execution. In a Horizon Mirage deployment, the desktop is a physical endpoint device, and so it runs either natively or on that device—central management and local execution.

The following diagram shows how Horizon Mirage executes locally and Horizon View executes centrally:

Horizon Mirage terminologies and naming conventions

Before we start to describe some of the use cases and how Horizon Mirage works, it’s worth spending five minutes on covering some of the terminologies used.

Endpoint

In this context, an endpoint refers to an end user’s device that is being managed by Mirage; so, in this case, it can either be a Windows desktop PC/laptop or a virtual instance of Windows running inside VMware Workstation or Fusion Professional.

Centralized Virtual Desktop (CVD)

The name CVD is a bit misleading really, because the desktop is not actually a virtual machine in the true sense of a VM running on a hypervisor. It more than likely refers to the level of abstraction used in creating the different layers of a desktop image. A CVD is a centralized copy or backup of a desktop or laptop machine that has been copied onto the Horizon Mirage Server in the datacenter. The CVD comprises the following core components:

  • Base layers
  • Driver profiles
  • User-installed applications
  • Machine states
  • User settings and data
  • Application layers

Collections

A collection is a logical grouping of similar endpoints or CVDs. This could be based on departmental machines, for example, the machines used by the Sales and Marketing departments. Collections can be static or dynamic.

Reference CVD

A reference CVD or reference machine is effectively the centralized copy of the endpoint that you use to build your “gold image” or “master image”. It is used to create your base layers. These base layers are then deployed to a user’s CVD which in turn synchronizes with the endpoint. All of your endpoints will now be running the same base layer, that is, the core operating systems and applications.

Base layer

A base layer is effectively a template from which to build a desktop. By removing any existing identity information, you are able to centrally deploy a base layer to multiple endpoints. A base layer comprises the core operating system, service packs, patches, and any core application. It is captured from a reference CVD.

The best practice is to have as few base layers as possible. The ideal solution is being able to have just one single base layer for all endpoints.

Application layer

An application layer is a feature introduced in Version 4.0 that allows applications to be captured and deployed as separate layers. This allows you to manage and deliver applications independent of the base layer by assigning them to a user’s CVD.

Driver library / driver profile

The driver library is where the Horizon Mirage Server stores the drivers from the different hardware vendors/makes/models of endpoints you have in your environment. The best practice is to download these directly from the vendor’s website or driver DVD.

A driver profile will contain details of all the drivers required for a particular piece of hardware. For example, you may have a driver profile for a Dell Latitude E6400 containing all the relevant drivers for that particular hardware platform.

Managing drivers separately effectively decouples the base layer from the hardware, allowing it to build base layers that are independent of the endpoint hardware. It also means that driver conflicts are prevented when you refresh or migrate users to new or different hardware platforms.

Hardware-specific device drivers are stored in the driver library and correct drivers are automatically applied to endpoints based on a set of rules that you create to match drivers to endpoints.

The driver library can also detect missing or broken drivers on endpoints and fix them; however, it does not upgrade or take other actions on existing healthy drivers.

Single Instance Store (SIS)

The SIS contains the deduplicated data from all the uploaded CVDs, including operating systems, applications, and user files/data. It significantly reduces the storage requirements for CVDs, because it only holds one copy of each unique file.

For example, if you centralize a Windows 7 endpoint which is 100 GB in size, the first upload will be 100 GB. Any subsequent uploads will only store the files that are different; so, in this case, if the second endpoint is also Windows 7, those files that are already stored will not be copied and, instead, pointers to those files will be created. So, in this example, maybe only 200 MB will be copied. The Horizon Mirage Management Server will show you the dedupe ratio for a centralized CVD.

Horizon Mirage use cases

In this section, we are going to cover, at a high level, some of the key use cases for Horizon Mirage. These are reflected in the Horizon Mirage Common Wizards page in the Management Server.

I have broken these down into three categories: manage, migrate, and protect.

Manage

These features and components are all about delivering image management to your endpoint devices.

Endpoint repair

As the user’s desktop is backed up in the datacenter, it’s very easy to replace missing or corrupt files from the backed up image down to the endpoint device. This could be fixing a single file, application, or directory folder, or a complete restore of the endpoint.

For example, a user accidentally deletes the Excel executable file and Excel now fails to load. The IT helpdesk can compare the image in the datacenter with the current state of the endpoint and work out that it’s the Excel.exe file that is missing. This file will now be copied back to the endpoint and Excel is now up and running again.

Single image management

With Horizon Mirage you have the ability to create a layered approach to the operating environment by abstracting operating systems, applications, drivers, user data, and so on. This allows you to manage fewer images; in fact, the idea (in Horizon Mirage-speak) is that you have only one core operating system image or base layer.

To build a complete endpoint, you assign any additional layers to a user’s CVD, for example, assigning an application layer or driver profile. The layers are merged together and then synchronized with the endpoint device. It’s like ordering a pizza. You start with the base, choose your toppings, bake it, and then it gets delivered to you.

Application layering

A new feature in Horizon Mirage is the ability to deliver an application as an individual layer. Application layers can be added to a user’s CVD to create a complete desktop with the correct applications for the user based on their entitlement or the department that they work in.

For those familiar with VMware ThinApp and the capturing process, Horizon Mirage captures an application layer in a similar way; however, Mirage does not build a virtual bubble like ThinApp. A Horizon Mirage application layer natively installs the application onto the endpoint device, so you first need to make sure the application is compatible with the operating system.

Remote office management with Mirage Branch Reflectors

Remote office locations have always been a problem for a traditional VDI solution because connectivity is usually limited or, in some cases, non-existent. So how can you deliver a centralized image with limited connectivity or slow WAN connections?

With the Branch Reflectors you can “nominate” a desktop PC in the remote location to act as an intermediary between the local endpoints and the datacenter.

The local endpoints connect locally to a Branch Reflector rather than the Horizon Mirage Server and, in turn, the Branch Reflector synchronizes with the datacenter, downloading only the differences between the IT-managed layers and the local endpoints. These newly built layers can then be distributed to the local endpoints.

One thing to remember is that this feature does not back up the endpoint devices. It is purely for updating an image and so, for example, is ideal for remotely migrating an operating system.

Migrate

The second category, migrate, covers two migration areas, one for the desktop operating system and the second for hardware refresh projects or migrating between platforms.

Windows XP / Windows Vista to Windows 7

Probably the most important feature of Horizon Mirage today is its ability to migrate operating systems, especially as we are rapidly approaching April 8, 2014 when Windows XP goes end-of-support. By using the layered approach to desktop images, Mirage is able to manage the operating system as a separate layer and can therefore update this layer while leaving the user data, profile, and settings all in place.

The migration process is also less intrusive to the end user because the files are copied in the background, keeping the user downtime to complete the migration to a minimum.

Hardware refresh

Similar to the way that Horizon Mirage can migrate an operating system using a layered approach, it can also manage drivers as a separate layer. This means that Horizon Mirage can also be used if you are refreshing your hardware platform, allowing you to build specific driver profiles to match different hardware models from multiple vendors.

It also means that, if your endpoint device became corrupt, unusable, or was even stolen, you could replace it with something entirely different, yet still use your same image.

Protect

The third and final category is protection. This is something that customers don’t typically deploy for their desktop and laptop estates. It’s usually left to the user to make sure their machine is backed up and protected.

Centralized endpoint backup

By installing the Horizon Mirage Client onto an endpoint, meaning that the endpoint will now be managed by Horizon Mirage, the first thing that happens is that the endpoint is copied to the Horizon Mirage Server in the datacenter in the form of a CVD for that endpoint/user.

In addition to this, Horizon Mirage can create snapshots of the image and create points in time from which to roll back.

Desktop recovery

Backing up desktops is only half the story; you also need to think about restoring. Horizon Mirage offers the option of restoring specific layers, while preserving the remaining layers. You can restore an endpoint to a previous snapshot without overwriting user data. If a computer is stolen, damaged, or lost, you can restore the entire image to a replacement desktop computer or laptop. It doesn’t even need to be the same make and model. Or, you could just select which layers to restore. For example, if a particular application became corrupted, you could just replace that application layer.

In this use case, it doesn’t just apply to the physical machines. You could restore a physical computer to a virtual desktop machine either temporarily or as a permanent migration, maybe as a stepping-stone to deploying a full VDI solution.

Summary

In this article we learned about what Horizon Mirage is and the terminologies used along with the three use case categories: Manage, Migrate, and Protect.

Resources for Article:

Packt

LEAVE A REPLY

Please enter your comment!
Please enter your name here