2. 603D: The Ultimate XenDesktop 5.x Troubleshooting Workshop
Fred Donovan
Senior Support Product Manager
Rene Alfonso
Hello and welcome to our session on Troubleshooting XenDesktop.
Let’s get things started today with a simple question
What’s going to keep us from a successful XenDesktop deployment?
It’s going to depend on us and our ability to overcome any technical hurdle or challenges we may face. Our environments today have gotten more complex with a lot more moving parts.
Think of that last time you had to troubleshoot an issue. Was it a negative, positive, or frustrating experience? What‘s the key distinction between those experiences.
Its about being prepared
Having the knowledge of architecture, tools and techniques in place before an issue occurs can help us over come any potential obstacles we may encounter in the most efficient manner. That’s what we are going to be discussing today. Troubleshooting XenDesktop using Citrix Tools..
Before we go any further let me introduce our team today. My name is Rene Alfonso Citrix Support Architect and I am joined today with Fred Donovan Senior Support Product Manager.
Our facilitators are
Architect, Technical Support
May 2012

3. Session Topics Brief Architectural Review XenDesktop Troubleshooting
 Lab
VDA High Availability Mode
 Lab
XenDesktop 5.x Database
 Lab
Personal vDisk Troubleshooting
Objective to provide you guys with the necessary survival skills to deal with typical issues so you can get a raise and have your weekends off
 Lab
Next Generation Support: TaaS

4. Brief Architectural Review XenDesktop
Quick poll
How many attendees using XD 5.6?
How many attendees on XD 5.x?
How many attendees on XD 4.x?

5. The XD DDC Core Architecture
XenDesktop 5.x
Controller Services
Machine Creation
AD Identity
Machine
Identity
Host
Configuration
Broker
XenDesktop 4.x
Controller Services
Pool Manager
VM Host
Web Svc
Domain Controller
LDAP
HTTP WI
80, 443
XML Service
Workstation (VM or blade PC)
VDA (VM or blade PC)
WCF x
80 5.x
Controller Service
Desktop Service
CGP Svc
PortICA Drivers
PortICA Svc
ICA
CGP
Client (via AG)
1494
2598
DDC Servers
IMA
2512
First lets take a look at the previous generation of XD architecture XD 4. We see the different services and their various roles.
In XD 5.x the architecture has been completely changed, and the database model has changed as well.
Note on the VDA side CGP service is now a part of the kernel stack in 5.x.
Broker: Brokers connections to desktops
Configuration: Stores service configuration information
Host Service: Manages hosts and hypervisor connections
Machine Creation: Creates new virtual machines
AD Identity: Manages Active Directory computer accounts
Machine Identity: Manages virtual machine storage (Diff Disk)
Delivery Services Protocol Transition: Provides for impersonation of an arbitrary user via protocol transition
Diagnostic Facility COM: Controls Citrix diagnostic trace sessions on the system
ICA File Signing Service: Adds a digital signature to ICA files
Licensing
License Server
Data Store
ADO

6. Broker Services XenDesktop 4: SSL XML IMA CDS Pool Management
443 80
SSL
XML
IMA
CDS
Pool Management
XenDesktop 5:
443 80
Broker Service
The broker service uses 443/80 and incorporates functionality of XML, IMA, CDS and Pool Mgmt from XD4. The broker service has several components and interacts with various XenDesktop components outside of the Delivery Controller such as the License Server, VDAs, WI, AG, Netscaler, hypervisors and the SQL database.
Database Management
XML components
Hosting Management
PowerShell SDK
VDA Management
Licensing

7. New Desktop Delivery Controller (XD5.x)
IMA Service is replaced by various .NET services communicating over Windows Communication Foundation (WCF)
New relational SQL database
No controller to controller communication  each controller talks to the database
SQL Database
DDC1
DDC2
Improved scalability
Improved resiliency and fault tolerance
Stateless controllers and a simplified database schema
Simplified architecture leveraging single service
More agile, allowing more rapid feature development
.NET platform to reduce terminal failures
We aimed for were better scale and resilience.  In XD5, we could pull the brokering logic together – into a single service, to simplify it and reduce the number of ways it could fail.  Having a ‘proper’ database schema and ‘stateless’ controllers is part of that too.  The .NET platform should also mean less outages / terminal failures.
Why WCF is important? (AD – Kerberos dependencies)

8. Controller 5.x Roles & States
Controllers no longer hold state information; it is now located in the database
No Local Host Cache
Hypervisor connection maintained by one controller
(Get-BrokerHypervisorConnection)
Database
Controller#2
Controller#1
No local host cache
Get-BrokerHypervisorConnection – Useful for troubleshooting –
Fail over will occur in the event if the controller becomes unavailable
Example of output
Capabilities               : {PowerOn, PowerOff, SuspendResume, Reset...}
HypHypervisorConnectionUid : 0XXXXXX-XXXXX-XXX-XXXXXXXXXXXXXX
Name                       : XenServer_xx
PreferredController        : Domain\Controller#1
State                      : On
Uid                       

9. High-level Service-Oriented Architecture
Desktop Studio
Desktop Director
WinRM (WMI)
PowerShell
SDK available for automation
WCF
Desktop Delivery Controller
Virtual Desktop
Configuration Service
Broker Service
XenDesktop 5 has a new Service-Oriented Architecture with the Broker Service, Configuration Service, Host Service and
Machine Creation Services ( Machine Creation Service & AD Identity Service & Machine Identity Service )
PowerShell SDK interface allows both for automation and troubleshooting
Host Service
Machine Creation
Service
AD Identity Service
Machine Identity Service
SQL Server

10. VDA Registration (CTX126704)
Allows Broker to control VDA
Power Management
Open TCP Ports
3 Strikes before VDA is placed in Maintenance Mode
(MaxFailedRegistrationsAllowed)
After a period of time (20 Min) unsuccessfully registered VDA shutdown
(MaxRegistrationDelayMin)
Sliding window
Registration is critical for users to connect – If there is a registration issue the user will not be able to connect to their desktop.
ListOfDDCs is checked first; if it is not configured then we look for AD discovery if it is configured; this assumes Service Connection Point obbjects (DDCs) exist in the configured OU in AD
Active Directory-Based Controller Discovery
To perform AD-based controller discovery, run the PowerShell script Set-ADControllerDiscovery.ps1 that is installed on each controller in the folder $Env:ProgramFiles\Citrix\Broker\Service\Setup Scripts.
DesktopServer\MaxRegistrationDelayMin
Period after which a power-managed VM is started by the broker service. Power-managed VM shuts down if it does not subsequently register with a DDC. 20 minutes The broker assumes something is wrong and shuts the VM down again
DesktopServer\MaxFailedRegistrationsAllowed
Defines the number of times this is allowed to happen (in sequence without a successful registration in between occurrences) before the VM is deemed bad and automatically put into maintenance mode. Defaults to a value of 2 if not present (so with this value of 2, VMs that fail 3 times in a row get placed in Maintenance Mode). A negative value for this entry disables event automatically putting VMs into Maintenance Mode.
The script must be run on a controller in the site by a user who is a full administrator of the controller and who has the appropriate permissions to make changes in the relevant OU in AD. For more information about the script, see Active Directory Considerations.

11. VDA Registry Based Registration
VDA initiates communication over WCF and provides its SID
Broker Verifies Computer AD Object
Broker then communicates directly to VDA
Broker verifies the VDA in
database and sends
information
Registration Success Results
VDA initiates communication over WCF and provides its SID
VDA
Broker verifies computer AD object
Broker then communicates directly to VDA
Broker verifies the VDA in database and sends configuration information
Controller
Trace Event Broker:IRegistrar.Register called
Trace Event Broker:IRegistrar.Register exit: result True
32 bit:
HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgent\ListOfDDCs (REG_SZ)
This string value takes a space-delimited list of Desktop Delivery Controllers, each specified by Fully Qualified Domain Name (FQDN) (for example, myddc.mydomain.com). If the ListOfDDCs value is set the Virtual Desktop Agent uses this list instead of the farm OU as long as the FarmGUID value (HKEY_LOCAL_MACHINE\Citrix\VirtualDesktopAgent\FarmGUID) is not present in the registry. The FarmGUID value is set if a farm OU is specified when the Virtual Desktop Agent is installed.
Registry Path HKLM/Software/Citrix
Key Name DesktopServer
Value Name HeartbeatPeriodMS
Type DWORD
Default Value 60000
Comments
Installer
Registration completes successfully

12. Broker service and VDA registration (XD5.x)
Registry based VDA registration from ListofDDCs registry key on the VDA
Uses WCF/ Connection Brokering Protocol
Validates VDA, test call-back and writes state into database
VDA broker service role handles launch sequence, status updates and session control
Registration Types:
Soft – sets up minimal ping support to maintain heartbeat
Hard – fully configures the VDA with desktop group membership
Registration
The workstation agent service on each desktop machine will attempt to register with a broker service instance on a controller via the broker’s ‘IRegistrar’ WCF service. Each registration request received is validated, including a test WCF call-back to the VDA, and if successful, the data transferred in the registration request is written to the state area of the broker database. Registrations can be ‘hard’ or ‘soft’, the difference being whether the desktop machine has been configured to be a member of a desktop group yet or not; ‘hard’ registrations configure the VDA fully whereas ‘soft’ registrations only set up the minimum ‘ping’ support to keep the registration alive. Each controller machine can be configured with a maximum number of VDA machines that it will accept registrations (hard or soft) from.
Launch sequence
During a resource (desktop or application) launch, a number of WCF transactions occur between the chosen VDA workstation agent and the broker service. Some of these are initiated by the broker service and some are initiated by the workstation agent service. See the launch sequence end-to-end example for some extra detail of these WCF transactions.
Status updates
When some status value on the VDA machine changes (eg session state, user logged in, PortICA stack state etc.) the VDA asynchronously informs the broker service of the new state value via a call to a WCF service offered by the broker service. The broker service stores this data in the broker state schema of the database.
Session Control
The broker can control the session on any desktop machine via use of a WCF service offered by the VDA workstation agent; the sessions can be disconnected or terminated, and a message can be displayed to the user of the session. Typically these session control actions originate from an administrator and the broker service receives then as SDK commands.
Open TCP Ports 1498
Hyper Visor Power Events
Broker License Events
Reconnect to disconnected

13. Under The Hood: VDA Registration (Active Directory)
DDC Server
Broker Service
VDA
DDC
WCF
Desktop Service 
Service starts and looks up the farm OU in the registry 
Service looks up VDA computer account 
DDC checks that computer account (SID) is valid in AD 
Service queries DC for all Service Connection
Point objects (DDCs) in that OU 
Controller initiates WCF connection to VDA (using peer IP address and Kerberos ticket) 
Service selects one DDC at random, looks up DDC computer account and initiates a connection through WCF
LDAP
Active Directory-Based Controller Discovery
To perform AD-based controller discovery, run the PowerShell script Set-ADControllerDiscovery.ps1 that is installed on each controller in the folder $Env:ProgramFiles\Citrix\Broker\Service\Setup Scripts.
The script must be run on a controller in the site by a user who is a full administrator of the controller and who has the appropriate permissions to make changes in the relevant OU in AD.
For more information about the script, see Active Directory Considerations.
Now let’s take a look at some of the key steps of the registration process…
Publishing with Service Connection Points
The Active Directory Schema defines a serviceConnectionPoint (SCP) object class to make it easy for a service to publish service-specific data in the directory. Clients of the service use the data in an SCP to locate, connect to, and authenticate an instance of your service.
More details on the actual SCP object: 
Controller validates that caller is member of “Controllers” group, and sets configuration 
OS retrieves Kerberos ticket for DDC AD 
DDC service receives connection (Kerberos prevents man-in-the-middle) 
Connection succeeds and VDA is marked registered

14. CDF Tracing and CDF Control

