Freigeben über


SQL Server Installation schlägt fehl, nachdem Standardbenutzerrechte entfernt wurden

Dieser Artikel hilft Ihnen, ein Problem zu beheben, das auftritt, wenn Sie Microsoft SQL Server installieren oder aktualisieren, nachdem Sie die Sicherheit verschärft haben.

Gilt für: SQL Server

Symptome

Betrachten Sie das Szenario, in dem Sie Microsoft SQL Server in Windows ausführen. Um die Sicherheit zu erhöhen, entfernen Sie einige Standardbenutzerrechte aus der lokalen Administratorgruppe. Um SQL Server auf dem System einzurichten, fügen Sie das Setupkonto der lokalen Administratorgruppe hinzu.

Wenn Sie in diesem Szenario versuchen, SQL Server zu installieren oder zu aktualisieren, schlägt der Installationsvorgang fehl, und Sie erhalten möglicherweise eine Fehlermeldung, die einer der folgenden Meldungen ähnelt:

  • Szenario 1: Wenn bei einer neu installierten Installation ein Fehler auftritt, wird die folgende Fehlermeldung angezeigt:

    Access is denied
    

    Möglicherweise erhalten Sie auch Fehlermeldungen, die in der Detail.txt-Datei wie folgt aussehen:

    2009-01-02 13:00:17 SQLEngine: --SqlServerServiceSCM: Waiting for nt event 'Global\sqlserverRecComplete$NIIT' to be created  
    2009-01-02 13:00:20 SQLEngine: --SqlServerServiceSCM: Waiting for nt event 'Global\sqlserverRecComplete$NIIT' or sql process handle to be signaled  
    2009-01-02 13:00:20 Slp: Configuration action failed for feature SQL_Engine_Core_Inst during timing ConfigRC and scenario ConfigRC.  
    2009-01-02 13:00:20 Slp: Access is denied  
    2009-01-02 13:00:20 Slp: Configuration action failed for feature SQL_Engine_Core_Inst during timing ConfigRC and scenario ConfigRC.  
    2009-01-02 13:00:20 Slp: System.ComponentModel.Win32Exception: Access is denied  
    2009-01-02 13:00:20 Slp:    at System.Diagnostics.ProcessManager.OpenProcess(Int32 processId, Int32 access, Boolean throwIfExited)  
    2009-01-02 13:00:20 Slp:    at System.Diagnostics.Process.GetProcessHandle(Int32 access, Boolean throwIfExited)  
    2009-01-02 13:00:20 Slp:    at System.Diagnostics.Process.OpenProcessHandle()  
    2009-01-02 13:00:20 Slp:    at System.Diagnostics.Process.get_Handle()  
    2009-01-02 13:00:20 Slp:    at Microsoft.SqlServer.Configuration.SqlEngine.SqlServerServiceBase.WaitSqlServerStart(Process processSql)  
    2009-01-02 13:00:20 Slp:    at Microsoft.SqlServer.Configuration.SqlEngine.SqlServerServiceSCM.StartSqlServer(String[] parameters)  
    2009-01-02 13:00:20 Slp:    at Microsoft.SqlServer.Configuration.SqlEngine.SqlServerStartup.StartSQLServerForInstall(String sqlCollation, String masterFullPath, Boolean isConfiguringTemplateDBs)  
    2009-01-02 13:00:20 Slp:    at Microsoft.SqlServer.Configuration.SqlEngine.SqlEngineDBStartConfig.ConfigSQLServerSystemDatabases(EffectiveProperties properties, Boolean isConfiguringTemplateDBs, Boolean useInstallInputs)  
    2009-01-02 13:00:20 Slp:    at Microsoft.SqlServer.Configuration.SqlEngine.SqlEngineDBStartConfig.DoCommonDBStartConfig(ConfigActionTiming timing)  
    2009-01-02 13:00:20 Slp:    at Microsoft.SqlServer.Configuration.SqlEngine.SqlEngineDBStartConfig.Install(ConfigActionTiming timing, Dictionary<string, string> actionData, PublicConfigurationBase spcb)  
    2009-01-02 13:00:20 Slp:    at Microsoft.SqlServer.Configuration.SqlConfigBase.PrivateConfigurationBase.Execute(ConfigActionScenario scenario, ConfigActionTiming timing, Dictionary<string, string> actionData, PublicConfigurationBase spcbCurrent)  
    2009-01-02 13:00:20 Slp:    at Microsoft.SqlServer.Configuration.SqlConfigBase.SqlFeatureConfigBase.Execute(ConfigActionScenario scenario, ConfigActionTiming timing, Dictionary<string, string> actionData, PublicConfigurationBase spcbCurrent)  
    2009-01-02 13:00:20 Slp:    at Microsoft.SqlServer.Configuration.SqlConfigBase.SlpConfigAction.ExecuteAction(String actionId)  
    2009-01-02 13:00:20 Slp:    at Microsoft.SqlServer.Configuration.SqlConfigBase.SlpConfigAction.Execute(String actionId, TextWriter errorStream)  
    2009-01-02 13:00:20 Slp: Exception: System.ComponentModel.Win32Exception.  
    2009-01-02 13:00:20 Slp: Source: System.  
    2009-01-02 13:00:20 Slp: Message: Access is denied.  
    
  • Szenario 2: Wenn bei einer Neuinstallation von Microsoft SQL Server 2012 oder Microsoft SQL Server 2008 R2 ein Fehler auftritt, wird eine der folgenden Fehlermeldungen angezeigt:

    Rule "Setup account privileges" failed.  
    
    The account that is running SQL Server Setup doesn't have one or all of the following rights: the right to back up files and directories, the right to manage auditing and the security log and the right to debug programs. To continue, use an account with both of these rights.
    
  • Szenario 3: Wenn die Installation von SQL Server 2012 oder einer höheren Version fehlschlägt, wenn Sie eine Netzwerkfreigabe (UNC-Pfad) für den Speicherort des Sicherungsverzeichnisses angeben, erhalten Sie die folgende Fehlermeldung:

    SQL Server setup account does not have the `SeSecurityPrivilege` on the specified file server in the path *\<UNC backup location>*. This privilege is required to set folder security in the SQL Server setup program. To grant this privilege, use the Local Security Policy console on this file server to add SQL Server setup account to **Manage auditing and security log** policy. This setting is available in the **User Rights Assignments** section under Local Policies in the Local Security Policy console.
    

    Hinweis

    Dieses Problem tritt auf, weil das SQL Server Setupkonto nicht über die SeSecurityPrivilege Berechtigungen auf dem Dateiserver verfügt, der die Netzwerkfreigabe hostet.

