SQL Server Installation Errors? User Rights Removal May Be the Cause

Table of Contents

Installing or upgrading Microsoft SQL Server is a critical process that requires specific system configurations and permissions to execute successfully. When system security is tightened by removing default user rights, particularly from administrative groups, the SQL Server setup process may encounter access issues, leading to installation failures. This article delves into the common symptoms, underlying causes, and resolutions for such problems, emphasizing the importance of required user rights for a seamless SQL Server setup.

Applies to: SQL Server

Symptoms of Installation Failure¶

When attempting to install or upgrade SQL Server after modifying default user rights, you might encounter various error messages indicating permission issues. These errors often prevent the setup from completing essential configuration steps, such as starting the SQL Server service or accessing necessary directories. Understanding the specific error message can help pinpoint the root cause of the failure.

Consider a scenario where you are running Microsoft SQL Server on a Windows operating system. In an effort to enhance security, some default user rights have been removed from the local administrators group. To proceed with the SQL Server installation or upgrade, the setup account is added to the local administrators group. However, despite the account being a member of this group, the installation process fails.

Here are some specific scenarios and the associated error messages you might encounter:

Scenario 1: General “Access is Denied” During New Installation¶

A common symptom during a new installation that fails is a generic “Access is denied” error message. This indicates that the setup process lacks the necessary permissions to perform a required operation. While the top-level error might be broad, the setup log files, specifically the Detail.txt file, provide more granular information about the exact point of failure and the underlying Windows API call that was denied access.

The Detail.txt log file may contain entries similar to this, showing a failure during the configuration action for the SQL Engine Core instance:

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.

This log snippet clearly shows a System.ComponentModel.Win32Exception with the message “Access is denied” occurring during the configuration phase. The call stack points to attempts to manage or start the SQL Server service, indicating a lack of necessary privileges for the setup account to interact with system processes or services at a low level.

Scenario 2: Setup Account Privileges Rule Failure¶

In later versions like Microsoft SQL Server 2012 or SQL Server 2008 R2, the setup process includes explicit rules to check for required user privileges before proceeding. If the account running the setup lacks specific user rights, one of these validation rules will fail, and the setup will halt, providing a more descriptive error message than a simple “Access denied.”

You might see an error message like this:

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.

This message is highly informative as it explicitly lists the missing user rights: “the right to back up files and directories,” “the right to manage auditing and the security log,” and “the right to debug programs.” This rule failure is a direct consequence of removing these specific privileges from the account used for installation, even if it’s a local administrator. The SQL Server setup requires these rights to perform critical tasks like configuring service accounts, managing system processes, and setting up file permissions securely.

Scenario 3: UNC Path Backup Directory Permissions Failure¶

When installing SQL Server 2012 or a later version and specifying a network share (UNC path) for the backup directory location, the setup performs specific checks on the remote file server hosting the share. If the SQL Server setup account does not possess a particular privilege on that file server, the installation might fail with an error related to security settings on the UNC path.

The error message in this scenario clearly points to a missing privilege on the file server:

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.

This specific error highlights the need for the SeSecurityPrivilege, associated with the “Manage auditing and security log” policy, on the file server hosting the UNC share used for backups. The setup needs this privilege to verify and potentially set appropriate file system permissions (ACLs) on the backup directory for the SQL Server service account, ensuring backups can be performed successfully after installation.

Cause: Insufficient User Rights¶

The primary cause for these installation failures when security is tightened is the removal of essential user rights required by the SQL Server setup process. While membership in the local administrators group typically grants broad privileges, specific user rights can be explicitly revoked or never granted by default in highly secured environments or custom security templates.

When running the SQL Server setup as a local administrator, the account must possess several specific user rights to successfully configure and start the SQL Server services and components. These rights enable the setup process to interact with the operating system at a low level, manage services, handle security logs, and access system resources.

The critical user rights required for the SQL Server setup account include:

Local Group Policy Object Display Name	User Right Identifier	Description
Backup files and directories	SeBackupPrivilege	Allows the user to back up files and directories. This right is needed to read files regardless of their access control lists (ACLs).
Debug Programs	SeDebugPrivilege	Allows the user to debug programs, which includes the ability to open processes and threads belonging to other users. Essential for interacting with system processes like starting services.
Manage auditing and security log	SeSecurityPrivilege	Allows the user to manage the security and audit logs and to specify auditing options for resources. Needed to set file system ACLs and manage audit policies.

If any of these user rights are missing from the account performing the SQL Server installation, the setup will fail during the configuration phase, as observed in the symptoms.

Furthermore, if you are configuring SQL Server to use an SMB file share for data directories (user database, user database log, TempDB, TempDB log) or the backup directory, additional permissions are required on the SMB file server. The setup process needs to verify and set appropriate permissions on these remote locations.

