A few months ago we installed SQL Server 2012 in Windows 2008 R2 under the virtual account "NT Service\MSSQLSERVER", all good.
A few days ago, one of the admins of the IT dept installed Full Text Search component to the SQL Server 2012 (the problem is he could not recall what settings exactly he chose during the setup), and after that, quite a few problems come:
A. We checked the Windows Logs, in Application, we find out that MSSQLServer has quite a lot of abnormal logs, like:
The SQL Server Network Interface library could not register the
Service Principal Name (SPN) [ MSSQLSvc/FooComputer.FooDomain.com:1433
] for the SQL Server service. Windows return code: 0xffffffff, state:
63. Failure to register a SPN might cause integrated authentication to use NTLM instead of Kerberos. This is an informational message.
Further action is only required if Kerberos authentication is required
by authentication policies and if the SPN has not been manually
registered.
It seems to be the cause but no idea why and how to solve it.
B. SQL jobs with owners who are domain users like ("MyDomain\FooUser") will fail with following message:
The job failed. Unable to determine if the owner (MyDomain\FooUser)
of job JOBNAME has server access (reason: Could not obtain information
about Windows NT group/user 'MyDomain\FooUser', error code 0x6e.
[SQLSTATE 42000] (Error 15404)).
We did intensive search, and finally replace the owner with "sa" and solved the problem, although it's not that decent. Still, we would like to find out why.
C. Cannot access network resources like a folder in other computers, for example, the following sql will return "access is denied":
DECLARE @CopyCommand nvarchar(1000)
set @CopyCommand = 'dir ' + Char(34) + '\\FooComputer\FooFolder\' + Char(34)
EXEC master..xp_cmdshell @CopyCommand
For problem C, according to MSDN (http://technet.microsoft.com/en-us/library/ms143504.aspx) we tried to grant full control access for the account "MyDomain\SQLServerComputerName$" to the folder, still same result.
Best Answer
Those three problems are all a result of the account running the SQL Service not being a domain account, and they will all be corrected by changing SQL to run under a domain account. Specifically:
A - an SPN is a Kerberos security feature that requires a domain account, and doesn't work with local accounts
B - In order to read from active directory, the service needs a domain account's credentials
C - Local accounts aren't recognized by remote computers, so they deny the connection attempt.
Here's a walk-through on how to change the service account:
http://technet.microsoft.com/en-us/library/ms345578.aspx