SQL Server AlwaysOn Setup Tool v1.0.0

Cluster: SQL-CLUSTER-01

Primary Node

1 – Cluster
Cluster-Name	SQL-CLUSTER-01
Nodes	NODE-01, NODE-02
2 – Dienst
Service-Konto	DOMAIN\svc-sql-db
Passwort	••••••••
3 – Availability Group
AG-Name	AG-PRODUCTION-01
Listener-Name	AG-LISTENER-01
Listener-IP	10.10.50.100
Listener-Port	1433
Endpoint-Port	5022
Failover-Modus	Automatic
Backup-Präferenz	Primary
4 – Backup
Test-Datenbank	AlwaysOnTest
Backup-Share	\\\\FILESERVER\SQLBackup

[10:56:32] === SQL Server AlwaysOn Setup Tool v1.0.0 ===
[10:56:32] === Modul-Voraussetzungen ===
[10:56:32] FailoverClusters v2.0.0.0 – OK
[10:56:32] dbaTools v2.7.13 – OK
[10:56:32] === Cluster- und SQL-Informationen einlesen ===
[10:56:32] Cluster gefunden: SQL-CLUSTER-01
[10:56:32] Nodes: SQL-NODE-01, SQL-NODE-02
[10:56:32] Listener-Name: AG-LISTENER-01 | IP: 10.10.50.100 | Port: 1433
[10:56:33] SQL-NODE-01 – Dienst: SQL Server (MSSQLSERVER) | Konto: DOMAIN\svc-sql-db | AlwaysOn: AUS
[10:56:34] SQL-NODE-02 – Dienst: SQL Server (MSSQLSERVER) | Konto: DOMAIN\svc-sql-db | AlwaysOn: AUS
[10:56:34] Einlesen abgeschlossen.
[10:57:01] === Konfiguration startet – Primary: SQL-NODE-01 ===
[10:57:01] Cluster-Settings gesichert: C:\System\WinSrvLog\MSSQL\AlwaysOn_ClusterSettings_...
[10:57:01] Windows-Auth 'SQL-NODE-01': OK
[10:57:01] Windows-Auth 'SQL-NODE-02': fehlgeschlagen – SSPI context
[10:57:01] === Manuelle Aktion erforderlich: SQL-Login anlegen ===
[10:57:01] Bitte auf ALLEN Nodes folgendes T-SQL als sysadmin ausführen:
 
EXEC msdb.dbo.sp_syspolicy_update_policy
 
    @name = N'New Login_Enforce Passwort Policy', @is_enabled = 0;
 
CREATE LOGIN [AGSetup_a3f9c12b]
 
    WITH PASSWORD = 'Kx7#mNpQ2rYs...', CHECK_POLICY = OFF;
 
ALTER SERVER ROLE [sysadmin] ADD MEMBER [AGSetup_a3f9c12b]; 
[10:57:01] Login: AGSetup_a3f9c12b   Nach Ausführung: Klick auf 'Weiter'

Bitte SQL-Login anlegen und dann "Weiter" klicken.

PropertyGrid – Konfiguration

RTF-Log – Echtzeit-Ausgabe

Details: Kategorie: Tools

SQL Server AlwaysOn Setup Tool – Dokumentation

DBA-Team · Intern · Version 1.0.0 · April 2026

SQL Server AlwaysOn Setup Tool

Vollautomatische Konfiguration von Always On Availability Groups auf Windows Server Failover Clustern

SQL Server 2022 / 2025 Windows Server 2022 PowerShell 5.1+ FailoverClusters RSAT dbaTools >= 2.0

Das SQL Server AlwaysOn Setup Tool ist ein PowerShell-Script mit WinForms-Oberfläche, das alle Schritte zur Einrichtung einer Always On Availability Group (AG) auf einem bestehenden Windows Server Failover Cluster (WSFC) automatisiert. Es liest Cluster- und SQL-Informationen automatisch ein, präsentiert diese im PropertyGrid zur Überprüfung, und führt nach Bestätigung alle Konfigurationsschritte durch.

⚡ Empfehlung: SPNs vor dem Setup setzen

Wenn die Service Principal Names (SPNs) für das SQL-Dienstkonto im Active Directory vor dem Setup registriert sind, läuft das Tool vollautomatisch durch – ohne manuellen Eingriff. Fehlen SPNs, pausiert das Tool und erfordert einen zusätzlichen manuellen Schritt. Details in Abschnitt 4 – SPNs.

