In diesem Blogbeitrag möchte ich euch über die Möglichkeit berichten, die drei Citrix-SQL-Datenbanken (Site, Monitoring, Logging) auf einen anderen SQL-Server zu migrieren. Ich schreibe diesen Beitrag, da ich im Internet komischerweise keine für mich passende Anleitung gefunden habe. Ich war dadurch gezwungen, mir die Infos von mehreren Seiten zusammenzutragen. Eigentlich ist das Migrieren der Datenbanken kein Hexenwerk, trotzdem sollte man für einen reibungslosen Ablauf ein paar Dinge beachten.

  1. ) Datenbank sichern
    Im ersten Schritt sollten wir die Datenbanken auf dem jetzigen SQL-Server sichern. Sollten wir nicht wissen, auf welchem Server sich die Datenbanken aktuell befinden, können wir das mit PowerShell-Befehlen feststellen.
asnp citrix* <- Die Citrix PowerShell Module
Get-BrokerDBConnection <- Zeigt die Site Database Verbindung an
Get-LogDBConnection <- Zeigt die Configuration Logging Database Verbindung an
Get-MonitorDBConnection <- Zeigt die Monitor Database Verbindung an
In unserem Beispiel lautet der Server DEHWT-DC04, und die Datenbanken haben als Präfix CitrixDEDHN.

Um mit der Sicherung zu beginnen, sollten wir zuvor dafür sorgen, dass der Delivery Controller (global für die Site) keine weiteren Daten in die Monitoring- und Logging-Datenbank schreibt.

Set-MonitorConfiguration -DataCollectionEnabled $false <- Deaktiviert das Monitoring

Set-LogSite -State Disabled <- Deaktiviert das Logging

Die beiden Befehle geben keine Rückmeldung bei erfolgter Ausführung.

Entweder verbinden wir uns jetzt Remote oder direkt auf dem SQL Server via SQL Management Studio zur entsprechenden Instanz des SQL Servers.

Nach dem Login auf der SQL-Server-Instanz

Durch einen Rechtsklick auf die jeweilige Datenbank öffnet sich ein Kontextmenü. Unter Tasks befindet sich der Punkt Back Up

Im nächsten Dialog müssen wir das Backupziel auswählen. In diesem Fall habe ich den Ordner Temp gewählt. Zusätzlich kann man einen Namen für die Backupdatei wählen. Bitte darauf achten: Wenn ihr keine Dateiendung angibt, wird die Datei ohne Endung gespeichert. 🙂 Wir wiederholen diesen Schritt für alle drei Datenbanken.

Es gibt hier je nach SQL-Version auch die Möglichkeit, ein Backup auf ein Bandlaufwerk zu schreiben.

Nun wechseln wir auf den neuen SQL-Server, auf dem wir die drei Datenbanken einspielen wollen. In unserem Beispiel heißt der neue Server ADM01. Nachdem wir auch hier via Management Studio verbunden sind, klicken wir mit der rechten Maustaste auf den Punkt Database und wählen im Kontextmenü Restore Database.

Hier könnt ihr dann unter Device eure Datenbank lokal oder auf einem Netzlaufwerk suchen. Achtung: Ihr könnt zwar eine Mehrfachauswahl treffen (mehrere Dateien gleichzeitig), aber trotzdem nur die zuletzt gewählte Datenbank unter dem Punkt Database importieren. Falls es dafür doch einen Weg gibt und man alle drei Datenbanken auf einmal importieren kann: gerne per Mail. Ansonsten wiederholen wir den Schritt für jede exportierte Datenbank.

Als Nächstes erstellen wir den Account (Computerkonto) für den Delivery Controller. Da es nicht möglich ist, ein Computerkonto über die Standardfunktion hinzuzufügen, verwenden wir eine kurze SQL-Abfrage. Diesen Vorgang wiederholen wir natürlich für jeden Delivery Controller den wir in unserer Site haben.

create login [itnetx\dehwt-xc01$] from windows

Nachdem wir das Computerkonto hinzugefügt haben, überprüfen wir die Berechtigungen des Computerkontos auf den Datenbanken. Da sich die SID des Computerkontos nicht geändert hat, sollten alle Berechtigungen noch richtig gesetzt sein. Rechte Maustaste auf den entsprechenden Computeraccount → Properties

Unter User Mappings können wir dann einzeln für jede Datenbank die „role membership“ prüfen. Für Configuration Logging ist es:

Logging database – ConfigLoggingSchema_ROLE
Logging database – public

Für die Monitoring Database sind es die folgenden Rollen:

Monitoring database – Monitor_ROLE
Monitoring database – public

Abschließend für die Site Database sind es folgende Rollen:

Site database – ADIdentitySchema_ROL
Site database – Analytics_ROLE (7.8 and newer)
Site database – AppLibrarySchema_ROLE (7.8 and newer)
Site database – chr_Broker
Site database – chr_Controller Site database – ConfigLoggingSchema_ROLE
Site database – ConfigLoggingSiteSchema_ROLE
Site database – ConfigurationSchema_ROLE 
Site database – DAS_ROLE
Site database – DesktopUpdateManagerSchema_ROLE
Site database – EnvTestServiceSchema_ROLE
Site database – HostingUnitServiceSchema_ROLE
Site database – Monitor_ROLE
Site database – MonitorData_ROLE
Site database – OrchestrationSchema_ROLE (7.11 and newer)
Site database – public 
Site database – StoreFrontSchema_ROLE (7.8 and newer)
Site database – TrustSchema_ROLE (7.11 and newer)

