Building a Flexible (yet secure) Desktop Solution

Many of you are already familiar with server virtualization and VDI and you might be looking for a virtualization approach that will help more easily secure and control desktop environments in a wider range of environments, i.e. bring-your-own-laptop, offline access, remote employees, etc.

In this post, I am going to describe one way to build a desktop environment which provides a lot of flexibility to users but still lets IT maintain control.

Consider an alternative approach to VDI: instead of running the VM image on a centralized server, the VM is running locally on the end-user's machine. The mantra is: "Manage centrally, execute remotely." This new model provides a great platform for IT organizations to customize solutions to fit their needs.

First, let's look at application virtualization and how that might fit in. Some of you maybe familiar with it - the big names in this space are: Microsoft AppV (formerly SoftGrid), VMware ThinApp (formerly Thinstall), and Citrix XenApp. In this model, an application is packaged up in a bundle and the user runs the application from this bundle in a sandbox environment on their unmanaged desktop. This is a great solution for delivering single applications to users because the application does not need to be installed manually on the local machine and it is delivered on-demand to the user. IT does not get involved in managing the OS and data on the machine.

However, not managing the OS or the rest of the desktop makes the computing environment vulnerable. In most cases, it's imperative to properly manage the environment to make sure the computer doesn't crash due to a missing security patch or that business data is not left unsecured. This is one of the reasons the desktop virtualization approach "manage centrally, execute locally" really shines - by easily securing the environment around a virtualized application:

Let's use the below image to explore the MokaFive layer approach to managing a virtual desktop, from bottom to top:

• On the lowest layer, there is the host PC or Mac operating system. The Mokafive Player, to download and run the virtual "LivePC" desktop, can be run on either platform, so you don't need to worry about cross-platform support in your solution. We take care of that.
• The layers above the host platform is the MokaFive Player and the Hypervisor. This allows you to manage the next layers above and control various security settings. IT can control what the user can or cannot do in the virtual desktop by setting policies on the central, Web-based management console.
  
• Then there is the base OS that runs inside the virtual machine (Windows XP or Vista).
  
• You can also install any corporate applications, i.e. Outlook, Word, a CRM or ERP application, etc. Together with the base OS, this can be your standard base virtual desktop image for your company or one base image for a specific department. By default, the base image is locked down by the MokaFive Player so it can't be tampered with.
  
• The top layer is where the magic happens. You can deploy additional applications to your users, based on their needs, using application virtualization technology. You can have users run applications from the server or you can have the applications streamed down to the virtual desktop, depending on performance needs. If you have an existing virtualized application installation, the MokaFive solution fits right now.
  
• Also on the top layer is the user installed applications. Using the personalization feature that is built into the MokaFive 2.0 technology, you can allow users to install their own applications on top of your standard managed image. You give your users flexibility to do whatever they want on the top layer while you maintain control on the lower layers.
  

We have tried this configuration with XenApp, AppV and ThinApp. I think this configuration provides the most flexibility to both IT and end users while at the same time, IT still maintains control.

The Basics of Image Management: Targeting & Policy Control of Virtual Desktops

In the world of server virtualization, one of the challenges is to manage all those virtual machine images. An enterprise may have a couple hundred servers but they may have a couple THOUSAND virtual machine images to manage. The reason for having so many images is that IT needs to support different OSes, different software stacks and different applications, etc. There are image management tools for server virtualization that sell for thousands of dollars just to keep track of the images.

If an enterprise is going to virtualize their desktops, the images management may become an even bigger problem. Is IT going to set up one VM image per user? Probably not. But what if different users need different applications or different access control policies? Is IT going to set up one VM image per difference? Maybe. But should they?

There is a better approach - achieved through two management concepts related to targeting and policy control.

The idea behind targeting is to allow an IT admin to "target" a particular version of an image to a particular group of users along with a unique set of access control policies. For example, Group A will use Image X and their policies are set so that they cannot paste copied data outside of the VM.

For the same Image X, IT can target it to Group B with a different set of policies. Targeting makes this possible with just a few clicks in the management software and doesn't require the creation or cloning of any images.

Different group of users can also be targeted with different version of the same image. This is great for quickly and easily testing changes to an image without a lot of fuss. For example, if the IT admin adds an application to an image but wants only a few people to test it before it is released to everyone, he or she can target the update version to a smaller group while everyone else stays in the current version.

Once everything is tested, the admin can switch the update version to become the release version and everyone would automatically get the update. It's important that only the changes to the image be sent out to users, so that users don't have to download the entire image again. When just the differential is sent the image can be updated in the background without disrupting the user at all, saving a lot of time and bandwidth.

Another way to simplify image management is to make sure that when IT updates an image, all the access policy settings remain unchanged, avoiding major headaches and time sinks. For instance, if IT has one Image X targeted to Group A with Policy 1 and the same Image X is targeted to Group B with Policy 2. When IT releases an update to the image, both groups will get the update while keeping their respective policy settings.

Of course, MokaFive's 2.0 technology and the MokaFive Suite incorporates the sophisticated image management functionality of targeting and persistant policy settings.

Here is a video that demonstrate these management features. Take a look and let us know if you have any feedback.