1. 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.
2. Ports Used by the Mirage System
The following table summarizes the default communication ports and protocols used by Mirage System and Clients: Component Communication Port Protocol Notes:
|Mirage Server Service External
|TCP/IP or SSL/TLS The only port required for communications between Mirage Clients and Mirage Servers. Note: SSL/TLS is optional and can be enabled as described in Configuring the Secure Sockets Layer (SSL/TLS).
|Branch Reflector External
|TCP/IP Used for communication between the Branch Reflector and the local peers at the remote site.
|Mirage Management Service External
||TCP/IP Used for communication between Mirage Management Console and Mirage Management service. SOAP Message-level Security applied.
|Mirage Server Service Internal
||TCP/IP Used for control communication between the Mirage Management Service and the Mirage server. Note: You may limit access to this port to incoming connections from the Mirage Management Service host.
|File Portal Internal
||TCP/IP Used for communication between the IIS server and the Mirage Management Server. External communications is used for communications between the Mirage Management Server and Mirage Servers with the Mirage Clients or Management Console. Internal communications is used for communications between Mirage Management Server and the Mirage Servers. Note: You can configure different ports to be used as part of the SSL configuration CLI command as described in the previous section, or by modifying the Mirage Server and Management services configuration files if SSL is not used. Consult with VMware Support for further instructions.
3. Using the Hardware Migration Wizard
When reassigning a CVD to a new device, Mirage checks for drive letter compatibility between the endpoint and the CVD in the data center. If the CVD and the new endpoint have the same drive letters, Mirage displays a confirmation message that includes the drive letters and the disk numbers. If the CVD has different drive letters than the new endpoint, Mirage does not allow the restore operation to proceed.
It is important to do a “Sync Now” option on the endpoint before migrating it to a new machine. This ensures that all data is saved to the data center before the
migration takes place.
4. Mirage Boot USB Keys
To help assist customers with recovery operations and system imaging VMware has developed a way to create bootable USB media. Once created, VMware’s Boot USB contains a clean install of Windows 7 (Professional or Enterprise Edition). The Horizon Mirage client is installed and is pre-configured to connect to your Horizon Mirage Server when the machine boots. The Mirage Boot USB Key can be customized to accommodate a variety of different hardware platforms and additional pre- and post-Windows installation actions (which may include joining the new system to the desired domain, renaming the system, and so on). The most common usage scenarios are as follows:
Restoring a device which can no longer boot into Windows.
Restoring or reimaging a remote device out in the field.
Provisioning/Imaging a fresh Windows installation on an existing machine quickly.
Deploying the Windows image with the Mirage Boot USB Key takes between 15 to 30 minutes (on average).
The following prerequisites are required:
A Windows 7 (Professional or Enterprise Edition) machine.
Note: This is represented as Drive C through-out this guide.
The Mirage Boot USB Scripts (provided by VMware).
A Windows 7 (Professional or Enterprise Edition) DVD or ISO file.
Note: This is represented as Drive D throughout this guide.
An 8 Gigabyte USB Drive
Note: This is represented as Drive U throughout this guide.
A Mirage Client MSI installer file (x86 or x64 version).
Note: This file is renamed later in this guide.
4.2. Creating the Mirage Boot USB Key
To create the bootable USB disk, drive letter “U” must be available (the creation scripts currently do not warn you if it is already in use).
The entire USB drive that you use is formatted during this process!
➣ To create the Mirage Boot USB key:
- Copy the BootUSB folder into the C:\ root. Do not modify the file structure or add sub-directories. (The BootUSB folder contains the Mirage Boot USB Scripts. It is obtained from VMware.)
- In the C:\BootUSB\MirageClient subdirectory, rename the required Mirage client .msi file according to the type of key you are building:
For a 64-bit installation of Windows 7, rename the MirageClient.x64.34651.msi file to MirageClient.msi.
For a 32-bit installation of Windows 7, rename the MirageClient.x86.34651.msi file to MirageClient.msi.
- Find any hardware drivers you need for the new hardware and copy them into the C:\BootUSB\Drivers folder.
- Insert the Windows 7 Pro DVD into your DVD Drive. Alternatively, you can mount your Windows 7 ISO file (this speeds up boot USB key creation).
- Insert the USB Key and wait until Plug and Play detection completes.
- Run a Command Prompt window as an Administrator and type cd C:\BootUSB and press <Enter>.
- Type win7usb.cmd and press <Enter>. A list of the available disks and their disk number are displayed. Look for the disk number of your USB drive (which you can identify by the size value):
8. Run the complete command as follows:
win7usb.cmd [win7 dvd path\iso mount point] [msi path] [server ip] [ssl] [usb disk number]
a. [win7 dvd path\iso mount point] is the path to the Windows 7 DVD or ISO file.
b. [msi path] is the path of a Mirage client msi path.
c. [server ip] is the IP address for your Mirage server which any client devices connect to.
d. [SSL] is whether or not this client connects using SSL (Use true or false).
Note: the Mirage Server must already be configured for SSL for this to be turned on!
e. [usb disk number] is the number of the USB disk to format a list of connected disk numbers will be displayed upon invocation.
Each customer’s exact string is different. For example, this is a typical string assuming that the Windows 7 DVD is in the D: drive, the Mirage client has been
renamed (step 3), the IP of the Mirage server is 192.168.11.203, SSL is turned off, and the USB Key is listed as disk #2:
C:\BootUSB\MirageClient\MirageClient.msi 192.168.11.203 false 2
9. The USB disk is prepared. When the USB key creation is complete you can customize it in additional ways (for example, have it automatically install
additional software, or embed hardware drivers, and so on). For more information about customizing your USB Key, see the appendices at the end of
4.3. Using the Mirage Boot USB Key
Note: Do not unplug the USB disk until this process is fully completed and you have Windows and Mirage installed on your Windows 7 system.
➣ To use the Mirage Boot USB Key
1. Perform a one-time boot from the USB disk by choosing the correct option in the startup menu. For example, most Dell laptops use the F12 key. Windows 7
begins loading (the process is very similar to a clean install of Windows 7).
2. Select the version of Windows that you wish to install (must select a Professional or better edition).
3. Install Windows (prompts may vary based on which version of Windows you are installing and what Windows installations (if any) currently exist on the endpoint).
a. If you are prompted to select a version of Windows, you must select a Professional edition (Mirage does not support Home editions).
b. If you are prompted with an option to choose between an upgrade and custom (advanced), select the Custom (advanced) option.
c. When you select a partition to install the new copy of Windows onto, it is up to you if you want to format that partition or not.
Note: VMware software does not modify any existing partition tables.
d. As Windows installs, the target machine reboots several times to complete the Windows install. This is normal.
4. Once the installation is complete you are prompted to login. Use the following login information:
The default user is TEST and the password is: password
The default Administrator password is: passwd1!
Note: You can change these passwords by editing the account values in the autounattend.xml file found on the USB Key.
5. Once you login for the first time, the target machine may install the PnP (Plug and Play) Drivers. It may require an additional reboot after this process
completes and this reboot should happen automatically.
4.4. Customizing your Boot USB Key
Once the Boot USB has been created you can customize and configure it to suit your site or location. There are a number of files on the Boot USB Key that you can use to modify without having to rebuild your Boot USB Key in the process. These files are all found on the root of the built USB Key (unless specified otherwise).
- InstallClient.cmd. This file controls the command that runs the Mirage installer. You can modify the commands here, including the server Mirage connects to, using SSL or not, and any MSI switches you wish to use during installation.
- SetupComplete.cmd. This batch file is invoked automatically when Windows 7 deployment is completed. You can add additional commands to this file as needed (install VPN client, for example). The file is located in:
- MirageClient.msi. The Mirage client that is installed on the new Windows 7 machine. You can change which Mirage Client is on your Boot USB Key.
Remember to rename it to MirageClient.msi when you copy it to the root of the created Boot USB Key.
- Autounattend.xml. An answer file for the unattended Windows 7 installation that you can edit to customize the deployed Windows 7 installation.
4.5. Adding Drivers to your existing Mirage Boot USB Key
It may be necessary to add additional drivers to the Mirage Boot USB Key depending on what hardware you’ll be using. To do this, you do not need to rebuild your entire Mirage Boot USB Key. You only need to locate the Drivers folder on the USB Key and copy any new drivers into that directory. The next time you use the USB Key on a replacement system all the drivers in this folder are copied over to the device and used for potential plug and play driver installations.
4.6 Known Limitations
The Windows 7 installation is not activated and does not include a product key. Windows 7 allows working with a non-activated machine for a few days. This limitation can be worked around by editing the autounattend.xml file. It is known that some antivirus products (for example, Trend Micro) prevent the
copying of “autorun.inf” to removable disks. As the process of creating a bootable USB disk requires the copying of such a file, it is necessary to disable
Trend Micro while creating the USB disk using this utility. If you try to install Mirage with a SSL Mirage server, the newly deployed machine
cannot connect to the server if it is not yet a member of the domain. In this case, you should add a custom action on the USB disk to add the machine to the