15. Introduction to Citrix Diagnostic Facility Tracing
What is CDF tracing?
A unified debug tracing system integrated into various Citrix products
It is high performance tracing, supported by the Microsoft OS (ETW)
It allows various components, such as DLL’s, EXE’s and drivers to be traced
A single architecture that an Engineer can leverage to troubleshoot problems
XenDesktop, XenApp, Receiver

16. Introduction to CDFControl (CTX111961)
A GUI based CDF trace capture and analysis tool was developed
Expert Control Feature
Dynamic TMF file download feature:
TMF files are automatically downloaded as needed and temporarily stored in the user’s temp directory. These files are deleted automatically after use.)

17. Expert Control Expert Control finds the messages that are *meaningful*
Known issues are automatically flagged
Knowledge Base articles are automatically launched

18. XDPing Tool (CTX123278)
Can be run on both the DDC and VDA to troubleshoot registration issues
Used to collect data related to basic components
Will verify if the components are working correctly
Verify Domain Membership
Network Interfaces
WCF Endpoints
Services
DNS lookup
Time difference between machine and Domain Controller
Description
The XDPing tool is a command-line based application which automates the process of checking for the causes of common configuration issues in a XenDesktop environment. The tool can be used to verify configuration settings on both the XenDesktop Broker and VDA machines, both from the console and remotely.
Depending on how the tool is run, and from where, the following checks and information can be displayed:
• Information and status of Network Interfaces and Network settings. (Console Only)
• Performs DNS lookup and reverse lookup on the IP address of the device.
• Information on Time synchronization and time check for Kerberos Authentication (Console Only)
• User information for login User (Console Only)
- Including User details, Authentication type used, Group Membership.
• Machine information (Console Only)
- Environment information (Computer Name, operating system version, Domain)
- Domain membership verification (Membership = Verified, SID:S-X-X-XX-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-XXXXX [OK])
• Information on XenDesktop Services (Windows Communication Foundation Endpoints) installed and confirms if each installed service in responsive. (Console Only)

19. Troubleshooting Tips for VDA Registration Issues
Check Domain Membership /Time Synchronization
Check value under HKLM\Software\Citrix\VirtualDesktopAgent\ListOfDDCs
Check Citrix Desktop Service warnings and errors
Look under Error Details for the exact condition
Get-BrokerDesktop -MachineName DOMAIN\MACHINE
LastDeregistrationTime LastDeregistrationReason VALUES
See CTX for details
XD 5
Note: By default, controller discovery is registry-based, and XenDesktop requires no objects to be created in Active Directory. For more information about the registry entries used by registry-based discovery, see:
HKLM\Software\Citrix\VirtualDesktopAgent\ListOfDDC
HKLM\Software\Wow6432Node\Citrix\VirtualDesktopAgent\ListOfDDCs
Citrix Knowledge Base article CTX117248
Virtual desktop not firewall not properly configured
If the firewall on the virtual desktop machine has not had the appropriate exclusions configured to enable DDC’s communication, registration will fail. As an experiment you should try disabling all firewall software on the VDM and restart it. If registration now succeeds, the problem points to mis-configuration of the firewall; reconfigure it as described in CTX – Desktop Delivery Controller 2.0 Administrator's Guide and re-enable it.
Note: It is not advisable to run with the firewall permanently disabled on virtual desktop machines!
Domain Name Services (DNS) not properly configured
If the VDM or the DDC controller sees an incorrect IP address for the other party, registration will fail. To see if this is an issue, the following experiment should be attempted:
On both machines, launch a command shell window and run the following commands:
ipconfig
ping <othermachine.domain.com>
Both machines should be able to ping each other successfully by DNS name (this means using the fully qualified domain name (FQDN) including the domain.com bit and not the simple NetBIOS name). Crucially, the IP address reported for the remote machine by the ping command in each case should match the IP address reported by the ipconfig command on the relevant machine.
If there is any discrepancy, fix the problem with your DNS configuration and restart either the VDM and/or the DDC controller, as appropriate.
Time synchronization not properly configured
The communication between VDMs and DDC controllers is secured using Kerberos. This relies upon Tickets with a limited life span. If the difference in system time between the two ends of the communication is too great, the Tickets will always be considered to have timed out when they are accessed and communication fails.
Check that the system time on all systems are within a reasonably small margin (the default domain-wide Kerberos setting is 5 minutes).
XenDesktop 5 Controller VDA Registry Key
Verify the following registry key has correct information
(x86) HKEY_Local_Machine\Software\Citrix\VirtualDesktop
(x64) HKEY_Local_Machine \Software\Wow6432Node\Citrix\VirtualDesktopAgent\ListOfDDCs
ListOfDDCs REG_SZ
Also view event log entries from Citrix Desktop Service for related information
PowerShell example on local VDA Machine
Get-EventLog -Log Application -Source 'Citrix Desktop Service' | fl
Powershell example on remote computer
Get-WinEvent -Computer <machine-name> -Old -Prov 'Citrix Desktop Service' | fl
where <machine-name> is the DNS name of the VM
Domain membership problems
Under some circumstances, it can appear that a machine (VDM or DDC controller) is properly a part of a domain, but in fact is not (for various reasons). This can cause problems with the secure communication between VDMs and DDC controller.
Try removing the machines in question from their domains (by temporarily moving them into a workgroup, for example) and then subsequently rejoin them to their domains. When the subsequent system restart has completed, check to see if registration has been successful.
Service Principal Names (SPNs)
Communication between virtual desktop machines and DDC controllers uses Microsoft’s Windows Communication Foundation (WCF). The services implementing the communication endpoints use the computer’s identity. Thus, WCF’s mutual authentication model uses the SPN associated with the respective computer accounts (by default, HOST/host’s-fully-qualified-domain-name). The DDC determines the virtual desktop’s SPN by inspecting the servicePrincipalName attribute of the associated computer account in Active Directory.
You can inspect the virtual desktop’s computer account using tools such as Active Directory Explorer; if the servicePrincipalName attribute does not include an entry with the computer’s fully qualified domain name, try editing it manually and check to see if that fixes registration problems.
Multiple Network Adapters
If the virtual desktops contain multiple network adapters that can be used to communicate with the DDC, this may cause the security negotiation to fail. In that case, try disabling all network adapters except for the one used to communicate with the DDC.