1. Übersicht und Konfigurationsschritte

Das Tool führt die folgenden neun Schritte in dieser Reihenfolge aus. Übersprungene Schritte werden im Log ausgewiesen.

Schritt	Bezeichnung	Beschreibung
1	SQL-Service-Konto	Optional: Konto und Passwort per WMI auf allen Nodes ändern und Dienst neu starten
2	HADR aktivieren	Always On per `sp_configure 'hadr enabled', 1` auf allen Nodes; Dienst-Neustart mit aktivem Bereitschaftstest
3	Endpoint erstellen	Datenbankspiegelungs-Endpoint (Port 5022) per T-SQL anlegen und starten
4	CONNECT-Berechtigung	Windows-Login anlegen, `GRANT CONNECT ON ENDPOINT` auf alle Nodes
5	Testdatenbank	Datenbank anlegen, Recovery-Modell FULL setzen, initiales Full-Backup erstellen
6	Availability Group	AG per reinem T-SQL (`sqlcmd`) anlegen, Replicas beitreten, Autoseed aktivieren
7	Listener	AG-Listener mit IP-Adresse und Port per `ALTER AVAILABILITY GROUP`
8	Status	AG-Synchronisierungsstatus und Replica-Rollen per DMV ausgeben
9	SPN-Prüfung	Fehlende MSSQLSvc-SPNs erkennen, setspn-Befehle als Textdatei für das AD-Team exportieren

2. Voraussetzungen

Infrastruktur

Windows Server 2022 oder neuer auf allen Cluster-Nodes
SQL Server 2022 oder neuer (Enterprise oder Standard Edition)
Bestehender Windows Server Failover Cluster (WSFC) mit 2 oder 3 Nodes
Gemeinsamer Backup-Share (UNC), beschreibbar von allen Nodes
Port 5022 zwischen allen Nodes geöffnet (HADR Endpoint)

Berechtigungen

