Upravit

Sdílet prostřednictvím


SQL Server services using domain credentials fail to start

This article discusses an issue wherein SQL Server fails to start when the startup account doesn't have the required permissions.

Original product version:   SQL Server
Original KB number:   3006856

Symptoms

When you try to start or restart a SQL Server service, it fails to do so, and the following messages are logged in the SQL Server error log:

<Time stamp> spid9s Error: 17182, Severity: 16, State: 1.

<Time stamp> spid9s TDSSNIClient initialization failed with error 0xffffffff, status code 0x80. Reason: Unable to initialize SSL support.

<Time stamp> spid9s Error: 17182, Severity: 16, State: 1.

<Time stamp> spid9s TDSSNIClient initialization failed with error 0xffffffff, status code 0x1. Reason: Initialization failed with an infrastructure error. Check for previous errors.

<Time stamp> spid9s Error: 17826, Severity: 18, State: 3. Time stamp spid9s Could not start the network library because of an internal error in the network library. To determine the cause, review the errors immediately preceding this one in the error log.

<Time stamp> spid9s Error: 17120, Severity: 16, State: 1. Time stamp spid9s SQL Server could not spawn FRunCommunicationsManager thread. Check the SQL Server error log and the Windows event logs for information about possible related problems.

Note

This issue only occurs on a SQL Server instance that runs under a domain account.

Cause

The issue occurs because the usual permissions granted to a SQL Service account are missing. The user rights for the SQL Server startup account that must be present are as follows:

  • Adjust memory quotas for a process (SeIncreaseQuotaPrivilege).

  • Bypass traverse checking (SeChangeNotifyPrivilege).

  • Log on as a service (SeServiceLogonRight).

  • Replace a process-level token (SeAssignPrimaryTokenPrivilege).

For more information, see Service Permissions.

Resolution

To resolve the issue, grant the missing permissions to the SQL Service domain account by using the User Rights Assignment pane in the Local Security Policy MMC snap-in.