April 9, 2007 at 1:48 pm
I have a scheduled job on a SQL 2000 database which is failing. Here is the error message :
The job failed. Unable to determine if the owner (caci\slape) of job Integrity Checks Job for DB Maintenance Plan 'IDS' has server access (reason: Could not obtain information about Windows NT group/user 'caci\slape'. [SQLSTATE 42000] (Error 8198)).
I am the SA on the instance. I wonder why would I be getting this error message? I am able to logon to this instance and browse and change things. So clearly it recognizes me. But when I run the job it fails. Wonder why? my SQL Server version is 8.0.
April 9, 2007 at 1:50 pm
actually the version is 8.00.2039. any ideas?
April 9, 2007 at 2:57 pm
Your job is running in the security context of your SQL Server Agent. Make sure that user has permission.
April 10, 2007 at 3:57 am
I believe this happens when the ID is not explicitly defined as a user but gets its access via group membership, sql agent is not able to determine if user is valid in this case. The job will definitely run if you change its owner to sa or the account the Sql service runs under. As this is a dbcc job it is acceptable to use an acount with sysadmin privileges
---------------------------------------------------------------------
April 10, 2007 at 7:13 am
Jobs run under the account the context of the sql serve agent. If your agent service account gets its access to sql server via windows membership it may be problematic at times. Make sure to change it to SA or to the account that has access explicitly granted in sql server. I experienced a few problems and after I changed the job owner the problem disappeared.
April 10, 2007 at 8:36 am
I have seen this with trust relationships between more than one network.
It is possible to create a job on a server that is part of one network and the owner being a user from a different network. When the credentials are passed to the domain controller, they are being passed to the DC for the SQL server and if the trust relationships are not set up perfectly, the user cannot be found.
A reliable solution is to change the job owner to either the service account for the SQL server, or sa.
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply