Selecting a XenDesktop Logoff Behavior

I wanted to take a moment and provide some thoughts around selecting the correct logoff behavior for your XenDesktop environment. When working with a pooled desktop environment, the administrator can choose between restarting the virtual desktop at logoff and doing nothing. Below is a screen shot of the two settings I am referring to for a pooled desktop group:

When selecting a logoff behavior, administrators should consider the operating environment since selecting the wrong logoff behavior could have a negative impact on your user experience. In order to see how this could be the case, let’s first look at the logoff process and then apply it to a simple customer scenario. Here are the steps executed when “Restart the virtual desktop” is selected for the desktop group and the user logs off:

1. Virtual Desktop Agent notifies the Desktop Delivery Controller of the user logoff event.
2. Desktop Delivery Controller initiates the shutdown and restart via the pool management service.
3. If the DDC contacted is not the farm master then the request is routed through IMA to the farm master and then executed.
4. The farm master sends a desktop shutdown command to the hosting infrastructure.
5. If the idle pool count is not met the Desktop Delivery Controller then sends a startup command for the desktop to the hosting infrastructure.
6. The desktop boots up, and if streamed from provisioning services anywhere from 90MB (XP) to 220MB (Vista) of data will be sent over during the boot process for the desktop.

When the logoff behavior is set to “Do nothing” the following sequence is executed for each user logoff.

1. Virtual Desktop Agent notifies the Desktop Delivery Controller of the user logoff event.

Probably obvious now is that a significant amount of overhead is avoided by not restarting the desktop each time a user logs off. Now the question for administrators is “when does not restarting the desktop make sense?” In most situations, restarting the desktop is the best answer. However, there are some situations where restarting the desktop after each logoff will impact the user experience. Consider the following basic XenDesktop configuration:

• 2 Desktop Delivery Controllers
• 500 virtual desktops hosted on 10 servers in a single resource pool
• 2 Provisioning Servers hosting a single Windows Vista vDisk used by all 500 desktops

If the 500 desktops in above example are supporting 1200 users across three shifts (400 desktops per shift) then during a shift change the amount of overhead caused by restarting the desktops could be significant and easily introduce user logon delay. When 400 users logoff in a relatively short time span, say 15-20 minutes, you would end up with 400 desktop boot processes occurring. If we pick the longer 20-minute interval, and assume even distribution (best case), that is 20 desktops per minute that will need to reboot (400 desktops/20 minutes).

If you are using Provisioning server to deliver Windows XP desktops, you have 90MB of data traversing the wire for each of those desktops and considerably more for later desktop operating systems. In addition, some hosting infrastructures have a limitation of how many desktops can be started within a given time period for a single resource pool or server. Furthermore, if the XenDesktop farm master is throttled (usually by a registry setting for performance reasons see the XD Best Practices Guide) and has a limited number of outstanding VM management commands then the 400 restart commands will get queued thus further slowing the end user’s response time.

As the number of virtual desktops in the environment increases, the impact of a restart becomes more noticeable. For instance, if we were considering 5,000 desktops across 2 resource pools with the same 3 shifts and 80% utilization, the number of desktops being rebooted in a short time span becomes 4,000. Even splitting this across 2 resource pools would lead to 100 desktops per minute rebooting in each resource pool.

In contrast, setting the desktop group to “Do nothing” provides a much faster response for the users during shift changes and taxes the network and disk infrastructures less. In addition, if the user is routed back to a desktop they have been to before, the user profile update is faster since the entire user profile will not need to be created and loaded.

Of course, like any architecture decision, it has tradeoffs. By not rebooting the workstations at every user logoff, the write cache file for the provisioning services will grow larger than it would if the workstation was rebooted more often. How much larger, really depends on the environment. In addition, if the users are local administrators on the desktops, then user security is at risk because any files left by other users would then be visible to anyone logged on.

In this case, to mitigate the write cache file issue, I would leverage something like Workflow Studio to reboot the 20% of unused desktops in between shift changes. To prevent users from gaining access to left over files, you could not make users local administrators or employ a profile management solution in conjunction with redirected folders to keep the sensitive data stored on remote drives and/or remove the data at logoff.

So, now you have another perspective around designing a XenDesktop farm and something more to consider during your configuration. If you found this posting valuable and would like to be notified of future blogs, please follow me on twitter @pwilson98.

Cross-post