Ursache

Wenn Sie das Setup als lokaler Administrator ausführen, benötigen Sie die folgenden Benutzerrechte, damit setup erfolgreich ausgeführt werden kann:

Anzeigename des lokalen Gruppenrichtlinie-Objekts Benutzerrecht
Sicherungsdateien und Verzeichnisse SeBackupPrivilege
Debuggen von Programmen SeDebugPrivilege
Verwalten von Überwachungs- und Sicherheitsprotokollen SeSecurityPrivilege

Hinweis

Weitere Informationen zu den Berechtigungen, die zum Installieren von SQL Server erforderlich sind, finden Sie im Abschnitt "Voraussetzungen" in den folgenden Artikeln:

Wenn eine Speicheroption für Datenverzeichnis oder andere Verzeichnisse (Benutzerdatenbankverzeichnis, Benutzerdatenbankprotokollverzeichnis, TempDB-Verzeichnis, TempDB-Protokollverzeichnis oder Sicherungsverzeichnis) eine SMB-Dateifreigabe verwendet, benötigt das Setupkonto die folgenden zusätzlichen Berechtigungen auf dem SMB-Dateiserver, wie unter Installieren von SQL Server mit SMB-Dateifreigabespeicher beschrieben.

SMB-Netzwerkfreigabeordner VOLLZUGRIFF SQL-Setupkonto
SMB-Netzwerkfreigabeordner VOLLZUGRIFF SQL Server- und SQL Server-Agent-Dienstkonto
SMB-Dateiserver SeSecurityPrivilege SQL-Setupkonto

Lösung

Führen Sie die folgenden Schritte aus, um dem Setupkonto die Rechte hinzuzufügen:

  1. Melden Sie sich als Administrator an.
  2. Wählen Sie Ausführung starten> aus, geben Sie Control admintools ein, und klicken Sie dann auf OK.
  3. Doppelklicken Sie auf Lokale Sicherheitsrichtlinie.
  4. Wählen Sie im Dialogfeld Lokale Sicherheitseinstellungen die Option Lokale Richtlinien aus, öffnen Sie Zuweisung von Benutzerrechten, und doppelklicken Sie dann auf Sicherungsdateien und Verzeichnisse.
  5. Wählen Sie im Dialogfeld Eigenschaften von Sicherungsdateien und Verzeichnissen die Option Benutzer oder Gruppe hinzufügen aus.
  6. Geben Sie im Dialogfeld Benutzer oder Gruppen auswählen das Benutzerkonto ein, das Sie für das Setup verwenden möchten, und wählen Sie dann zweimal OK aus.

    Hinweis

    Führen Sie die Schritte 1 bis 6 aus, um das Benutzerkonto für die Richtlinien "Programme debuggen" und "Überwachung und Sicherheitsprotokoll verwalten" hinzuzufügen.

  7. Öffnen Sie im Menü Datei das Dialogfeld Lokale Sicherheitseinstellungen , und wählen Sie dann Beenden aus, um sie zu schließen.

