Seit der Version 2016 kann schon während der Installation des SQL-Servers das Recht „Perform Volume Maintenance Tasks“ vergeben werden, um die Funktionalität „Instant File Initialization“ zu aktivieren. Doch welches Konto erhält das Recht?
In einem Kundenprojekt haben wir das Thema etwas genauer unter die Lupe genommen und zeigen hier die Ergebnisse. Starten wir also von vorne …
In den meisten Fällen ist die Nutzung des lokalen virtuellen Dienstkontos „NT SERVICE\<Dienstname>“ (im Folgenden: Dienstkonto) die beste Option. Sollen jedoch Hochverfügbarkeitsfunktionen wie Always On eingesetzt werden, ist die Nutzung eines Active Directory Kontos (im Folgenden: AD-Konto) notwendig. Unsere Empfehlung: Nutzen Sie in diesen Fällen gruppenverwaltete Dienstkonten (englisch: Group-managed service accounts). Weitere Informationen finden Sie in der Dokumentation von Microsoft und unserem Blog-Artikel „Ich will das Kennwort gar nicht wissen – Nutzung von gruppenverwalteten Dienstkonten für Microsoft SQL Server“.
Bei der Nutzung des Dienstkontos stellt sich die Eingangsfrage nicht, in allen Fällen wird dieses Konto korrekt berechtigt.
Die Installation mit einem AD-Konto
Die Ausgangssituation beim Kunden sieht jedoch wie folgt aus. Der SQL-Server wurde in der Version 2022 mit einem gruppenverwalteten Dienstkonto installiert. Während der Installation wurde direkt die Erteilung des Rechts „Perform Volume Maintenance Tasks“ beauftragt.
Nach der erfolgreichen Installation meldete das SQL-Server-Protokoll, dass die Funktionalität „Instant File Initialization“ aktiviert ist. Somit sind wir davon ausgegangen, dass das verwendete AD-Konto das Recht „Perform Volume Maintenance Tasks“ erhalten hat. Eine Überprüfung ergab jedoch, dass das Recht stattdessen an das Dienstkonto vergeben wurde.
Das Konzept ist gut
Hieran wird das Konzept von Microsoft deutlich. Jeder Dienst hat immer ein zugehöriges Dienstkonto im System. Dieses Dienstkonto kann mit Rechten ausgestattet werden, die das durch den Dienst gestartete Programm erhalten soll. In unserem Fall hat der SQL-Server somit immer das Recht „Perform Volume Maintenance Tasks“. Damit kann das zum Start verwendete Konto geändert werden, ohne dass Änderungen an den Berechtigungen notwendig werden.
Die Ansicht im Configuration Manager
Aber was sehen wir jetzt in der von Microsoft bereitgestellten Oberfläche zur Verwaltung des Dienstes? Der Configuration Manager zeigt in unserem Fall ein deutliches „No“, angeblich hat der SQL-Server dieses Recht also gar nicht.
Warum? Weil der Configuration Manager wohl den Namen des zum Start verwendeten Kontos, also in unserem Fall des AD-Kontos, zur Überprüfung verwendet. Wenn wir hier nun durch Auswahl von „Yes“ eine „Korrektur“ vornehmen, dann wird das zum Start verwendete AD-Konto noch zusätzlich berechtigt. Das ist zwar nicht notwendig, aber zumindest sagt der Configuration Manager jetzt die Wahrheit.
Um der Sache weiter auf den Grund zu gehen, haben wir einen Blick in die Dokumentation geworfen und weitere Tools betrachtet, die wir ebenfalls beim Kunden einsetzen.
Was sagt die Dokumentation?
Die Dokumentation spricht vom „Startkonto des SQL Server-Dienstes“ bzw. „Konto […], über das der SQL Server-Dienst ausgeführt wird“. Wir lesen das so, dass hiermit das AD-Konto gemeint ist. Das entspricht zwar dem Verhalten des Configuration Managers, aber nicht dem Verhalten des Installationsprogramms „setup.exe“. Wir gehen aktuell davon aus, dass das Installationsprogramm das von Microsoft gewünschte Verhalten umsetzt. Damit müsste neben dem Configuration Manager auch die Dokumentation angepasst werden.
[Update 18.06.2024: Wir haben eine Änderung an der Dokumentation vorgeschlagen, die hier öffentlich einsehbar ist. Wir erhoffen uns hierdurch vor allem ein Feedback von Microsoft zu diesem Thema.]
[Update 26.07.2024: Die von uns vorgeschlagene Änderung an der Dokumentation wurde - zumindest in der englischen Version - inzwischen übernommen. Der Text lautet nun "add the SQL Server service account".]
dbatools
[Update 29.05.2024: Der folgende Teil wurde angepasst, da unsere Code-Änderungen inzwischen übernommen wurden.]
Mit der Version 2.1.16 wurde der Befehl Install-DbaInstance des PowerShell-Moduls dbatools angepasst. Der zur Konfiguration genutzte Parameter „PerformVolumeMaintenanceTasks" hat zum einen die beiden Aliase „InstantFileInitialization" und „IFI" bekommen. Zum anderen wird nun bei der Installation eines SQL Servers (ab der Version 2016) direkt der Parameter „SQLSVCINSTANTFILEINIT" der setup.exe genutzt – genau wie bei der interaktiven Installation.
Der Befehl Set-DbaPrivilege, der zum nachträglichen Setzen des Rechts „Perform Volume Maintenance Tasks" genutzt werden kann, arbeitet aktuell noch wie der Configuration Manager und berechtigt das Startkonto des Dienstes, in unserem Fall also das AD-Konto.
Wir werden in Kürze eine weitere Änderung des Codes vorschlagen, um das Verhalten von Set-DbaPrivilege anzupassen.
First Responder Kit
Die Prozedur „sp_Blitz“ aus dem First Responder Kit von Brent Ozar nutzt zur Überprüfung die Abfrage „select instant_file_initialization_enabled from sys.dm_server_services“. Damit wird der SQL-Server direkt befragt und liefert somit immer das korrekte Ergebnis.
Fazit
Prinzipiell hat jeder Dienst ein Dienstkonto, unabhängig davon, welches Konto zum Start des Dienstes verwendet wird. Auch wenn in vielen Fällen das Dienstkonto zum Start genutzt wird, gibt es gerade beim SQL Server ab und zu Gründe dafür, ein AD-Konto zu verwenden. Wird ein alternatives Konto genutzt, so funktioniert die „Instant File Initialization“ dennoch, da das Dienstkonto berechtigt wird. Eine generelle Erkenntnis sollte sein, dass man nicht jeder grafischen Oberfläche, in diesem Fall dem Configuration Manager, direkt vertrauen sollte. Ist Ihnen auch schon einmal eine Anzeige nicht ganz richtig vorgekommen?
Seminarempfehlung
ADMINISTRATION EINER MICROSOFT SQL SERVER INFRASTRUKTUR MS-SQL-02
Mehr erfahren