There are several approaches or strategies in attacking your VMware VDI desktop deployment from a design standpoint. Most organizations enter their architecture
with hesitation and reserve using a very static approach. They plan to map desktop users 1:1 each desktop user will be given a dedicated virtual desktop
and some division or swag is made regarding how many desktops they can concurrently run on each VDI server.

Really there is nothing wrong with that. Probably one of the most difficult tasks in planning a desktop migration, particularly when moving from a distributed architecture to a centralized architecture; is profiling your users, understanding the desktop compute cycles they need, and centralizing that in a
fair-share scheduling model. Because of the difficulty and effort required in looking at every user across the enterprise and coming up with a methodology that makes sense then getting the design right out the gate. I am a fan of getting sets of common users onto a VDI architecture and studying their usage patterns.

Ultimately a static 1:1 approach is not going to yield the highest return on your dollar. The more dynamic you allow the architecture to become. The higher
return you will realize. Often when I meet with customers and discuss their VDI architectures I talk about the concept of oversubscription. Oversubscription is
stepping outside the bounds of asking how many desktop users per core can I get, really understanding your users usage patterns, and figuring out how
many more users can be allocated per server by oversubscribing.

In most enterprise and office environments, as you walk around you will find large populations of empty cubes and idle desktops. Business is constantly changing and in order to stay competitive companies are being forced to change the workplace. More people are teleworking, using flexible work schedules and becoming more mobile. When users are in two hour long meetings or on conference calls several times a day, typically they are not using their desktops. When three out four people are not working on an exact 9-5 schedule the number of concurrent users is reduced. All of this combined results in an opportunity to revisit going beyond static VDI architectures making them more dynamic and oversubscribing the servers. With this approach mileage may vary in different cases. For example, a contact center environment where users are heads down, might not realize the same benefits.

As VMware VDI deployments have continued to grow and mature, customers are starting to explore unlocking the full potential of VDI. They have realized the benefits of VMware virtualization technology and are looking to gain more. As customers take a more centralized view of their desktops, they are realizing how underutilized or idle they are. It’s becoming clearer, oversubscribing the servers might not be that risky and the rewards could be great. Ultimately, this leads to a new set of questions as the creative juices start to flow.

There are several tools that can be used to harness the full potential of your VDI solution and make it more dynamic. In addition, it can actually be really simple or it can be more elegant. Each approach and the pro and cons of each is beyond this blog post. However, several customers have asked me to write about this and address some of the more simple or tactical questions.

As customers look at making their VDI environments more dynamic, The most popular question I get today is " How do I logoff idle users" followed by " How do I power off or suspend their virtual desktop". Recently I have been working with the VDI team at a collage who really wanted to do this and I felt obliged to help.

The solution is simple - VMware VDM 2 has a power policy for virtual machines that allows you to suspend or power off a virtual desktop instance when not in use. When a user logs off, it automates suspending or powering off that desktop. Ultimately this frees up the resources making them available to other desktops on the ESX server. If you think of those users on a flexible schedule or in a meeting there is no reason they need to hold up resources when idle.
Logging off these idle users is as easy as implementing a simple GPO in Active Directory that tracks idle time as well as those pesky disconnected RDP sessions.

Under the Local Computer Policy\Computer Configuration\Administrative
Templates\Windows Components\Terminal Services\Sessions folder, the following settings can be made:

• Set time limit for disconnected sessions
• Set time limit for active sessions
• Set time limit for idle sessions
• Terminate session when time limits are reached

Or

Under the Local Computer Policy\User Configuration\Administrative
Templates\Windows Components\Terminal Services\Sessions folder, the following
settings can be made:

• Set time limit for disconnected sessions
• Set time limit for active sessions
• Set time limit for idle sessions
• Terminate session when time limits are reached

Note: Windows XP has a bug where the idle tracker will not work. You
need to request a hot fix from Microsoft in order to resolve it. See KB890864

The result in the combination of the VDM 2 power policy and this simple GPO is idle users are logged off at a time interval you set, and their virtual
desktop is powered off or suspended. Simple to implement with large benefits.

To protect you from oversubscribing too far, increasing the SLA of your desktop users, and making the environment more dynamic. VMware DRS and VMotion can be added. If you are more aggressive with your oversubscription using VMware DRS you can set a threshold that ensures your users are not affected. For example, if you know your virtual desktops perform best at 8 users per core, but have over subscribed to 16 user per core; expecting only 50% are concurrent at any given time. VMware DRS/VMotion will ensure the 9/10/11 user per core is run from another ESX server with available resources. This can be as simple as having a standby server or allocating the sessions across other underutilized servers in the cluster.