In diesem Artikel werden die Schritte beschrieben, die ich vor und während des Umzugs eines SQL Servers in eine neue Domäne durchgeführt habe. Bei anderen Server sind sicherlich Abweichungen zu beachten.

Vorraussetzungen

Die neue Domäne existiert bereits und die Benutzerkonten wurden dort bereits angelegt. Alle Benutzer aus der alten Domäne sind bereits in der neuen Domäne vorhanden und sollen mit den gleichen Rechten weiterarbeiten können. Der Wechsel soll störungsfrei und möglichst ohne Aufwand für die Anwender erfolgen.

Auf dem Windows-Server wurde ein lokales Konto als lokaler Administrator berechtigt, um einige Schritte zu erleichtern. Es ist auch eine gute Idee ein SQL-Login als Sysadmin in der Hinterhand zu haben!

Was ist zu beachten?

Die Dienste müssen umgestellt werden, falls sie unter Domänen-Konten laufen. Weiterhin sind alle Berechtigungen vorher zu ermitteln und möglichst per Skript für die neuen Benutzer zu vergeben. Der Besitz von Objekten muss auf die neuen Konten übertragen werden, bevor die alten Konten vom Server gelöscht werden. Die Anbindung an den Mailserver ist zu ändern.

Service-Accounts

Dienste ändern

Über den SQL Server Configuration Manager werden die Konten für die Dienste umgesetzt. Vorher merkt man sich welche Konten für die Dienste verwendet wurden. Es soll für den Umzug Local System verwendet werden.
Danach wird der SQL Server einmal neu gestartet und überprüft, ob alle Services laufen. Jetzt werden alle Dienste beendet und deaktiviert.

Domänenzugehörigkeit ändern

Jetzt wird die Maschine in die neue Domäne verschoben. Hierzu meldet man sich am besten mit einem lokalen Administrator an und wählt folgendes aus: Computer - Properties - Computername - Change - SQL_Workgroup
Danach wird die Maschine neu gestartet. Man meldet sich wieder mit dem lokalen Administrator an und ändert wie oben bereits beschrieben die Zugehörigkeit auf die neue Domäne. Hierzu benötigt man einen Domänen-Admin der neuen Domäne.

SQL Server wieder starten

Nun werden die Dienste wieder aktiviert und gestartet. Falls alles funktioniert werden wieder über den SQL Server Configuration Manager die Dienstkonten auf die neuen Domänen-Konten geändert, wo dies gewünscht ist. Achtung: Nicht gleichzeitig die Startoption auf Automatisch setzen und das Konto ändern. Man beachte die Reihenfolge: Zuerst die Startoption setzen und mit "Apply" bestätigen. Der Dienst wird neu gestartet. Danach das Konto ändern.

Den Service-Principal-Name (SPN) registrieren

Damit auf dem Server zukünftig via Kerberos zugegriffen werden kann, muss ein Domänen-Administrator den Service-Principal-Name erfassen. Eine andere Lösung wäre, dem Dienstkonto des SQL Servers dieses Recht einzuräumen. Dann würde er dies beim Serverstart durchführen. Details dazu findet man hier. Für SQL Server und Reporting Services sind folgende Einträge notwendig:

setspn -A MSSQLSvc/<servername>.<domain>.de:1433 <sql server service account>
setspn -A MSSQLSvc/<servername>:1433 <sql server service account>
setspn -A HTTP/<servername>.<domain>.de:80 <sql server service account>
setspn -A HTTP/<servername>:80 <sql server service account>

SQL Server wieder starten und Mail konfigurieren

Zum Abschluss werden die Dienste des SQL Servers neu gestartet und über

EXECUTE msdb.dbo.sysmail_update_account_sp

können die Einstellungen für Datenbank-Mail geändert werden.

SQL Server Database Engine

Ich bereite die Umstellung per Skript vor, so dass zwischen Vorbereitung und Durchführung ein paar Tage liegen. Um letzte Änderungen zumindest noch zu protokollieren, sollte man sich kurz vor der Umstellung zuerst die aktuellen Berechtigungen in einer Tabelle abspeichern. Hierzu dient das erste Skript "Berechtigungen merken".

