Wednesday, March 14, 2018

How to: Configure Citrix XenMobile to use Microsoft SQL multi-subnet (Basic) Availability Groups

In the previous blogs I’ve explained you “How to: Install and configure Microsoft SQL Server 2016 Standard multi-subnet Basic Availability Groups for Citrix XenDesktop and XenMobile” and “Microsoft SQL and Microsoft SQL AlwaysOn basics for Citrix Admins”.

This blog is a guide for configuring Citrix XenMobile with a multi-subnet SQL AlwaysOn database. When using a multi-subnet SQL AlwaysOn cluster, we need to reconfigure the Windows Failover Cluster Network parameters RegisterAllProvidersIP=0 and HostRecordTTL=60 for the XenMobile AlwaysOn listener. Special thanks for the details delivered by @JanPaulPlaisier! Details will be explained later in this blog.


During a customer’s project we’ve build the following XenMobile backend:

  • One XenMobile cluster 
    • One XenMobile server in Amersfoort: PBO-XMS01.pbo.lan 
    • One XenMobile server in Nijkerk: PBO-XMS02.pbo.lan 
  • Both sites have a NetScaler with a GSLB configuration for XenMobile. The NetScaler configuration is not covered in this blog. 
    • The XenMobile service in Amersfoort is the primary site. When the XenMobile service in Amersfoort becomes unresponsive, GSLB will failover the XenMobile services to Nijkerk.
Logical overview

Note: Site-to-site network latency is 4ms.

Create SQL Login for XenMobile service account

Create an Active Directory Service Account for the XenMobile database connection as follows:

1.    Create a Domain User in Active Directory, this is your service account (i.e. XMSvc)


2.    Open SQL Management Studio
3.    Create a SQL Server login for the XenMobile service account on all the SQL nodes in your AlwaysOn configuration. Starting with node 1:


4.    Select Windows Authentication and select your Service Account (i.e. PBO\XMSvc). Then click Server Roles:


5.    Select dbcreator and click OK:


6.    Create this login on the remaining SQL servers:

Creating the initial database

Before we can join the Citrix XenMobile database to a (Basic) Availability Group, we need to create the database on one of the SQL servers directly using the XenMobile appliance. This how-to is describing an initial setup using the XenMobile appliance. If you need to move an existing XenMobile database to an availability group, please skip this chapter and start with the next chapter.

1.    Import the XenMobile appliance you’ve downloaded from download.citrix.com
2.    The “First time Use mode” is started, I will not discuss default configuration. I will only discuss database configuration


3.    Configure the database connection to connect to one of your SQL nodes directly (i.e. PBO-SQL01.pbo.lan). Connect using the XenMobile service account (i.e. PBO\XMSvc)


4.    The database is created by the “First Time Use mode


5.    Finish the “First Time Use mode” configuration with the specific options for your XenMobile design.

Joining the Citrix XenMobile database to a (Basic) AlwaysOn Availability Group

At this point, we want to join the “CTX-XM” database to a new Microsoft SQL multi-subnet Basic AlwaysOn Availability Group (BAG). When you have a Citrix XenMobile environment running without BAG, you can also use these steps to move to a BAG setup.

1.    Open SQL Management Studio
2.    Right click the CTX-XM database and click Properties


3.    Click Options and ensure Recovery model is Full. Click OK


4.    Right click CTX-XM and click Tasks --> Back Up..


5.    Create a Full backup of the CTX-XM database:


6.    Right click Availability Groups and click New Availability Group Wizard…


7.    Click Next


8.    Enter a name for the Availability Group (i.e. BAG-CTX-XM) and click Next


9.    Select the CTX-XM database and click Next


10.    Click Add Replica…


11.    Login to the second SQL node:


12.    Select Automatic Failover and ensure Availability Mode is Synchronous commit. Click Listener tab:


13.    Configure DNS-name and static IPs for the SQL AlwaysOn listener, click Next:


14.    Use a SMB share for initial seeding, click next:


15.    Availability Group validation. Click Next


16.    Verify Summary and click Finish


17.    Creating the AlwaysOn Availability group


18.    When everything is OK. Click Close:


19.    The availability group is created:



Reconfigure Windows Failover Cluster network parameters for BAG-CTX-XM Availability group

As I’ve mentioned in the Citrix XenApp/XenDesktop multi-subnet AlwaysOn blog, Windows Failover Cluster is creating a round-robin DNS A-record for the multi-subnet Availability group. This is also the default after creating a multi-subnet Availability group for XenMobile:


Since XenMobile is supporting (Basic) Availability groups https://docs.citrix.com/en-us/xenmobile/server/system-requirements.html


