Enabling Local Mode

From vmWIKI
Jump to: navigation, search

Originating Author

Michelle Laverick

Michelle Laverick.jpg

Barry Coombs

Screen Shot 2014-04-28 at 09.41.39.png

Video Content [TBA]

Introduction Enabling Local Mode

Version: Horizon View 5.1

NOTE: Local Mode uses a role called the Transfer Server, the Transfer Server is used to speed up the download and upload process of the virtual desktops. In the first incarnation of the transfer server VMware only supported Windows 2008 R2 with the LSI Parallel SCSI adapter, unfortunately the default controller selected when building a 2008 R2 machine is the LSI Logic SAS controller. This led to much confusion and troubleshooting needed when things wouldn’t work. We are pleased to see that in View 5.1 VMware have rectified this.

The Local Mode feature allows a user to carry on using their virtual desktop even when they are not connected to the network. Users now represent an increasingly mobile population who expect access to corporate services while on the move – and not all of those services can currently be provided by handheld devices such as smartphones and PDAs. A Local Mode desktop is enabled by installing a special client onto the user’s computer, and installing the Transfer Server component on the View back-end. The Transfer Server is a new component in View. Previously, offline desktops (as they were then called) were managed by the Connection Server. VMware have developed a more efficient Transfer Server role to improve the synchronization process. The main engine of the Transfer Server is the Tomcat web service. The Transfer Server is designed to run solely and only in a virtual machine, and it is possible to have more than one. All Transfer Servers connect to a centralized repository of virtual desktops (the Image Library) that have been checked out for Local Mode use. In a simple configuration its possible to store the checked out offline desktops inside a second virtual disk inside the Transfer Server rather than on an external file server on the network.

It is important to note that you are only able to make dedicated desktops available in Local Mode, if you have a user who is currently assigned a floating desktop and they need to be able to take it local you will need to switch them over to a dedicated pool first, this doesn’t seem to be very well documented in the transfer server / local mode documentation. Local Mode desktops work by first downloading the user’s entire virtual desktop to their local computer in a process called “Checking Out”. This initial download can take some time, so it’s best done from the LAN in this first instance. The Local Mode desktops essentially then become a synchronization feature that you might have come across in other technologies, with just the differences synchronized between the user’s local computer and the View environment. When the user is disconnected from the network - say on a long-haul flight - the locally-cached offline desktop is powered on and available. While the user works with the offline desktop, changes accrue in a snapshot delta file. This allows for further functionality such as:

Check In – when the user returns the corporate network the user Checks In the virtual desktop, and any changes (just the differences) are synchronized back to the vSphere environment

Rollback – when the user decides to return the virtual desktop to its state before it is Checked In

Backup to Server – when the user decides that the changes should neither be Checked In nor Rolled back but maintained, until such time as they choose to Check In or Rollback their virtual desktop

These privileges can be taken away from the end user by using the View administration web pages and adjusting the policy options. During the transfer process the transfer server mounts the virtual disks used by the virtual desktop to additional SCSI controllers inside the VM. This speeds up the transfer process. Any VM can only have a maximum of 4 controllers, with 15 slots. This allows for a maximum of 60 transfers at any one time. As such the ESX host that the transfer server executes on must have access to all the datastores the virtual desktops reside on in order for the mounting process to be successful. The transfer process itself is carried out on a non-encrypted channel, as virtual desktops might contain sensitive data, you might wish to consider ways of encrypting the TCP sessions it generates or restricting transfer to LAN use only. Finally, once added to the View configuration the transfer server is isolated from DRS and set to be disabled for DRS. Watch out for maintenance modes that might “hang” at 2% because transfer server must be manually moved by the administrator of vCenter.

Installing the Transfer Server

Finally before we get started there are some important pre-requisites that we must be aware of.

• The Transfer Server must be installed on a dedicated VM and cannot co-exist with any other of the View Components.

• The Transfer Server can only be installed on Windows Server 2008 R2 with or without SP1

• 4GB is the minimum recommended memory

• It is possible to install multiple transfer servers for load balancing and resilience

• The location you configure to be the repository for the local mode desktops needs to have enough space to store the static images of all desktops to be managed by the transfer server.

• The transfer server VM must be managed by the same VC that manages the desktops that it will manage

• The ESXi host that the Transfer Server runs on must have access to the desktop disks that are to be transferred