20. Lab #1 VDA Registration Troubleshooting

21. Lab Environment URL http://training.citrixsynergy.net/
Class Code: <Provided by Instructor>
Requirements Latest Citrix ICA Client

22. Citrix Scout / XD Collector (CTX130147)
Push button easy data collection system
Makes data collection and upload push button easy
Integrates data collected by Scout with the Citrix Tools as a Service (TaaS) backend
Simplifies data collection & analysis
Citrix Scout used to collect environment information and CDF traces
XenDesktop Collector the replacement for Scout with the next Feature Pack release of XenDesktop

23. HDX Monitor 2.x (CTX123058) VDA User Experience Monitoring Diagnostics
Configuration
Performance
Remote VDA Monitoring 2.x
Available for XD5.x XA 6.x
Platforms Supported:
Windows XP SP3 (32-bit and 64-bit)
Windows Vista SP2 (32-bit and 64-bit)
Windows 7 RTM (32-bit and 64-bit)
The software will automatically install on your virtual desktop using Microsoft ClickOnce technology. It will also keep the software up to date with new versions we publish.
HDX technology is a set of capabilities that delivers a “high definition” desktop virtualization user experience to end users for any application, device or network. These user experience enhancements balance performance with low bandwidth – anything else becomes impractical to use and scale. HDX technology provides network and performance optimizations to deliver the best user experience over any network, including low bandwidth and high latency WAN connections.
Changes from HDX v1 to v2:
Remote monitoring
Additional Info: Scanner, Printers, Client Drives, System Information, 3D Graphics

24. Lab #2 HDX Monitor

25. XD PowerShell SDK XenDesktop 5 built on PowerShell
Desktop Studio PowerShell Tab
Citrix Developer Network
Code Share
SDK Documentation

26. Checking Broker State PowerShell for troubleshooting
Add-PSSnapin citrix*
Get-BrokerServiceStatus
Returns OK if broker service is responding to requests
Get-BrokerDBConnection
Displays SQL connection information
Get-ConnectionLog *New in XD 5.6
Displays user connection history both success and failures
Switch can be added to prevent warnings after initially loading the snapin -ErrorAction SilentlyContinue

27. Lab #3 PowerShell

28. XenDesktop 5.x VDA High Availability Mode
ICA
File
Dedicated Virtual Desktop
ICA Connection
ICA Ports
1494
2598
VDA Registration
SQL Database
Another key area we would like to discuss is troubleshooting the high availability feature in XenDesktop. This feature allow users to connect to their desktop in the event of a complete controller outage. After 5 minutes if the VDA cannot communicate with the controllers it will go into HA mode. Note this needs to be enabled in the registry.
Controller1
Controller2

29. XenDesktop 5 HA Mode (CTX127392)
VDA can operate in high availability mode if all controllers fail in a XenDesktop 5 site
Dedicated Desktops Only
Registry enabled –
HighAvailability REG_DWORD 1
Configurable time period (default 5 minutes)
Must register with controller within 30 days
Prompt for password EnforceAutoLogon
REG_DWORD 0
High Availability of the Virtual Desktop Agent
Updated:
If all controllers in a XenDesktop site fail, you can configure the Virtual Desktop Agent to operate in high availability mode so that users can continue to access and use their desktops. In high availability mode, the Virtual Desktop Agent will accept direct ICA connections from users, rather than connections brokered by the controller.
Note: This feature is for use only on the rare occasion that communication with all controllers fails; it is not an alternative to other high availability solutions, such as configuring database fault tolerance and site failover. Before using this feature, refer to the list of limitations below as these have security implications.
If communication with the controller fails, high availability mode is initiated only after a set period of time has elapsed. By default, this is 300 seconds (5 minutes) but you can configure the time period.
Once in high availability mode, the Virtual Desktop Agent will attempt to register with a controller for up to 30 days, while the user continues to use the desktop in this mode. When the controller later becomes available, the desktop registers and the user's session continues uninterrupted, but any subsequent connection will be brokered by the controller as normal. If after 30 days the desktop is unable to register with the controller, the desktop will stop listening for connections and shutdown. This means the administrator has 30 days in which to repair the controller infrastructure and should not become reliant upon high availability mode.
High availability mode is suitable only for use with dedicated desktops, where the mapping between the user and the Virtual Desktop Agent is known. You cannot configure high availability mode for use with pooled desktops.
To enable high availability mode, you:
Set theHighAvailability and HaRegistrarTimeout registry keys
Provide users with an ICA launch file that will enable them to make direct ICA connections. You have to create an ICA file for each user who requires this feature; Citrix do not create or distribute ICA files for this purpose.
Setting the Registry Keys
To configure the Virtual Desktop Agent so that it will operate in high availability mode when necessary, add the following registry key(s). You must do this after the Virtual Desktop Agent has been installed.
Caution: Using Registry Editor incorrectly can cause serious problems that can require you to reinstall the operating system. Citrix cannot guarantee that problems resulting from incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk. Make sure you back up the registry before you edit it.
In HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\ VirtualDesktopAgent, add the following registry entry (of type REG_DWORD): HighAvailability.Set this to 1 to enable high availability mode; 0 (zero) disables high availability mode.
To change the time period that the Virtual Desktop Agent will try registering with the controller before initiating high availability mode, also add the following registry entry (of type REG_DWORD): HaRegistrarTimeout. Specify the number of seconds. The default is 300 seconds.
Restart the virtual desktop.
Preparing an ICA Launch File
To establish a direct ICA connection to desktops, you provide users with an ICA launch file that they can use should communication with the controller fail. You must create an ICA launch file for each user who requires this feature; Citrix do not create or distribute ICA files for this purpose. For information on how to create ICA files, see
You will need to tell users when it is appropriate to use this ICA launch file and where they can access it from.
High Availability Mode Limitations
High availability mode is suitable only for use with dedicated desktops; you cannot configure this for use with pooled desktops.
In high availability mode, some features are unavailable. These include:
User roaming. If a client device is already connected to the desktop, users will be unable to connect from a different client device.
Power management. When the desktop powers up, it attempts to register, fails and, after the timeout, enters high availability mode.
Controller-originated policies. Policies originating on the controller, such as those governing client drive mapping and access to the clipboard, will not function as there is no connection to the controller. Policies originating from the Domain Controller and Local Group Policy are unaffected.
Access Gateway and Remote Access
High availability mode persists for up to 30 days only, after which the desktop is no longer available.
Password=
Specifies the password for the user account. This is an optional field. The password, if used, must be encrypted. To enter an encrypted password into the ICA file, use the Citrix Program Neighborhood version 11.0 or earlier and use the Custom Connection Wizard to create a new entry. When you are prompted for the username and password, enter the password that you want to use in the ICA file. Finish the wizard. Open the file APPSRV.INI in the Windows directory and locate the entry you just created. Copy the password value and paste it into your ICA file.
The following registry key on the Virtual Desktop Agent computer must be created to allow the connection to occur when using XenDesktop 5 if the password field is omitted in the ICA file.
Registry location
HKLM\Software\Policies\Citrix
EnforceAutoLogon REG_DWORD 0

