VMware Mirage 5.1 Release Notes

VMware Mirage 5.1 | 16 September 2014

These release notes cover the following topics:

About VMware Mirage

VMware Mirage offers a unique solution for managing physical or virtual desktops and laptops that combines centralized management for IT and local execution for end users. When Mirage is installed on a Windows PC, it centralizes a complete virtual copy of that end point to the data center and keeps it synchronized. The synchronization includes changes from a user's Windows PC being uploaded to the data center, and changes from IT being downloaded and applied directly to the user's Windows PC. Mirage enables central image management of desktops while still allowing local execution at the user end point.

What's New in Mirage 5.1?

Mirage 5.1 introduces more than 20 new features, enabling you to extend the management of remote and mobile-user devices. Included are the following new features and improvements:

  • IT managers can control the Mirage clients' bandwidth consumption from the Mirage Management console. You can limit bandwidth by subnet or by Active Directory site.
  • Mirage now has an API that currently supports centralization and OS migration use cases. You can use the API to integrate Mirage with third-party systems, such as ticketing or help desk applications. Partners and customers can access and integrate with Mirage data and services.
  • You can now install and configure the Mirage Gateway server by using a self-installed Web configuration portal.
  • IT managers can generate a variety of reports from the Mirage Web Manager console. The reports provide analytics for Mirage operations. You can generate reports on demand, or save report parameters as a template and generate the report according to a specified schedule.
  • You can provision a device with a base layer and app layers using a single wizard.
  • Mirage now includes the VMware Customer Experience Improvement Program (CEIP). When you join CEIP, the CEIP tool collects technical data from the Mirage database and log files, and sends the data to VMware on a daily basis. Before the data is sent to VMware, it is made anonymous and is encrypted in your systems or servers.
  • You can now protect all fixed drives by using the Mirage upload policy.

Known Limitations with Mirage 5.1

The following limitations are known in this Mirage release.

  • Mirage supports up to 1,000,000 files per CVD on 32-bit systems. There are no file limits on 64-bit systems.
  • Local user profiles on a reference machine are deployed only in a base layer when used in Windows 7 migration or base layer provisioning. In image assignment and layer updates, only the default local user profile is deployed. Applications that require the creation and use of local user profiles are not suitable for inclusion in a base layer or an app layer.
  • During the streaming restore process, applications cannot access offline files before the Mirage service has started, which might impact their normal operation. You can extend the minimal restore setup to accommodate these specific applications. For further information, see the VMware Mirage Administrator's Guide.
  • All changes to the CVD on the server (base layer assignment, policy change) only propagate to the client on the next synchronization interval (by default, 1 hour, customizable by policy). Use the Sync Device action from the Mirage Management console or the Sync Now action from the endpoint device to force synchronization.
  • If the account password for a machine has expired after a restore operation, you might not be able to connect to the domain. This is a known issue with Active Directory and backups. See http://support.microsoft.com/kb/175468.
  • Mirage requires the default Windows Shadow Copy Provider 1.0. Use the line: vssadmin list providers command to view the VSS providers installed on the computer.
  • Mirage does not support the Windows Fast User Switching option. You must disable it on the endpoint and reference machines before capturing a base layer.
  • Mirage only uploads and stores the main NTFS stream of a file. All other streams are not uploaded to, or restored from, a CVD.
  • Changes to a .pst file are uploaded from the endpoint into the CVD once a day. To ensure that the .pst file is successfully uploaded to the CVD before you perform a restore operation of a CVD to a new hardware, type zeros in the LastFullUploadTicks value in the registry:
    HKEY_LOCAL_MACHINE\SOFTWARE\Wanova\Mirage Desktop Service\LastFullUploadTicks = 00 00 00 00 00 00 00 00
    and click Sync Now.
  • Mirage does not support applying a base layer to an endpoint that removes or installs Kaspersky antivirus software. See http://kb.vmware.com/kb/2048424 for additional details and a solution.
  • When restoring a CVD that does not have Sophos SafeGuard Encryption installed to a machine that does have SafeGuard installed, the restoring procedure might fail. See http://kb.vmware.com/kb/2081607 for additional details and a solution.
  • If you work with multiple volumes, note the following:
    • Content of non-fixed drives (network maps, volatile devices such as Disk-on-key) is not uploaded to the server.
    • When assigning a base layer or an app layer to the endpoint, Windows fixed-drive letters on the endpoint must be the same as on the reference machine from which the base layer or app layer was captured. (For example, it cannot be C: on a CVD and D: on a base layer.)
    • By default, only the system volume is uploaded to the CVD. You can add volume drive letters to the upload policy to upload additional volumes.
  • Base layering and app layering do not currently support SQL Express or SQL Server.
  • When reverting to Windows XP after an OS migration from Windows XP to Windows 7, 802.1X settings might not be preserved.
  • Mirage only supports delivery of a full Microsoft Office suite to endpoints that do not already have a Microsoft Office suite installed.
  • Mirage does not support delivery of two, full Microsoft Office suites in different layers.
  • Mirage does not support scenarios in which an endpoint has more than one version of a full Microsoft Office suite.
  • Windows system restore points do not work on machines that have Mirage installed.
  • Mirage does not support in-place OS migration scenarios on machines that have McAfee Endpoint Encryption enabled.
  • Mirage does not support the deployment of different versions of Microsoft Office applications in different layers, as part of the same deployment procedure.

Issues Addressed in this Release

The following issues have been resolved since the last Mirage release.

  • Memory leaks occur following repeated restore operation and migration operation failures.
  • An upload procedure might fail when Mirage creates file system elements with a path that exceeds 256 characters.
  • If a device disconnects from the network while Mirage is performing a forced-upload procedure, the upload procedure cannot be resumed. The upload procedure restarts.
  • In rare cases, when a machine fails to read the server manifest, the machine might enter the Pending Restore status.
  • When you perform a base layer update procedure, the View Agent settings are not preserved.
  • When you migrate a machine with a non-default Windows directory path, for example C:\winNT, the user profile fails to migrate.
  • In non-streaming scenarios, the Mirage driver blocks access to all offline files until the Mirage service starts.
  • The user session in the Mirage Web Manager might not be revoked in the case of a security related exception.
  • After you provision Windows 7 on a Windows 8.1 client, unsigned audio drivers and audio devices might not work.
  • The Mirage desktop service might display a warning message before shutting down.
  • When certain files are missing on the reference machine, the migration preparation tool might fail.
  • When you access the CVD history for an unnamed machine, an Internal Error message might appear.
  • In rare cases, when you assign an app layer after centralizing with a base layer, an Internal Error message might appear.
  • After you perform a migration or layer provisioning procedure, the Windows Reliability Monitor does not display any information.
  • The Mirage Web Manager installer fails to upgrade from Mirage 4.4 to Mirage 5.0 because of certificate issues.
  • In rare cases, if you cancel a base layer update procedure, the client might enter malfunction status.
  • If a protected drive is not formatted, when scanning the drive, the client might enter malfunction status.
  • IPV6 configurations are not generalized during provisioning or OS migration scenarios.
  • When a file on Isilon storage has a path that exceeds 256 characters, the CVD Integrity procedure might fail.

Known Issues in Mirage 5.1

The following known issues affect the Mirage 5.1 release.

  • If you apply a Windows 8.1 base layer that has a different Windows product ID than the one in the CVD, assigning the CVD to a different hardware device might cause user-installed Windows Store applications to not work. Clicking Repair when you try to launch the Windows Store applications might not repair them.

  • Workaround: Reinstall any user-installed Windows Store applications that do not work.
  • When performing an in-place Windows 8 migration, McAfee AntiVirus software might prevent Mirage from setting the correct access rights on directories. You might not be able to create or edit files.
    Workaround: Before you start the OS migration, disable McAfee access protection. For more information, see http://kb.vmware.com/kb/2052489
  • When you update a base layer or app layer, the power settings might be re-configured to the power settings of the reference machine.
    Workaround: Add the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\User\PowerSchemes\ActivePowerScheme exclusion to the base image rules.
  • After performing an OS migration, if you try to revert to the previous OS image, the migration might fail due to lack of available disk space. Mirage does not consume local disk space for local files that are identical to the files in the reverted CVD image and in the same path.
    Workaround: Verify that the available disk space is greater than the size of the previous OS image. You can run the disk-cleanup utility and delete Windows installations to increase space.
  • When you perform an OS Migration from Windows 7 with Sophos SafeGuard 5.6 in the base layer to Windows 8.1 with Sophos SafeGuard 6.1 in the base layer, the migration might fail.
    Workaround: Before starting the OS migration, remove Sophos SafeGuard 5.6 from the Windows 7 base layer. After you migrate to Windows 8.1, install Sophos SafeGuard 6.1 on the Windows 8.1 machine.
  • Mirage does not detect the compatibility of a processer with the Hybrid Sleep capability of Windows 7 and Windows 8.1. After peforming an OS migration from Windows 7 to Windows 8.1, the Hybrid Sleep function might not work.
    Workaround: Before you capture base layers for OS migration, disable Hybrid Sleep on the reference machine.
  • When you try to install an OS using a Mirage boot USB that has been configured for Windows 8.1 U1, the installation might fail.
    Workaround: When you configure the Mirage boot USB for Windows 8.1, do not use Update 1.
  • In rare cases, McAfee's Access Protection mechanism might block Mirage operations, such as downloading base layers, OS migration, provisioning, and so on.
    Workaround: Exclude the Mirage service from security products.
  • When you have an endpoint that has Symantec Endpoint Protection (SEP) version 12.1.671.4971 installed that you are migrating from Windows XP to Windows 7, the migration might fail.
    Workaround: Before starting the migration procedure, either uninstall SEP or upgrade to a newer version of SEP.
  • If you perform a base layer or app layer update that removes a Web-browser application that an end user has specified as their default Web browser, the end user might receive an error message when opening Websites or HTML files.
    Workaround: Advise the end user to re-install the Web browser or select another default Web browser.
  • When you perform a layer procedure that results in multiple versions of Microsoft Visio on a single machine, the Microsoft Office configuration window might display on an end user's machine when they open Microsoft Visio.
    Workaround: This is a known issue with Microsoft Office. See http://support.microsoft.com/kb/298947 and http://support.microsoft.com/kb/314392.
  • When you perform a layer procedure that includes Microsoft Office, if you open a Microsoft Office application before the "completing system updates" phase is finished, the Microsoft Office configuration window might appear.
    Workaround: Wait for all layer assignment procedures to finish before you run any Microsoft Office applications.
  • In rare cases, when you deliver a base layer that includes a Windows Live account, some sysprep operations might fail.
    Workaround: Do not capture a base layer that includes a Windows Live account. If you deliver a base layer that includes a Windows Live account and the user experiences issues, recapture the base layer without a Windows Live account.
  • When the Mirage Gateway server is deployed in a different subnet than the Mirage Management server, and the Mirage Gateway's server is secured using SNAT, you cannot manage the Mirage Gateway server through the Mirage Management console.
    Workaround: There is no workaround for this issue.
  • When you perform a base layer procedure, the static IP address configured on the endpoint is not preserved.
    Workaround: To preserve the static IP address that is configured on the endpoint follow this procedure.
    1. 1. Write a pre-VSS script that uses "netsh" to save the network settings in C:\Wanova Volume Information.
    2. 2. Write a post-provisioning script that uses "netsh" to import the network settings. Run the C:\Program Files\Wanova\Mirage Service\Wanova.Desktop.Control.exe -unlock file before you access C:\Wanova Volume Information\ and run the C:\Program Files\Wanova\Mirage Service\Wanova.Desktop.Control.exe -lock file after you access C:\Wanova Volume Information\.
  • When two or more Microsoft Office applications are installed on a machine, and at least one is part of a layer, the interoperability of the remaining Microsoft Office applications might not work.
    Workaround: There is no workaround for this issue.
  • When you assign a layer that includes a Microsoft Office 2013 product to a machine that already has a Microsoft Office 2013 SP1 product installed, Microsoft Office might not work.
    Workaround: Recapture the layer to include Microsoft Office 2013 SP1.
  • When you deploy a layer that includes Microsoft Office products to a machine that already has Microsoft products installed, and the architectures are different, you cannot manually install Microsoft Office products on the machine.
    Workaround: There is no workaround for this issue.
  • When you deploy a layer that includes a Microsoft Office product, and you update the Microsoft Office product, if you remove the layer that includes the Microsoft Office product, you might not be able to manually install Microsoft Office products.
    Workaround: See http://support.microsoft.com/kb/290301
  • In rare cases, after you perform a layer update, Windows might fail to install drivers for one or more hardware devices.
    Workaround: Get the compatible drivers from the manufacturer's Website and apply them manually or by using the Mirage driver library feature.