VCP7-DTM Learning Concept Part 3 – Mirage

I recall when I first saw Mirage a few years ago. I had a hard time wrapping my head around it. It hasn’t exactly been a popular tool since, which hasn’t helped with folks understanding what it is. At the time I saw it as a bit of a software distribution tool. However, in effect, it is actually more of a backup tool that can restore various points in time to endpoints.

Let’s start with a high-level overview of what Mirage does. First of all, the agent can be installed on physical or virtual machines. On the virtual side, it cannot be used with Floating Pools, Linked Clones, or Instant Clones. Rather, it can only be used with Full cloned desktops. On the management side, the concept of layers is used within Mirage. A layer is almost like a snapshot or the differences between two points in time. This concept will become clearer once we go through the workflow.

Note that this isn’t written to be a tutorial on how to use the tool. Instead, this is geared more towards understanding what Mirage is and how it operates.

WORKFLOW

I mentioned the term “layers” above. A layer is basically a collection of changed bits. Think of it as starting a capture at point A, making changes, and stopping at point B. The Mirage agent will keep track of all changes made between those two points (e.g. new files, registry changes, etc.). These packages are wrapped up into a layer, which can then be deployed elsewhere.

To start things off, a Mirage agent needs to be installed on whatever machines you want to use it with. At that point, you’ll need to create a base layer. Generally speaking, you’ll want this base layer to include things like drivers and other system-level software (e.g. VPN software, antivirus, etc.). This base layer is captured into what is referred to as a CVD – Centralized Virtual Desktop. The CVD represents the “authoritative” contents.

After this, you can start capturing individual application layers. This is where you will do things like install Microsoft Office, change wallpapers, etc.. You’ll want to make sure that there are no pending OS changes prior to starting this. Things like OS updates can really wreak havoc during the application process. In fact, you may want to reboot your reference machine prior to starting a capture to ensure there are no lingering changes. The process is essentially you tell Mirage you are going to start a capture, you make the changes, and then you tell it when you are done. While it is performing the capture, it is tracking all the changes made.

BRANCH REFLECTOR

In cases where the endpoints may not be in the same location as the Mirage server, something called a Branch Reflector can be used. Think of this as a proxy for Mirage files. If you have 50 endpoints that you need to push a new layer out to, you may not want to send all 50 over the WAN. Instead, you can utilize a Branch Reflector that is located at the remote site. Using this method, the clients at the remote site will pull their copies down from the Branch Reflector, which is local to them. So instead of sending 50 copies over the WAN, you are only sending one.

Depending on your network setup, this can also be an ideal way to interact with clients which may not be on your corporate network very often.

USE CASES

Some of the common uses cases for Mirage include endpoint backup and software distribution, as mentioned above. However, you could actually use it to perform OS migrations. Because of the way the layers work (it is just a collection of bits), you can use Mirage to push down a different OS. It may not be the most elegant solution though, and you’ll need to consider things like file conflicts.

This can also be useful to get software out to folks who may not be able to connect to the internal VDI infrastructure.

CAVEATS

Because an agent is required to work with Mirage, you won’t be doing any sort of bare metal recoveries. In the event that you need to start from scratch, you would need to do a base OS install somewhere, and then pull down whatever layers you need.

Another interesting gotcha is that you cannot capture an application layer using a machine that was used to capture a base layer. If you are hoping to get by with using one VM to create the various layers, you’ll need to take a snapshot, grab the base layer, revert the snapshot, and then perform the application capture.