30. HA Mode Demo / Lab Citrix Desktop Service
Event ID 1014 controller communication failure
Event ID 1012 controller communication success
CDF Trace Event (on VDA)
CdsWorkerAgent:2:1:Register FAILURE: HighAvailabilityActive = True, InHighAvailabilityMode = True, _firstRegistrationAttemptTime = xx/xx/xxxx xx:xx:xx, HighAvailabilityRegistrationTimout = 00:05:00
ICA File
HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\ Ica\Session\VDAOperationalMode with a value 2
Note: A value of 2 means the VDA is in High Availability Mode; this is a read only value.
In HA mode ICA TCP ports are open Netstat -an .
Active Connections
Proto Local Address Foreign Address State
TCP : : LISTENING
TCP : : LISTENING

31. Lab #4 VDA HA Mode

32. XenDesktop 5.x Database Overview

33. Support Database System Requirements
Microsoft SQL Server 2008 R2 (SP1 supported)
Microsoft SQL Server 2008 w/SP1 or later
Microsoft SQL Server 2008 R2 Express Edition
(on media, SP1 supported)
Microsoft SQL Server 2012 (see CTX132438)
Supported Databases For Citrix Products CTX114501
SQL Server not officially tested and will be out of mainstream support by April 2011.
Non-Standard SQL TCP Ports See CTX XD 5.0
XD 5.x+ SQLServer,Port during installation
If using a non-standard SQL port, this will need to be configured in a specific way via the PowerShell SDK see CTX for more information
The SQL Studio Management Console Express is a separate download and install for Express editions

34. Database sizing information (1 of 2)
It’s important to consider DB sizing during initial setup of an environment
Sizing depends on several factors
# of registered VDAs
# of connected sessions
Connection rate
# of managed desktops
# of provisioned desktops

35. Database sizing information (2 of 2)
A formula from the test teams has produced the following data - CTX127939
Provisioned Desktops Using MCS
5,000
10,000
20,000
Per Worker (KB)
14,500
29,000
58,000
Per Session (KB)
25,500
51,000
102,000
Per Connection (KB)
840
1,680
3,360
Per AD Account (KB)
9,000
18,000
36,000
Per MCS machine (KB)
9,700
19,400
38,800
Approx. Total (MB) 59
117
233
Unmanaged Desktops
5,000
10,000
20,000
Per Worker (KB)
14,500
29,000
58,000
Per Session (KB)
25,500
51,000
102,000
Per Connection (KB)
840
1,680
3,360
Approx. Total (MB) 40 80
160

36. Database schemas
Schemas are a type of container used to organize database objects and permissions
Multiple SQL schemas exist in the database
ADIdentitySchema DesktopUpdateManagerSchema
Chb_Config (broker) HostingUnitServiceSchema
Chb_State (broker) MachinePersonalitySchema
ConfigurationSchema
Schemas map to the Windows services on the Controller
The chb_config schema is more persistent configuration information. The chb_state schema is more dynamic with many reads and writes.
Show Database

37. How controllers connect to the DB2
Controller 1
SQL Login domain\Broker1$
SQL Login domain\Broker2$
This illustration is for a production SQL server on a remote machine as opposed to SQL Server Express installed on a Controller (though that will be similar the local system will connect differently).
DB Roles
DB User domain\Broker1$
DB User domain\Broker2$
Tables + SPs
XD5 Database
SQL Server Instance

38. Database Security (CTX127998)
SysAdmin rights needed for special administrative operations
Each database user maps to database roles with specific rights to corresponding objects -
ADIdentitySchema_ROLE
Chr_Broker
Chr_Controller
ConfigurationSchema_ROLE
DesktopUpdateManagerSchema_ROLE
HostingUnitServiceSchema_ROLE
MachinePersonalityServiceSchema_ROLE
XD 5 Upgrade Best Practices CTX128748
Objects include tables, stored procedures, etc.
Built-in database roles such as db_owner are not used for security reasons. These roles provide the minimum access required to perform the necessary tasks.
Each XenDesktop service gains access to the database through the local controller’s machine account. All routine Desktop Studio, Desktop Director, and SDK operations go through one of the XenDesktop services and thus no additional machine account logons are required for use of any of those components irrespective of the machine on which they run.
For a controller machine that is not on the same machine as the database server, the detailed database permissions are granted as follows:
The services gain access to the database server through their machine account logon (names of the form ‘DOMAIN\MACHINE$’). These logons do not need to be members of any server-level roles.
Within the XenDesktop database, the machine logons are mapped one-to-one with a dedicated per-machine user. Each such user has the same name as the logon to which it relates (in other words: ‘DOMAIN\MACHINE$’).
Administrative Permissions
The permissions required to perform various administrative operations on a XenDesktop 5 database are shown in the table below. Because it is envisaged that these are typically performed by a database administrator, no operation-specific database roles are provided, thus db_owner rights are usually required as shown.
All of these operations can be performed using Desktop Studio, if required. In these cases, a direct connection is made from Desktop Studio to the database server; thus, the Desktop Studio user must either have a database server account that is explicitly a member of the appropriate server roles or be able to provide credentials of an account that is. Such direct database access is only used for the following operations; all other operations go through the underlying XenDesktop services.
Certain activity's like DB creation, Add remove controller will require higher level permissions