Häufig gestellte Fragen (FAQs)

Warum ist SeSecurityPrivilege auf dem Dateiserver für das Sicherungsverzeichnis auf der UNC-Freigabe erforderlich?

Diese Berechtigung ist erforderlich, um Access Control Listen (ACLs) im Standardsicherungsverzeichnis abzurufen, um sicherzustellen, dass das SQL Server-Dienstkonto über vollständige Berechtigungen für den Ordner verfügt. Das Dienstkonto legt auch die ACLs fest, wenn Berechtigungen für das SQL-Dienstkonto fehlen, sodass eine Sicherung des Verzeichnisses ausgeführt werden kann. Das Setupprogramm führt diese Überprüfungen für das Standardsicherungsverzeichnis aus, sodass bei einer Sicherung nach der Installation kein Fehler auftritt (aufgrund fehlender Berechtigungen).

Hinweis

SeSecurityPrivilege ist erforderlich, um die get/set ACLs aus den Verzeichnissen und Unterordnern zu ändern. Dies gilt auch, wenn Benutzer, die über VOLLZUGRIFFsberechtigungen für die Verzeichnisse verfügen, keine Berechtigungen für get/set OWNER und Überwachungsinformationen aus dem Verzeichnis haben.

Warum tritt der in Szenario 3 beschriebene Fehler nur in Microsoft SQL Server 2012 und höheren Versionen auf?

Ab SQL Server 2012 bietet Microsoft Unterstützung für Daten- und Protokolldateien auf der SMB-Dateifreigabe. Im Rahmen dieser Verbesserung wird die Einrichtungserfahrung weiter verbessert, um die Sicherheitsüberprüfungen zu verschärfen, sodass Kunden nach der Installation keine Fehler oder Probleme aufgrund unzureichender Berechtigungen auftreten. In Versionen vor SQL Server 2012 können Benutzer weiterhin den Netzwerkfreigabepfad für das Sicherungsverzeichnis einrichten, wenn das SQL-Dienstkonto nicht über berechtigungen zum Ausführen einer Sicherung verfügt. In dieser Situation tritt bei diesen Benutzern jedoch nach der Installation ein Fehler auf. Diese Szenarien werden jetzt verhindert, wenn Sie die SQL 2012-Setupüberprüfung auf einer Netzwerkfreigabe starten.

Weitere Informationen

  • Verwenden Sie das ToolAccessChk.exe , um die Liste der Berechtigungen zu überprüfen, die derzeit dem Setupkonto zugeordnet sind. Informationen zum Herunterladen dieses Tools finden Sie unter AccessChk v6.13.

    Verwendung: accesschk.exe- a \<setup account> *

    Beispiel: c:\tools\accesschk.exe -a testdc\setupaccount *

      Sample output:
             SeSecurityPrivilege
              SeBackupPrivilege
              SeRestorePrivilege
              SeSystemtimePrivilege
              SeShutdownPrivilege
              SeRemoteShutdownPrivilege
              SeTakeOwnershipPrivilege
              SeDebugPrivilege
              SeSystemEnvironmentPrivilege
              SeSystemProfilePrivilege
              SeProfileSingleProcessPrivilege
              SeIncreaseBasePriorityPrivilege
              SeLoadDriverPrivilege
              SeCreatePagefilePrivilege
              SeIncreaseQuotaPrivilege
              SeChangeNotifyPrivilege
              SeUndockPrivilege
              SeManageVolumePrivilege
              SeImpersonatePrivilege
              SeCreateGlobalPrivilege
              SeTimeZonePrivilege
              SeCreateSymbolicLinkPrivilege
              SeInteractiveLogonRight
              SeNetworkLogonRight
              SeBatchLogonRight
              SeRemoteInteractiveLogonRight
    
  • Weitere Informationen finden Sie unter Konfigurieren von Windows-Dienstkonten und -Berechtigungen.