Change management considerations for a VMware View deployment

VMware View implementation can bring your organization clear benefits but can also create tension and territorial infighting among server and desktop IT teams.

Who's made the most noise about virtual desktops in your organization? Is it the desktop management team, which

wants a way to deploy user workstations but also reduce setup time? Is it virtualization administrators, who want to help translate their success in virtualizing servers into time and cost savings for the desktop team? Or is it the lone administrator who wants to take advantage of the existing vSphere environment and reduce time spent on maintaining desktops?

Each group has reasons to want a virtual desktop environment, and I have seen the push come from each direction. Whichever camp you're in, a VMware View deployment affects your job. By understanding how View changes your environment, you can minimize the tension and territorialism among teams and help make a virtual desktop initiative successful.

View's effect on the server team

View's main effect on the server team is a substantial increase in the size of the vSphere environment because of a new vSphere cluster. First, the cost of licensing ESX is dramatically cheaper with View's bundled licensing. Plus, it includes all the necessary ESX hosts with a single license key, so as additional hosts are commissioned, there is no need to add or update ESX licensing.

View Composer's limitation of eight hosts per cluster can also affect the server team. For many environments, the limit becomes a serious scaling constraint. Keep this knowledge in mind, because even by virtualizing desktops on a small scale, you need to plan for future efforts. Remember how we went from server sprawl to virtual machine sprawl in the blink of an eye?

The third effect has trickier security implications. Introducing virtual desktops to a vSphere environment can require allowing administrative access to an entirely new group of administrators. By splitting desktops' virtual machines (VMs) into a separate cluster from your existing server cluster, you can avoid becoming extremely granular with permissions. You should still consider limiting the permissions of the desktop administrators within vSphere (the hosts themselves, for example), but at least you won't have to worry about dividing up VMs.

Next, let's consider the dynamic nature of your vSphere environment. A well-managed and controlled vSphere server environment is relatively static compared with a VMware View environment, especially if you take advantage of nonpersistent pools. After you implement View, the Tasks section of the vSphere client will explode with life. This is neither good nor bad but can lead to more troubleshooting. More moving parts means more places for breakdowns.

The final effect to consider is not vSphere-related but server-based. A highly dynamic environment like VMware View depends heavily on a well-functioning Active Directory (AD) environment. I have encountered View deployments that bring a poorly designed or maintained AD environment to its knees. Particular focus should be paid on the Domain Name System, Dynamic Host Configuration Protocol, organization unit (OU) structures and group policies. In fact, a View deployment may well require a redesign of your OU structure and group policy use.

You also need to consider the use of roaming profiles and folder redirection policies. For many administrators, these are both dreaded topics. but may be necessary to realize the complete vision of a virtual desktop. If properly implemented, however, roaming profiles can work well.

View's effect on the desktop team

If you are a desktop administrator, your world will obviously be affected as well. The biggest impact will be the level of automation and consistency that virtual desktop infrastructure (VDI) brings to desktops.

One of the goals of deploying VMware View should be to take advantage of automation. Tasks such as creating, assigning and decommissioning desktop images can now be accomplished without the intervention of IT. Troubleshooting that previously required you to go to a user's desk can now be done mostly from your desk.

Having a "golden" image of the operating system that everyone can use will allow you to spend less time creating and maintaining images. Since every user has the same operating system environment, troubleshooting issues becomes much simpler. If you can't quickly find the root cause, you can send the user back to the golden image with the click of a button.

Using application virtualization products such as VMware ThinApp can do the same for your applications. ThinApp helps eliminate applications that conflict with one another (i.e., different applications with different Java versions) or with the operating system itself (i.e., applications that don't natively work on Windows 7). All these factors create a less complicated application environment. Plus, you need to install the application only once for all users, which saves the time and pain it takes to install the same application on multiple desktops.

Keys to a successful View deployment

There are, of course, potential bumps in the road. Server and desktop teams that have not traditionally worked closely together now need to be highly coordinated. VDI blurs the lines of responsibility, and it may take time to redefine where they belong. If the two teams don't work together, the infrastructure is virtually guaranteed to fail.

The potential for finger pointing also increases. View is more complex than the traditional desktop model and requires a more advanced and disciplined troubleshooting methodology.

Another critical success factor is strong support from upper management. Implementing View can change processes with implications outside IT. Without strong management support, these changes cannot be maintained, which devalues the infrastructure going forward.

Ultimately, introducing a VDI infrastructure is disruptive to many organizational groups. But if the infrastructure is well designed, if roles and responsibilities are well defined, and if the project is kept on a straight-and-narrow track, it can bring many advantages to your organization.

ABOUT THE AUTHOR: Brian Knudsten is currently a system engineer for a large Midwestern enterprise technology provider with over a decade of IT experience. He is a VMware Certified Professional, a vExpert, the leader and creator of the Omaha-area VMware Users Group and maintains a VMware-related blog called knudt blog. You can follow him on Twitter at twitter.com/bknudtson.

This was first published in July 2010

Dig deeper on VMware basics

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

SearchServerVirtualization

SearchVirtualDesktop

SearchDataCenter

SearchCloudComputing

Close