Als nächstes erstelle ich mir ein Skript mit allen Berechtigungen für Windows-Logins, da nur diese von einem Domänen-Umzug betroffen sind. Dieses Skript kann man über den Objekt-Explorer über Tasks-Skript generieren erstellen. Man wählt eine Datenbanken aus und setzt später das Häkchen für "Benutzer".
Deutlich eleganter geht es mit Tools von Drittanbietern, wie z. B. "Apex SQL Script". Dort kann man sich auf eine Weise das Skript für einen ganzen Server erstellen lassen.

Anschließend ersetze ich im Skript die alten Logins durch die neuen Logins. Hierzu habe ich ein paar SQLs in dem ersten Skript angefügt, die mir die detaillierteren Infos liefern, die besondere Beachtung verdienen.

Zu jedem Login ist außerdem die Zugehörigkeit zu den Serverrollen zu ermitteln und mit sp_addsrvrolemember zu vergeben. Im Skript "Windows Logins" habe ich die notwendigen Schritte hinterlegt um folgendes zu ändern:

• Datenbank-Owner
• Job-Owner
• Beispiel für Credentials

User ändern

Bevor die neuen User für die neuen Windows-Logins mit den gleichen Namen angelegt werden können, wie die alten User (nicht immer heißen die User gleich mit den Logins), müssen die alten User zuerst gedropped werden. Im nächsten Schritt setzen wir die Rechte für die eben angelegten Windows-Logins in den einzelnen Datenbanken.

Update 2017

Ab dem SQL Server 2008 ist es möglich den Namen eines Users in der Datenbank zu ändern und dessen Zugehörigkeit zu einem Login. Daher geht es nun viel einfacher mit ALTER USER anstelle von einer Neuanlage der User.

Integration Services

Im nächsten Schritt ändern wir den Besitz der im Server abelegten SSIS-Pakete. Hierbei ist zwischen SQL Server 2005 und den Nachfolgeversionen zu unterscheiden. Das erste SQL zeigt die Pakete mit Eigentümer an, das zweite liefert uns das Update-Statement. Falls SQL Server 2008 oder höher verwendet wird, so heißt die Tabelle msdb.dbo.sysssispackages!

select l.name as Loginname, p.*
from msdb.dbo.sysdtspackages90 p
inner join master..syslogins l
on p.ownersid = l.sid
where l.name like '<old domain>%';


Select 'UPDATE msdb.dbo.sysdtspackages90
SET [ownersid] = SUSER_SID(''' + l.name + ''')
WHERE [name] = '''+ p.name +''';'
from msdb.dbo.sysdtspackages90 p
inner join master..syslogins l
on p.ownersid = l.sid
where l.name like '<old domain>%';

Damit haben wir auch bereits die Wartungspläne erledigt, die nun nur noch inhaltlich geprüft werden müssen. Dies gilt übrigens für alle Pakete: Es muss sichergestellt werden, dass alle dort verwendeten Pfade nach dem Umzug noch erreichbar sind.

Logins droppen

Nachdem die alten Logins nicht mehr benötigt werden, können diese jetzt gedropped werden. Am Ende kann man noch einmal prüfen, ob alle Windows-Logins funktionieren. Hierzu gibt es die Prozedur:

Exec sp_validatelogins

SQL Server Reporting Services

Zur Überprüfung der Reporting Services, kann man das Report-Server Configuration Tool aufrufen. Hierüber kann man den Service-Account setzen, falls noch nicht geschehen. Weiterhin könnte man die Datenbank-Verbindung ändern falls notwendig. Unabhängig davon hat man sich ja bereits zu einem früheren Zeitpunkt den Encryption-Key gesichert, mit dem alle verschlüsselten Verbindungs-Informationen im Reporting Service verarbeitet werden können. Diese Datei hat man bereits auf einem anderen Server hinterlegt und auch schon eine Sicherung auf Band angefertigt. Im Fehlerfall kann nach dem Restore der Reportserver-Datenbank und dem Restore des Encryption-Keys wieder auf die Informationen zugegriffen werden.
Damit der Report-Server auch Mailings verschicken kann, sind hier die EMail-Settings neu zu setzen.

