Mit der neuesten Citrix Virtual Apps & Desktops (CVAD) LTSR Version wurden ältere SQL-Server-Versionen abgekündigt. Wer seine Umgebung stabil und supportfähig halten möchte, kommt um eine Migration der Citrix-Datenbanken (Site, Logging, Monitoring) auf moderne SQL-Server (2019/2022) nicht herum. Ob Cluster, Always On oder Spiegelung – das Vorgehen bleibt im Kern gleich. In diesem Beitrag zeige ich Schritt für Schritt, wie die Migration sicher gelingt.
1. Voraussetzungen
- Vollständige Backups aller Citrix-Datenbanken
- Backups/VM-Snapshots der Delivery Controller (DDCs)
- Neuer SQL Server (Cluster, Always On oder Mirror)
- Gleiche SQL-Version auf Principal und Mirror
1.1 Backups erstellen
Bevor du mit der Migration beginnst, steht das Wichtigste an erster Stelle: saubere, verifizierte Backups.
Klingt banal, aber wer einmal eine Citrix-Site ohne funktionierendes Backup wiederherstellen musste, weiß, warum dieser Schritt entscheidend ist.
Erstelle vollständige Datenbank-Backups aller Citrix-Datenbanken:
- Monitoring-Datenbank (z. B.
CitrixMonitoring) - Site-Datenbank (z. B.
CitrixSite) - Logging-Datenbank (z. B.
CitrixLogging)
1.1.1 Schritt-für-Schritt in SSMS (GUI)
- SQL Server Management Studio (SSMS) starten und am Quell-SQL verbinden (Windows/SQL-Auth)
- Im Objekt-Explorer die erste DB auswählen (z. B. CitrixLogging)
- Rechtsklick auf die DB → Tasks → Backup…
- Backup type auf Full stellen
- Unter Destination ggf. Einträge entfernen, dann Add… → Datei wählen, z. B. D:\Backups\CitrixLogging_Full_YYYYMMDDHHmm.bak
- Reiter Media Options
- Verify backup when finished (Backup nach Abschluss prüfen)
- Perform checksum before writing to media (falls verfügbar)
- Reiter Backup Options
- Compress backup (kleinere, schnellere Backups)
- OK klicken → Erfolgsmeldung abwarten
- Das Ganze für Site-DB und Monitoring-DB wiederholen (CitrixSite, CitrixMonitoring o. ä.)
- Transaktionsprotokoll-Backups erstellen (Recovery Model Full!):
- Wieder Tasks → Backup…, Backup type = Transaction Log, Ziel: *.trn
- Optional: mehrere Log-Backups bis zum Migrationszeitpunkt sichern
- Backupdateien auf eine Freigabe kopieren, die der neue SQL-Server lesen kann
1.1.2 T-SQL Alternative
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
-- Full Backups (COPY_ONLY, CHECKSUM, COMPRESSION empfohlen) BACKUP DATABASE [CitrixSite] TO DISK = N'D:\Backups\CitrixSite_Full_YYYYMMDD.bak' WITH COPY_ONLY, CHECKSUM, COMPRESSION, STATS = 10; BACKUP DATABASE [CitrixLogging] TO DISK = N'D:\Backups\CitrixLogging_Full_YYYYMMDD.bak' WITH COPY_ONLY, CHECKSUM, COMPRESSION, STATS = 10; BACKUP DATABASE [CitrixMonitoring] TO DISK = N'D:\Backups\CitrixMonitoring_Full_YYYYMMDD.bak' WITH COPY_ONLY, CHECKSUM, COMPRESSION, STATS = 10; -- Transaktionslog (nur bei Recovery Model = FULL) BACKUP LOG [CitrixSite] TO DISK = N'D:\Backups\CitrixSite_Log_YYYYMMDD_HHMM.trn' WITH CHECKSUM, COMPRESSION, STATS = 10; |
2. Datenbank-Wiederherstellung
Nach dem Backup folgt der eigentliche Migrationsschritt: das Wiederherstellen (Restore) der Citrix-Datenbanken auf dem neuen SQL-Server.
Dabei spielt es keine Rolle, ob du eine Standalone-Instanz, einen Cluster oder Always On verwendest – das Vorgehen bleibt im Kern gleich.
2.1.1 Restore auf neuem Principal (GUI)
- Am neuen SQL-Server in SSMS verbinden
- Objekt-Explorer: Rechtsklick Databases → Restore Database…
- Source = Device → Add… → Full-Backup *.bak wählen
- Destination prüfen (DB-Name unverändert lassen)
- Reiter Files: Pfade ggf. an neue Laufwerke anpassen
- Reiter Options:
- RESTORE WITH RECOVERY (Standard)
- „Overwrite the existing database“ nur wenn wirklich nötig
- OK → Erfolgsmeldung. Danach ggf. das letzte Log-Backup einspielen (nur wenn du bis T-Zeitpunkt gehen willst)
2.1.2 Restore per T-SQL
|
1 2 3 4 5 6 7 8 |
RESTORE DATABASE [CitrixSite] FROM DISK = N'\\BackupShare\CitrixSite_Full_YYYYMMDD.bak' WITH MOVE N'CitrixSite' TO N'D:\SQLData\CitrixSite.mdf', MOVE N'CitrixSite_log' TO N'D:\SQLLogs\CitrixSite.ldf', CHECKSUM, STATS = 10, RECOVERY; -- Optional bis zu einem Zeitpunkt: -- RESTORE LOG [CitrixSite] FROM DISK = N'...\CitrixSite_Log_YYYYMMDD_HHMM.trn' WITH RECOVERY; |
2.2 Logins & Berechtigungen
Nach dem Restore müssen die Delivery Controller (DDC)-Maschinenkonten wieder Zugriff auf die neuen Datenbanken bekommen.
Da SQL-Server-Logins serverweit sind, werden sie beim Backup/Restore nicht mitkopiert – du musst sie also manuell anlegen.
|
1 2 3 |
CREATE LOGIN [DOMAIN\DDC01$] FROM WINDOWS; CREATE LOGIN [DOMAIN\DDC02$] FROM WINDOWS; CREATE LOGIN [DOMAIN\DDC03$] FROM WINDOWS; |
Anschließend in jeder Citrix-Datenbank (Site, Logging, Monitoring) die passenden Rollen vergeben:
|
1 2 3 4 |
USE [CitrixSite]; EXEC sp_addrolemember N'db_owner', N'DOMAIN\DDC01$'; EXEC sp_addrolemember N'db_owner', N'DOMAIN\DDC02$'; EXEC sp_addrolemember N'db_owner', N'DOMAIN\DDC03$'; |
2.3 Optional: Seeding für Always On / Spiegelung
Wer seine Citrix-Datenbanken hochverfügbar betreiben will, kann sie in eine Always On Availability Group oder eine klassische Datenbankspiegelung einbinden.
Bei Always On gilt:
Alle beteiligten Replikas müssen identische Datenbanken besitzen, die mit NORECOVERY wiederhergestellt wurden.
Das nennt man Seeding — also das initiale Befüllen der sekundären Replikas.
|
1 2 3 4 5 6 7 8 9 10 |
-- Auf dem Sekundär-Knoten: RESTORE DATABASE [CitrixSite] FROM DISK = N'\\BackupShare\CitrixSite_Full_YYYYMMDD.bak' WITH MOVE N'CitrixSite' TO N'D:\SQLData\CitrixSite.mdf', MOVE N'CitrixSite_log' TO N'D:\SQLLogs\CitrixSite.ldf', NORECOVERY, CHECKSUM, STATS = 10; RESTORE LOG [CitrixSite] FROM DISK = N'\\BackupShare\CitrixSite_Log_YYYYMMDD.trn' WITH NORECOVERY, CHECKSUM, STATS = 10; |
Danach dieselben Schritte für Logging und Monitoring Datenbank durchführen.
Sobald alle DBs im Zustand RESTORING sind, kannst du sie der Availability Group hinzufügen.
Falls du noch mit klassischer SQL-Spiegelung (Mirroring) arbeitest, ist das Vorgehen ähnlich:
Auch hier muss die sekundäre Datenbank mit NORECOVERY wiederhergestellt werden.
|
1 2 3 4 5 6 7 |
RESTORE DATABASE [CitrixSite] FROM DISK = N'\\BackupShare\CitrixSite_Full_YYYYMMDD.bak' WITH NORECOVERY; RESTORE LOG [CitrixSite] FROM DISK = N'\\BackupShare\CitrixSite_Log_YYYYMMDD.trn' WITH NORECOVERY; |
Dann auf dem Principal:
|
1 2 |
ALTER DATABASE [CitrixSite] SET PARTNER = 'TCP://SQLMIRROR.domain.local:5022'; |
Und auf dem Mirror:
|
1 2 |
ALTER DATABASE [CitrixSite] SET PARTNER = 'TCP://SQLPRINCIPAL.domain.local:5022'; |
Sobald der Status „Synchronized“ erreicht ist, kannst du die anderen Citrix-Datenbanken identisch hinzufügen.
3. Delivery Controller vorbereiten
Bevor du die neuen Datenbankverbindungen setzen kannst, müssen die Delivery Controller (DDCs) vorbereitet werden.
Das Ziel: Alle bestehenden Verbindungen zur alten SQL-Umgebung sauber trennen, Logging und Monitoring kurzzeitig deaktivieren, und damit verhindern, dass Citrix-Dienste in der Migrationsphase fehlerhafte Daten schreiben.
3.1 Monitoring & Logging deaktivieren
Zunächst sollten alle Telemetrie- und Protokollierungsdienste pausiert werden.
Das verhindert unnötige Schreibvorgänge während des Wechsels der Datenbankverbindungen.
|
1 2 |
Set-MonitorConfiguration -DataCollectionEnabled $false Set-LogSite -State Disabled |
Damit werden sowohl das Citrix Monitoring als auch das Configuration Logging temporär abgeschaltet.
Sobald die Migration abgeschlossen ist, aktivierst du beide Funktionen wieder.
3.2 Alte DB-Verbindungen trennen
Jetzt müssen die alten DB-Verbindungen der Controller aufgelöst werden.
Die Citrix-Dienste (Broker, Config, Logging, Monitoring usw.) halten jeweils eigene SQL-Connectionstrings, die du einzeln auf null setzen musst.
Dazu zunächst das Citrix-Modul laden:
|
1 |
Asnp Citrix* |
Dann alle bestehenden Verbindungen löschen:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
Set-ConfigDBConnection -DBConnection $null Set-AcctDBConnection -DBConnection $null Set-AnalyticsDBConnection -DBConnection $null Set-AppLibDBConnection -DBConnection $null Set-BrokerDBConnection -DBConnection $null Set-EnvTestDBConnection -DBConnection $null Set-HypDBConnection -DBConnection $null Set-OrchDBConnection -DBConnection $null Set-ProvDBConnection -DBConnection $null Set-SfDBConnection -DBConnection $null Set-TrustDBConnection -DBConnection $null 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-AdminDBConnection -DBConnection $null -Force |
Nach diesen Befehlen bestehen keine aktiven SQL-Verbindungen mehr zwischen den Citrix-Diensten und der alten Datenbankumgebung.
- Führe diese Schritte auf allen Delivery Controllern aus (DDC01, DDC02, DDC03 etc.).
- In einem laufenden Cluster spielt die Reihenfolge keine Rolle – du kannst Controller einzeln umstellen.
- Wenn du sicher gehen willst, führe vorher
Get-BrokerServiceStatusaus, um zu prüfen, ob die Dienste sauber laufen.
Alle Controller sind jetzt von der alten Datenbank getrennt, Logging & Monitoring pausiert.
Damit ist die Umgebung bereit, um im nächsten Schritt die neuen Verbindungen zum neuen SQL-Server zu setzen.
4. Neue Verbindungen konfigurieren
Nachdem die alten Datenbankverbindungen getrennt wurden, können nun die neuen Connection Strings auf den Delivery Controllern gesetzt werden.
Dieser Schritt verknüpft die Citrix-Dienste wieder mit ihren jeweiligen Datenbanken — jetzt aber auf dem neuen SQL-Server.
Zuerst definierst du den Ziel-SQL-Server und die neuen Datenbanknamen.
Achte darauf, dass der SQL-Server-Name entweder direkt auf den neuen Server oder — bei Always On — auf den Listener zeigt.
|
1 2 3 4 5 6 7 8 |
$ServerName = "SQL2022.domain.local" $DBName = "CitrixSite" $LogDBName = "CitrixLogging" $MonitorDBName = "CitrixMonitoring" $cs = "Server=$ServerName;Initial Catalog=$DBName;Integrated Security=True" $csLogging = "Server=$ServerName;Initial Catalog=$LogDBName;Integrated Security=True" $csMonitoring = "Server=$ServerName;Initial Catalog=$MonitorDBName;Integrated Security=True" |
Wenn du Always On einsetzt, verwende unbedingt den Listener-Namen (z. B. SQL-LISTENER.DOMAIN.LOCAL) so bleiben deine Controller auch bei einem Failover verbunden, ohne dass du später Connection Strings anpassen musst.
4.1 Site-DB setzen
Jetzt stellst du die Verbindung zur neuen Site-Datenbank her.
Diese ist der Kern deiner Citrix-Umgebung und muss zuerst gesetzt werden.
|
1 2 3 4 5 6 7 8 9 10 11 |
Set-AdminDBConnection -DBConnection $cs Set-ConfigDBConnection -DBConnection $cs Set-AcctDBConnection -DBConnection $cs Set-AnalyticsDBConnection -DBConnection $cs Set-HypDBConnection -DBConnection $cs Set-ProvDBConnection -DBConnection $cs Set-BrokerDBConnection -DBConnection $cs Set-EnvTestDBConnection -DBConnection $cs Set-AppLibDBConnection -DBConnection $cs Set-SfDBConnection -DBConnection $cs Set-TrustDBConnection -DBConnection $cs |
Alle zentralen Citrix-Dienste (Broker, Config, Prov, Hyp, usw.) sind damit wieder mit der Site-DB verbunden.
4.2 Logging & Monitoring setzen
Als Nächstes folgen die beiden sekundären Datenbanken:
Configuration, Logging und Monitoring.
|
1 2 3 4 5 6 7 8 9 |
Set-LogDBConnection -DBConnection $cs Set-LogDBConnection -DataStore Logging -DBConnection $csLogging Set-LogDBConnection -DataStore Logging -DBConnection $null -Force Set-LogDBConnection -DataStore Logging -DBConnection $csLogging Set-MonitorDBConnection -DBConnection $cs Set-MonitorDBConnection -DataStore Monitor -DBConnection $csMonitoring Set-MonitorDBConnection -DataStore Monitor -DBConnection $null -Force Set-MonitorDBConnection -DataStore Monitor -DBConnection $csMonitoring |
Mit dieser Sequenz stellst du sicher, dass beide Dienste sauber auf die neuen Datenbanken zeigen und keine alten Connection Strings mehr aktiv sind.
4.3 Verbindung prüfen
Nach dem Setzen der neuen Verbindungen ist ein kurzer Funktionstest Pflicht.
Überprüfe den Status aller Citrix-Dienste:
|
1 2 3 4 5 6 7 8 9 10 11 |
Get-AcctServiceStatus Get-AdminServiceStatus Get-BrokerServiceStatus Get-ConfigServiceStatus Get-EnvTestServiceStatus Get-HypServiceStatus Get-LogServiceStatus Get-MonitorServiceStatus Get-ProvServiceStatus Get-SfServiceStatus Get-AppLibServiceStatus |
Alle Services sollten den Status OK zurückgeben und auf den neuen SQL-Server verweisen.
Wenn du mehrere Delivery Controller hast, wiederhole diese Schritte auf allen Knoten. Prüfe anschließend per Get-LogDBConnection und Get-MonitorDBConnection, ob wirklich alle Controller dieselben Connection Strings nutzen. Unterschiedliche Connection Strings führen später oft zu Synchronisationsproblemen zwischen den Services.
4.4 Logging & Monitoring wieder aktivieren
Wenn alle Verbindungen erfolgreich gesetzt wurden, kannst du die zuvor deaktivierten Dienste wieder einschalten:
|
1 2 |
Set-MonitorConfiguration -DataCollectionEnabled $true Set-LogSite -State Enabled |
Damit ist die Citrix-Site wieder voll funktionsfähig und produktionsbereit.
5. Fazit
Die Migration der Citrix-Datenbanken ist kein Hexenwerk – aber sie verlangt Disziplin, ein sauberes Vorgehen und ein Verständnis für die internen Abhängigkeiten der Citrix-Dienste.
Wer planlos „einfach restored“, riskiert fehlerhafte Verbindungen, defekte Logging-Datenbanken oder abgebrochene Monitoring-Sessions.
Mit dem oben beschriebenen strukturierten Ablauf bleibt die Migration dagegen transparent, sicher und reproduzierbar.
Wichtig ist vor allem:
- Backups prüfen, bevor du loslegst.
- Datenbanken in der richtigen Reihenfolge wiederherstellen.
- Controller-Verbindungen kontrolliert trennen und neu setzen.
- Am Ende alle Services testen – lieber einmal zu viel als zu wenig.
Besonders in produktiven Enterprise-Umgebungen empfiehlt es sich, die Schritte vorher in einer Testfarm zu simulieren und die Connection Strings zu dokumentieren.
So lassen sich Fehler im Live-System vermeiden, und du kannst bei Problemen jederzeit Rollbacken.
Wer darüber hinaus Always On oder SQL-Spiegelung nutzt, profitiert von echter Hochverfügbarkeit und stellt sicher, dass seine Citrix-Site auch bei SQL-Ausfällen weiterarbeitet, ohne dass die Benutzer es merken.
Kurz gesagt:
Eine saubere Citrix-Datenbankmigration ist weniger eine technische Herausforderung als eine Frage der Vorbereitung und Sorgfalt.
Wer die Schritte beherrscht, hat nicht nur ein stabiles System, sondern auch die perfekte Vorlage für künftige Updates oder SQL-Wechsel.
