1. XenDesktop Design and Architecture
Jamie Baker
Sr. Escalation Engineer

2. Agenda XenDesktop Architecture Review Pool Management USB Redirection
Troubleshooting Tools and Techniques

3. XenDesktop Architecture

4. This is a high level view of the entire XenDesktop Architecture
This is a high level view of the entire XenDesktop Architecture. There are three major areas that we’ll focus on today:
The controllers and inter-controller communication
The Virtual Machine pools and management of the pools.
The login process and connectivity between the client and the VDA
You also can see here how XenDesktop can utilize Provisioning Server and XenApp to deliver OS’s to the targets and deliver applications to the Virtual Desktops. We’ll separate out each major component and discuss how it works, what it does and how we can get diagnostic data from it if there is a failure.

5. Inter-DDC Communication
Independent Management Architecture
Similar to the role IMA takes in XenApp
Central Data Store
Zone Data Collector handles Dynamic
Store
Limited to one zone
Those of you who are familiar with the architecture of the XenApp Server farm will be very familiar with the XenDesktop DDC farm Architecture. The main components of which are nearly identical to the main components of the XenApp architecture.
The backbone of the Xen Desktop Server farm is the Independent Management Architecture Service. Static Data such as Desktop Group membership is stored in a Central Data Store. Dynamic Data such as VDA assignments and session states are stored in an in memory table on the Zone Data Collectore.
One important difference inherent in the XenDesktop Architecture is that it is limited to one zone. We do not support farms with multiple zones at this time. Geographically dispersed networks should place a separate farm in each location.

6. Inter-DDC communication
Farm Management PC
The Desktop Delivery Controllers serve as the hub for the XenDesktop Architecture. The controllers are responsible for managing the pools of available VDA’s as well as directing and monitoring user’s connections to the VDA’s. For those of you familiar with XenApp, the systems used within the DDC should be very familiar to you. The Independent Management Architecture Service provides inter-ddc communication to share session information, to enumerate session pools for users and to store centralized configuration information.
The DDCs use a central DataStore that contains static configuration information, such as desktop pool configuration, DDC membership and farm settings. VDA configuration data is also stored in the datastore.
Farm Management:
a. Admin opens AMC
b. Configuration change is made
c. DDC updates Datastore
d. DDC updates Data Collector
e. Data Collector updates Farm
2. Session Management:
a. New session initiates
b. DDC contacts Data Collector
c. DDC contacts Licensing Server
Session Management

7. Virtual Machine Registration
On the Virtual Desktop Agent Machine
Citrix Desktop Service
On the Desktop Delivery Controller
Citrix Desktop Delivery Service
Independent Management
Architecture

8. Virtual Machine Registration
In order for the DDC farm to be able to broker connections to the VDA desktops, they must be registered with the farm. During the installation of the VDA on a VM, the farm id for the farm is entered into the registry. This allows the VDA to find the correct farm when querying active directory for DDC’s. The registration process is as follows:
Virtual Machine starts up (either manually or by command of the Pool Management Service)
Citrix Desktop service starts up, queries AD for list of DDCs.
The correct OU is configured either on setup or by GPO in the VDA registry
AD validates the FarmID and sends a list of DDC’s to the VDA.
The Citrix Desktop Service randomly picks one of the provided DDCs and attempts to contact it on port 8080.
The communication is received by the Desktop Delivery Controller Service on the DDC. The VDA is now registered with that particular DDC and that DDC is responsible for it.
The DDC forwards the registration to the Zone Data Collector which enters the information into the Dynamic Store
The Desktop Delivery Controller Service retrieves PortIca default settings from the DataStore and sends them to the VDA.
The VDA sends a heartbeat every 30 seconds to report its availability.

9. Enumeration and Connection
Citrix XML Service
IMA Service
Desktop Delivery Service
Citrix ICA Service
Citrix CGP Service

