Implementing Virtual Desktops

Where Do I Start with Virtual Desktops?

Virtualization by itself is a mature and smart move for the business data center. Compressing large numbers of physical servers into small numbers of virtual hosts, the move to virtualization reduces the raw costs of running a data center while improving your management of individual servers.

Yet virtualization needn't necessarily stop with the conversion of servers to virtual servers. Its enhancements to overall systems administration and reductions in cost play equally when virtualizing user desktops. The very same virtualization infrastructure you use for your servers today can be naturally extended to support the hosting of desktops as well. As a result, users gain the flexibility of connecting to a well‐managed desktop from virtually any network endpoint. The business reduces its overall costs in maintaining its distributed computing infrastructure. And your IT organization gains previously‐unseen levels of security and control that arrive as a function of centralization.

But how do you get there? What exactly are virtual desktops and how are they presented to their users? What technologies, both hardware and software, are necessary to achieve this end goal? What are today's best use cases for deployment? This series will attempt to answer these important questions in implementing virtual desktops, leaving you with the right set of information to make an educated decision about extending your own virtual infrastructure.

What Is a Virtual Desktop?

Simply put, a virtual desktop is a virtual machine. These operating system (OS) instances are the very same kinds of virtual machines that you may already host atop virtual platforms, such as VMware vSphere or ESX. As a virtual machine, a virtual desktop automatically enjoys the same kinds of workflow and consolidation benefits as do all types of virtual machines:

• Multiple virtual desktops can be hosted on a single physical server, increasing utilization of existing hardware.
• A virtual desktop's initial configuration is often based on a reference image, making possible its rapid and automated deployment.
• Being hosted within your protected data center, and with only screen updates and mouse/keyboard commands traversing the network, their data is dramatically more secure than in a traditional distributed infrastructure.
• As an instance that is designed for remote access, users can access their full‐fidelity desktop from any network connection.

The primary difference between a virtual desktop and a virtual server lies within its OS and end user. Virtual servers are used for processing workloads in the data center, such as file services, email services, databases, and network applications. Virtual desktops are instances of desktop OSs such as Windows XP, Windows Vista, and Windows 7. Their end user is the individual employee in your organization, with each virtual desktop supporting the processing needs of one individual. Different than a physical desktop, a virtual desktop is connected to via the network using some form of endpoint technology. That network can be either the local LAN or WAN, or, with the proper routing and security in place, it can also be the Internet.

This one‐to‐one ratio between virtual desktop and user is fundamentally different than the architectures used by other remote access solutions such as Microsoft's Terminal Services or Citrix's XenApp. Within these products, application use is shared by multiple users on the same server. Thus, the same instance of Microsoft Word is leveraged by every user using that application on that server.

Although this type of access is good with the right kinds of applications and when application needs are slight, many applications simply do not function in a multi‐user environment. Also, applications with high resource needs tend to experience overload conditions in these environments, which reduces the overall user experience. Most importantly, these environments require a high level of administrative control in order to keep collocated users from stepping on each other, which limits users' ability to customize their environments to their liking. Virtual desktops make sense when full­fidelity desktops are necessary for users, with each user enjoying their own individual OS instance that is not shared with others.

Types of Virtual Desktops

Considering the previous statement, there are in fact a number of architectures by which full‐fidelity desktops can be delivered to users. Depending on the needs of your users, any of these may make sense for your business:

