How to Migrate XenDesktop Database to New SQL Server
This article describes how to migrate a XenDesktop database from SQL 2008 to a second SQL 2012 Server.
When using Microsoft SQL Server, refer to the Database Server product documentation for scheduling automated backups of the Data Store. In most cases, daily backup is sufficient to prevent loss of farm data.
In this scenario, it is expected that the Citrix Data Store is unavailable until the procedure is complete. Therefore, complete all the steps in the following procedure within the same change window.
- Citrix strongly recommends that no administrative changes be attempted until the Database is back online and verified.
- All Management Consoles should be closed.
Review throttling and idle pool settings as soon as you restore the DB to mitigate the possibility of boot storms.
The following environmental data is used as an example:
Stop the Configuration Logging Service
- Start Windows PowerShell as an Administrator and run:
- Before moving the database, stop configuration Logging:
##Disable Configuration Logging
From GUI – Logging > Preferences > Disable.
In PowerShell, run:
Set-LogSite -State "Disabled"
- Close Citrix Studio and reopen so the PowerShell command can take effect.
In PowerShell, run:
Set-MonitorConfiguration -DataCollectionEnabled $False
Backup and Restore Process
- Backup Registry.
- Backup the Existing Database and restore it onto the SQL target server.
Refer to the Copying Databases with Backup and Restore web page of Microsoft MSDN library for more information.
- Verify that all the Delivery Controllers have valid logins for their machine account in the form DomainNameComputername$on the database server. If verified, repeat Step 5.
Creating a Delivery Controller SQL Login
Complete the following procedure to create machine logins for all Delivery Controllers (Controllers) on the database server:
- Start SQL Server Management Studio or SQLCMD.
- Run the create login [domainmachine$] from windows query, as displayed in the following screen shot:
- Each Delivery Controllers Machine Login should have a corresponding user account under the restored Database. Locate these accounts and verify that their Database role membership is set to the following role, as displayed in the screen shot:
ROLE Account (one for each Broker) ADIdentitySchema_ROLE DOMAINMACHINE$ chr_Broker DOMAINMACHINE$ chr_Controller DOMAINMACHINE$ ConfigLoggingSchema_ROLE DOMAINMACHINE$ ConfigLoggingSiteSchema_ROLE DOMAINMACHINE$ ConfigurationSchema_ROLE DOMAINMACHINE$ DAS_ROLE DOMAINMACHINE$ DesktopUpdateManagerSchema_ROLE DOMAINMACHINE$ EnvTestServiceSchema_ROLE DOMAINMACHINE$ HostingUnitServiceSchema_ROLE DOMAINMACHINE$ Monitor_ROLE DOMAINMACHINE$ MonitorData_ROLE DOMAINMACHINE$ StorefrontSchema_ROLE DOMAINMACHINE$
Test Restored Database
- From Each Controller, test the database connection string before making changes:
## ## Replace <dbserver> with the New SQL server, and instance if present ## Replace <dbname> with the name of your restored Database ## ## $ServerName="<dbserver>" $DBName ="<dbname>" # $cs="Server=$ServerName; Initial Catalog=$DBName; Integrated Security=True" $cs Test-AdminDBConnection -DBConnection $cs Test-ConfigDBConnection -DBConnection $cs Test-AcctDBConnection -DBConnection $cs Test-HypDBConnection -DBConnection $cs Test-ProvDBConnection -DBConnection $cs Test-BrokerDBConnection -DBConnection $cs Test-EnvTestDBConnection -DBConnection $cs Test-LogDBConnection -DBConnection $cs Test-MonitorDBConnection -DBConnection $cs Test-SfDBConnection -DBConnection $cs
Migrate First Controller to New Database
- Remove the existing Database connections:
At the Delivery Controllers, from the open PowerShell window, run the following commands where <dbserver> is the name of your SQL server, which is the instance if defined and <dbname> is the name of the XenDesktop database. This process clears the existing database connection and then configures the new connection for each service:
## ## First unregister the Delivery Controllers from the current database: ## Set-ConfigDBConnection -DBConnection $null Set-AcctDBConnection -DBConnection $null Set-HypDBConnection -DBConnection $null Set-ProvDBConnection -DBConnection $null Set-BrokerDBConnection -DBConnection $null Set-EnvTestDBConnection -DBConnection $null Set-SfDBConnection -DBConnection $null Set-MonitorDBConnection -DBConnection $null Set-MonitorDBConnection -DataStore Monitor -DBConnection $null
Set-LogDBConnection -DBConnection $null Set-LogDBConnection -DataStore Logging -DBConnection $null
Set-AdminDBConnection -DBConnection $null
- If you see the following error, you must restart all the Citrix services:
- After restarting all the Citrix services, you must possibly restart the server:
Get-Service Citrix* | Stop-Service -Force Get-Service Citrix* | Start-Service
- Rerun the original set of command to confirm that the existing connection is properly removed and returns status:DBUnconfigured.
- Redirect the Controller to the new database:
## ## Replace <dbserver> with the New SQL server, and instance if present ## Replace <dbname> with the name of your restored Database ## ## $ServerName="<dbserver>" $DBName ="<dbname>" # $cs="Server=$ServerName;Initial Catalog=$DBName;Integrated Security=True" $cs Set-AdminDBConnection -DBConnection $cs Set-ConfigDBConnection -DBConnection $cs Set-AcctDBConnection -DBConnection $cs Set-HypDBConnection -DBConnection $cs Set-ProvDBConnection -DBConnection $cs #Set-PvsVmDBConnection -DBConnection $cs Set-BrokerDBConnection -DBConnection $cs Set-EnvTestDBConnection -DBConnection $cs Set-LogDBConnection -DBConnection $cs Set-LogDBConnection -DataStore Logging -DBConnection $cs Set-MonitorDBConnection -DBConnection $cs Set-MonitorDBConnection -DataStore Monitor -DBConnection $cs Set-SfDBConnection -DBConnection $cs
Note: It is important to verify that all the preceding Set-<service>DBConnection commands have returned a result of OK. In case, when the result is other than OK 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 can be used to verify the consistency of your database after the move.
If any Virtual Delivery Agents were running when the Controller services were shut down in Step 1, then it could take up to 10 minutes before the Virtual Desktop Agents re-registers. No other action should be necessary.
- After moving the Delivery Controllers, on each of them enable Monitoring and Logging:
##Enable Monitoring Set-MonitorConfiguration -DataCollectionEnabled $true
##Enable Configuration Logging Set-LogSite -State "Enabled"
- Restart Citrix Studio.
- From each Controller, test the database connection services to the new database:
Get-AcctServiceStatus Get-AdminServiceStatus Get-BrokerServiceStatus Get-ConfigServiceStatus Get-EnvTestServiceStatus Get-HypServiceStatus Get-LogServiceStatus Get-MonitorServiceStatus Get-ProvServiceStatus Get-SfServiceStatus