Nachdem wir nun alles für einen reibungslosen Übergang zum neuen Datenbankserver vorbereitet haben, beginnen wir damit die alten Datenbankverbindung vom Delivery Controller zu trennen. Vorab können wir uns noch versichern, dass der Local Host Cache aktiv ist. Damit sind zumindest Shared Desktops beim Umschalten weiter verfügbar. Bestehende Verbindungen zu Hosted Shared Desktops oder Hosted VDI sind von dem Ausfall zudem auch nicht betroffen.

Get-BrokerSite

Set-BrokerSite -LocalHostCacheEnabled $true -ConnectionLeasingEnabled $false <- Setzt den LHC sollte er nicht gesetzt sein.

Wir müssen jetzt verschiedene Einträge, die auf unsere alte Datenbank verweisen, „nullen“. Idealerweise schreiben wir uns die Zeilen in der Microsoft ISE oder einem anderen PowerShell Editor eurer Wahl zusammen. Ihr könnt euch auch mit dem folgenden Befehl alle Set-*DBConnection Befehle anzeigen lassen.

get-command set-*DBConnection

Jetzt übertragen wir unsere Befehle in ein Skript. Wichtig ist, dass die AdminDBConnection als letzte genullt wird.

Set-ConfigDBConnection -DBConnection $null
Set-AppLibDBConnection –DBConnection $null    
Set-OrchDBConnection –DBConnection $null      
Set-TrustDBConnection –DBConnection $null     
Set-AcctDBConnection -DBConnection $null
Set-AnalyticsDBConnection -DBConnection $null 
Set-HypDBConnection -DBConnection $null
Set-ProvDBConnection -DBConnection $null
Set-BrokerDBConnection -DBConnection $null
Set-EnvTestDBConnection -DBConnection $null
Set-SfDBConnection -DBConnection $null
Set-MonitorDBConnection -DataStore Monitor -DBConnection $null  
Set-MonitorDBConnection -DBConnection $null                     
Set-LogDBConnection -DataStore Logging -DBConnection $null       
Set-LogDBConnection -DBConnection $null                          
Set-AdminDBConnection -DBConnection $null -force

Nachdem wir das auf dem ersten Delivery Controller gemacht haben, müssen wir es natürlich auch auf dem zweiten tun. Entweder verbinden wir uns dort per RDP oder machen es per PowerShell

Enter-PSSession $Hostname

Dort führt ihr natürlich auch das Script aus. Vorher müsst ihr aber dort nochmal die Citrix Module laden wie oben beschrieben.

Nachdem nun alle Datenbankeinträge genullt sind, hat der Delivery Controller den Local Host Cache aktiviert, und eine aktive Steuerung ist nicht mehr möglich. Damit wir diesen Zustand schnell wieder ändern, setzen wir ein weiteres Skript ein. Wichtig sind für euch die oberen 4 Zeilen. Dort pflegt ihr ServerName sowie die Namen der unterschiedlichen Datenbanken. Solltet ihr mehrere SQL-Instanzen haben, müsst ihr die entsprechende Instanz beim ServerName mit angeben.

$ServerName = "ADM01"
$SiteDBName = "CitrixDEDHNSite"
$LogDBName = "CitrixDEDHNLogging"
$MonitorDBName = "CitrixDEDHNMonintoring"

$csSite = "Server=$ServerName;Initial Catalog=$SiteDBName;Integrated Security=True;MultiSubnetFailover=True"

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

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

Set-AdminDBConnection -DBConnection $csSite
Set-ConfigDBConnection -DBConnection $csSite
Set-AcctDBConnection -DBConnection $csSite
Set-AnalyticsDBConnection -DBConnection $csSite # 7.6 and newer
Set-HypDBConnection -DBConnection $csSite 
Set-ProvDBConnection -DBConnection $csSite
Set-AppLibDBConnection –DBConnection $csSite # 7.8 and newer
Set-OrchDBConnection –DBConnection $csSite # 7.11 and newer
Set-TrustDBConnection –DBConnection $csSite # 7.11 and newer
Set-BrokerDBConnection -DBConnection $csSite
Set-EnvTestDBConnection -DBConnection $csSite
Set-SfDBConnection -DBConnection $csSite
Set-LogDBConnection -DBConnection $csSite
Set-LogDBConnection -DataStore Logging -DBConnection $null
Set-LogDBConnection -DBConnection $null
Set-LogDBConnection -DBConnection $csSite
Set-LogDBConnection -DataStore Logging -DBConnection $csLogging
Set-MonitorDBConnection -DBConnection $csSite
Set-MonitorDBConnection -DataStore Monitor -DBConnection $null
Set-MonitorDBConnection -DBConnection $null
Set-MonitorDBConnection -DBConnection $csSite
Set-MonitorDBConnection -DataStore Monitor -DBConnection $csMonitoring

Nun setzen wir das Script auf dem ersten Delivery Controller ab.

Nachdem das erfolgreich durchgeführt wurde, wechseln wir auf den nächsten Delivery Controller in unserer Site und führen das Skript auch dort aus.

Abschließend aktivieren wir wieder Logging und Monitoring und kontrollieren die Verfügbarkeit der Site im Citrix Studio.

Set-MonitorConfiguration -DataCollectionEnabled $true

Set-LogSite -State Enable

Ein Test im Studio über den Zustand der Site

Alternativer Test über die PowerShell

Get-AcctServiceStatus
Get-AdminServiceStatus
Get-BrokerServiceStatus
Get-ConfigServiceStatus
Get-EnvTestServiceStatus
Get-HypServiceStatus
Get-LogServiceStatus
Get-MonitorServiceStatus
Get-ProvServiceStatus
Get-SfServiceStatus
Get-AppLibServiceStatus

Ich hoffe, die Anleitung ist für euch hilfreich und ihr könnt sie bei der nächsten Datenbankmigration gebrauchen. Solltet ihr Fragen, Anregungen oder Kritik haben: gerne per Mail. Bis zum nächsten Blogpost.