• Assigned desktops. The assigned desktops architecture fits well in environments that want the highest level of desktop configurability for users. In this environment, a virtual desktop is created and specifically assigned to each user. When a user connects into the virtual desktop infrastructure, the user always receives the same desktop. Because desktops are assigned, one‐off applications can be installed for specific users, and users can customize their desktop instances according to their needs.
• Pooled desktops. Environments that leverage a more standardized set of applications can enjoy a more efficient use of resources by pooling desktops. In this architecture, a set of desktops is made available for concurrently‐connecting users. As no assignment of user to desktop is made, any user may randomly connect to any desktop. Desktops are preloaded with necessary applications, and limited state information is injected onto the desktop as part of the login operation. In this environment, it is often the case that a smaller count of desktops is necessary, as the number of available desktops need only meet the concurrent user count rather than the total user count. Further, as pooled desktops are deployed with the assumption of random assignment, it is easier to refresh the pool en masse when updates are required.
• Kiosk/lab desktops. Virtual desktops provide a significant advantage to kiosk and lab environments due to their ability to be quickly refreshed, deleted, and re‐created on demand. This is particularly the case in low‐security kiosk and lab environments where desktop refreshes are necessary and often must be accomplished with short notice and within a short timeframe. Here, entire labs can be quickly rebuilt to support new missions through a few mouse clicks.
• Converted desktops. This scenario is similar in delivery to assigned desktops but is different in that users' original physical desktops are converted to virtual desktops through some mechanism. These desktops are then operated with the same configuration as the original desktops but function with the benefits of virtual desktops. This architecture tends to enjoy the lowest level of automation flexibility because individual desktops are not created from a central source. Further, directly converting physical desktops to hosted desktops is an option that is typically only considered on an exception basis due to their inherent lack of commonality.

In all of these scenarios, a primary management benefit relates to the ability to rebuild any virtual desktop instance on demand. A virtual desktop arrives as the combination of a reference desktop image, installed applications, injected user personality information, and connections to documents and files (see Figure 1). These four elements are laid down using an automated interface:

• The desktop's OS image is copied from a reference image, creating the base OS environment for the desktop.
• Applications that are not already part of the reference image are installed automatically to the desktop.
• The user's individual personality configurations such as desktop and Internet shortcuts, backgrounds, colors, and any other customization are injected into the image as the user connects to it.
• Any files needed by the user and stored on alternative servers are connected through drive mappings or shortcuts.

Figure 1: Provisioning a new virtual desktop involves the automated invocation of four steps.

This means that the entire set of user‐specific data can be rolled from one instance to another at will. Should a user experience a problem with his or her desktop—if its configuration is corrupted or if it is inadvertently or maliciously infected with malware— an administrator needs only to re‐provision a new virtual desktop image to the user.

Where to Start?

Due to their flexibility, virtual desktops can be rolled out to an organization using essentially any plan that works for the business. A business can elect to roll out virtual desktops to a select group of individuals first, while slowly implementing them for others in the organization. Virtual desktop rollouts can be further implemented based on the capacity of the virtual infrastructure. As your business incrementally transitions resources from physical purchases to a virtual infrastructure, more processing power and client endpoints can be implemented into the environment. This horizontal scaling of resources enables more users to move to virtual desktops.

For environments that aren't ready for full conversion, virtual desktops needn't necessarily operate as full desktop replacements. Virtual desktops leverage the same network infrastructure as distributed physical desktops, so users can leverage virtual desktop use for specialized circumstances such as work‐from‐home situations or in maintaining operations during a disaster. Article three will talk more about some of these potential situations and their benefits.

Virtual desktops also make sense in limited implementations when users are highly mobile in their workday patterns. For example, doctors and nurses in hospitals or students in university settings, both of which involve users who must connect multiple times per day in multiple locations. Call centers are excellent targets for a virtual desktop infrastructure because of their limited application set, highly mobile workforce, and limited need for desktop customization.

In the case of call centers as well as in the retail sector, virtual desktops have a large advantage over alternative remote application infrastructures due to their extensive support of peripherals. Unlike traditional remote application infrastructures, which tend to have limited support for point‐of‐sale and call center peripherals, virtual desktops that leverage the right kind of client endpoint can use any peripheral that is supported by the virtual desktop's OS.

Virtual Desktops Solve Many IT Problems

