In this first post of a series I am going to talk about VDI. The first post, will describe what VDI is, why you may use VDI, describe the architecture and provide a guide for a test environment.  This blog entry is less technically deep than the usual Deployment Guys content but the plan is that subsequent blogs on VDI will focus on actual deployment and configuration of VDI infrastructure. The reason for starting with a higher level blog is that there is a lot of confusion about what VDI means, hopefully this entry will allow us all to progress with a common understanding.

VDI is a term used to describe users accessing a full desktop Operating System(OS) environment remotely. The desktop could be a normal PC, a Blade PC or a Virtual Machine. The ability to access a full desktop remotely has been available for many years via Terminal Server(TS). VDI is different from TS because in a TS environment multiple users would access a single environment, which could be customised on a per user basis but resources were not dedicated to a particular user. In a VDI environment each user either accesses their own centrally hosted physical PC/Blade or VM or they can access a shared VM. In a TS environment a number of applications had issues working on TS and also resources are not dedicated per user. VDI enables applications to be run as if they are on a local PC, removing any issues caused when running in a TS environment. In a VDI environment physical CPU, Memory and Disk capacity can be allocated to particular users which stops one users actions affecting other users. In addition VDI can assist

• When a users local device is incapable of running the latest Operating System and applications.
• Working from anywhere security, especially for emergency access using a non company PC to access company resources.
• Hosted images are securer than providing local desktops. Useful for offshore workers accessing company resources.
• VDI enables the core image(s) that everybody uses to be updated, even the OS, quickly and cost efficiently. This allows companies to take advantage of new OS’s and applications quickly without the usual delays caused by cost and planning.
• Users can be provisioned a new desktop each time which reduces support costs as the issues that build up due to adhoc software installation and removal do not exist.
• Data and VDI infrastructure can be deployed in geographically dispersed data centres enabling disaster recovery even for PC hardware which for many companies would not be quickly recovered should a disaster happen to an end user office.

A VDI environment can be as simple as the one described below or it can consist of all or some of the following components.

VDI Architecture Diagram

The diagram illustrates the components required in an Enterprise VDI environment. Where Microsoft provides a product which fulfils the technical requirement this has been identified. 3^rd parties provide products which fulfil some of these requirements and in the case of the Broker, Microsoft does not have a product but will partner with a number of suppliers depending on the customers’ requirements.

VDI machines can have all the software a user requires installed on it or a users applications can be streamed to them on demand or the user can access web based or TS apps as they would using a local machine. The locally installed applications are managed using the same tools you would use to manage a local desktop machine.

Broker software provides different functionality depending on the vendor, the list below is a few of the more common functions

• Allocating users to the correct VM or physical machine depending on permissions.
• Provisioning tools which allow multiple users to access a single VM, the ability to load up and shutdown VM’s depending on the time of day, minimum numbers of free VM’s to ensure there is always adequate capacity.
• Enable DR.
• Manage accidentally dropped connections.
• Connection persistency.
• Mask the original OS except at login. For instance a user has a local Windows XP PC. The PC has the Brokers client installed and this is configured to automatically start and load a Windows Vista VM. When the user logs in they see the Windows XP login screen then a Vista desktop loads and the user never sees a Windows XP desktop. The user can never access a Windows XP desktop. This provides a great way of deploying the latest OS and applications on hardware that is incapable.

A number of vendors have created their own access protocol’s or added enhancements to RDP. These protocols and enhancements add a number of features including

• Reduced bandwidth requirements per user.
• Increased responsiveness between the client and the VDI.
• Enhanced Video and Audio capabilities – these can increase bandwidth requirements.

Simple VDI Environment

The apparent infrastructure requirements may deter people from experimenting with VDI but the components listed below will create a basic VDI environment. Testers can use the environment to check VDI has the potential to meet their business requirements. The results of this testing will enable a Request for Information(RFI) or Request for Price(RFP) to be created for the Broker components. Following the RFI/RFP a fuller test environment which includes the remaining architecture stack should be created to test if a fully featured VDI environment can meet the business requirements. This test environment could be used to compare a number of Brokers to assist a company in choosing the broker they require if indeed they do require one. If a company plans to map specific VM’s to specific users and RDP provides the required performance then a broker may not be required.

A simple VDI environment consists of

• Active Directory
• A Hyper-V server
• A number of Windows Vista VM’s
• A number of PC’s which should be representative of the existing estate

This will allow testers to make RDP connections from PC’s to VM’s for test purposes.

Summary

VDI may be implemented for many reasons, these include enhanced security, cost savings and business enablement. VDI is not suitable for all desktop deployments and should be considered as an option not a panacea for all desktop requirements. As per all technology investments the business requirements must be gathered first then analysed. If analysis indicates VDI can assist in achieving the requirements then a business case should be created which can be used to assess whether a test environment is worth implementing. If a test environment is created the business case should be checked for viability following the testing to ensure VDI is suitable. A business may decide to implement VDI even though there are no costs savings because of the security improvements or enhanced functionality.

This post was contributed by Andrew Rennie a Solution Architect with Microsoft Services UK.