Vollautomatische Konfiguration von Availability Groups
auf Windows Server Failover Clustern
Uwe Janke · Senior SQL Server DBA · dtcSoftware
AlwaysOn-Konfiguration manuell — ein fehleranfälliger Marathon.
Zeitaufwand für eine manuelle AG-Einrichtung — je nach Erfahrung des Bearbeiters
Jeder DBA hat seine eigene Word-Checklist. Kein einheitlicher Stand, keine Versionierung
Schritt vergessen? Falsche Portangabe? Endpoint schon vorhanden? — Fehler fallen spät auf
SPNs fehlen → Cannot generate SSPI context → AD-Team kontaktieren → warten → weitermachen
WSFC-Gruppe hängt noch, Registry-Key blockiert Neuversuch — schwer zu finden ohne Erfahrung
Was wurde konfiguriert? Welcher Failover-Modus? Welches Service-Konto? — Nachträglich kaum rekonstruierbar
Ein einziges Script — AlwaysOnSetup.ps1 — erledigt alle 9 Konfigurationsschritte vollautomatisch nach einmaliger Parameterprüfung.
Cluster-Daten werden automatisch eingelesen. Kein Tippen nötig — nur prüfen und starten.
Cluster-Backup, vollständiges Log und SPN-Anforderungsdatei werden automatisch gespeichert.
Kann bei Fehler neu gestartet werden. Bereinigt WSFC-Überreste automatisch.
| Vorher | Nachher |
|---|---|
| 2–4 Stunden | ~20 Minuten |
| Checkliste Word/Excel | GUI mit Vorbelgung |
| Kein Log | 3 Dateien automatisch |
| SPN: AD-Team anrufen | setspn-Datei generiert |
| Fehlversuch → manuell putzen | Automatischer WSFC-Cleanup |
Das Tool konfiguriert — es baut nicht. Was vorher stehen muss:
Windows Server Failover Cluster mit 2 oder 3 Nodes
Enterprise oder Standard auf allen Nodes, gleiche Version
Zwischen allen Nodes für den HADR Mirroring Endpoint
UNC-Pfad beschreibbar von allen Nodes
| Anforderung | Hinweis |
|---|---|
| Lokaler Administrator | Auf dem ausführenden Node |
SQL sysadmin | Auf allen Nodes |
| Domänen-Leserecht | Für SPN-Prüfung (Schritt 9) |
FailoverClusters | Wird automatisch installiert |
dbaTools ≥ 2.0 | Wird automatisch installiert |
Cluster-Daten werden automatisch eingelesen. PropertyGrid links — Live-Log rechts.
Alle Schritte laufen sequenziell und protokolliert. Übersprungene Schritte werden im Log ausgewiesen.
AlwaysOn ist in SQL Server standardmäßig deaktiviert und muss auf jedem Node einzeln eingeschaltet werden.
Auf allen Nodes: hadr enabled = 1 via Invoke-DbaQuery
Win32_Service.StopService() / StartService() — kein Restart-Computer nötig
SELECT 1 alle 2 Sek., max. 120 Sek. — erst dann weiter zu Schritt 3
Restart-Service MSSQLSERVER prüft nicht ob der Dienst wirklich wieder bereit ist.
WMI + aktiver Verbindungstest stellt sicher, dass SQL Server vollständig initialisiert ist, bevor Schritt 3 beginnt.
# Auf jedem Node: Invoke-DbaQuery -SqlInstance $node ` -Query "EXEC sp_configure 'hadr enabled',1; RECONFIGURE" # WMI Dienst-Neustart $svc = Get-WmiObject Win32_Service ` -ComputerName $node ` -Filter "Name='MSSQLSERVER'" $svc.StopService() # warten bis Stopped $svc.StartService() # warten bis Running # Bereitschaftstest (max. 120s) $ok = $false for ($i=0; $i -lt 60; $i++) { try { Invoke-DbaQuery -Query "SELECT 1" $ok = $true; break } catch { Start-Sleep 2 } } if (-not $ok) { throw "Timeout" }
Für CREATE AVAILABILITY GROUP wird bewusst sqlcmd direkt verwendet — nicht Invoke-DbaQuery.
sys.availability_groups noch leer — obwohl die AG bereits existiert.
sqlcmd öffnet bei jedem Aufruf eine frische TCP-Verbindung und sieht den aktuellen Zustand.
Invoke-DbaQuery und Connect-DbaInstance werden genutzt.
Alle anderen Operationen: direktes T-SQL, WMI oder FailoverClusters-Cmdlets.
# CREATE AVAILABILITY GROUP via sqlcmd # -- frische Verbindung, kein dbaTools-Cache $sql = @" CREATE AVAILABILITY GROUP [$AgName] WITH (AUTOMATED_BACKUP_PREFERENCE = PRIMARY) FOR DATABASE [$TestDb] REPLICA ON N'$node1' WITH ( ENDPOINT_URL = 'TCP://$node1:5022', FAILOVER_MODE = AUTOMATIC, AVAILABILITY_MODE = SYNCHRONOUS_COMMIT), N'$node2' WITH ( ENDPOINT_URL = 'TCP://$node2:5022', FAILOVER_MODE = AUTOMATIC, AVAILABILITY_MODE = SYNCHRONOUS_COMMIT); "@ # sqlcmd direkt aufrufen sqlcmd -S $node1 -E -Q $sql
SPNs ermöglichen Kerberos-Auth. Fehlen sie, schlägt Windows-Auth mit Cannot generate SSPI context fehl.
| Situation | Ablauf |
|---|---|
| SPNs gesetzt ✓ | Vollautomatisch — kein Eingriff |
| SPNs fehlen ✗ | Pause → T-SQL anzeigen → manuell → Weiter |
Fallback-Mechanismus:
Kerberos-Test schlägt fehl auf betroffenem Node
Temporäres Login — fertig zum Kopieren in SSMS
Tool prüft SQL-Auth, setzt mit allen Schritten fort
Temporäres Login am Ende garantiert gelöscht
# Je Node – Kurzname und FQDN setspn -S MSSQLSvc/SQLNODE01:1433 DOM\svc-sql setspn -S MSSQLSvc/SQLNODE01.dom.com:1433 DOM\svc-sql setspn -S MSSQLSvc/SQLNODE02:1433 DOM\svc-sql setspn -S MSSQLSvc/SQLNODE02.dom.com:1433 DOM\svc-sql # AG-Listener setspn -S MSSQLSvc/AG-LISTENER:1433 DOM\svc-sql setspn -S MSSQLSvc/AG-LISTENER.dom.com:1433 DOM\svc-sql # Prüfung: setspn -L DOM\svc-sql
AlwaysOn_SPN_ADTeam_<Datum>.txtAlle Dateien landen automatisch unter C:\System\WinSrvLog\MSSQL\ — keine manuelle Aktion nötig.
| Datei | Inhalt | Zeitpunkt |
|---|---|---|
AlwaysOn_ClusterSettings_<Datum>.txt | Cluster-Backup vor Änderungen | Schritt 1 |
AlwaysOn_Setup_<Datum>.log | Vollständiges Text-Log | Abschluss |
AlwaysOn_Setup_<Datum>.rtf | Farbiges Log (manuell) | Manuell |
AlwaysOn_SPN_ADTeam_<Datum>.txt | setspn-Befehle für AD-Team | Schritt 9 |
| ■ Blau | Abschnittsüberschrift |
| ■ Grün | Erfolg |
| ■ Gelb | Warnung / Hinweis |
| ■ Rot | Fehler |
Fehlgeschlagene Setup-Versuche hinterlassen WSFC-Überreste, die einen Neuversuch blockieren.
Tool prüft ob WSFC-Gruppe für den AG-Namen bereits existiert
-RemoveResources -Force — vollständige Bereinigung
HadrAgNameToldMap auf allen Nodes via Invoke-Command
Kein manueller Eingriff nötig
# WSFC-Überreste prüfen und bereinigen $existingGroup = Get-ClusterGroup ` -Name $AgName -ErrorAction SilentlyContinue if ($existingGroup) { Write-Log "Verwaiste WSFC-Gruppe gefunden – bereinige..." Stop-ClusterGroup -Name $AgName -Force Remove-ClusterGroup -Name $AgName ` -RemoveResources -Force } # Registry auf allen Nodes bereinigen $regKey = "HKLM:\Cluster\HadrAgNameToldMap" Invoke-Command -ComputerName $allNodes { if (Test-Path $using:regKey) { Remove-ItemProperty -Path $using:regKey ` -Name $using:AgName -ErrorAction SilentlyContinue } }
Das AlwaysOn Setup Tool richtet die AG ein. sqmSQLTool übernimmt danach den laufenden Betrieb.
Invoke-sqmSplunkConfiguration — AG-Replikationsstatus, Sync-Health, Failover-Events an Splunk
Invoke-sqmSaObfuscation — SA-Account auf allen Nodes umbenennen, Standardangriffsfläche reduzieren
New-sqmSqlCertificate — Endpoint-Verschlüsselung mit eigenem SQL-Zertifikat absichern
Get-sqmServerSetting — regelmäßige Prüfung aller AG-Replicas auf Synchronisierungsstatus
Invoke-sqmUserDatabaseBackup — erkennt Read-Only Secondaries automatisch und überspringt sie
Get-sqmDeadlockReport — AG-aware, liest nur vom Primary, stündliche Erfassung
Was das Tool bewusst nicht macht — und warum.
| Aufgabe | Zuständigkeit |
|---|---|
| WSFC anlegen | Server-Team / Failover-Cluster-Setup |
| DNS-Einträge für Listener | Netzwerk-Team |
| Firewall Port 5022 | Netzwerk-Team |
| SPNs setzen | AD-Team (Tool liefert die Befehle) |
| SQL Server installieren | SQLSetupTool |
| Produktivdatenbanken in AG aufnehmen | Manuell / Migration Tool |
.\AlwaysOnSetup.ps1). Kein Installer, keine Registry-Einträge — bewusst einfach zu deployen.
| Fehlermeldung | Ursache | Lösung |
|---|---|---|
Cannot generate SSPI context |
SPNs fehlen im AD | Manuellen SQL-Login-Schritt im Tool durchführen. Langfristig: AD-Team SPNs setzen lassen |
WSFC group … already exists |
Überrest eines Fehlversuchs | Tool bereinigt automatisch: Remove-ClusterGroup + Registry |
Login failed for user AGSetup_… |
Mixed Mode deaktiviert oder Password-Policy | Server Properties → Security → SQL Server and Windows Authentication mode |
Backup-Verzeichnis nicht erreichbar |
UNC-Pfad ungültig / keine Schreibrechte | Pfad im PropertyGrid korrigieren — muss von allen Nodes beschreibbar sein |
Endpoint-Port 5022 belegt |
Bestehender Endpoint oder anderer Dienst | SELECT * FROM sys.endpoints WHERE type=4 — Port im PropertyGrid anpassen |
AG nach 60s nicht sichtbar |
SQL Server nicht vollständig bereit | Tool wartet aktiv bis 120s. Danach Dienst manuell prüfen |
Endpoint-Eigentümer ungültig |
Temporärer AGSetup_*-Login war Eigentümer und wurde gelöscht |
AUTHORIZATION auf Service-Konto gesetzt — tritt nicht mehr auf |
AUTHORIZATION-Klausel setzt SQL Server den aktuell ausführenden Login als Endpoint-Eigentümer.
Im SQL-Auth-Fallback (fehlende SPNs) wäre das der temporäre AGSetup_XXXXXXXX-Login —
der am Ende von Schritt 9 gelöscht wird. Ergebnis: Endpoint existiert weiter, sein Eigentümer-Principal nicht mehr.
Das Tool setzt daher explizit AUTHORIZATION [<ServiceKonto>] — oder sa als Fallback.
Vollautomatischer Durchlauf nach einmaliger Parameterprüfung
Fehlende SPNs stoppen das Setup nicht — kontrollierter Workaround
Cluster-Backup, Log, SPN-Datei — ohne Zusatzaufwand
WSFC-Cleanup erlaubt sauberen Neuversuch nach Fehler
Zusammen mit sqmSQLTool und SQLSetupTool vollständiger DBA-Workflow
| GitHub | github.com/JankeUwe/AlwaysOnSetup |
| Doku | AlwaysOn_Doku.html |
| Handbuch | AlwaysOn_Handbuch.docx |
| Website | www.powershelldba.de |