You can see in this article that a virtual desktop infrastructure has the potential to solve many of the administrative nightmares faced by IT. Centralizing the otherwise distributed desktop infrastructure means tighter security, easier administration, and more rapid problem resolution. At the same time, it enables desktops to be presented to users no matter where they may be located.

The next step is in implementing its technologies. There is no single product or technology that represents an entire virtual desktop infrastructure. Instead, getting to this management nirvana requires the integration of a set of technologies from virtualization infrastructures to client endpoints. Solutions that offer out‐of‐the‐box integration of principal components can significantly accelerate the successful deployment of virtual desktops within an organization. Article two in this series will outline what you'll need for your own infrastructure.

What Technologies Are Critical for Virtual Desktop Success?

Virtualization, orchestration, personality management, servers and storage, and the allimportant endpoint—these are technologies you must integrate to create a successful virtual desktop infrastructure. The first article in this series closed with the statement that today's virtual desktops encompass no single technology. There is no shrink‐wrapped box of software that you can buy to Next, Next, Finish your way to a virtual desktop environment. Instead, multiple technologies must be integrated in careful ways to create the necessary architecture.

But don't let this statement scare you. The multi‐product approach to creating an IT infrastructure of any type isn't a new technique. Even mature technologies such as email and file services require multiple products to be successful. As an example, an email server requires the server to function but also requires the addition of anti‐spam, anti‐malware, proxying, and often multiple additional servers in larger environments to correctly accomplish its mission. With virtual desktops, it is likely that you already have many of its components or the capacity to host them in place.

What Are the Prerequisites for Virtual Desktops?

Figure 1 outlines a few of the components necessary to stand up your initial virtual desktop infrastructure. Obviously, the first necessary component is a mechanism to actually virtualize the desktops themselves. This enterprise virtualization platform should be able to support a high level of virtual machine density, enabling large numbers of virtual desktops to be hosted per configured server.

Figure 1: A virtual desktop is powered by a virtual host. It is accessed via a client endpoint through many types of network connections.

Also necessary in combination with that virtual platform are the servers that host virtual machine processing. With an enterprise‐class virtualization platform and correctly configured hardware, it is not unheard of to expect between five and eight virtual desktops per server core. Each desktop can be configured with as little as 512MB of RAM for users with light workloads such as minimal Microsoft Office utilization, or as much as 1GB or more of RAM for heavier uses.

Note: Be cautious with the assignment of memory to virtual desktops, as conservation of RAM is critical to ensuring the highest level of virtual desktop density.

Disk performance in virtual environments can be a singular bottleneck when not properly planned. As virtual machine processing is highly disk‐centric due to its entire configuration being on disk, the rotation speed of disks used in virtual environments is exceptionally important. High‐performance SAS or FC disks with a rotation speed of 15,000RPM or greater is recommended to eliminate any disk bottlenecks, although slower drives (such as those that operate at 10,000RPM) can be used for less‐demanding workloads if properly monitored. The use of high‐speed disk controllers with efficient RAID is recommended to ensure that the processing of disk requests can keep up with server processing.

Also critical is the speed of the network. Although a deficiency in any physical component such as processor power or disk speed can cause a reduction in performance for the end user, a well‐performing network is critical to the best user experience. Although not technically a "streaming" technology, the connection between virtual desktop and user is highly reliant on an uninterrupted and efficient stream of data. Latency either in the network or as a function of a resource bottleneck is the greatest enemy of a virtual desktop infrastructure. Any latency will be felt by users as sluggish performance and will result in a reduction in the user experience. Most high‐speed business LANs should not experience this problem; however, environments that span the Internet, multiple sites, campus environments, and metro‐area environments must take care to architect the proper amount of bandwidth to prevent latency effects.

As such, you must be cautious not to overload your virtual infrastructure with too many virtual desktops. Although a virtualization platform can create effectively unlimited numbers of virtual machines, the performance utilization and count of those virtual machines must be closely monitored to ensure that each user retains an experience equivalent to a local desktop.

