Share this post

In XenDesktop 7.x, all information (static configuration and runtime data) is stored in the site configuration database.  Delivery controllers communicate only with the database and not with each other as opposed to the XenApp data collectors. Every single controller can be unplugged from the network or turned off without this affecting other controllers in the site. If the server hosting database fails, existing connections to virtual desktops will continue to function until the user either logs off or disconnects from their virtual desktop. As long as the database server is unavailable new connections cannot be established. This means, however, that the database is the most critical part of the infrastructure and should be protected from becoming a single point of failure.

The database usage on a per product basis is shown in the table 1 below.

Table 1

The following table highlights the impact from database outage:

ComponentImpact of Database Outage
XenDesktop site databaseUsers will be unable to connect or reconnect to a virtual
desktop. Administrators are unable to use XenDesktop Studio
or XenDesktop Director. Any Users with existing connections
will be unaffected
XenDesktop monitoring
XenDesktop Director will not display any historical data and
XenDesktop Studio cannot be started. Brokering of incoming
user requests and existing user sessions will not be affected.
XenDesktop configuration
logging database
If allow changes when the database is disconnected has
been enabled within XenDesktop logging preferences, an
outage of the configuration logging database will have no
impact (other than configuration changes not being logged).
Otherwise, administrators will be unable to make any
changes to the XenDesktop site configuration. Users are not
Provisioning Services
farm database
When offline database support is enabled and the database
becomes unavailable, the stream process uses a local copy
of the database to retrieve information about the provisioning
server and the target devices supported by the server. This
allows provisioning servers and the target devices to remain
operational. However, when the database is offline, the
console and the management functions listed below become
• AutoAdd target devices
• vDisk creation and updates
• Active Directory password changes
• Stream process startup
• Image update service
• PowerShell and MCLI based management If offline database
support has not been enabled, all management functions
become unavailable and the boot and failover of target
devices will fail.
XenClient databaseAdministrators will be unable to access the synchronizer
webpage to manage the environment, new computers will be
unable to register and existing computers will be unable to
receive image updates or policies. Existing users will still be
able to function normally with access to their virtual machines
being uninterrupted.

Decision: Vendor and Version

In order to streamline the daily maintenance and support of used Citrix products it is recommended to use the same type of database engine for all installed products. The previous versions of Citrix XenApp supports database software from Microsoft, Oracle and IBM, while support for all other Citrix products has been limited to Microsoft SQL Server. Starting from XenDesktop 7.0 only Microsoft SQL server is the supported database engine.

For more information on supported database vendors and versions for Citrix products, please refer to the Citrix knowledge base article CTX114501 – Supported Databases.

Decision: Edition

There are five editions of Microsoft SQL Server 2012:

  • Express
  • Web
  • Standard
  • Business Intelligence
  • Enterprise

The the most important features of each edition, which are applicable to Citrix databases are shown in the table 3 below.

Table 3

As opposed to older versions, XenDesktop 7 uses three databases:

  • Site database – Contains static configuration and dynamic runtime data
  • Monitoring database – Contains monitoring data which is accessible via XenDesktop Director
  • Configuration logging database – Contains a record for each administrative change performed within the XenDesktop site. Data is accessible via XenDesktop Studio.

By default, the monitoring and configuration logging databases are located within the site database. It is recommended changing the location of these secondary databases as soon as the configuration of the XenDesktop site has been completed. For more information, please refer to my post XenDesktop 7 configuration logging explained

Decision: High-Availability Type

In addition to the built-in Citrix database redundancy options, Microsoft SQL Server, as well as the underlying hypervisor (in virtual environments), offer a number of high availability features. These enable administrators to ensure single server outages will have a minimal impact (if any) on the Citrix infrastructure. The following the SQL / hypervisor high availability features are available:

  • VM-level HA – This high availability option is available for virtual SQL servers only, which need to be marked for High Availability at the hypervisor layer. In case of an unexpected shutdown of the virtual machine or the underlying hypervisor host, the hypervisor will try to restart the VM immediately on a different host. While VM-level HA can minimize downtimes in power-outage scenarios, it cannot protect from operating system level corruption. This solution is less expensive than mirroring or clustering because it uses a built-in hypervisor feature. However, the automatic failover process is slower, as it can take time detect an outage and start the virtual SQL server on another host. This may interrupt the service to users.
  • Mirroring – Database mirroring increases database availability with almost instantaneous failover. Database mirroring can be used to maintain a single standby or mirror database, for a corresponding principal or production database. Database mirroring runs with either synchronous operation in high-safety mode, or asynchronous operation in high- performance mode. In high-safety mode with automatic failover (recommended for XenDesktop) a third server instance, known as a witness, is required, which enables the mirror server to act as a hot standby server. Failover from the principal database to the mirror database happens automatically and is typically completed within a few seconds. It is a good practice to enable VM-level HA (or a similar automatic restart functionality) for at least the witness to ensure SQL service availability in case of a multi-server outage.
  • SQL Clustering – Failover clustering provides high-availability support for an entire instance of Microsoft SQL Server. A failover cluster is a combination of two or more nodes, or servers, with two or more shared disks. A Microsoft SQL Server failover cluster instance appears on the network as a single computer, but has functionality that provides failover from one node to another if the current node becomes unavailable. The transition from one note to the other node is seamless for the clients connected to the cluster.
  • AlwaysOn – AlwaysOn Availability Groups is an enterpriselevel high-availability and disaster recovery solution introduced in Microsoft SQL Server 2012, which enables administrators to maximize availability for one or more user databases. AlwaysOn Availability Groups require that the Microsoft SQL Server instances reside on Windows Server failover clustering (WSFC) nodes. Similar to failover clustering a single virtual IP / network name is exposed to the database users. In contrast to failover clustering, shared storage is not required since the data is transferred using a network connection. Both synchronous and asynchronous replication to one or more secondary servers is supported. As opposed to mirroring or clustering secondary servers can be actively used for processing incoming read-only requests, backups or integrity checks. This feature can be used to offload user resource enumeration requests to a secondary SQL server in XenDesktop environments to essentially scale-out a SQL server infrastructure. Since the data on active secondary servers can lag multiple seconds behind the primary server, the read-only routing feature cannot be used for other XenDesktop database requests at this point in time. For more information, please refer to MSDN – AlwaysOn Availability Groups (SQL Server).

Recommended SQL high availability features for each database are shown in the table 4 below.

Table 4