The SQL driver in the XenMobile appliance isn’t aware or configurable with the MultiSubnetFailover=true for the SQL connection string. Due to this, the XenMobile appliance will resolve the IP-addresses of the BAG with a round robin mechanism. Result: connection issues to the XenMobile database when the off-line IP off the SQL listener is resolved. Other Citrix products like Provisioning Services, XenApp or XenDesktop are configurable with the MultiSubnetFailover=true connection string.
 

To fix this issue for XenMobile, we can reconfigure the network parameters for the AlwaysOn XenMobile Availability group listener to only register the on-line IP to the DNS A-record. To force a recheck of the operating system, we reconfigure the network parameters to register a short TTL to the DNS record. This will force the XenMobile appliance to check if the IP is changed on the DNS every minute.

Reconfigure the network parameters for the SQL AlwaysOn XenMobile listener as follows:


1.    Login to one SQL nodes of the Windows Failover Cluster (i.e. PBO-SQL01)
2.    Start Powershell elevated


3.    Type Import-Module FailoverClusters to import the powershell modules:


4.    Type Get-ClusterResource and find the Cluster Resource Network Name for your XenMobile BAG. In this example BAG-CTX-XM_BAG-CTX-XM


5.    Reconfigure Cluster parameters as follows (replace BAG-CTX-XM_BAG-CTX-XM with the name of your WFC configuration):


Import-Module FailoverClusters 

Get-ClusterResource BAG-CTX-XM_BAG-CTX-XM | Set-ClusterParameter RegisterAllProvidersIP 0  

Get-ClusterResource BAG-CTX-XM_BAG-CTX-XM |Set-ClusterParameter HostRecordTTL 60 

Stop-ClusterResource BAG-CTX-XM_BAG-CTX-XM

Start-ClusterResource BAG-CTX-XM_BAG-CTX-XM

Then wait or force DNS replication to all your DNS-servers. After that flush DNS information on all the WFC nodes of the SQL AlwaysOn cluster and the XenMobile appliances.


6.    You will now have only one A-record with the active IP for the BAG:



7.    And after a failover to the other SQL server in the other subnet:


8.    The DNS record is adjusted:


As described in this blog I have a DNS-server PBO-DC01 in Amersfoort and a PBO-DC02 in Nijkerk. It is important that the XenMobile appliance (PBO-XM01) and SQL Server (PBO-SQL01) are using the DNS-server (PBO-DC01) as primary DNS-server in Amersfoort. For the Nijkerk site it is important that the XenMobile Appliance (PBO-XM02) and SQL Server (PBO-SQL02) are using DNS-server (PBO-DC02) as the primary DNS-server. The Windows Failover Cluster will contact the primary DNS-server to reconfigure the DNS-records in case of a failover. So if SQL and XenMobile appliances are configured the same way as WFC/SQL, XenMobile will notice the A-record change within 1 minute since it is contacting the same primary DNS-server.

Reconfigure Citrix XenMobile to use the multi-subnet Basic Availability Group

You can reconfigure XenMobile as follows:

1.    Login to the console of your XenMobile appliance and select 0 (Configuration) from the menu:


2.    Select option 3 (Database) from the menu:


3.    Reconfigure the server property to connect to the BAG FQDN:


4.    Reboot the appliance:


5.    Rebooting


6.    XenMobile is now reconfigured using the BAG:


Wednesday, March 7, 2018

How to: Configure Citrix XenApp/XenDesktop to use Microsoft SQL multi-subnet (Basic) Availability Groups

In the previous blogs I’ve explained you “How to: Install and configure Microsoft SQL Server 2016 Standard multi-subnet Basic Availability Groups for Citrix XenDesktop and XenMobile” and “Microsoft SQL and Microsoft SQL AlwaysOn basics for Citrix Admins”.
 

This blog is a guide for configuring Citrix XenApp/XenDesktop with a multisubnet SQL AlwaysOn Datastore. When using a MultiSubnet SQL AlwaysOn SQL Cluster, you have to reconfigure all the XenDesktop connection strings to use the MultiSubnetFailover=True feature.

For your information: Configuring MultiSubnetFailover=True connection string is only possible using powershell at this moment. MultiSubnetFailover=False is the default setting after a new site installation.


During a customer’s project I’ve created the following XenDesktop backend:

  • One XenDesktop Site called: “PBO-LAB”
  • Two Zones
    • Primary Zone: “Amersfoort” containing two delivery controllers
      • AMF-DDC001
      • AMF-DDC002
    • Secondary Zone: “Nijkerk” containing two delivery controllers
      • NRK-DDC003
      • NRK-DDC004
  • The VDA’s connecting to the corresponding delivery controller in their corresponding site.
    • Two GPO’s are configured. Both with the Citrix Policy “Controllers” for the corresponding site.
Logical overview:

Note: Site-to-site network latency is 4ms.