Lastly are the personality management and orchestration components that ensure users are correctly connected to the right virtual desktop and that user state is properly injected. Orchestration components are typically made available through a virtual desktop technology's vendor, making each technology different in the mechanism by which users are connected to desktops (more on this in a minute). Personality management technologies typically leverage either Microsoft Windows Roaming Profiles or make use of a third‐party application.

How Do Users Interact with Virtual Desktops?

With all these pieces, we're not quite done. It can be argued that of these components, the most important to consider relates to the client endpoint itself. Essentially, some technology must exist at the users' network connection in order to interact with their virtual desktops.

Figure 1 shows how the display and interaction with a virtual desktop occurs over the network. Transporting that data across the network occurs through one of many network protocols, all of which are highly‐optimized for network utilization and preservation of the user experience. Different virtual desktop vendors leverage different technologies for delivering that interface to its users, and it is the selection of the right technology here that will determine the success of your virtual desktop implementation.

To explain this statement, think for a minute about the elements that must be in place for a user to access a virtual desktop. A virtual infrastructure must be in place to host that desktop. The network must contain the capacity to support the network transport of its interface. Management tools must be available for creating and administering the desktop infrastructure. And, most importantly, some component must be in place at the user's location to receive the desktop.

It is the selection of this client endpoint component that ultimately makes or breaks a virtual desktop deployment's ROI. Cost models associated with hosted desktops gain much of their financial benefit through the elimination of "real" desktops at the user's location. By eliminating the real desktop, the cost of maintenance and upgrade is eliminated, as is the annual cost of administering the configuration, security, and application load‐out on that endpoint.

However, with virtual desktops, one cannot simply eliminate the device at the client's location. Something must be present to receive the data for the virtual desktop and convert it into a useable interface for the user. Accomplishing this task by using traditional desktop computers eliminates much of the potential benefit gained by centralizing desktop processing. Rather, needed is a specialized device that requires no configuration, retains no onboard state, and can be swapped out as easily as the user's desk or their telephone. Such a device fulfills the need for an endpoint but does so while maintaining the ROI gained through the total and complete centralization of desktop processing.

The Value of the Zero Client

Lacking any form of onboard configuration information, such a device could be considered a completely stateless client, or a "zero client." This moniker is used as a comparison with early "thin client" devices. These devices interoperated with remote application environments such as Terminal Services or XenApp. With a thin client, a minimal operating system (OS) is stored on the client device itself. Its processing was used to connect the client device to a remote access server for the deployment of applications.

Thin clients grew in popularity towards the end of the last decade. Having very few moving parts, these clients could be easily deployed and needed only minor updating—often through flash RAM updates but sometimes via small onboard hard drives. Their primary responsibility was to connect the user to their remote applications, present a user interface, and send keyboard/mouse commands back to the server.

However, over time, many found that the promise of thin clients didn't align with the reality of their administration. With many thin clients, their minimal onboard OSs still required updating, a process that consumed time and increased their cost to maintain. Further, producers of thin client OSs weren't often able to keep pace with changing technology at the server side, forcing many thin client deployments to stick with older server‐side technology. Even more problematic, when needed business applications were found to not function atop Terminal Services or XenApp, businesses were often forced to revert back to traditional desktops.

Contrast this situation to the virtual desktop alternative. Here, every part of a virtual desktop's processing (and indeed all its code) is retained at the server side and within the virtual desktop itself. In this situation, the client is little more than an electrical transceiver, one that converts electrical signals from an Ethernet cable that is connected to a common TCP/IP network into useable signals for video, mouse, keyboard, and peripherals.

Such a client is entirely stateless, and as such, never needs updating, management, or replacement of onboard code. When technology changes at the server side—alternative virtualization hypervisors, new technologies in deployment, improvements in data transport protocols, and so on—there is never a need to update individual clients. Technology changes at the server side are immediately and automatically useable by clients that are deployed into the field. The only necessary step to implement new technology is in altering the server infrastructure.