10. User Authentication and Pool Resolution
When a user is ready to launch their desktop, they open a browser on their client machine and navigate to the Web Interface page. In this diagram we are showing a remote connection through Access Gateway.
The Web Interface page is displayed and the user enters their credentials.
The WI server sends a request to the XML service on the XML broker/DDC server.
XML service authenticates the user through Active Directory.
XML service then resolves the list of available desktop groups for that user
The list is returned through XML to the WI page and displayed for the user.

11. Desktop Connection
Once the user is presented with their available desktops, the process continues.
1. The user clicks the icon representing the desired.
2. WI makes an XML launch request to the XML broker/DDC server
3. The XML broker uses IMA to query the Data Collector for any existing active or disconnected sessions for that user.
If there is no existing session, the ZDC chooses one of the idle VMs and returns it to the DDC server.
The VDA is then notified to begin listening for a connection attempt.
The XML service returns this information to the WI which generates an .ica file
The .ica file is downloaded to the client machine and the desktop receiver initiates a connection to the VDA on port 1494 or 2598.

12. Pool Management

13. Services Involved Citrix Pool Management Service
Hosting Infrastructure
XenServer Pool Master
Vmware Virtual Center
MS SCVMM
Virtual Machines
Pool Master
Pool Management Service

14. Pool Management Virtual Machines Pool Master
Desktop Delivery Controller
Pool Management Service
In order to speed user login and connection, XenDesktop will keep a pool of Virtual machines powered up to receive new connections. This pool can be configured through the AMC. The idle pool allows user to connect to a desktop without having to wait for it to be powered on and booted.
The Pool Management service runs on all DDC servers in the farm, however only the ZDC is actively managing the pool. Failover is similar to the ZDC election process and if the ZDC/primary pool manager goes down, the server elected to the new ZDC will take over.
The pool management service maintains the state of each VDA.
When the pool needs to be replenished, the service makes a call to the hosting infrastructure, either the XenServer PoolMaster, Vmware Virtual Center or Hyper-V.
The call asks for specific VMs to be powered on. The calls are throttled to 10% of the total pool in order to prevent overwhelming the hosting infrastructure.
Once the VDA is registered, then it is added to the pool. If the VDA does not register in 3 minutes, then the pool management service places it in an error state and attempts to start a new machine in its place.

