XenDesktop Design and Architecture Jamie Baker Sr. Escalation Engineer

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

XenDesktop Architecture

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.

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.

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

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

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.

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

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.

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.

Pool Management

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

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.

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.

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 …

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.

USB Redirection

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.

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.

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.

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

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.

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.

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.

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.

Troubleshooting Tools and Tips

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

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

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

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

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!

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

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!

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

Questions??

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 www.citrixeducation.com for more information

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: http://www.citrix.com/techedgesurvey Link will also be emailed to all attendees The TechEdge PPTs will be posted on the Knowledge Center by Tuesday, May 5th