Lastly, and most importantly, the virtual desktop infrastructure back in the data center retains the 1:1 mapping between users and OS instances. This means that any application that works on Microsoft Windows will work in the virtual desktop environment. Thus, it is likely that your business will never be forced to revert back to traditional desktops because of an application incompatibility.

Multiple Technologies. Agile Processing.

There are a number of technologies that are required to create a virtual desktop infrastructure. These technologies incorporate the consolidation power of virtualization with the automation flexibility gained through OS management. With the right tools in place, it is possible for users to connect to their desktops from anywhere with a network connection. At the same time, problems in the environment can be solved with very little effort. Although the initial costs of building such an environment can be high considering the technology outlay that is required, such an expense can quickly pay for itself through the reduction in operational expenditures over time.

Now that you understand the promise of virtual desktops as well as the technologies that make them a reality, your final question likely relates to the use cases where it most makes sense. Today's implementations of virtual desktops work well across a range of environments, with some gaining dramatic efficiencies. The final article in this series will tell a set of stories from industries who have benefitted from their virtual desktop implementations.

What Are Others Doing with Virtual Desktops?

The first two articles in this series have attempted to answer the questions surrounding "why" virtual desktops make sense for the business. The architectures and technologies behind virtual desktops were explained in detail, showing how multiple technologies aggregate to create a virtual desktop infrastructure.

But knowing that a thing can be done doesn't necessary explain how and where it should be done. This third and final article will attempt to answer those questions, detailing how and where many organizations are currently and successfully using virtual desktops. Delivered as a series of generalized case studies, this article will explain how a few organizations have turned virtual desktops into a competitive advantage.

Case Study #1: Mobile Access Stations at a Hospital

ABC Hospital is a large hospital with multiple departments, all of which are served by a centralized IT organization. The primary responsibility of the IT organization is in maintaining the hospital's data center as well as its unified patient service application. Within this application are stored all forms of patient records, including prior admissions, doctor notations and recommendations, prescribed drugs and interactions, as well as imaging via x‐ray, MRI, or other devices. As the singular application that handles and records virtually every facet of patient interaction, it is needed in every examination room by multiple doctors and nurses.

The problem with ABC Hospital's use of this application relates directly to the login process required to connect doctors and nurses into the application. Because both groups of people regularly move between offices, yet need access in each office to patient records via the application, the time to connect must be minimal. ABC Hospital's original attempts to leverage traditional Windows logins and logouts with locally‐installed workstations often required login and application startup times of multiple minutes. This was unacceptable to both doctors and nurses, with the original system quickly being scrapped as alternatives were sought.

Microsoft Terminal Services‐ and Citrix XenApp‐based solutions were also rejected due to incompatibilities in the application itself. This application was developed for the healthcare industry and was not created to be interoperable with traditional remote application infrastructures.

A workable solution was developed that leverages the rapid connection and disconnection power of virtual desktops. As virtual desktops remain assigned to individual doctors and were not logged off or powered down as doctors relocate from room to room, an individual doctor can quickly connect to their assigned desktop with its applications already loaded. To the doctors, the user experience appeared as if each monitor in each examination room were independently connected to their personal desktop. Connection time was reduced to a single‐digit number of seconds rather than the multiple‐minute requirements of the physical desktop infrastructure. This improved the doctor/patient relationship, and even saved a few lives over the course of its lifespan.

Case Study #2: Hot Desking at a Three‐Shift Call Center

ABC Call Center is a three‐shift call center that handles multiple clients. First‐ and secondshift operators typically handle customer service activities across ABC Call Center's client list, with its third shift dealing with emergency situations. As a multiple‐shift environment, employees use available desks during their 8‐hour shifts. This workflow means that any particular hot desk is generally always staffed during the full 24 hours of the day.

