MS SQL Server 2014 Express auf einem Domänencontroller installieren

Gerade bei kleinen Umgebungen in denen es nur einen Server gibt oder z.B. ein SBS oder Essentials Server zum Einsatz kommt, die in der Regel Domänencontroller sind, hat man kaum eine andere Möglichkeit, als den SQL Server (Express) dort zu installieren.

Empfohlen wird dies (aus Sicherheitsgründen) nicht, wenn man allerdings keine andere Wahl hat, ist es dennoch möglich. Das Setup blockiert die Installation auf einem Domänencontroller nicht.

Bietet die Anwendung die den SQL Server benötigt die Möglichkeit, einen bestehenden SQL Server bzw. eine bestehende Instanz zu verwenden, so hat man gute Karten, diese Kombination zum Laufen zu bekommen.

Schwierig kann es hingegen sein, wenn der SQL Server (Express) von einem Anwendungssetup mitgebracht und automatisch installiert wird. Dann läuft man ggf. chancenlos in eine Fehlersituation hinein, ohne etwas ändern zu können.

Woran hängt es überhaupt?

Laut Recherche kann es dafür mehrere unterschiedliche Gründe geben. Im vorliegenden Szenario scheiterte die erfolgreiche Einrichtung am Dienstkonto. Per Standard soll vom Setup ein Benutzer in der Art „NT Service\MSSQL$<INSTANZNAME>“ eingerichtet werden. Auf einem Domänencontroller scheitert dies allerdings. Darüber hinaus kann der SQL Server Express nicht mit den Benutzerkonten „Lokaler Dienst“ oder „Netzwerkdienst“ ausgeführt werden.

Workaround

Als schnelle Lösung kann das „SYSTEM“-Konto verwendet werden, dies ist allerdings nicht zu empfehlen und sollte zumindest später geändert werden (s.u.). Dieses muss bei der Installation ausgewählt werden. Ein nachträgliches Ändern ist zwar über die Diensteverwaltung besser im SQL-Konfigurationsmanager umsetzbar, allerdings ist unter Umständen die zugrundeliegende Installation unvollständig oder dermaßen Defekt, das ein Start bzw. eine Reparatur nicht möglich sind. Dies kann man, wenn man so mag, dead-on-arrival nennen.

Ausgehend von einer Standard-Installation muss das Dienstkonto von „NT Service\MSSQL$MSQLEXPRESS“ zu „NT-AUTORITÄT\SYSTEM“ geändert werden:

Alternativ und besser ist es ein eigenes Dienstkonto für den SQL Server-Dienst manuell anzulegen und bei der Installation auszuwählen oder später zu ändern. Siehe dazu:

Windows: Group Managed Service Account für Dienste konfigurieren

MS SQL – Konfigurieren von Windows-Dienstkonten und -Berechtigungen

windowsserversecurity.com – Step-by-Step Guide to Configure Group Managed Service Accounts

Jeff’s Blog – Managed Service Accounts in Server 2012 R2

Welche Anwendungen betrifft es?

Dieser Beitrag entstand aufgrund des Umstands, das bei einem Kunden SFirm V4 eingeführt werden sollte. Beim gemeinsamen Termin mit einem Mitarbeiter der Sparkasse scheiterte die Installation aufgrund der zuvor genannten Dienstkonten-Gegebenheiten. Erst nach Recherche und Tests konnte die Lösung mit dem „SYSTEM“-Konto ermittelt und angewendet werden. Bei dem Server handelt es sich um einen Windows Server 2012 R2 Foundation.

Star Finanz, der Hersteller von SFirm, liefert jenseits der automatischen Installation des SQL Server Express die Möglichkeit, eine bestehende Instanz nutzen zu können. Dazu ist neben der SQL Server-Installation die Vorbereitung für die SFirm-Installation notwendig. Auf der Homepage finden sich dazu die notwendigen Schritte:

SFirm – Anleitungen und Info-Dokumente zu SFirm

Siehe dort „Installation von SFirm (inkl. MS SQL Server)“. Am einfachsten geht es mit  dem Assistenten (Kapitel 5, Seite 27), alternativ mit Batch/SQL-Skript oder per Management Studio.

Hinweis: Das SFirm-Setup installiert einige Abhängigkeiten. Diese erfordern einen Neustart. Zum Zeitpunkt als dieser Beitrag geschrieben wurde war es leider so, das selbst wenn bei der „Neustart“-Abfrage man „Nein“ angeklickt hat, der Server dennoch neustartet. Im laufenden Betrieb ist das gelinde ausgedrückt einigermaßen ungut. Darüber hinaus ist es wichtig, das der Server auf einem aktuellen Stand in Sachen Windows Updates ist, andernfalls kann es zu nicht näher definierten Fehlern bei der Installation kommen wie z.B. das der SFirm-Updatedienst nicht gestartet werden kann und in Folge das Setup abbricht.

Bemerkung: Damit ein manuell installierter SQL Server (Express) mit SFirm als auch weiteren Anwendungen und Netzwerkarbeitsplätzen funktioniert, sind ggf. zusätzliche Schritte notwendig. Stichsätze dazu sind:

  • Den Dienst „SQL Server-Browser“ starten.
  • Dynamische TCP-Ports deaktivieren.
  • Port „1433/tcp“ (SQL Server-Standardport) konfigurieren
  • Die Ports „1433/tcp“ (SQL Server) und 1434/udp“ (SQL Server-Browser) in der Windows-Firewall freigeben.