• When we configure the transfer server, DRS will automatically be set to manual mode for this VM.

The Transfer Server component is contained in the same installer as the Connection Server.


Once you have chosen to install the transfer server role you need to configure the apache installation as show in the screenshot below.


You will now need to choose whether you wish the installer to configure the View Transfer Server automatically.


Once the Transfer Server is installed, you need to modify the Connection Server configuration to make it aware of the new server. This is very much like updating the Connection Server configuration when we installed the View Composer component.

1. Open the View Configuration

2. Click the Servers link

3. Select the Transfer Server pane from the top menu bar

4. Click the Add button

5. In the Add Transfer Server page, select the vCenter


6. Click next, and in the Transfer Server Virtual Machine, select the Transfer Server


After completing this process, you will see the status of the Transfer Server change from Pending, to Initializing Image Repository, to Ready. You may find that it displays a message of “No Transfer Server Repository Configured” if an Image Repository has yet to be configured. During this process the Transfer Server VM is rebooted, and additional SCSI controllers are added to it, these multiple SCSI controllers increase the amount of simultaneous disk transfers the Transfer Server can accommodate.

Enabling a Centralized Image Repository

Before you begin using Local Mode, you will need to set up the Image Repository – the Image Repository stores the Local Mode VMs either on a network fileshare or on storage local to the Transfer Server. The best location to use is a network-based one, this allows for scaling up the Local Mode feature by adding additional Transfer Servers, each Transfer Server will point to this central location for checking virtual desktops in and out.

1. Open the View Configuration

2. Click the Servers link

3. Select the Transfer Server pane from the top bar

4. Click the Enter Maintenance Mode button and click OK


5. Click the Edit button under the Transfer Repository section in the lower half of the screen – complete the dialog box with the UNC path to the shared location and the credentials required to access it


Note: At this stage you have choice – to store the transfer repository on a network file share/SMB supported storage array – or inside a virtual disk on the Transfer Server. We opted to add a second virtual disk to our transfer server, and allocated an X: drive to it.

6. Once added, return to the Servers link

7. Select the Transfer Server pane from the top menu bar

8. Select the Transfer Server, Click the Exit Maintenance Mode button and click OK

After a short while the status of the Transfer Server should update from Missing Transfer Server Repository to Ready.


Publish the Source Parent VM


Publishing is mandatory requirement for Linked Cloned Desktops, but not required for regular desktop pools.

If you are using the Linked Clones feature, the final configuration step for enabling the Transfer Server with a linked clone desktop is to publish the Parent VM in the image repository. The task does not need carrying out if you are not using linked clones. If you are working with conventional published desktops it is possible to skip this step. This publishing process accelerates the download process for linked cloned local mode desktops. If you think about the link clones – each users desktop is only slightly different from another users. The publishing process stores a compressed and encrypted version of the View Composer image, so they can be quickly downloaded by each user, together with the deltas that make up their own virtual desktop. You can see this as a kind of “caching” process.

1. Open the View Configuration

2. Select Servers

3. Select the Transfer Server pane from the top menu bar

4. Select the Contents tab under the Transfer Server Repository pane

5. Click the Publish button


6. Next select the View Composer Image you wish publish


Note: The system will then go through an initializing phase followed by a publishing phase with a % value, at this point the image is being transferred to the network location specified earlier. The information in the General pane will refresh to show you how much disk space your images are using.

7. Finally we either need to enable the local mode policy on our desktop pool or allow local mode globally. We would normally set this on a per pool basis as below.

a. Select Pools
b. Highlight the Pool you wish to enable local mode on
c. Click the Pool ID hyperlink
d. Choose the Policies tab
e. Click Edit Policies under the Local Mode Policies
f. Change Local Mode to Allow
g. Click OK


Check Out a Local Mode Desktop

For testing purposes, you might like to run the Local Mode client inside a VMware Virtual Machine. Unfortunately, VMware won’t allow it. They appear to use a registry setting inside the VM to detect that Windows is running inside a VMware virtual machine. Our workaround to this limitation was to virtualize Windows on a different vendor’s virtualization platform. We have both recently made the switch to Apple Mac’s, so our solution was to download Sun’s VirtualBox application that is free for both Windows and Mac, and using it to get the Local Mode client running. Madness, but it beats the hell out of locating a physical Windows PC for a 10-minute test.

