Migrating NTUSER.DAT and UsrClass.DAT with Horizon Mirage

I don’t know about you but I found it to be a little weird that there is not way to tell Mirage to move NTUSER.DAT and UsrClass.DAT when performing an hardware migration.

Considering Mirage uses USMT to migrate the user state mean that this is a precise choice from VMware and not a technological limitation.

Those two files include two pretty important user settings: the user portion of the registry and the user class of the registry.

If you want to have the migrated workstation to have exactly the same look and feel, including the customization of the single applications settings, icon positioning on the desktop and so on you definitely want to apply NTUSER.DAT and UsrClass.DAT as well; I am sure there are scenarios where you don’t want this but there are also scenarios but if you want you should be able to do it.

In the Factory Defaults this is explicitly forbidden, so if you want to apply NTUSER.DAT and UsrClass.DAT too you need to follow this procedure:

  • Log in to your Mirage Management Server
  • Open a command line as administrator
  • Browse to C:\Program Files\Wanova\Mirage Server
  • Launch the Server CLI: “Wanova.Server.Cli.exe <server name/ip>” of your Mirage Management Server such as <localhost>
  • Enter: “GetFactoryPolicy c:\factorypolicy.xml” (Get the current factory policy)
  • Edit the file c:\factorypolicy.xml (e.g. with notepad,notepad++)
  • Save the file by entering: “SetFactoryPolicy c:\factorypolicy.xml”

When editing the file, you can search for “NTUSER” and “UsrClass.dat” and just remove the lines with “”.

Advertisements

How to distribute Mirage Client with logon script

One of the things that Horizon Mirage doesn’t give you out of the box is the ability to deliver the Mirage client to clients in a centralized manned, which is kinda awkward for a solution that tries to centralize everything.

I solved this problem with a logon script i use for client deployments; you can use and tweak my script as you want but don’t blame me if it doesn’t work for you 🙂

Here’s the thing:

@echo off

rem echo Detecting OS processor type

if "%PROCESSOR_ARCHITECTURE%"=="AMD64" goto 64BIT

:32BIT
rem echo 32-bit OS
msiexec /norestart /quiet /l* "\\path_to_log\%COMPUTERNAME%-MirageClient.log" /i "\\path_to_setup\MirageClient.x86.15875.msi" serverip=<your_mirage_server> usessltransport=false
goto END

:64BIT
rem echo 64-bit OS
msiexec /norestart /quiet /l* "\\path_to_log\%COMPUTERNAME%-MirageClient.log" /i "\\path_to_setup\MirageClient.x64.15875.msi" serverip=<your_mirage_server> usessltransport=false
:END

Notice that the setup files have to be on a network share as well as the location of the log files where everyone have write access.

Upgrading VMware Mirage to 4.3

I’ve been waiting for a while for version 4.3 to come out for some interesting features some of my customers would be able to leverage, but I never thought I would be so surprised once I got to understand how to do it.

Essentially, there is no upgrade procedure, you just uninstall and reinstall the components just as they were before by using installer files from the 4.3 version.

Yes, I know, I thought the same but I can say that in the end it just seems to work. Even if there is no orchestration of a version upgrade that checks things around before proceeding I have to admit that the ease of operations is pretty nice.

Preparations steps are simple, just make sure you have the following written down:

  • Database server name
  • Credentials for the database server
  • Horizon Mirage server cache directory location
  • Cache size

Then just stop all Mirage services, snapshot all volumes, backup your DB and you’re done. A more detailed procedure can be found here but there is really not much more than that.

Now to the upgrade (or should I say reinstall?), the only thing to remember is that the order of operations must be respected:

  1. Select Control Panel > Add or Remove Programs to uninstall the system components.
  2. Uninstall all Horizon Mirage servers.
  3. Uninstall the Horizon Mirage Management console.
  4. Uninstall the Horizon Mirage Management server.
  5. Uninstall Horizon Mirage WebAccess.
  6. Use the new mis files to install the latest version of Horizon Mirage.
  7. Install the Horizon Mirage Management server.
  8. Install the Horizon Mirage Management console.
  9. Install the Horizon Mirage servers.
  10. Install Horizon Mirage WebAccess.

You will need to reboot the server after step 9.

A neat thing is that you won’t need to do anything to update your Mirage clients because once they contact the server they will self-upgrade with no downtime for the user. I just wish it would be possible to suppress the balloon notification that informs users about the upgrade or the possibility to decide when user clients will be upgraded.

I used this procedures twice on simple single server implementations and I had no issues.

Even if I would prefer a real upgrade procedure, in the end of the day i just want upgrades to work and this seems to be the case with Horizon Mirage, so no complains.

Horizon Mirage CVD Explorer AKA How to extract files from a CVD that is not actively being used

In Horizon Mirage the client has a nice little feature that allows users to self-restore files and folders taking them straight from their snapshots in the SIS (Single Instance Storage) database on the Horizon Mirage server that they are connected to.

Simple enough, but there is still a situation where you can’t use this feature. What if a specific CVD had been archived or what if simply the user or the sysadmin doesn’t have access to the endpoint where the Mirage client is installed?

In the Horizon Management Server there is some sort of a hidden feature (Mirage seems to have many…) that lets you open a CVD from the SIS, browse the filesystem and recover files and folders; the only limitation I’ve found compared to the full Mirage client experience is that you will not have the chance to choose from what snapshot to extract the files but you can only access the last one.

Fair enough.

Here’s what I did when I had to recover a folder from a user’s CVD:

1. RDP to the Management Server
2. cd “C:\Program Files\Wanova\Mirage Management Server”
3. run “Wanova.Server.Tools.exe CvdExplore”
4. Set output directory by clicking “Server -> Set output dir” (if you don’t set this value default location will be “C:\Program Files\Wanova\Mirage Management Server\CvdExplorer” for a default install)
5. Type in the path of the Mirage storage (eg. e:\mirage)
6. Type in the CVD number then hit enter (eg. 10001)
7. Browse the file system and find the file/folder you need
8. Right click and choose “Extract”
9. The application will automatically exit and you will find your files/folders in the output directory

Good to go!

Horizon Mirage 4.3 Released!

After quite a long radio silence i can tell you that since i’ve been working behind the scenes with Horizon Mirage, i am pretty excited about the announcement of the new 4.3 version!

This version provides the following new features and improvements:

  • The IT manager can now manage VMware View full clone desktops with Horizon Mirage. The IT manager can send image updates to View desktops, while keeping the user applications and data intact.
  • A new policy enables Horizon Mirage to work only with base and app layer updates, without uploads, reducing the overhead of the Horizon Mirage steady state on the end user’s machine.
  • Using Windows 7 migration with layers:
    • The IT manager can send app layers during the migration process.
    • Endpoints receive the base layer and the app layers in a single batch, and require only one reboot.
    • When the IT manager is following the progress of the migration, the app layers assignments under the Windows 7 migration task can also be followed.
  • The new web console supports the Protection Manager role, which has primary responsibility to ensure that the devices are protected and synchronized with the CVDs.
  • The dashboard for the Protection Manger role includes:
    • Last known upload errors, to help the IT manager focus on the main issues that are preventing users from uploading their data.
    • Centralization trends, to enable the IT manager to view the current state of the endpoint centralization process and determine how long this phase will take to finish.
    • Unprotected endpoints, to enable the IT manager to view, for a specific time period, which endpoints did not complete the upload.
    • Network disconnects, to enable the IT manager to view if there are slow remote branches that suffer from network disconnects that affect user uploads.

I’ll try to share my findings with this product soon as i did with Horizon Workspace.

Stay tuned!

%d bloggers like this: