Take the 2-minute tour ×
Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. It's 100% free, no registration required.

Every so often (e.g. ~months) a SQL Server Agent hourly Job will begin reporting an Error 15404 and continue to do so until intervened with.

[298] SQLServer Error: 15404, Could not obtain information about Windows NT group/user 'DOMAIN_NAME\SomeDomainAccount', error code 0x6e. [SQLSTATE 42000] (ConnIsLoginSysAdmin)

Sometimes the first failure occurs immediately after a manual restart of the SQL Server Engine and SQL Server Agent services. The problem can be cleared by rebooting the machine.

The Job Owner is the name listed in the error message and is a SQL Server Admin.

The SQL Server Engine Service account looks to be a service account (I believe it is the default install account (one notch better than generic NetworkService to prevent interference between Engine/Agent instances):

   NT Service\MSSQL$INSTNAME

It would be one thing if the job always failed but since the job succeeds after a reboot it makes me think that a service account like is supposed to be working and that there is some A/D timing issue or possibly a bug. When IT is asked about the A/D configuration, the response is usually "nothing has changed."

  • Restarting the engine and agent services can cause the job to start failing.
  • A machine reboot clears the problem.
  • An immediate subsequent restart of the engine and agent no longer cause the job to fail.

Link: How to troubleshoot a SQL Server 8198 error

share|improve this question
    
Update, this has happened two more times since the post. –  crokusek Mar 7 '14 at 22:58
    
Possibly related, we also have an intermittent (weekly) cannot generate SSPI problem on two different servers. –  crokusek Nov 13 '14 at 18:45
    
I'll just add that I've just randomly got this error from a SQL script that was working yesterday. No changes to the script, exact same machine, no obvious errors in the windows logs. The offending line of SQL was a CREATE ASSEMBLY statement, AUTHORIZATION [dbo], PERMISSION_SET = EXTERNAL_ACCESS; –  redcalx Apr 9 at 9:34
    
More info. Restarting SQL Server didn't resolve the issue, but rebooting the machine did. Possibly a log-off/on would have done it, as I suspect it's some subtle issue around my domain account. Note that I haven't changed my password recently. –  redcalx Apr 9 at 9:46

1 Answer 1

Not a solution, but you can work around the issue by making the job owner a SQL account.

Each time a job is started, SQL Server verifies the identity of the job owner and checks that it has permission to execute the job. If the owner is a Windows account, the engine needs to query Active Directory. If for any reason that fails, the job will not run. It could be because the AD server is busy, down or cut off from the network, or that the SQL Server service account doesn't have rights.

Since it works immediately after rebooting, that makes me think it might have something to do with cached credentials. Windows will save the credentials it looks up for later use. That cache is cleared on reboot. Perhaps something is corrupting the cache.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.