1. Login using Local Mode Desktop client

2. Right-click virtual desktop listed, and choose Check Out


Remember, the Check Out option also appears in the menu in the end user toolbar if they have already connected to the virtual desktop


3. Before the download process begins, you may be warned that it is good practice to make sure the end user has logged in once to the virtual desktop


The files are downloaded to this path C:\<User Profile Path>\ <Username> \AppData \Local \VMware \VDM \Local Desktops. Using the browse option, it is possible to change the location of the download. During this time the user will receive a percentage-based indicator of the progress of the download and the size of the virtual desktop.

During this time the drop-down arrow will allow the user to either cancel or pause the Check Out process.

Just before the download process begins, the virtual desktop is powered down and a snapshot is taken of the user virtual desktop:


Additionally, the Annotations on the virtual desktop are updated:


In the administration web pages you will see the following under the Monitoring and Local Sessions tab:


When the user logs into the local desktop for the first time they will get a message explaining that the desktop is running in local mode and that before they can used it Windows will need to automatically detect the new virtual hardware and they will then be asked to restart.


Check In, Rollback and Backup to Server

Once the user has used the offline desktop for the first time, new menu options appear in the window that displays the virtual desktop.


The time it takes to Check In or Backup to Server is dependent on two variables - the amount of bandwidth available, and the number of changes accrued in the delta file. Of course, the rollback option checks the virtual desktop back into View, but discards any changes accrued whilst in local mode.

Manage Local Mode Desktops with View Administration

There are surprisingly few options to control Local Mode desktops in the current edition of View However it is possible to force a Rollback of the user’s virtual desktop from the administrative webpages by

1. Log in to the Connection Servers administrative webpage

2. Under Monitoring, select the Local Session icon

3. Select the end-users desktop

4. Click the Rollback… button

Additionally, it’s also possible to control whether users have access to the Local Mode desktop feature (by default, if they have the right client they do) and the Rollback option, as well as controlling for how long the Local Mode desktop will be allowed to function. It’s possible for the administrator to set an expiration period describing for how many minutes, hours or days the Local Mode desktop can be checked out. After this period expires, the user’s Local Mode desktop privileges also expire and they will find that the desktop will not power on after that time. You can adjust these settings so they affect every user, but it is possible to also have policy exceptions to allow for individual settings.

1. Under Policies, Click the Global Policies node

2. Select the Global Policies… icon under the Local Mode Policies pane


Most of these setting are common sense but what might need some explanation is the replication options which are disabled by default in the policy.

Enabling Replication

It is possible to enable a schedule of replication by which every so often the local mode desktop sends back its changes that have been accruing whilst offline. This guarantees that any deltas are being sent back to the virtual desktop in vCenter. By default it is turned off, which I think is kind of logical given that by definition a local mode user is well, running the virtual desktop locally and might not have any connectivity to sync back their changes. I think the reason for this feature is to allow for an automatic method for user to sync there changes, rather than relying on the end-user to do it. To enable automatic replication, and modify the frequency of updates – edit the global policy and set the desired replication frequency.


The View Administrator can initiate replication manually, by selecting a local mode desktop(s) in the Local Sessions node, and clicking the Initiate Replication button. As you can see in the screen grab above by default only the persistent disk is replicated back to the system. It is possible to change this to be just the OS Disk or both the OS Disk and the Persistent Disk.

When a replication is initiated the user will receive a message that a backup has started and by clicking the View icon on the taskbar they are able to review the progress.


The user is able to initiate a backup (replication) from the options menu in the client.


When the user is finished working offline they are able to check their desktop back in to continue working in the standard online mode.



The local mode within View 5 addresses the issue of needing to support users who need to be able to work away from any connection in the office. We have covered how the user is able to check out a desktop, backup / replicate a desktop and check it back in once completed. We hope this feature maybe developed in the future to allow desktops to be checked out and checked in, in the background, at present the desktop is powered down before the process of the check out / check in starts. We would also love to see this functionality brought to the Apple client as having the ability to take a Windows PC on the road with you for a Mac user may have even more of a benefit than that of a PC user. In our next chapter we will be looking at a special mode for View called “Kiosk Mode”. This may or may not be of interest to you – it depends very much on your environment. Its main use is allowing public access to a virtual desktop say in a lobby area or in a library.