In order to process calls, ABC Call Center leverages a central call center application. This application presents the necessary scripts to employees as well as enables actions that can be accomplished by the employee in resolving a customer problem. Because ABC Call Center handles multiple clients at once, the same employee can handle requests across multiple clients during any particular shift, with their individual scripts and actions being presented to the employee by the application.

ABC Call Center originally leveraged the use of physical desktops at each hot desk. This configuration enabled users to log in as they arrived for work, and log out as they completed their shift. However, it suffered from a number of critical limitations. The employees for ABC Call Center had a tendency to "play" with the desktops during irregular downtime periods. This non‐work use of the systems regularly led to their need for troubleshooting or re‐imaging. However, due to the high utilization of the call center as well as its multiple‐shift nature, any downed computer meant one less employee handling calls on the call room floor. Further, the installation of required updates to the individual desktops created a substantial impact on operations.

To remedy this situation, ABC Call Center leveraged a set of zero clients that connected to a pool of virtual desktops. Installed to those virtual desktops was the call center application. They were further locked down to prevent known forms of non‐work use.

Because virtual desktops were used in a pooled configuration, any user automatically received an arbitrary, available desktop. That desktop was always properly configured for their use, because each was constructed on‐demand from a reference image as the employee logged in. Updating the pool of images required updating only the reference image and forcing a refresh of all virtual desktops in the pool, effectively provisioning any update automatically at the next shift change. The result to ABC Call Center was a substantial increase in worker efficiency and a reduction in costly downtime to nearly zero.

Case Study #3: Training Lab at a University

ABC University is a large university with multiple departments. After a major centralization activity, IT services for all departments were unified under a singular organization. This enabled ABC University to consolidate its dozen computer labs into a single building that could support the needs of all departments at a much lower operational cost.

However, quickly after the consolidation, it was found that the physical environment used by the lab was insufficient for the rapid re‐provisioning needed by different faculty. For example, a computer lab that was configured for use by a Foreign Languages professor would be needed during the next teaching hour by a Computer Sciences professor for a completely different class. Whereas the Foreign Languages professor's class required only a simple application, the Computer Sciences class might engage in wholesale manipulations to the systems and the network. As a result, professors would regularly find that the computer lab was insufficiently set up for their needs.

As a further need, the university found itself wanting to provide access to labs for users at all hours and from all locations. This access would alleviate the strain on the actual computer lab by allowing students to access lab equipment over the network and from their dorm rooms.

A mechanism to accomplish both the rapid redeployment as well as the ubiquitous access problem was needed. The creation of a virtual desktop infrastructure was eventually decided upon by university IT. Such an infrastructure enabled lab administrators to create and manage multiple reference images, one for each professor and class. With enough processing power in the university's data center, lab administrators were able to clone dozens or even hundreds of images that were specifically created for each lab. This could occur in the 10 minutes between one class ending and another starting. Professors with needs for new images could simply create them according to a standardized process and submit them to IT for uploading into the virtual desktop infrastructure.

Extending the early implementation to the rest of the university's network infrastructure required very little extra effort on the part of IT. A third‐party orchestration component was customized by the university that enabled students to connect to any class's virtual desktop. Such a desktop could be cloned at any point during the day and would be available for the student for a period of 4 hours before being automatically removed. User data was gathered from any and all images prior to removal, enabling users to reconnect at their leisure.

The result was a significant reduction in wait times for lab equipment as well as an increase in student and professor satisfaction with the overall environment. Ultimately, both professors and students found themselves needing less actual real‐time access to lab equipment during the day, reducing power costs as well as the count of equipment necessary to run the university's classes.

Case Study #4: Disaster Recovery Operations at a Corporation

ABC, Inc. is a multinational corporation with offices in the United States, EMEA, and Japan. As a multinational corporation with very high‐end clients, its data processing had a requirement of 99.95% uptime. Its customers were highly intolerant of both downtime and any loss of data. This fact required ABC, Inc. to create and execute a disaster recovery plan that assured continued access to data, even during disaster operations. Although ABC, Inc. was able to replicate its data to multiple alternative sites, and was further able to replicate its application servers to those sites, it found itself unable to connect employees to necessary applications in the case of a disaster.