Der Lesart nach kann es ebenso kleine JTL-Installationen betreffen. Mit Sicherheit gibt es noch viele weitere Anwendungen.

Quellen:

BASICS.NET – SQL Server 2012 Express: How to install on a Windows 2012 R2 Domain Controller

Update 26.06.2018

Wegen ALF-BanCo musste nun auf einem Windows Server 2016 Standard ein MS SQL Server 2017 Express installiert werden. Der Server ist ebenfalls Domänencontroller. Soweit ich es aktuell beurteilen kann, gibt es dort dieses Problem wie hier beschrieben nicht. Womöglich wurde da etwas in den neueren Versionen geändert.

9 Kommentare

  • Lieber Andy,

    bitte verwende keine SYSTEM-Konten – insb. auf Domain Controllern. Das ist Sicherheitstechnisch schwer bedenklich. Besser ist ein Service Account oder noch besser ein Managed Service Account.
    Dann hast zumindest eine Chance beim Logging/Regelmentieren von Zugriffen.

    Viel Spaß noch
    Nik

  • Pingback: Windows: Group Managed Service Account für Dienste konfigurieren | Andys Blog – Linux & Windows

  • Hallo Nik,

    man Favorit ist das auch nicht, daher der Hinweis mit „auf die Schnelle“. Nach 2.5 Stunden rumgekasper mit Sparkassen- und indirekt Star Finanz-Mitarbeitern war das der Schnellschuss, damit es irgendwie weiter geht. Zu gMSA wurde ein eigener Beitrag verfasst und in diesem hier verlinkt.

  • Danke Andi für die Erweiterung 😉

  • Gerne, aber irgendwie habe ich noch Schwierigkeiten mit den gMSA (siehe anderer Beitrag). Nach einem Neustart funktionieren die Accounts nicht mehr. Hast du damit evtl. Erfahrung?

  • Mit MSA und gMSA schon. Zwar nicht auf DCs. Aber melde Dich doch auf mein eMail Adresse und wir stimmt uns dazu dann einfach ab.

  • Joachim Wittkowski

    Vielen Dank für diesen aufschlussreichen Artikel.

    Den hätte ich mal früher lesen sollen.

    Lange Zeit habe ich den S-Firm Hinweis auf die neuen Version ignoriert. Nun endlich sollte es passieren…. Also zunächst S-firm V4.0 auf dem Server installieren. Und da war dann erstmal Schluss:
    „Server 2008 ist veraltet. Hier sollte man keinen SQL-Server mehr installieren. Keine Update usw.“

    Ok… dachte ich mir, wir wollte ohnehin schon lange den alten Server 2008 sowie den Server 2003, der seit fast zwanzig Jahren als Domaincontroler dient, gegen einen Server 2019 ersetzen. Gesagt, getan. lediglich drei Tage herumgebastelt, konfiguriert, Daten kopiert, jede Installationsfalle mindestens einmal besucht, und schon lief alles bestens.
    Jetzt konnte endlich Sfirm aktuallisiert werden.

    Meldung: „Dieser Server ist ein Domaincontroler. Hier spielt sich mit SQL-Server mal garnix ab.“ (oder so ähnlich)
    Meine Begeisterung hielt sich verständlicherweise in Grenzen.

    Da kam mir dann der alte Werbespot der Sparkasse wieder in den Sinn: „Wir machen das jetzt mit den Fähnchen.“

    Der Server 2003 steht jetzt in unserer Asservatenkammer für Computerschrott. Der alte Server 2008 hängt in der neuen Domäne und dient jetzt Datenhalter für S-Firm auf einem Datenbanksystem, dass ich als Software-Entwickler niemals freiwillig installiert hätte. Welch ein Luxus.

    Gelungene innovative Neuerung von Star Finance. Meine Hochachtung.

  • Hallo Andy,

    was spricht eigentlich dagegen, statt einem echten Dienstkonto ein normales Benutzerkonto für den SQL-Dienst zu verwenden, und dem Konto die notwendigen Rechte zuzuweisen. Nachdem wir auch mit Deinen Tipps die Verwendung von Dienstkonten getestet haben und dort ständig die in den Kommentaren geschilderten Probleme hatten, wurde diese Ansatz wieder verworfen.
    Wir installieren nun den SQL-Express immer erst mal mit dem SYSTEM-Konto als temporären Workaround. Anschließend wird ein normales AD-Benutzerkonto erstellt, das mit den erforderlichen Berechtigungen für die SQL-Datenverzeichnisse versehen wird. Dieses Konto wird dann per Dienstmanager dem SQL-Dienst zugeordnet. Das funktioniert bisher ohne Probleme.
    Gruß, Frank

  • Hallo Frank,

    das mit dem SYSTEM-Konto ist eben nur ein Workaround, laut MS soll man überhaupt keinen SQL-Server auf einem DC installieren.
    Das Ganze wird nicht supported und auch die Software-Hersteller stellen sich mittlerweile quer.
    Bei allen anstehenden Migrationen und Neuinstallationen wo MS SQL im Spiel ist, werden wir das so auch nicht mehr machen bzw. so auch nicht mehr weiterführen.
    Seinerzeit war das halt ein Notnagel und wenn man so möchte eine Verzweiflungstat.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.