Dieser Teil verdient insgesamt auch noch besondere Beachtung! Ich stelle kommentarlos die Schritte dar, die bei mir notwendig waren.
Bei der Änderung des Dienstkontos auf Local System (vor dem Umzug) wird man aufgefordert den "Encryption Key" zu sichern. Dieser muss zuerst wieder restored werden, bevor das Dienstkonto erneut geändert werden kann.
Bei der Änderung auf das neue Domänen-Konto kommt wieder diese Aufforderung. Am Ende hat man also drei Schlüsseldateien, da man sich seine alten Dateien auf keinen Fall überschreibt. Ich habe als letzten Schritt die ursprüngliche Datei wieder zurückgesichert.

Abonnements ändern

Lediglich der Besitz der Abonnements läßt sich per Skript übertragen. Hierzu findet sich im Anhang eine entsprechende Vorlage. Aus der User-Verwaltung (dbo.Users) im ReportServer werden die IDs der alten und neuen User ermittelt und in der Tabelle, welche die Abonnements enthält (dbo.Subscriptions) ausgetauscht. Falls man mal die Jobs für Abonnements gelöscht hat, oder die Report-Server-Datenbank auf einen anderen Server kopiert, braucht man lediglich einen Neustart der Reporting-Services durchzuführen. Beim Neustart werden die fehlenden Jobs generiert.

Berechtigungen in den Reporting Services

Nun kommt der eigentliche unangenehme Teil der Umstellung, da mir hier noch keine skriptbasierte Lösung begegnet ist. Man muss sich vorher die Berechtigungen ermitteln, was zum Glück per Skript geht, und diese danach über den Report-Manager neu vergeben.

Hierzu gibt es einen blog-Eintrag von Sankar Reddy mit dem Titel "Inside look at Reporting Services Meta-Data". Im Anhang sind einige SQLs aufgelistet, die ich verwendet habe, um die Berechtigungen zu ermitteln. Vor dem Umzug in die neue Domäne setzt man am besten schon mal in den Siteeinstellungen die Berechtigungen so, dass die BUILTIN\Administrators als "System Administrator" berechtigt sind.

Im einzelnen sind folgende Schritte notwendig:

• In den Siteeinstellungen die Berechtigungen ändern
• Berechtigungen auf Verzeichnisebene vergeben
• Zusätzliche Berechtigungen auf Objektebene vergeben, welche für das Verzeichnis nicht existieren
• Berechtigungen auf Objektebene entfernen, die aber auf Verzeichnisebene vergeben sind

SQL Server Analysis Services

Serveradministratoren

Bei den Eigenschaften des Analysis Server im Objekt-Explorer findet man die serverweiten Berechtigungen. Man kann diese über ein XMLA-Skript setzen. Ein Beispiel findet sich im Anhang, wobei man sich über den Objekt-Explorer das ALTER-Skript für die aktuelle Definition als Ausgangspunkt skripten kann. Dazu ist aber ein kleiner Trick notwendig: Man nimmt über die GUI ein neues Konto in die Gruppe der Serveradministratoren auf und läßt sich das Skript für die Aktion in eine 'Neue Abfrage' schreiben. Dann beendet man die GUI mit "Abbrechen" und entfernt aus dem eben generierten Skript das überflüssige Konto.

Cube-Rollen

Diese Berechtigungen finden sich in jedem Cube unter Rollen wieder. Auch diese können per XMLA-Skript gesetzt werden, wobei man sich über den Objekt-Explorer das ALTER-Skript für die aktuelle Rolle als Ausgangspunkt skripten kann. Über eine Textverarbeitung werden dann die Bezeichnungen der Domäne (alt gegen neu) getauscht. Die Angaben der SIDs werden aus dem Skript entfernt.

  A00 Berechtigungen anzeigen
  A01 Berechtigungen merken
  A01a User Mapping ändern
  A02 Windows Logins
  A05 User Permissions
  A06 Package Owner
  A07 Logins droppen
  X01 Reportserver untersuchen
  X02 Reportserver Subscriptions
  Cube Role0.xmla