Citrix Desktop Director is a great tool for your XenDesktop environment. It allows you to manage the VM power states, user assignments, and see session statistics for troubleshooting. That said it’s primary purpose really is integration with XenDesktop. Oh sure, you can use it with XenApp 6.0 and XenApp 6.5 and I do. But the usage is a lot more limited in that scenario. One thing we quickly realized though is that there will always be those outlier VMs that for whatever reason can’t be brokered with XenDesktop. One of the big problems with XenDesktop is that when you assign multiple users to a desktop and one user disconnects, the other users can’t tell who is actually still logged in. We see this quite often with our kiosk machines, and it’s a real pain. In those cases good old RDP still works quite nicely and it has the benefit of TELLING you who is logged in! So in our environment roughly 10% of our total VDI is still dedicated RDP desktops. Problem is we have to manage those, and they are spread over 5 different VCenters. When a user calls our help desk still needs to be able to find the VM, reboot it, etc;
Enter Desktop Director! We have been using it this way since 1.0 and are now on version 2.1. Basically what you need to do is import your RDP only VMs like any other brokered VDI. You will want to put them in their own machine group and turn maintenance mode on for the entire group. If you don’t XenDesktop will start rebooting the VMs over and over trying to force them to register. Trust me that’s not fun. So now you have them imported and assigned to a group with Maintenance Mode turned on. What good does that do? Well, the beauty of Desktop Director is that when you request it to perform power control actions it actually passes the commands through the ESX APIs. So you can look up a VM in Desktop Director and even though it is not brokered with ICA you can still perform all the power control actions like forcing a shutdown or reboot. When your RDP machine (inevitably) hangs your help desk staff can still force the reboot. And if they do need to figure out the VCenter to look at they can find that information within Desktop Director also.
Let’s take it one step further though. Sometimes I need to reboot a server. As far as Desktop Director is concerned a server is just another VDI. So create a machine group called Servers (and again, put it in maintenance mode!) and put all your virtual servers in there that you want to be able to control. It makes on the fly reboots a whole heck of a lot easier when you need to. Just don’t come complaining to me when your change control team has a fit :).