39. Database Activity
Live session state held in database, including registration info
One transaction per desktop for health ‘ping’
Default period 30 seconds per desktop
Small # of transactions per desktop launch
Automatic database clean-up (purge stale records)
Controller health heartbeat
Loss of database access = dead broker
No heartbeat  other brokers will take over responsibilities
Some of this functionality is performed by the site services role on one of the Controllers. This is different from the farm master in XD4.

40. Database Maintenance and Troubleshooting

41. Monitoring SQL Connections
Controller SQL Connections
SQL Activity Monitor
Right Click SQL Server
Activity Monitor
BrokerService
Citrix.ADIdentity.SdkWcfEndPoint
Citrix.Configuration.SdkWcfEndPoint
Citrix.MachineCreation.SdkWcfEndPoint
Citrix.Host.SdkWcfEndPoint
Management Views
sys.dm_exec_sessions
select * from sys.dm_exec_sessions
Citrix Connections
select * from sys.dm_exec_sessions where PROGRAM_NAME like 'Citrix%'
SELECT login_name ,COUNT(session_id) AS session_count
FROM sys.dm_exec_sessions
GROUP BY login_name;
Citrix.Identity.SdkWcfEndPoint

42. Performance Counters Database Avg Transaction Time Database Connected
Database Transaction/sec
Database Transaction Error/sec
Brokered Sessions
The database connected performance count will have a zero or a one. A one value means it is connected. Note if the broker service stops running for any reason these values will not get updated.

43. Managing the transaction log (1/2)
A transaction log is the recording of all changes performed against a database
Recovery model options
Simple – Reclaims log space but can only recover to the last backup (default option for XD5 database)
Full – Can recover to any point in time but requires the most disk space
Only use the full recovery model when absolutely necessary such as implementing SQL Mirroring which requires it.
When using full recovery, ensure that complete database and transaction log backups are performed regularly.

44. Managing the transaction log (2/2)
Average transaction log sizing formula
A VDA with no activity generates approximately 62KB of transaction log data per hour
# of VDAs X 24 Hours X Approx. 62KB of data
100 VDAs X 24 Hours X 62KB = 145MB
Set the log to a fixed size and backup the log when it reaches 50%.
Place the log on a separate physical disk
Using a separate physical disk for the transaction log exclusively will increase performance since it is written to in a serial manner.
Growing the transaction log automatically causes transactions to stall and controller response times to increase. Backup the transaction log often using a SQL Server Agent Job.

45. Maintaining tables indexes
XenDesktop 4 and current XenApp versions contain an IndexTable in the database to efficiently search the BLOB data
outlines the details
XenDesktop 5 requires that indexes be maintained just like any other SQL database
Reorganizing indexes sorts the order of the leaf nodes in an index
Rebuilding indexes drops and recreates the entire index for maximum efficiency
Be aware of SQL version limitations
SQL Express has no maintenance plans or SQL Agent to automate tasks (Maintenance can be performed manually or using Task Scheduler)
Rebuilding indexes requires the table to be offline unless using Enterprise Edition
Database indexes allow us to quickly find the records and information we are looking for. This is the same concept of a book index.
Database statistics, backups, and other areas should be included in a maintenance plan as well.

46. SQL Maintenance Plans Database Integrity Index Maintenance
Update Statistics
Database Backups
Only the enterprise edition of SQL supports rebuilding of indexes online. It is recommended to run the maintenance plan during a maintenance window.

47. XDDBDiag (CTX128075) Overview Command line tool
Performs database consistency check on data
Collects diagnostic Information
Site Information
VDA Information
Current Connections / Connection Log
Hypervisor Connections
Policy Information
Desktop Groups
Controller Information
This command line support tool will perform a consistency check on the data in a XenDesktop 5 database. It will also output the following diagnostic data into comma separated value (csv) files located in a compressed file (zip) named computername_XDDBDiag_Output.zip to the same directory in which the program is located.
• Site Information
• VDA Information
• Current Connections / Connection Log
• Hypervisor Connections
• Policy Information
• Desktop Groups
• Controller Information
This program will check for updates automatically when it is first executed. This is only a notification and will not impact the behavior.
Example
XDDBDiag 1.x Citrix Support
This version is now out of date. For the latest version please see
To disable program update notifications modify the following line in the XDDBDiag.exe.Config
<add key="DisableUpdateNotification" value="true"/>
To disable exporting of data modify the following line in the XDDBDiag.exe.Config
<add key="DisableDataExport" value="true"/>
How to Use XDDBDiag
The following command line parameters will control how the program connects to the XenDesktop 5 database.
For local connections to a SQL express installation use the [local] switch
For remote connections to a SQL server use the following parameters
Command line Parameters [windows] [SQL server] [SQL Database]
Example:
SQL Express
XDDBDiag local
SQL Windows Authentication
XDDBDiag windows sqlserver mydatabase
You can view the log file for any errors or additional information XDDBDiagLog.txt.
There is no dependency on the broker service since this queries the XenDesktop 5 database directly.
Installing XDDBDiag

48. XDDBDiag (CTX128075) Usage Database Backup History SQL Connections
XDDBDiag 2.1 Citrix Support
To connect to a local SQL Express database use [local] switch
XDDBDiag [local]
To pass database connection settings via command line
Command line Parameters [windows] [SQL server] [SQL Database]
New SQLStats
Database Backup History
SQL Connections
SQL Version

49. Lab #5 General Database Troubleshooting