Create the initial databases

Before setting up a new XenDesktop Site, we need to create three empty databases and join them to a (Basic) AlwaysOn Availability Groups. You can do this as follows:

1.    Open SQL Management Studio and connect to one of your SQL Servers
2.    Right click databases --> New Database…


3.    Enter the Citrix Site database name, for example “XD-Site”:


4.    Click Options. Make sure you configure the following:

               Collation: Latin1_General_100_CI_AS_KS
               Recovery model: Full
               Is Read Committed Snapshot On: True


5.    Create an empty “Logging” and “Monitoring” database with the same procedure. You will have three databases in the end:

Joining the Citrix XenDesktop databases to (Basic) AlwaysOn Availability Group(s)

Now we need to join the XD-Site, XD-Logging and XD-Monitoring databases to AlwaysOn Availability Groups. Since I’m using SQL 2016 Standard I will create three different Basic Availability Groups as follows:

1.    As a prerequisite for AlwaysOn, backup all three databases. Right click the database, choose Tasks --> Back Up..


2.    Create a Full file backup of the database:


3.    In SQL Studio, Right Click Availability Groups and choose New Availability Group Wizard…


4.    Click Next


5.    Specify the Availability Group name and click next


6.    Select the database to join the Availability group and click Next:


7.    Click Add Replica


8.    Login to your second SQL server:


9.    Select “Automatic Failover” and ensure Availability Mode “Synchronous Commit”. Click listener tab:


10.    Configure a DNS-name and IP-addresses in both subnets for the listener


11.    Use a temporary SMB File share for seeding the database, click Next


12.    Validation completed successfully, click next


13.    Click Next


14.    SQL is creating the Availability Group for you:


15.    Done, Click Close:


16.    Create a Availability Group for the Logging database:


17.    Create a Availability Group for the Monitoring database


18.    You will having three Availability Groups in the end:

Configure Citrix XenDesktop to use the MultiSubnetFailover Availability Group

Since we’re now having empty Site, Monitoring and Logging databases in three different Basic Availability Groups, we can now install and configure XenDesktop to use these databases as follows:

1.    Install the Citrix Delivery Controller software like you’ve always do:


2.    Launch Citrix Studio and start “Site setup


3.    Select “A fully configured, production-ready Site” and enter your “Site name”, click Next


4.    Here’s where you configure the FQDN’s for the three SQL Availability Groups with their corresponding database name. Click Next


5.    Configure your Licensing and Click Next


6.    Configure your hosting connection, click Next


7.    Configure your features and click Next


8.    Summary of your site configuration. Verify the SQL information and click Next


9.    The site and databases are configured

Configuring MutliSubnetFailover=true connection string

Your site is now configured using SQL AlwaysOn using MultiSubnetFailover=False by default. If you are using a single subnet AlwaysOn configuration, your good now. When using a MultiSubnet AlwaysOn configuration you need additional configuration, although everything will appear to work correctly.

Let me explain a bit: Since we’ve configured two IP’s in different subnets for the listeners, Windows Failover Clustering will configure both IPs in DNS:


C:\Windows\system32>nslookup

Default Server:  PBO-DC01.pbo.lan

Address:  10.9.0.10



> bag-xd-site.pbo.lan

Server:  PBO-DC01.pbo.lan

Address:  10.9.0.10



Name:    bag-xd-site.pbo.lan

Addresses:  10.9.0.222

          10.11.0.222

Since only one SQL node is able to read and write to the SQL-database, Windows Failover Clustering controls which listener IP is Online and which one is Offline. In this screenshot, when the SQL node in subnet 10.9.0.0/24 fails. The listener IP 10.11.0.222 will come online and IP 10.9.0.222 will go offline:


We’re using the Fully Qualified DNS name of the SQL AlwaysOn listener for the connection. Windows and another operating system will contact one of the IP-addresses of the DNS-record by a round-robin mechanism. This is like Russian roulette if the on-line IP is resolved by the round-robin mechanism. 


So this is the point the MultiSubnetFailover=True connection string is needed. When a SQL connection is configured with MutliSubnetFailover=True, the SQL driver knows about the multi-subnet configuration and will figure out which IP is online and will try to failover to the other one when a SQL node will become inactive. So it is a good idea to configure this feature for your XenDesktop Delivery Controllers. So configure it on all of your delivery controllers as follows:


1.    Login to your Citrix Desktop Delivery Controller
2.    Close all Citrix Studio consoles on this Delivery Controller
3.    I’ve updated the script from https://support.citrix.com/article/CTX216504, so it supports more availability groups. You can download it here https://pqr.sharefile.eu/d-se8c22e087cf40209 or copy paste it from below:



######################

#

# Updated script for SQL Basic availability Group

#

