job failed. Unable to determine if the owner has server access 1

[JSpicolli]

I have a SQL Server 2000 DTS package scheduled as a job.
The DTS package queries Active Directory and imports / updates all info into SQL.

The owner of the DTS package is an account that has access to A/D. The Sql Box itself has permissions to access A/D.

If I am logged into the console and manually run the package under my credentials it succeeds.

When I am not logged in the job fails, even if I run it under my account.

=======================================================
SQL Server Scheduled Job 'UPDATE Employee Tables' (0xBC84EC21A2323D4F872895739B115EBF) -
Status: Failed - Invoked on: 2005-04-26 09:02:38 -
Message: The job failed. Unable to determine if the owner (xxx\jspicolli) of job UPDATE Employee Tables has server access (reason: Could not obtain information about Windows NT group/user 'xxx\jspicolli'. [SQLSTATE 42000] (Error 8198)).
=======================================================


Any ideas?

 

[JSpicolli]

Upon further inspection I found the apparant exact error message:


Non-SysAdmins have been denied permission to run CmdExec job steps. The step failed.

SqlServerAgent is running under the system account.
I was going to try to give System full admin privledges, but cannot locate an account called 'system' on the box.

???

 

[mrdenny]

The local system account already has full rights to the server. Based on the error that you first posted the SQL Agent can't connect to the domain controllers to find out if your account exists and has rights on the domain.

It may be because your SQL Agent is running under the local system account. Set it up to run as a domain account, then try to run the job again.

Denny
MCSA (2003) / MCDBA (SQL 2000)

--Anything is possible. All it takes is a little research. (Me)

http://www.mrdenny.com

(My very old site)

 

[JSpicolli]

it works now

 

[chrob]

Hey, JSpicolli, what did you finally do to resolve the issue? I obviously am experiencing the same problem, but I already have SQL Agent running under the Domain Service account and has rights in AD. I have a user (who has SA rights on the instance) who is trying to use his new AD account to run the job.

I have read the two KBA's which suggest to create a Pre-Windows 2000 group, but our AD team is reluctant to do so.

If this is a matter of the user's ID needing to have certain permissions in AD, does anyone know exactly what we need to check or change?

Any info you (or anyone else) could provide would be great.

 

[JSpicolli]

actually, I redesigned the package.

Now I use csdve, to dump the cpntents of AD into a CSV, then I use DTS to import it from AD.

This works for mr because I only need to synch with AD on a nightly basis. If your requirements are similar, you may want to use a similar approach. Much much easier, all the way around.

 

[weigoldk]

Hey chrob,

Did you resolve the issue? I can't use JSpicolli's work around.

Thanks in advance

 

[chrob]

We found a couple of resolutions:

(1) Use 'sa'
(2) Apply SQL 2000 SP4
(3) There is supposedly a patch from Microsoft that they have to specifically send to you. You cannot download it directly. Search their site with the error message - I cannot recall which patch it is.

 

[grimwyre]

This is an intermittent problem, described in KB241643, so we changed all our accounts from Windows to SQL and have had no problems since. This has the advantage that changes in Windows accounts (e.g. deletion) do not affect SQL jobs. When our jobs were installed, they used the account of the installer, when that account was deleted, all the jobs failed. Now we insist that the job runs under a generic account or SQL account.