50. XenDesktop 5.6 Personal vDisk Troubleshooting

51. Pooled Desktop with Personal vDisk Standard Pooled Desktop
A personal vDisk is created for each provisioned virtual machine. During initial session launch that VM is assigned to a single user.
User Environment
User Data
User Settings
User Installed Applications
Corporate Installed Applications
Profile Management OS
Common Base Image
Citrix Personal vDisk
With PVD, a separate disk image is maintained for each user that contains all changes to the pool VM. PVD combines, at runtime, the content of the base VM and the content of the user’s disk, providing a composite view of the entire environment. From the user’s perspective, they see a mix of content (applications, data, settings) from both environment, without knowing (or needing to know) where each part is sourced from.
Standard image with personalization stored in a Personal VDisk
User personalization (settings and installed applications) are stored in the personal vDisk that is merged with the base VM image during session launch.

52. Citrix Personal vDisk Drive Location On base VM as the P: Drive
On Hypervisor
as <vm_name>_pvdisk
The VHD created using the template is mounted as P: and in that VHD has another VHD on it and that is mounted as V: and is hidden and captures the apps installed and machine state in UserData.vhd.
In the hypervisor infrastructure the disk will appear as <vm_name>_pvdisk.

53. Drivers and Components
Ivm.sys
Ivmvhd.sys
Ivmboot.sys
Ivmpnp.sys
CtxPvd.exe
CtxPvdSvc.exe
PvDWMI.dll
VhdTool.exe
Drivers:
ivm.sys (referred to hereinafter as IVM) is the main PVD driver, containing the interception and redirection technology described earlier. IVM is a Windows minifilter, meaning it participates in a pipeline of I/O processing provided by Microsoft’s fltmgr.sys driver.
ivmboot.sys blocks the further boot of the system past early phase 1. As described earlier, ivmboot waits for an event to be signaled by IVM indicating either a suitable PVD volume was located and started, or the specified timeout expired. After initial boot, ivmboot performs no additional function.
ivmvhd.sys provides a standard VHD volume driver that adheres to the MS VHD (but not VHDX) specification. We chose to write our own VHD driver since there was no publically-available VHD driver that supports Windows XP, and because writing our own VHD driver afforded us the ability to add additional features (such as caching and the ability to have ancestral differencing disks) not present in Microsoft’s Win7 implementation.
ivmpnp.sys controls another aspect of the system’s early boot – namely, it blocks the start of networking until the first user mode process (smss.exe) is started. In order for a blended view of networking to function (which is required when supporting user-installed networking components such as firewalls and VPNs), both tcpip.sys and ndis.sys must be delayed to start after IVM has started virtualization. The point in the boot sequence immediately preceding smss.exe launch is the last possible time in which networking can be started (under most circumstances).
Components:
CtxPvdSvc.exe is the user-mode PVD service, responsible for managing the image update process and verifying proper configuration of the PVD disk. It is also responsible for formatting the initially-unformatted PVD disk on first time startup. The service runs as local system, but drops the privileges it doesn’t need immediately on startup.
CtxPvd.exe provides a control facility for the PVD Service (CtxPvdSvc.exe, described shortly). It is responsible for controlling the service, instructing it to perform various services (eg, image update) required by PVD. CtxPvd.exe is also used in base VM mode to intercept shutdown requests (in Windows 7 base VMs) so that the administrator can be reminded to take the inventory before shutdown occurs.
VhdTool.exe
An administrator tool that can be used to mount/format/dismount PvD VHD files. Must be invoked as an administrator. (/? Provides list of options)
PvDWMI.dll
Provides the WMI endpoint user by desktop director when querying PvD for statistics (e.g., available/used profile and application space) and for resetting the PvD VHD
These drivers load at system boot time and are responsible for applying the virtualization logic
These components handle the initial inventory and image updates as well as VHD management and performance statistics

54. Personal vDisk Process Flow
Inventory Process of
Base VM
(Initial or Image Update)
Pooled Desktop Start-Up
Virtual Logic Application
Personalized
Desktop
Inventory process
The PVD inventory comprises metadata about the base VM image contents. This metadata is used by PVD at runtime to determine from where to satisfy resource I/O requests (files, registry keys, registry values, etc.) The inventory must be kept up to date with respect to base image changes, and it is for this reason that PVD will remind administrators to update the inventory on each shutdown of the base VM.
CtxPvDSvc.exe -> VhdTool.exe -> IVMVHD.sys -> UserData.VDESK.TEMPLATE created and mounted to v: (default) -> Machine state snapshot captured and copied to template vhd (Includes resource catalog, governing rules and 0-byte sentry files) -> UserData.VDESK.TEMPLATE un-mounted and stored under %ProgramData%\Citrix\personal vDisk to be used during Pooled Desktop start-up (also used as starting point when resetting PvDisk through Desktop Director).
Pooled Desktop Start-UP and Virtualization Logic
If a properly configured PVD VHD is located upon boot, PVD will perform a sequence of operations in order to make the system suitable for persistent personalization (see PVD Startup Sequence). One step of this startup process comprises loading and starting the ivm.sys minifilter. Ivm.sys is PVD’s virtualization core and is responsible for intercepting I/O requests in the system. For each request, PVD satisfies the I/O by providing content from either the base VM image or from the PVD volume.
CtxPvDSvc.exe detects and formats the PvDisk (volume created by MCS) and assigns drive letter P: (default) -> CtxPvDSvc.exe copies UserData.VDESK.TEMPLATE from base VM to root of PvDisk as UserData.vhd -> CtxPvDSvc.exe reboots VM -> IVM.sys validates correct version of UserData.vhd -> IVM.sys performs PvD start-up sequence -> CtxPvDSvc.exe mounts UserData.vhd to V: (default) -> IVM.sys loads resource catalog (MojoControl.dat) into the registry.
Application generates I/O -> Intercepted by IVM.sys -> IVM.sys queries resource catalog -> Application requests (R/W) sent to either the Base VM or PvDisk.
Image updates
When an administrator makes a change to the base VM image, a new PVD inventory will be created. This, in turn, will create a new template VHD containing the metadata of the new base image. This new inventory will differ from the previous base VM inventory – perhaps files were added, deleted, or changed (the same may be true for registry keys and values). In order for the user’s personalization to remain intact and functional when used with this new base VM image, the content of the user’s PVD must be altered first to match with the latest changes (since the user’s PVD originally started its life as a copy of the template VHD containing the first “v1” base VM image inventory).
IVM.sys checks UserData.vhd version on root of PvDisk against value stored in the registry of the VM -> If outdated, mounts vhd only (does not perform standard start-up) -> CtxPvDSvc.exe reviews template vhd from base image v1 and v2 -> changes are then merged with existing UserData.vhd -> VDESK GUID (inventory marker) is then updated.