SMB Network Share Folder / File Server	Required Permission	Account	Purpose
SMB Network share folder	FULL CONTROL	SQL Setup account	To verify and potentially set permissions during setup.
SMB Network share folder	FULL CONTROL	SQL Server and SQL Server Agent Service account	Required for the SQL services to access data and log files during operation.
SMB File server	SeSecurityPrivilege	SQL setup account	Required on the file server to manage auditing and security log, specifically to set ACLs on the share directory.

The SeSecurityPrivilege on the file server hosting the SMB share is particularly crucial for the setup to successfully configure the permissions on the share so that the SQL Server service account can access it with FULL CONTROL. Without this privilege, the setup cannot guarantee the necessary permissions for the SQL service account, leading to the failure described in Scenario 3.

The principle behind these requirements is that the SQL Server setup needs elevated privileges not just to copy files, but to configure system-level settings, interact with services, and manage security permissions for the installed components and the service accounts they will run under. Removing these specific rights, even from an administrator account, directly impacts the setup’s ability to perform these critical configuration tasks.

Resolution: Restoring Required User Rights¶

To resolve SQL Server installation or upgrade failures caused by insufficient user rights, you must grant the necessary privileges to the account used for setup on the server where SQL Server is being installed. If an SMB share is used for data or backup directories, the setup account also needs the SeSecurityPrivilege on the file server hosting the share.

Here are the steps to add the required user rights using the Local Security Policy console on the respective server(s):

1. Log on to the server using an account that has administrative privileges sufficient to modify security policies (e.g., a Domain Administrator or a local Administrator if policy is not centrally managed).
2. Open the Local Security Policy console. You can do this by selecting Start, then Run, typing secpol.msc (or Control admintools and then double-clicking Local Security Policy), and selecting OK.
3. In the left pane of the Local Security Settings dialog box, expand Local Policies, and then select User Rights Assignment.
4. In the right pane, locate the policy named Backup files and directories. Double-click it to open its properties.
5. In the Backup files and directories Properties dialog box, select Add User or Group….
6. In the Select User or Groups dialog box, enter the name of the user account or group that you are using for the SQL Server setup. Use the “Check Names” button to verify the account name, then select OK two times to close the dialogs and apply the change for this policy.
7. Repeat steps 4 through 6 for the following policies, adding the same SQL Server setup account to each:
   • Debug Programs
   • Manage auditing and security log

Important Note: If you are using an SMB file share for data or backup directories and encountered the error described in Scenario 3, you must also perform these steps on the file server hosting the SMB share. On that file server, you specifically need to add the SQL Server setup account to the Manage auditing and security log policy (SeSecurityPrivilege).

8. After making these changes, you might need to log off and log back on with the setup account, or potentially restart the server, for the new user rights assignment to take full effect. However, often, simply opening a new command prompt or process under the modified account is sufficient.
9. Once the necessary user rights have been granted to the SQL Server setup account on the correct server(s), attempt to run the SQL Server installation or upgrade again. The setup process should now have the required permissions to complete successfully.

Modifying security policies, especially user rights assignments, should always be done with caution and awareness of the security implications. Granting excessive privileges is not recommended. The approach here is to grant the minimum required privileges specifically for the duration of the setup process to the account performing the installation. After the installation is complete, you may review and potentially revoke some of these temporarily granted rights from the setup account, although typically, accounts used for administrative tasks retain these rights.

Consider implementing a dedicated service account with precisely defined permissions for running SQL Server services post-installation, following the principle of least privilege. The permissions discussed in this article are primarily required for the setup account during installation, not necessarily for the SQL Server service account during normal operation, although there can be overlap in some requirements (like access to file shares).

Understanding the Flow of Permissions Check During Setup¶

To better visualize why these permissions are needed and where the setup fails without them, consider a simplified flow of the SQL Server setup process involving permission checks.

mermaid graph TD A[Start SQL Server Setup] --> B{Is setup account admin?}; B -- Yes --> C[Check Required User Rights]; C -- SeBackupPrivilege missing --> D[Fail: Setup Account Privileges]; C -- SeDebugPrivilege missing --> D; C -- SeSecurityPrivilege missing --> D; C -- All required rights present --> E{Using SMB share for data/backup?}; E -- Yes --> F{Check permissions on SMB server/share}; F -- SeSecurityPrivilege missing on File Server --> G[Fail: SMB Share Permissions]; F -- FULL CONTROL missing on Share --> G; F -- Permissions OK --> H[Proceed with Installation]; E -- No --> H; B -- No --> I[Fail: Account not Administrator]; H --> J[Configuration Phase]; J -- Permission denied during service start/config --> D; J -- Configuration Successful --> K[Installation Complete]; D --> L[Installation Failed]; G --> L; I --> L;
This diagram illustrates that the setup first checks for basic administrative rights (though full admin membership alone is not sufficient). It then performs specific checks for the required user rights (SeBackupPrivilege, SeDebugPrivilege, SeSecurityPrivilege) on the local server. If an SMB share is involved, further checks are performed on the remote file server and the share itself, specifically verifying SeSecurityPrivilege for the setup account on the server and FULL CONTROL for both setup and service accounts on the share. Failure at any of these checkpoints (C, F, J) leads to the installation failing (D, G, L).