ABC, Inc. eventually settled on a virtual desktop solution as its architecture for disaster operations. A virtual desktop infrastructure was implemented to support its most‐critical 30% of employees who were specifically targeted for continuing their work during a disaster. The other 70% of employees were not deemed mission critical, which enabled ABC, Inc. to incorporate a standby virtual desktop infrastructure of smaller size and cost.

Because ABC, Inc.'s virtual desktop infrastructure was hosted in a third‐party facility away from its other operations, its mission‐critical users were configured to access their disaster operations virtual desktops via the Internet. Users no matter where they were in the world could access replicated ABC, Inc. data to continue the operations of the company.

Although this standby virtual desktop infrastructure was useful in the case of a disaster, it was later leveraged during nominal operations for its field support teams. While in normal operations, up to 30% of its workforce could securely and safely access ABC, Inc.'s most critical business applications from any Internet endpoint. Ultimately, ABC, Inc. was able to improve its agility through this implementation alone such that it was able to extend operations in both EMEA and Japan where direct LAN/WAN connections were sparse.

Case Study #5: Point‐of‐Sale Stations at a Multi‐Site Retail Company

ABC Retail Company exists in more than 100 locations spread throughout outdoor malls in the United States. A retail company that specializes in the sale of items as opposed to services, multiple point‐of‐sale (POS) terminals were required in each store to complete customer transactions.

Originally leveraging a mainframe application for the completion of such transactions, ABC Retail was forced by obsolescence to upgrade its technology to a Windows‐based solution. This Windows‐based solution enjoyed a much greater set of capabilities for tracking orders and analyzing trends in purchases. It, however, also required a network and directory services infrastructure in each individual store. Looking at the possibility of extending its Windows Active Directory (AD) domain along with accompanying server infrastructures out to each and every store, ABC Retail Company began looking for alternatives.

Being a company in more than 100 locations, the idea of distributing server equipment to each store represented an administrative nightmare. With so much distribution of equipment, even the most simple of maintenance processes such as monthly patching would be a painful process. ABC Retail Company needed a mechanism to centralize its infrastructure rather than distribute it to support its new Windows application.

ABC Retail Company also settled on a virtual desktop infrastructure as its solution of choice. Using zero clients as the mechanism for delivering the application's user interface (UI), the company was able to deploy very little hardware to its individual stores. Improving the situation even more was the idea that zero clients could be replaced by nontechnical retail managers when problems occur. If a problem occurred, the manager need only ship the device back to the central IT organization. Replacements were kept on‐site in each store, and reconnecting to the infrastructure and POS terminals involved little more than plugging in and powering on a replacement device.

As a public retail establishment, ABC Retail Company also handles payment cards, which means its infrastructure falls under both the Sarbanes‐Oxley Act as well as PCI compliance regulations. It was easily able to fulfill the requirements of both compliance regulations because it's selected zero clients could connect to payment card peripherals as well as encrypt payment card information as it crosses the wire back to the central office. Payment card approvals were done within the virtual desktop and not in the local store, so any theft of computing equipment could not expose the company to liability. Security of the environment was maximized because all customer data was always stored in the central data center. As a result, ABC Retail Company was able to expand its operations at will without fear of data exposure or loss.

Virtual Desktops Expand Application Access to Everywhere

These are but examples of how virtual desktops can extend the reach of your network infrastructure to virtually anywhere. Whether you're a university looking for a very extensible computer lab or a multinational corporation trying to expand into otherwise impenetrable markets, a virtual desktop infrastructure can extend the business applications on your LAN to where you need them most. Adding a deployment of zero clients to that infrastructure ensures the highest return on your virtualization dollar, while creating an infrastructure that easily scales to your business' needs.