Hi, 

I have server that had 2008 Standard edition on it. There were some jobs on the instance with owner being set as domain service account. We installed 2014 Enterprise edition on same box and transfer jobs to the new instance. The jobs start failing with below error message. 

The job failed.  Unable to determine if the owner (myDomain\SQLServiceAccount) of job "XXXXXXX" has server access (reason: Could not obtain information about Windows NT group/user 'myDomain\SQLServiceAccount', error code 0x6e. [SQLSTATE 42000] (Error 15404)).

If I am changing the job owner to SA it is working fine, but does not like the idea of using SA as job owner. 

Any help will be appreciated.

Yes, it is absolutely th

make sure account is not locked in AD level and Domain controller is accessible. Check these too..

https://social.technet.microsoft.com/Forums/windowsserver/en-US/27f62fc2-aa74-4c9c-b559-b65b20d6bbb3/could-not-obtain-information-about-windows-nt-groupuser-domainuser-error-code-0x5?forum=winserverDS

Yes, it is absolutely there.&

Verify that the SID for the job owner (sysjobs in msdb, I think) matches the logins in sys.server_principals. And use sp_validate_logins to see that it doesn't flag this login as orphaned (doesn't exist in domain). That is the chain used in the end, and above will hopefully let you know where it bre

The error points to permission/access problems with the AD. 0x6e = 110, NET HELPSMG 110 says The system cannot open the device or file specified.

You said that you tried different service accounts, but not service accounts for what. It's the service accuont for Agent that matters. And if you are running Agent under some local account like NT SERVICE/SQLAGENT, it is the machine account that needs access in the AD.

Erland, 

Service account for SQL agent is "NT Service/SQLAgent..." as you said. Could you please guide me how I can set that account to have access to AD?

Service account for SQL agent is "NT Service/SQLAgent..." as you said. Could you please guide me how I can set that account to have access to AD?

You can't. That is an account local to the machine. Possibly access could be granted to DOMAIN\MACHINE$ (that is, the machine account). This works in some situations, but I am not going vouch that it works Active Directory. An alternative is to let the service account be a domain account.

I'd be a bit surprised if using a virtual account (which is what is used now) is the cause of this problem. I frequently use the default, unless I have a reason not to. I mean, why have yet another account in the domain with password never expires?

Perhaps there is some synchronization issues between the domain controllers?

Hoever, the situation still stands, and the return code does indeed indication a permission issue. I would first rule out domain problems (just in case) and as second thing change (even if temporarily) the service account for the Agent service to a domain account. Make sure that thie is done using the right tool: SQL Server Configuration Manager tool - important.

I'd be a bit surprised if using a virtual account (which is what is used now) is the cause of this problem. I frequently use the default, unless I have a reason not to. I mean, why have yet another account in the domain with password never expires?

A virtual account like NT Services only has permissions on the local machine, so I'm fairly sure that this is part of the equation. But if granting the machine account permission in the AD is fine, well go for that.

I am using that service account for all my server that are in domain. It is working for all servers and instances except this instance. The old instance of same server is working fine. 

I am going through you guys suggestions and checking them. 

I am using that service account for all my server that are in domain.

No, you are not. NT Service/SQLAGENT is an account local to the machine. You may use namesake accounts on other machines, but they are not the same account.

I am using that service account for all my server that are in domain.

No, you are not. NT Service/SQLAGENT is an account local to the machine. You may use namesake accounts on other machines, but they are not the same account.

How about ... the new SQL Server being set up for mixed authentication?  If that isn't it, I will leave it up to the actual SQL Server DBA types to answer this question.