# Sources: https://support.citrix.com/article/CTX216504

#

# Patrick van den Born 15-02-2018

#

########################



#Vars

$SiteBAGName = "BAG-XD-Site.pbo.lan"

$SiteDBName = "XD-Site"

$LogBAGName = "BAG-XD-Logging.pbo.lan"

$LogDBName = "XD-Logging"

$MonitorBAGName = "BAG-XD-Monitori.pbo.lan"

$MonitorDBName = "XD-Monitoring"

$cs="Server=$SiteBAGName;Initial Catalog=$SiteDBName;Integrated Security=True;MultiSubnetFailover=True"

Write-Host $cs

$csLogging= "Server=$LogBAGName;Initial Catalog=$LogDBName;Integrated Security=True;MultiSubnetFailover=True"

Write-Host $csLogging

$csMonitoring = "Server=$MonitorBAGName;Initial Catalog=$MonitorDBName;Integrated Security=True;MultiSubnetFailover=True"

Write-Host $csMonitoring



#Add Snapin

Add-PSSnapin Citrix*



#Disable logging

set-logsite -state "Disabled"



#Clear connections

Set-AnalyticsDBConnection -DBConnection $null -force             #  7.6 and newer

Set-AppLibDBConnection -DBConnection $null -force                  # 7.8 and newer

Set-OrchDBConnection -DBConnection $null -force                    #  7.11 and newer

Set-TrustDBConnection -DBConnection $null -force                    #  7.11 and newer

Set-HypDBConnection -DBConnection $null -force

Set-ProvDBConnection -DBConnection $null -force

Set-BrokerDBConnection -DBConnection $null -force

Set-EnvTestDBConnection -DBConnection $null -force

Set-SfDBConnection -DBConnection $null -force

Set-MonitorDBConnection -DataStore Monitor -DBConnection $null -force

Set-MonitorDBConnection -DBConnection $null -force

Set-LogDBConnection -DataStore Logging -DBConnection $null -force

Set-LogDBConnection -DBConnection $null -force

Set-ConfigDBConnection -DBConnection $null  -force

Set-AcctDBConnection -DBConnection $null -force

Set-AdminDBConnection -DBConnection $null -force



#Set Multisubnet connections

Set-AdminDBConnection -DBConnection $cs

Set-ConfigDBConnection -DBConnection $cs

Set-AcctDBConnection -DBConnection $cs

Set-AnalyticsDBConnection -DBConnection $cs               # 7.6 and newer

Set-HypDBConnection -DBConnection $cs             

Set-ProvDBConnection -DBConnection $cs

Set-AppLibDBConnection –DBConnection $cs                 #  7.8 and newer

Set-OrchDBConnection –DBConnection $cs                    # 7.11 and newer

Set-TrustDBConnection –DBConnection $cs                  #  7.11 and newer

Set-PvsVmDBConnection -DBConnection $cs               # PBO: Will fail, maybe needed by older DDCs

Set-BrokerDBConnection -DBConnection $cs

Set-EnvTestDBConnection -DBConnection $cs

Set-SfDBConnection -DBConnection $cs

Set-LogDBConnection -DBConnection $cs

Set-LogDBConnection -DataStore Logging -DBConnection $csLogging

Set-MonitorDBConnection -DBConnection $cs

Set-MonitorDBConnection -DataStore Monitor -DBConnection $csMonitoring



#Enable logging

set-logsite -state "Enabled"



#Get connection strings

Write-Host "Configured connection strings for this controller"

Get-AdminDBConnection

Get-AcctDBConnection

Get-AnalyticsDBConnection   # 7.6 and newer

Get-HypDBConnection         

Get-ProvDBConnection

Get-AppLibDBConnection  #  7.8 and newer

Get-OrchDBConnection    # 7.11 and newer

Get-TrustDBConnection   #  7.11 and newer

Get-BrokerDBConnection

Get-EnvTestDBConnection

Get-SfDBConnection

Get-LogDBConnection

Get-LogDBConnection -DataStore Logging

Get-MonitorDBConnection

Get-MonitorDBConnection -DataStore Monitor

4.    Just fill out the following vars SiteBAGName, SiteDBName, LogBAGName, LogDBName, MonitorBAGName and MonitorDBName.

Experience: Disable Logging temporary, otherwise you will stuck at reconfiguring the connection strings. Cause: Logging DB connection is cleared and Citrix want to log everything even when not possible (logdb is down). 
 
5.    Run the script to reconfigure the SQL connections for this Desktop Delivery Controller:


6.    At the end of the script you will have an overview of all the reconfigured connections


7.    Execute the script on all of your Delivery Controllers in your site.
 

Now Citrix XenDesktop is configured for MultiSubnet SQL AlwaysOn Availability Group!