Frequently Asked Questions (FAQs)¶

Let’s delve deeper into some common questions related to these permission issues during SQL Server setup.

Why is SeSecurityPrivilege required on the file server for the backup directory on the UNC share?¶

The SeSecurityPrivilege, which is assigned through the “Manage auditing and security log” user right, grants an account the ability to manage security and audit logs for resources and to specify auditing options. Crucially, it also allows the user to view and modify the System Access Control List (SACL) and Discretionary Access Control List (DACL) of objects, including files and folders, even if they don’t have explicit read/write permissions on the object itself.

When you specify a UNC path on an SMB file share for the backup directory during SQL Server setup, the setup program needs to ensure that the SQL Server service account (the account that will actually run the database engine services after installation) has sufficient permissions to read and write to this directory. Specifically, the service account needs “FULL CONTROL” permissions on that share folder to perform backups successfully.

The SQL Server setup uses the SeSecurityPrivilege on the file server hosting the share to:
1. Retrieve Access Control Lists (ACLs): The setup needs to read the existing permissions (ACLs) on the specified backup directory on the remote file server.
2. Set ACLs (if necessary): If the setup determines that the SQL Server service account does not have the required FULL CONTROL permissions, it attempts to set or modify the ACLs on the directory to grant those permissions.

This privilege is required for the setup account to interact with the security descriptors of objects on the remote file server to perform these checks and modifications. Without it, the setup cannot reliably determine or ensure the necessary permissions for the service account on the backup directory, leading to the installation failure. This proactive check prevents potential backup failures that would occur post-installation if the service account lacked permissions.

Why does the error described in Scenario 3 occur only in Microsoft SQL Server 2012 and later versions?¶

Prior to SQL Server 2012, the support for placing database files (data and log files) directly on SMB file shares was not a supported or common configuration. While using a UNC path for the backup directory was possible in earlier versions, the setup process’s validation checks were less stringent regarding permissions on remote shares used for backup locations.

Starting with SQL Server 2012, Microsoft introduced formal support for using SMB file shares for database data and log files, in addition to backup directories. This enhancement necessitated more robust validation during setup to ensure the reliability and security of data stored on remote shares. As part of this improvement, the setup checks were enhanced to proactively verify that the SQL Server setup account has the necessary permissions (SeSecurityPrivilege) on the file server hosting the share to manage the security settings of the share directories. It also checks that the SQL Server service account will have FULL CONTROL.

In pre-SQL Server 2012 versions, the setup might have allowed you to specify a UNC backup path even if the setup account or the future service account lacked the necessary remote permissions. This could result in a seemingly successful installation, but users would then encounter errors later when attempting to perform a backup to that location because the service account couldn’t access it. By introducing stricter checks in SQL Server 2012 and later, the setup program prevents such misconfigurations upfront, leading to the failure described in Scenario 3 if the SeSecurityPrivilege is missing on the file server. This change was made to improve the overall setup experience and prevent post-installation issues related to remote storage permissions.

More Information and Best Practices¶

Beyond the specific user rights discussed, ensuring a successful SQL Server installation involves several other considerations, especially in secure environments:

• User Account Control (UAC): On modern Windows systems with UAC enabled, even members of the Administrators group run with filtered tokens that do not include all privileges by default. Running the SQL Server setup executable with “Run as administrator” explicitly elevates the process with the full administrative token, which is necessary to access all assigned user rights and perform system-level configurations. Always run the setup this way.
• Group Policy Objects (GPOs): User rights assignments can be configured and enforced through Domain Group Policies. If your server is part of a domain, check if any GPOs are overriding the local security policy settings. GPO settings typically take precedence over local settings. You may need to work with your domain administrators to temporarily exclude the server or the setup account from policies that restrict the necessary user rights, or apply a GPO that grants them.
• Antivirus and Security Software: Aggressive antivirus or endpoint security software can sometimes interfere with the setup process, particularly actions involving file system or registry modifications, or attempts to start services. Temporarily disabling such software during installation in a controlled environment might be necessary for troubleshooting, though this should only be done with caution and according to organizational security policies.
• System Prerequisites: Ensure all other prerequisites for the specific SQL Server version you are installing are met, including .NET Framework versions, Windows Installer, and specific Windows updates. The SQL Server Setup program includes a “Rule Check” step that verifies many of these prerequisites.
• Clean Installation Environment: Ensure the server meets the minimum hardware requirements and is free from previous failed installation attempts or conflicting software that might leave remnants in the registry or file system.

By understanding the specific user rights required by the SQL Server setup and how they interact with Windows security policies and potential remote file shares, administrators can effectively troubleshoot and resolve installation failures stemming from overly restrictive security configurations. While tightening security is essential, it must be balanced with the operational requirements of the applications being installed.

Engage and Discuss¶

Have you encountered similar issues when installing SQL Server in a highly secured environment? How did you troubleshoot and resolve them? Share your experiences and insights in the comments below. Let’s discuss best practices for balancing security and application requirements during server setup!