55. Desktop Director and Personal vDisk
Desktop Director includes helpdesk-facing PvD metrics and support
% of application area in use / total size
% of user profile area in use / total size
PVD reset
PVD reset allows the helpdesk to reset the application area while leaving the user’s data intact:
Similar to “reset to factory default”
Useful when user installed applications are causing problems with the desktop image
Using WMI (PvDWMI.dll), Desktop Director can query PvD for statistics (such as available/used profile space and available/used application VHD space), and for providing a method call used to reset the PVD VHD. It is loaded into the CtxPvdSvc.exe service executable, which houses the WMI provider during normal use.

56. Log Files
PvD maintains logs in the base of the volume attached to the VM
Run ctxpvd.exe –log to create a single PVDLOGS folder created under the %temp% directory
Review IvmSupervisor.log …
Located in the root of the P: drive
Windows event logs may also be helpful
By default logging for the Citrix personal vDisk feature is enabled. All log files can be captured using the –log switch with ctxpvd.exe to automatically gather all relevant log files into a single PVDLOGS folder created under the %temp% directory.
As a first step when troubleshooting PvD issues, support engineers should be aware of this automatic log collection functionality for quick and easy log file retrieval.Most frequently seen PVD support cases …
Failure of PVD to start virtualization (PVD can’t locate volume/VHD, etc …)
Installation of unsupported apps (phase 0 apps, etc …)
Trying to move PVDs between VMs

57. Lab #6 Personal vDisk Troubleshooting

58. TaaS Preview

59. XenDesktop 5.x Resources
XenDesktop 5.x Database Sizing and Mirroring Best Practices
XenDesktop 5.x SDK Cmdlet Help (PowerShell)
How To Move an Existing XenDesktop 5.x Database
Disconnect all Services from the existing database:
a. On each DDC in the site, launch PowerShell using the Run as administrator option.
b. Copy and paste the following code into the PowerShell window:
asnp Citrix.*
Set-ConfigDBConnection -DBConnection $null
Set-AcctDBConnection -DBConnection $null
Set-HypDBConnection -DBConnection $null
Set-ProvDBConnection -DBConnection $null
Set-PvsVmDBConnection -DBConnection $null
Set-BrokerDBConnection -DBConnection $null
c. Leave the PowerShell window open for Step 4.
Back up and restore the database:
For SQLExpress installations run the following command at the cmd prompt on the DDC that contains the database:
sqlcmd -S LOCALHOST\SQLEXPRESS -q "Backup Database CitrixXenDesktopDB to disk = "database-backup-location-directory-path? (example: C:\backup\test.bak)
For more information regarding backing up and restoring databases
Create Machine Logins for all DDCs on the new database server.
a. Launch SQL Server Management Studio or SQLCMD on the SQL server housing the restored database.
b. XenDesktop 5 uses machine accounts of the DDC servers to access the database directly. Create machine account logins for each of the DDCs in the site.
c. Each of the machine accounts should have their Database role membership set to the following roles:
ADIdentitySchema_ROLE
chr_Broker
chr_Controller
ConfigurationSchema_ROLE
DesktopUpdateManagerSchema_ROLE
HostingUnitServiceSchema_ROLE
MachinePersonalitySchema_ROLE
Redirect DDCs to the new database:
a. At each DDC, copy and paste the following lines into the open PowerShell window where <dbserver> is the name of your SQL server (and instance if defined) and <dbname> is the name of the XenDesktop database:
Set-ConfigDBConnection -DBConnection "Server= dbserver;Database= dbname;Trusted_Connection=True"
Set-AcctDBConnection -DBConnection "Server= dbserver;Database= dbname;Trusted_Connection=True"
Set-HypDBConnection -DBConnection "Server= dbserver;Database= dbname;Trusted_Connection=True"
Set-ProvDBConnection -DBConnection "Server= dbserver;Database= dbname;Trusted_Connection=True"
Set-PvsVmDBConnection -DBConnection "Server= dbserver;Database= dbname;Trusted_Connection=True"
Set-BrokerDBConnection -DBConnection "Server= dbserver;Database= dbname;Trusted_Connection=True"
b. Launch Desktop Studio to confirm that your site is fully operational.
Note: It is important to verify that all of the Set-<service>DBConnection commands above have returned a result of OK. If a result other than OK is returned for any of these commands, it might be necessary to enable logging or tracing to determine the cause of the connection failure.
The XDDBDiag utility (link below) can be used to verify the consistency of your database after the move.
If any Virtual Desktop Agents were running when the DDC services were shut down in Step 1, then it could take up to 10 minutes before the Virtual Desktop Agents reregister; no other action should be necessary.
PowerShell Resources

60. Session Take Away Critical Tool Matrix for XenDesktop CTX129149
PowerShell SDK CTX127254
See CTX For a Complete List of All Citrix Support Tools
XenDesktop 5.x Database Sizing and Mirroring Best Practices CTX127939
How To Move an Existing XenDesktop 5.x Database CTX128365
PvD FAQ CTX131553

62. Launch your browser and type http://training.citrixsynergy.net
Lab Environment Login
Launch your browser and type
Your session code is:
“session code”
Session code:
Each day you will have to update this with the new session code that will be provided to the instructors.
Note: Place this at the end of you presentation.