Lokaler Administrator auf dem ausführenden Cluster-Node
SQL Server sysadmin-Rolle auf allen Nodes
Domänen-Leserecht (für SPN-Prüfung in Schritt 9)
PowerShell als Administrator (#Requires -RunAsAdministrator)

PowerShell-Module

Modul	Installation	Hinweis
`FailoverClusters`	`RSAT-Clustering-PowerShell`	Wird vom Script automatisch installiert
`dbaTools >= 2.0`	`Install-Module dbatools`	Wird automatisch installiert; bereits geladene Version wird nicht neu importiert

ℹ dbaTools-Nutzung bewusst minimiert

Das Tool verwendet aus dbaTools nur Invoke-DbaQuery (T-SQL-Ausführung mit Credential-Support) und Connect-DbaInstance (Verbindungstest). Alle anderen Operationen laufen über direktes T-SQL (sqlcmd), WMI (Win32_Service) oder FailoverClusters-Cmdlets – um Versionsabhängigkeiten und interne Seiteneffekte zu vermeiden.

3. Bedienung

Start

PowerShell ISE oder PowerShell 5.1+ als Administrator öffnen
Script SetupAlwaysOn.ps1 ausführen
Das Tool prüft Module, liest Cluster-Informationen automatisch ein
Erkannte Werte erscheinen im PropertyGrid (linke Seite der Oberfläche)

PropertyGrid – Konfigurationsfelder

Feld	Kategorie	Beschreibung
AG-Name	3 – AG	Name der Availability Group (= WSFC-Rollenname)
Listener-Name	3 – AG	DNS-Name des AG-Listeners
Listener-IP	3 – AG	IP-Adresse des Listeners (aus Cluster übernommen)
Listener-Port	3 – AG	TCP-Port des Listeners (Standard: 1433)
Endpoint-Port	3 – AG	HADR Endpoint Port (Standard: 5022)
Failover-Modus	3 – AG	`Automatic` = synchron mit auto. Failover; `Manual` = asynchron
Backup-Präferenz	3 – AG	`Primary` / `Secondary` / `PreferSecondary` / `None` (Standard: Primary)
Test-Datenbank	3 – AG	Name der in die AG aufzunehmenden Datenbank
Backup-Share	4 – Backup	UNC-Pfad für das initiale Full-Backup
Service-Konto	2 – Dienst	SQL-Dienstkonto (automatisch erkannt, optional änderbar)

Ablauf nach dem Start

1

Alle Felder im PropertyGrid prüfen und ggf. anpassen

2

Primary-Node in der Dropdown-Liste wählen

3

Schaltfläche Konfiguration starten klicken

4

Fortschritt im Log-Bereich (rechts) farbkodiert in Echtzeit verfolgen

5

Falls SPNs fehlen: Weiter-Button nach manuellem SQL-Login-Setup klicken (→ Abschnitt 4)

6

Am Ende: SPN-Anforderungsdatei an das AD-Team weiterleiten

4. Service Principal Names (SPNs)

Service Principal Names (SPNs) sind Einträge im Active Directory, die SQL Server ermöglichen, Kerberos-Authentifizierung zu verwenden. Fehlen die SPNs, erscheint der Fehler „Cannot generate SSPI context" und Windows-Auth schlägt fehl.

⚠ SPNs vor dem Setup setzen – dringend empfohlen

Wenn SPNs fehlen, pausiert das Tool und fordert den Anwender auf, ein temporäres SQL-Login manuell per SSMS lokal auf jedem betroffenen Node anzulegen. Dieser Schritt entfällt vollständig, wenn die SPNs bereits im Active Directory registriert sind.

Auswirkung fehlender SPNs

Situation	Auswirkung	Ablauf
SPNs gesetzt ✓	Windows-Auth (Kerberos) auf allen Nodes	Vollautomatischer Durchlauf, kein manueller Eingriff
SPNs fehlen ✗	SSPI-Fehler auf betroffenen Nodes	Tool pausiert → T-SQL-Block anzeigen → manuell ausführen → Weiter → Fortsetzung per SQL-Auth

Benötigte SPNs

Je Node und für den Listener-Namen sind zwei SPNs erforderlich (Kurzname und FQDN):

# Je SQL-Node – Kurzname und FQDN 
setspn -S MSSQLSvc/SQLNODE01:1433 DOMAIN\SQLServiceAccount 
setspn -S MSSQLSvc/SQLNODE01.domain.com:1433 DOMAIN\SQLServiceAccount 
 
setspn -S MSSQLSvc/SQLNODE02:1433 DOMAIN\SQLServiceAccount 
setspn -S MSSQLSvc/SQLNODE02.domain.com:1433 DOMAIN\SQLServiceAccount 
 
# AG-Listener 
setspn -S MSSQLSvc/AG-LISTENER:1433 DOMAIN\SQLServiceAccount 
setspn -S MSSQLSvc/AG-LISTENER.domain.com:1433 DOMAIN\SQLServiceAccount 
 
# Prüfung nach dem Setzen: 
setspn -L DOMAIN\SQLServiceAccount

Das Tool generiert in Schritt 9 automatisch die konkreten setspn-Befehle und speichert sie als Textdatei:
C:\System\WinSrvLog\MSSQL\AlwaysOn_SPN_ADTeam_<Datum>.txt

Ablauf wenn SPNs fehlen

1

Tool erkennt automatisch welche Nodes nicht per Kerberos erreichbar sind

2

T-SQL-Block zur manuellen Login-Anlage wird im Log angezeigt (fertig zum Kopieren)

3

Anwender führt das T-SQL per SSMS lokal auf jedem betroffenen Node aus (per RDP)

4

Klick auf Weiter – Tool prüft SQL-Auth-Verbindung auf allen Nodes

5

Temporäres Login wird am Ende automatisch entfernt, Policy reaktiviert

5. Ausgaben und Logdateien

Farbcodierung im Live-Log

Farbe	Bedeutung
Blau (fett)	Abschnittsüberschrift (`=== ... ===`)
Hellgrün (fett)	Erfolg – Aktion erfolgreich abgeschlossen
Gelb	Warnung – Aktion übersprungen oder Hinweis
Rot (fett)	Fehler – Aktion fehlgeschlagen
Hellgrau	Information – allgemeine Statusmeldung

Gespeicherte Dateien

Alle Dateien werden automatisch unter C:\System\WinSrvLog\MSSQL\ gespeichert.

Datei	Inhalt	Zeitpunkt
`AlwaysOn_ClusterSettings_<Datum>.txt`	Cluster-Konfiguration, AG-Parameter, Node-Status – Backup vor Änderungen	Vor Schritt 1
`AlwaysOn_Setup_<Datum>.log`	Vollständiges Text-Log aller Schritte mit Zeitstempeln	Nach Abschluss
`AlwaysOn_Setup_<Datum>.rtf`	Farbiges RTF-Log (über Schaltfläche im Tool speicherbar)	Manuell
`AlwaysOn_SPN_ADTeam_<Datum>.txt`	Fertige setspn-Befehle für das AD-Team mit Erklärung und Prüfbefehl	Schritt 9

6. Fehlerbehebung

Fehlermeldung	Ursache	Lösung
`Cannot generate SSPI context`	SPNs für den Node fehlen im Active Directory	Kurzfristig: manuellen SQL-Login-Schritt im Tool durchführen. Langfristig: SPNs durch AD-Team setzen lassen
`WSFC group … already exists`	Überrest eines fehlgeschlagenen Setup-Versuchs	Tool bereinigt automatisch: `Remove-ClusterGroup` + Registry-Key `HadrAgNameToldMap` auf allen Nodes
`Login failed for user AGSetup_…`	SQL Server nicht im Mixed Mode oder Password-Policy blockiert	Mixed Mode in SSMS prüfen: Server Properties → Security → SQL Server and Windows Authentication mode
`Backup-Verzeichnis nicht erreichbar`	UNC-Pfad ungültig oder keine Schreibrechte	Pfad im PropertyGrid korrigieren; muss von allen Nodes beschreibbar sein
`Endpoint-Port 5022 bereits belegt`	Bestehender Endpoint oder Firewall blockiert den Port	`SELECT * FROM sys.endpoints WHERE type=4` ausführen; Port im PropertyGrid anpassen
`AG nach 60s noch nicht sichtbar`	SQL Server nach HADR-Aktivierung noch nicht vollständig initialisiert	Tool wartet aktiv per `SELECT 1` (max. 2 Minuten). Bei Timeout Dienst manuell prüfen

7. Technische Details

Verbindungsstrategie

Einlesen: Windows-Auth per WMI für Dienst-Informationen; T-SQL für HADR-Status.
Konfiguration: Windows-Auth (Kerberos) auf allen Nodes testen. Bei SSPI-Fehler → temporäres SQL-Login mit kryptografisch zufälligem Passwort (28 Zeichen, RNGCryptoServiceProvider).
Cleanup: Temporäres Login nach Abschluss auf allen Nodes automatisch gelöscht, Policy reaktiviert.

AG-Anlage per sqlcmd

Für CREATE AVAILABILITY GROUP und alle AG-Join-Befehle wird sqlcmd direkt verwendet statt Invoke-DbaQuery. Grund: Nach dem Dienst-Neustart in Schritt 2 hält dbaTools intern gecachte Verbindungen, über die sys.availability_groups noch leer erscheint. sqlcmd öffnet bei jedem Aufruf eine frische TCP-Verbindung.

WSFC-Cleanup bei wiederholten Versuchen

Das Tool prüft vor der AG-Anlage ob eine verwaiste WSFC-Gruppe existiert und bereinigt automatisch:

Stop-ClusterGroup + Remove-ClusterGroup -RemoveResources -Force
Registry-Key HKLM:\Cluster\HadrAgNameToldMap auf allen Nodes per Invoke-Command bereinigen

Sicherheit

Temporäres SQL-Login: kryptografisch zufälliges Passwort, ausschließlich T-SQL-sichere Sonderzeichen
Passwort wird nie in Logdateien gespeichert – nur im RTF-Fenster der laufenden Sitzung sichtbar
Policy Enforce Password Policy wird nur für die Dauer der Login-Anlage deaktiviert
Login und Policy werden am Ende garantiert zurückgesetzt

AlwaysOn Setup Wiz

Disclaimer

Die hier bereitgestellten Skripte und Codebeispiele wurden mit größtmöglicher Sorgfalt geprüft und getestet. Dennoch übernehmen wir keinerlei Gewähr für die Richtigkeit, Vollständigkeit oder Fehlerfreiheit der Inhalte. Es kann nicht ausgeschlossen werden, dass die Skripte unbeabsichtigte Fehler enthalten oder unter bestimmten Umgebungsbedingungen nicht wie erwartet funktionieren.

Der Einsatz der Skripte erfolgt ausschließlich auf eigene Gefahr. Vor der Ausführung in einer Produktivumgebung wird dringend empfohlen, die Skripte in einer geeigneten Testumgebung gründlich zu validieren und an die individuellen Gegebenheiten anzupassen. Der Autor haftet nicht für direkte oder indirekte Schäden, die durch die Verwendung oder Nichtverwendbarkeit der bereitgestellten Informationen entstehen.

AlwaysOn Automation