The Challenges of Virtual Desktops and Remote/Branch Offices (ROBO)

First lets define a problematic remote office's attributes:

• Smaller office with probably 10 or more desktops located there.

• Local printers (either connected to a desktop or on the network, but locally hosted).

• Potentially 1-4 servers located in the office to provide file, print and some application services

• Potentially managed by a different team than the central location

 

Typically IT admins will think that the remote office should be a perfect fit for VDI. They have these remote desktops that are a pain to manage, update and troubleshoot. There is little if any IT staff located in the office. And centralizing these desktops will probably remove the need for hardware and software troubleshooting to be done on-site. But… this doesn’t take into account the entire picture.

 

That remote office is probably connected via a small internet pipe. Let’s assume a T1 for our purposes here.  These users are using local PCs and having expectations of local PC performance not only with their business applications but also with any multi-media or videos they want to access. 

 

To provide a high-end thin client experience 20 or 30 desktops may need more bandwidth than that T1 can provide. The upgrade might be costly and not available in the near term…

 

Of course you can’t ignore the fact that the WAN connection now becomes the single point of failure for the entire office. If the WAN link fails today the machines still work. The users can access local data and print and may only suffer loss of the centralized applications. 

 

In a VDI environment this link not only has to have the bandwidth but it also has to be rock solid and when possible redundant. You may need multiple network connections back to the central location and these (in a perfect world) should be through different providers. Expensive enough yet?

 

Today the remote site potentially has some local servers. These may contain home directories for the users, some shared directories for the different groups there and maybe some application or print services even hosted locally. 

 

In order to provide optimal application and file services response (good performance in the desktop) the desktop execution needs to be close to the applications and file services. This will probably require moving all the services and file shares that are located in this office to the central VDI location. If you don't move these services you will be running connections BACK over the WAN pipe the remote desktop protocol just crossed to access the centralized desktop. Of course moving these servers/services is another migration project, with time and cost considerations that probably are not in VDI budget.

 

No one likes to discuss the political issues surrounding a VDI project (or any project for that matter) but we all know this is where we run into the most problems.  The users and management at that office are probably somewhat independent. They have some control of the desktops and maybe even a local “IT guy” that handles any problems that come up or can modify the desktops as needed. All these modifcations are decided on of course by someone other than centralized IT.

 

Moving the desktops central and controlling the images and apps may be great for cost and standardization, but loss of local autonomy is going to be a big problem for whoever “owns” the environment now. They will be sure to point out every technical problem or hurdle to ensure they continue to own the desktops and can modify them as they feel they need to in order to be productive. Do not underestimate the power of a manager scorned.

 

One potential solution to these types of problems is to deploy a remote VDI system. A scaled down version of the central VDI system including local host servers deployed to the site and a management system that will allow some control or input from the local management. 

 

The broker can be configured to route users from that site to their local desktops, and in some environments even a local broker virtual machine can be deployed to create a completely self-sufficient VDI environment.

 

In this potential distributed (ROBO) VDI environment the benefits of standardized images can still be realized and a combination of central management and remote desktop administration can alleviate some of the political problems.

 

With the desktops executing locally within the branch office, the servers on-site do not have to be moved and the WAN links can remain the same. The key here is that the VDI environment should be integrated into the overall VDI strategy used company wide. This can allow for standard images to still be leveraged (across multiple sites) and these sites can leverage the application packages being created across the organization.  You then gain the benefits of VDI while avoiding some of the technical and political problems that come along with these remote offices.

 

In the next blog (next Wednesday) I will discuss how Unidesk manages the replication of OS images, OS updates and Application Layers, to remote offices and how this is being used TODAY at current Unidesk customers with remote environments.

 

The final blog in this series will provide an overview of an existing Unidesk customer environment and some details on their implementation and management processes for the remote and centralized VDI desktops.

 

We also have a webinar on February 9th at 2:00 PM ET with Unidesk customer Workforce Solutions Alamo Board to discuss this very topic. The webinar is titled "Remote Office/Branch Office VDI: How One Local Government Agency Did It" and you can register by clicking here.