15. Addresses=[http://10. 54. 76. 172,http://10. 54. 76. 173][http://10. 7
In XD 2.0 and 2.1 there was a tool called XenMultiPool.exe that gave you the ability to configure multiple XenServer pools to provide desktops to one desktop group. With the release of 3.0, that tool has been deprecated. Multiple pools can now be configured through the Hosting Infrastructure Options screen during the Desktop Group creation Wizard.
One weakness of the design of the 2.x product was the need to manually configure a new pool master if your hosting Xenserver pool master needed to be changed. In 3.0 we’ve added the ability to configure a secondary pool master in the same location. So now if your XenServer pool fails over to a secondary master, the Pool Management Service will also know to fail over to the secondary Pool Master.
The pools are configure by pressing the options button and then entering the parameter Addresses= with the pools separated by square brackets and the masters in that pool separated by a comma.

16. Pool Management Virtual Machines Virtual Machines Pool Master
Desktop Delivery Controller
Pool Management Service
Virtual Machines
Pool Master
The behavior of multiple pools allows you to assign desktop to a single desktop group from multiple pools. It is not in and of itself a failover mechanism. The Pool Management service from the primary ZDC will connect to the pool master of each pool to manage the particular VM’s in both zones. VMs for the idle pool will be started from both of the pools. If one pool goes down, the VM’s in that pool will not be available. One other point to note when using this configuration. The user name and password entered into the wizard to control the pools must be the same for all pools configured. There is not mechanism for multiple credentials in the pool management service for a single desktop
But, by adding a backup pool master to the configuration …

17. Virtual Machines Pool Master Desktop Delivery Controller
Pool Management Service
You allow redundancy for each individual pool. So if there is a problem with the master for a particular pool and it is failed over to a secondary master for any reason, the pool management service will seamlessly fail over to use the secondary master to control VM’s in that pool.

18. USB Redirection

19. Device information Identifying a device
Descriptors
String, Device, Configuration, Interface, Endpoint & more
Device/interface classes & subclasses
Mass storage, Image, etc.
Devices are identified through a set of descriptors. The device descriptor gives the vendor, product and revision Ids, and also the index of the string descriptors for the manufacturer, product and serial number strings.
The device descriptor can also identify the class of the device – mass storage, image, audio, whatever.
However, many devices have this defined on a per-interface level (such as webcams – one interface for audio, one for video).
Also, many devices are vendor-specific devices, so use the vendor-specific class and subclass codes.
Each device can have multiple configurations, although only iPods/iPhones actually do.
Devices could use multiple configurations for controlling power requirements (for example). Only one configuration can be active at a time.
However, Microsoft’s Windows drivers don’t support multiple configurations – the device vendor would have to write their own special device driver that explicitly selects the other configurations (Apple has done this). Not impossible to do, but there’s no hand-holding – none of the frameworks support it.

20. Modified components Modified components Policy
Presentation Server console, IMA, DDC, PortICA configuration defaults
PortICA configuration schema
PortICA service
Workstation Agent
Desktop Toolbar
Policy console – for on/off USB policy control
IMA – for storing USB on/off policy
DDC – for sending USB on/off policy to VDA
PortICA configuration defaults – for storing default USB on/off policy. Also for the fine-grained USB device control (real defaults built-in; use GPO to change/update).
PortICA configuration schema – modified to allow passing the USB on/off policy, and also the fine-grained policy.
Workstation Agent – reads GPO and in-built policy defaults from registry, puts into PortICA configuration XML to send to the PortICA service.
PortICA service modified to store the received configuration for later access by the USB service.

21. New components New components Citrix USB Service Citrix USB bus driver
Protocol handling, Policy lookup and enforcement
Citrix USB bus driver
Presents devices to system
ctxusbf.sys – USB filter driver
Filter on all USB devices
ctxusbr.sys – USB redirection driver
‘Dummy’ device driver for redirected devices
vdgusbN.dll – USB virtual channel
USB service receives the data from client via ICA stack
Sends data packets to the Citrix USB bus driver.
Also performs policy checking and enforcement.
Parses only one packet – the announce packet which an endpoint sends to tell the VDA that there’s a new USB device to access remotely.

22. Endpoint / VDA relationship
Before Redirection
/ Not Redirected
Once Redirected
Desktop Receiver
(client)
Virtual Desktop Agent
(PortICA)
Apps
Apps
USB Redirection Manager
ICA Client
PortICA stack
USB Service
Standard
Drivers
Standard
Drivers
Interception driver
(pass through)
Interception driver
Blue blobs are Citrix components that are new
Grey blobs have been modified (slightly)
Orange are standard system components, or 3rd party drivers/applications – unmodified.
Far right-hand side shows an ordinary device stack, with the actual device-level components replaced by our bus driver.
Far left-hand side shows a non-remoted device stack, with out interception driver (ctxusbf.sys) in passthrough mode. MS
USBHUB
Citrix USB bus driver MS
USBHUB
Device
Device

23. User mode components Workstation Agent Citrix USB Service
Policy handling
Read from GPO registry keys
PortICA configuration
Written into configuration sent to ICA service
Citrix USB Service
Policy reading (from configuration)
Policy enforcement
Data pump
Fine-grained USB policy
Read from GPO section of the registry, merged with built-in defaults (which are also in the registry).
Sent to the ICA Service in the usual way that the XML configuration is sent.

24. Kernel mode components
Citrix USB bus driver
Control device – communication with USB Service
Device stack – Handles
IOCTLs from function drivers
Certain interface requests (e.g. USB_BUS_INTERFACE_USBDI_V0)
IOCTLS are mostly used to send URBs (USB Request Blocks) to bus driver.
URBs are majority of how USB transfers take place. Some specialised URBs for certain control transfers (e.g. Selecting an interface).
A few other IOCTLs for other information.

25. Desktop Receiver ctxusbf.sys – USB filter driver
Upper class filter on USB hubs
Lower filter on device stacks
Reads policy from registry:
HKLM\Citrix\ICA Client\GenericUSB\DeviceRules
HKLM\Policies\Citrix\ICA Client\GenericUSB\DeviceRules
Changes VID & PID on-the-fly
Not loaded for non-hub USB class devices.
Hub filter then loads as lower filter on device stacks; loaded for every device, but can operate in passthrough mode.
The filter driver reads the fine-grained policy from the registry in the same way that the Workstation Agent does on the VDA (note: different registry key), and checks each device against the policy. Denied devices remain local; allowed devices get remembered as being allowed until the client tries to grab them.
Toolbar grabs a device by setting a reservation, then having VD restart it; filter then grabs device by changing IDs. Grab-on-insert and Ask functionality does the same sort of thing, except that the filter knows that the focused client is interested in devices so they get grabbed immediately. If device isn’t wanted (either user doesn’t grab with the Ask dialog, or server rejects device) then device gets restarted again and filter allows it to go local.
Allowed devices get their VID and PID changed on-the-fly so that Windows will not load the normal Windows driver, but use the Citrix redirection driver instead.

26. Desktop Receiver ctxusbr.sys – USB redirection driver
‘Dummy’ device driver
Command pump for Host-to-Client commands
Sends responses back to client
Handles asynchronous URBs
vdgusbN.dll – USB virtual channel
Communicates with toolbar
Data pump to/from server/client
ctxusbr.sys:
Dummy driver used to prevent the OS from driving the device
Also used for sending URBs etc. received from the VDA via the client to the real hardware device.
Sends certain URBs asynchronously – particularly important for interrupt transfers.
vdgusbN.dll:
-Handles communication with the toolbar – activates the icon etc.
Is present in both normal and desktop appliance modes.
Only does toolbar interactions with the normal mode client.

27. Troubleshooting Tools and Tips

28. VDA registration issues
XDPing tool
Services on the DDC
Networking
DNS
Desktop Service Logging
CTX117452
CDFControl

29. Pool Management Failures
Logging in Pool Management Service
CTX117452
XenServer logs
CDF Tracing
XDPing tool

30. Desktop Connectivity Failures
CDF tracing
Event Logs on VDA
Standard IMA resolution troubleshooting
Standard ICA connection troubleshooting
Network tracing
XDPing

31. Case Study - User Association with a VDA is Lost
Username shows as "-" in AMC
User cannot reconnect to session once disconnected
User token is captured by ctxidhlpr.exe on session start
Token is not cached
Restart of the Desktop Service loses the token

32. Case Study - User Association with a VDA is Lost
The desktop service does not get user token on re-launch
Reassociate the token by running ctxidhlpr.exe in the user session
Do Not Restart the VDA Desktop Service without reason!

33. Case Study – Pool Management Churn
Idle pool spins up several VDAs
Registration does not take place in 3 minutes
Pool Manager Starts up more VDAs
Eventually all register
Pool Manager shuts down extra VDAs

34. Case Study - Pool Management Churn
Pool Management Logs
Desktop Service Logs
Performance Logs from Hosting Infrastructure
XDPing test to FQDN of the VDA
Correctly Size Your Hosting Infrastructure during transitional periods!

35. Recap XenDesktop Architecture is similar to XenApp Architecture
XenDesktop 3.0 provides:
XenServer Pool Master failover
USB device redirection
Use plaintext logging and XDPing for troubleshooting

36. Questions??

37. Visit www.citrixeducation.com for more information
Continue Your Learning
The following course expands on today's topics and is recommended to support your Citrix solution:
CXD-200 Implementing Citrix XenDesktop 3
Visit for more information

38. TechEdge Survey & Posting of PPTs
If you complete the survey, you will be entered to win the $250 Amazon gift card.The winner will be announced May 29th
TechEdge survey link:
Link will also be ed to all attendees
The TechEdge PPTs will be posted on the Knowledge Center by Tuesday, May 5th