First published on MSDN on Sep 22, 2016
One of the actions of SQL Server setup is to configure appropriate permissions on the binaries, data, log, tempdb, backup folders such that post-installation, SQL Service account has all the required permissions to read, write and execute from these folders without any errors. In order for SQL Server setup to be able to assign appropriate permissions to SQL Service account, it requires SeSecurityPrivilege on the server where these folders are created. One of the pre-requisites for running SQL Server setup is that setup account should be an administrator on the server and by default in windows, administrators are granted SeSecurityPrivilege unless overridden by group policy. Hence when installing SQL Server on a local server with setup account as local administrator, DBAs may have never felt the need of assigning these permissions explicitly to setup account. If the setup account has these permissions missing, you are likely to hit one of the scenarios discussed in
One of the common scenarios installing SQL Server is to setup the default backup directory to a SMB fileshare to store the backup files offsite as per the recommended practice. In this scenario, if the admins fails to grant SeSecurityPrivilege on the remote fileserver to setup account, the SQL Server setup validation with fail with following error not allowing you to proceed with the installation.
SQL Server setup account does not have the SeSecurityPrivilege privilege on the specified file server in the path <<network share>>
. This privilege is needed in folder security setting action of 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 is by design behavior of SQL Setup to ensure SQL Setup doesn’t fail later during the installation while trying to setup appropriate permissions on the SMB fileshare. These pre-requisites are also documented in the MSDN article
but the article primarily talks about Data and Log folders on SMB fileshare and hence the same requirements for default backup directory on the fileshare may not be so apparent.
My organization doesn’t allow SeSecurityPrivilege to be granted on the remote fileserver and I have already assigned FULL CONTROL permissions to setup account and SQL Service on the SMB fileshare but without SeSecurityPrivilege, SQL setup doesn’t allow me to proceed with the installation.. How can I overcome this?
In this scenario, you can setup default backup folder to a local directory during setup which will allow SQL Server installation to proceed as desired. Post-installation, the default backup directory can be changed using SSMS or Powershell. Unlike setup, SSMS or Powershell doesn’t configure the permissions on the backup folder or perform any validation, hence the default backup directory can be changed without requiring SeSecurityPrivilege on the fileserver. However in this case, the onus of setting the FULL CONTROL permissions on the default backup directory on SMB fileshare to SQL Service account lies on the admins. If the DBA fails to assign these permissions and later when the backup is performed on the default backup location, the backup will fail with access is denied error.
Another scenario where the setup account requires SeSecurityPrivilege on the server hosting SQL Server instance is during installing or applying Service Packs or Cumulative update patches from WSUS server. In this scenario, if the system account on WSUS server doesn't have SeSecurityPrivilege, it causes the performance counter (perfmon counter) installation to fail resulting into performance counter missing after applying CU patches.
SQL Server Database Engine Services Instance Features
Component error code:
The attempt to copy file 's:\Program Files\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\Binn\DllTmp64\sqlctr120.dll' to 'C:\Windows\system32\perf-MSSQLSERVER-sqlctr12.2.5000.0.dll' failed.
The process does not possess the 'SeSecurityPrivilege' privilege which is required for this operation. ---> System.Security.AccessControl.PrivilegeNotHeldException: The process does not possess the 'SeSecurityPrivilege' privilege which is required for this operation.
In this scenario, WSUS system account requires SeSecurityPrivilege permissions on the server hosting SQL Server instance for the performance counters to be successfully installed. Alternatively, you can run a repair to restore the missing performance counters.
Hope this clarifies the requirements for SeSecurityPrivilege on remote fileserver to SQL setup account and options to workaround it