The owner () of job <Job Name> does not have server access.

Question

Up till now the jobs have been running without fail for months after the upgrade to SQL 2005.
For some reason the jobs started to fail with the error:
The owner () of job <Job Name> does not have server access.

The user is a domain admin with the ability to control every sing aspect of SQL.
I then changed the owner and now the jobs are running again.

I am however afraid it will happen again since I am still clueless as to what could have caused the problem.

Any help would be greatly appreciated.
RoviWil

 

Answer 1

I too am having difficulty finding out why

Code Snippet

The owner () of job ____ does not have server access

 

The owner is a member of [the chosen] few who have sysadmin rights.

The individual logon is not declared on the server, but group permissions = membership to sysadmin.

SQL Server 2005, 2003 server.

 

Answer 2

Hi,

 

In principle this error says that SqlAgent was unable to verify that the login has sysadmin privileges. Since the rights came through group membership it's possible that some sort of network failure could have led to this. Is the failure reproducing consistently for you? If you try to use a different login that exists on the server do you still have problems?

 

Regards,

Ciprian Gerea

Answer 3

See this KBA http://support.microsoft.com/kb/825042

Answer 4

Found the problem: we had a power outage a number of days ago.

Found buried in my voicemail....

reboot the server and all is well. 

DNS server didn't like how we ignored her. Next time I will be nice.

Answer 5

I had the same problem, also caused by a power outage. I found that you do not have to reboot the server - for me, just restarting SQL Server Agent worked.

 

Thanks for putting me on the right track!

Answer 6

http://support.microsoft.com/kb/825042

 

This KBA is great, for SQL 2000.

 

But, I am having the same EXACT issue with SQL 2005 SP2.  This happens every time that I reboot the server.  A specific job, owned by a Domain\User, who access to the server by way of a Domain\GlobalGroup.  I can exec xp_logininfo for his Domain\User and it returns the correct information, including the permission path that shows the Domain\GlobalGroup.  Yet the job still fails!  The only workaround we have is to assign the job a different owner, and then assign back to him.

 

Why can't jobs be owned by Domain\GlobalGroups?  I can an error that says it will not accept the global group, but why not?  If I have a TEAM of DBA's that are in the same global group, they should ALL have access to the jobs, and I (as SA)should not have to reassign them to specific DBA's.

 

 

Answer 7

We are having the same exact problem in the environment that I support (e.g. SQL Server 2005 x64 SP2 build 3054). Where a Windows login name is a member of a Windows group and there is only a corresponding SQL Server Windows Group login that has sysadmin access. Jobs created by the setup of Replication or the Database Maintenance Wizard will fail until you change the job owner to sa. I'm surprised that this has not been reported to Microsoft yet?

 

Error Description:

Message
The job failed.  The owner (MyDomain\WinLoginName) of job MP-Full Adhoc Database Backup.Subplan_1 does not have server access.

Answer 8

restsarting sql server agent did for it for me. Also set you username for the job to be non windows domain ie..sa or someother internal username to sql server that doesnt require a connection to active directory

Answer 9

Recycling the SQLAgent worked for me as well.  Also switched the user who was running the job to another, ran the job successfully, then switched back.  Did that on one job, cycled the agent service to get the others working.  All jobs owned by the one owner failed, while others owned by a different domain user succeeded.  Strange.

Answer 10

Restarting SQL Server Agent- statrt jobs again...
:)
Works like a charm.

Answer 11

:)))

Answer 12

You will have remove the Job Owner Alias from Administrators group to overcome this issue

Answer 13

restarting the SQL Server Agent seemed to work for us.
I think it can be resolved completely if you set a dependancy on the netlogon service so that the SQL Agent Service waits for netlogon before starting up.

Answer 14

The same problem to me, was solved just restarting the SQL Server Agent.

Answer 15

Restarting SQL Server Agent is also fine for me :))

Answer 16

Working for me tooo :)))))

Answer 17

Thumb rule is...after creating any sql agent job always change job owner to [sa], u'll be happy forever.

---

Best Regards, Abhishek DBA(MCTS)

Answer 18

Note: by just restarting the SQL Server Agent you won't prevent the issue from happening again. See answer from G-Unit for permanent solution.

Answer 19

I had same issue in sql server 2008 EE sp1. I changed job owner from domain user (user part of dba group) to SA. it worked for me. I didn't restart sql agent.when looked at sql error log it shows server rebooted and i am not able to see "SQL Trace was stopped due to server shutdown. Trace ID = '1'. This is an informational message only; no user action is required." in previous error log than the current error log. from this what i understand is server rebooted with some power outage or some unexpected happened.

 

i will update on why server rebooted.

 

 

Thanks,

Brahma

 

---

------------------------ Brahma http://brahmarao.tech.officelive.com http://nani1211.info/sql

Answer 20

The job failed. The owner of job does not have server access, means - the owner of the Job does not have the windows authentication account enabled.

Do the below test you will find out the problem.

Login as Domain user account into a machine where you can access the SQL Server - > Open SSMS -> Select Windows authentication username will default to \Domain\Username

Click on Connect button, it should connect if not connecting then the user is not added properly to the Logins. First add the user to the login

Some times using windows 7 and Server 2008 you need to run the SSMS using Run as Administrator also to solve this problem