Managing XenDesktop Virtual Desktops with ConfigMgr 2012
The XenDesktop offering from Citrix is a popular tool with many companies. However managing ConfigMgr clients on these systems proves to be a difficult task more often than not. This post looks at how to configure XenDesktop to manage clients in ConfigMgr 2012.
My recent customer is going through a proof of concept with ConfigMgr 2012 RC2, in their existing environment they run Citrix XenDesktop 5.6 with the provisioning server to provision virtual desktops. The problem is managing those clients when the systems are rebooted, this problem causes the changes to be lost and cause duplicate entries in the database and you eventually get into a right mess with your database.
With ConfigMgr 2007 Rick Rohne published an article on his blog around using a computer startup and shutdown script via Group Policy to swap out the SMSCFG.INI file which contains the SMS GUID. Attempts to implement this for unknown reasons were failing. After reading up on XenDesktop a little more I found a solution which works.
I know that the problem was caused because of the persistence of settings on the virtual desktop and that as soon as it was rebooted or shutdown this would cause issues.
Installing The ConfigMgr 2012 Client
First, the client needs installing on the master image. Do this using the regular installation method or by using client push. If ConfigMgr is migrated from 2007 then you will need to update the base image otherwise the new client will be installed each time the pooled desktop is restarted.
To allow client push to take place and to allow ConfigMgr to communicate with the clients, the following firewall exceptions are needed on machines running the Virtual Desktop Agent:
- File and Printer Sharing
- Windows Management Instrumentation (WMI)
I appreciate for many this is simple and basic stuff but I just want to cover all bases so everyone has all the information required.
Managing Virtual Desktops Created with PVS
As we stand what we have done will make no difference, the clients will still cause duplication of the GUID and your database in time will look like a forest of obsolete machines. To prevent this from happening we need to make some changes to the write cache.
To ensure any desktops created with Provisioning Services operate correctly with ConfigMgr 2012, you must set the write cache to the target device’s hard drive. Using the Provisioning Services Console, in vDisk Properties, select Cache on device hard drive as the Cache Type. If you do not configure the cache this way, data required by ConfigMgr 2012 is not persisted when the desktops are restarted, which may result in unexpected behavior such as duplicate GUID’s or invalid inventory etc.
Extending ConfigMgr Inventory for XenDesktop
XenDesktop makes available to ConfigMgr 2012 so that virtual desktops can be managed using this tool. The properties are available for the Citrix_virtualDesktopInfo class in the Root\Citrix\DesktopInformation namespace.
The following properties are available. Property names are those used in the Windows Management Instrumentation (WMI) provider:
- BrokerSiteName – The name of your XenDesktop site; returns the same value as HostIdentifier
- DesktopCatalogName – The name of the catalog associated with the desktop
- DesktopGroupName – The name of the desktop group associated with the desktop
- HostIdentifier – The name of your XenDesktop site; returns the same value as BrokerSiteName
- IsAssigned – False for a pooled-random desktop, otherwise true
- IsVirtualMachine – True for a virtual machine, false for a physical machine
- OSChangesPersist – False if the desktop operating system image is reset to a clean state every time it is restarted, otherwise true
- PersistentDataLocation – The location where Configuration Manager stores persistent data. This is not accessible to users.
- PersonalvDiskDriveLetter – For a desktop with a personal vDisk, the drive letter you assign to the personal vDisk
The properties BrokerSiteName, DesktopCatalogName, DesktopGroupName, and HostIdentifier are determined when the desktop registers with the controller, so they are null for a desktop that has not fully registered.
You can display the properties using the hardware inventory in Configuration Manager or using attributes of Configuration Manager objects. When you do, the names may include spaces or vary slightly in other ways. For example, BrokerSiteName may appear as Broker Site Name.
Other properties are available in CCM_DesktopMachine in the Root\ccm_vdi namespace. This is a Microsoft class. For more information on these properties, consult the Microsoft documentation.
Note: When Boolean properties are displayed in ConfigMgr 2012, they may appear as 1 or 0, not true or false.
So as you can see, the management of virtual desktops from XenDesktop/PVS isn’t as daunting as it might first seem, it’s a tricky situation but if you need to manage your clients then this should help. I can only echo what Rick says in his original post which is as members of the V-Allliance, why are Citrix and Microsoft not working towards a cleaner solution.