Okay, this is driving me nuts! I'm evaluating 24x7, and I can't get a simple script to run as a domain user On Win2003. It runs fine as a local user (./automate), but I get a 1314 error when I try to run it as the domain user (mycorp/automate). I had the network admin add the "logon as a batch job" and the "logon as a service" to the mycorp/automate user-id, so I don't know what else to do. At this time, 24x7 is not running as a service.

The same script runs perfectly using the Windows Task Scheduler with the Run As set to the domain user.

You need "act as part of the operation system" rights for the account running the scheduler. The Windows Scheduler servicise runs under LocalSystem account and gets these right by default. The 24x7 runs under your admin account and by default doesn't get these rights. Hope this helps.

: Okay, this is driving me nuts! I'm evaluating 24x7, and I can't get a simple
: script to run as a domain user On Win2003. It runs fine as a local user
: (./automate), but I get a 1314 error when I try to run it as the domain
: user (mycorp/automate). I had the network admin add the "logon as a
: batch job" and the "logon as a service" to the
: mycorp/automate user-id, so I don't know what else to do. At this time,
: 24x7 is not running as a service.

: The same script runs perfectly using the Windows Task Scheduler with the Run
: As set to the domain user.

: You need "act as part of the operation system" rights for the
: account running the scheduler. The Windows Scheduler servicise runs under
: LocalSystem account and gets these right by default. The 24x7 runs under
: your admin account and by default doesn't get these rights. Hope this
: helps.

Ok, created a GPO object (and linked/eforced it) for the active directory which has the server in it (and filtered it for the local box DOMAIN\SERVERNAME$). I assinged the following rights to the domain user account (domainname\automate):

* Act as part of the operating system
* Logon as a batch job
* Log on as a service

Ran gpupdate /force on the box and rebooted. No change still

Just to clarify the setup:

The account running 24x7 needs to have "act as part of the operation system" privileges
The account used for the job needs to have "logon as a batch job" privileges and in case if 24x7 is run as a service, in addition to hat "logon as a service" privilege.

Is that what you have now?

Notes: Doman privileges granted using active directory override local policy.
After changing privileges you need to restart the target computer or at least logoff/logon to refresh the cached settings.

: Ok, created a GPO object (and linked/eforced it) for the active directory
: which has the server in it (and filtered it for the local box
: DOMAIN\SERVERNAME$). I assinged the following rights to the domain user
: account (domainname\automate): * Act as part of the operating system
: * Logon as a batch job
: * Log on as a service

: Ran gpupdate /force on the box and rebooted. No change still

: Just to clarify the setup: The account running 24x7 needs to have "act
: as part of the operation system" privileges
: The account used for the job needs to have "logon as a batch job"
: privileges and in case if 24x7 is run as a service, in addition to hat
: "logon as a service" privilege.

: Is that what you have now?

: Notes: Doman privileges granted using active directory override local policy.
: After changing privileges you need to restart the target computer or at least
: logoff/logon to refresh the cached settings.

Yes, these are my current settings:

Policy Setting
Act as part of the operating system domain\automate
Log on as a batch job domain\automate
Log on as a service domain\automate

The same account is being used to run 24x7 and also the Jobs. We have rebooted the local box and have logged on using RDP as the domain\automate user.

If you run this job using the same account simply leave Run As Another User job properties blank (just delete the stuff what you entered and you should be fine)

: Yes, these are my current settings: Policy Setting
: Act as part of the operating system domain\automate
: Log on as a batch job domain\automate
: Log on as a service domain\automate

: The same account is being used to run 24x7 and also the Jobs. We have
: rebooted the local box and have logged on using RDP as the domain\automate
: user.

: If you run this job using the same account simply leave Run As Another User
: job properties blank (just delete the stuff what you entered and you
: should be fine)

It does work correctly in that situation. That's the first thing I tried. However, I need to make sure all the functionality is there before I start loading over 50 jobs into it. I still need to test network share access and other functions, but if I can't get a simple copy in the same directory to work, then my hopes for the other functions are not very high.

I think the issue is in RDP and the Terminal Server. I don't know how it treats your GPO settings but I can assure you that if things are setup properly jobs will run as expected. Please try doing all this directly on the server without using RDP.

: It does work correctly in that situation. That's the first thing I tried.
: However, I need to make sure all the functionality is there before I start
: loading over 50 jobs into it. I still need to test network share access
: and other functions, but if I can't get a simple copy in the same
: directory to work, then my hopes for the other functions are not very
: high.