Virtualization: The Emerging Desktop

Setting up communication with the server
Nothing is offloaded into the client. The server still does all the processing, since it's a virtual environment. To achieve better performance and responsiveness, thin clients must have enough memory and processing power to react to high RDP-based I/O.

Engineers connected the e140 and the HP server through a small switch and a router. The connection was kept simple to maximize performance.

Because the virtual thin client technology is relatively new, solution providers should develop pilot programs to demonstrate the pros and cons of using this environment. This simple deployment installation works well in small remote offices serving less than 15 users.

Installing and configuring the thin client
Installation of Neoware's e140 is extremely simple and only takes a few minutes. A basic RDP connection is the only connection needed into a virtual server. After turning the e140 on, solution providers need to follow similar steps when activating XP's Remote Desktop Connection.

By navigating to Start, Programs, Accessories and Communications, engineers found the Remote Desktop client connection. The name or the IP address of the virtualized XP Pro is all that's required to establish a connection.

Engineers chose to use the IP of the XP instance running on the ESX Server. The thin client immediately connected to the XP Pro and started working. The ESX Server automatically creates new IP addresses, so solution providers only need to know the new IPs to establish connections.

By clicking the options button in the Remote Desktop Connection, solution providers can configure the thin client environment. On the local resources tab, engineers were able to map local resources with the virtualized desktop. All local resources such as sound, serial ports and USB devices can be sent from the XP instance over to the e140 client.

Working with the thin client
Users can get a nice experience with Neoware's e140. However, engineers suspect that network throughput goes up immediately if local sound is turned on. Sound can only be streamed in native form. Turning on other options such as password configuration are useful when rebooting.

Solution providers can configure user name and password, so that when users turn the client on the system automatically authenticates them. Solution providers can also turn off the local rebooting option so that virtualized clients are never shut down. Turning the thin client off will not shut off the OS.

Overall, the experience was identical to using a local PC. This technology has come a long way since the days of Citrix's ICA. Engineers were able to use local USB external drives to load applications and data into the virtualized environment.

Streamlining thin client deployment
Communication on large-scale thin client deployments is usually segmented in a way that most of the I/O occurs between virtual hosts and SAN environments. Network traffic between hosts and SANs have little effect on thin clients communicating to servers.

Companies should see less traffic on corporate networks when using virtual thin client environments, since the peak network traffic occurs mostly inside data centers. Nonetheless, CRNtech engineers recommend installing 30 to 50 clients in a pilot program to study load on a network before moving forward with a large-scale deployment.

Neoware recommends using VMware tools to extrapolate large-scale network requirements based on pilot programs. More importantly, solution providers need to have adequate experience deploying corporate-wide VMware server solutions.

Neoware also sells a less capable c50, which is a Linux-based thin client with less flash memory. Local thin client devices do not play an important role in this infrastructure.

Migrating software to thin client environments
Application and data migration must be factored in when transitioning users into thin client environments. Solution providers working as virtualized domain managers have to put in place steps to image old desktops or re-deploy applications.

While imaging old machines is the easiest way to migrate users, it is actually harder for solution providers to configure every user after transferring images so that they can conform to new policies in a virtualized environment. Standardizing software on every desktop machine before creating images is the easiest method of migrating software.

Since engineers did not image a system, software was installed via the VI client software and a local USB drive through the e140. Engineers used local access from a management desktop to run CDs. Engineers also used Web connections to download applications. This method is slow and repetitive, so it is only recommended when re-installing software at small remote offices.

Next: Tracking Software Licenses And Scanning Ports