scheduled jobs under a different user profile

[Guest]

We have an XP PC.



User who logs in is JSMITH. User has three scheduled jobs set up on the PC.
(The jobs must run from a PC. Application software limitation.)



When JSMITH password expires, jobs fail. User has to always remember to
reset all scheduled jobs every time they reset their password.



So we created a new profile called SCHEDJOB whose password never expires and
has restricted access so it can only be used for scheduled jobs.



We log onto JSMITH"s PC as SCHEDJOB and update the scheduled jobs to the
SCHEDJOB user profile. We also learned that we need to add all drive mapping
under SCHEDJOB as exists under JSMITH. We then run each of the scheduled
jobs while logged on as SCHEDJOB. They all work fine.



We then log off and back on to the PC as JSMITH. We try to run any of the
jobs and get an error



'Can't find working directory'.



The command line in the scheduled job is



R:\rrww.exe.......



The R: drive is mapped under both the JSMITH and SCHEDJOB users. (We know
it is because the jobs run successfully under the SCHEDJOB user profile.)



Can anyone assist with why the jobs won't run under the JSMITH user profile ?

 

[Shenan Stanley]

Extra spacing (triple spaced?!) removed due to... just being too long. heh

We have an XP PC.

User who logs in is JSMITH. User has three scheduled jobs set up
on the PC. (The jobs must run from a PC. Application software
limitation.)

When JSMITH password expires, jobs fail. User has to always
remember to reset all scheduled jobs every time they reset their
password.

So we created a new profile called SCHEDJOB whose password never
expires and has restricted access so it can only be used for
scheduled jobs.

We log onto JSMITH"s PC as SCHEDJOB and update the scheduled jobs
to the SCHEDJOB user profile. We also learned that we need to add
all drive mapping under SCHEDJOB as exists under JSMITH. We then
run each of the scheduled jobs while logged on as SCHEDJOB. They
all work fine.

We then log off and back on to the PC as JSMITH. We try to run any
of the jobs and get an error

'Can't find working directory'.

The command line in the scheduled job is
R:\rrww.exe.......

The R: drive is mapped under both the JSMITH and SCHEDJOB users.
(We know it is because the jobs run successfully under the SCHEDJOB
user profile.)

Can anyone assist with why the jobs won't run under the JSMITH user
profile ?

Because you cannot map the R:\ drive as both accounts at the same time from
the same computer.

Since you are running the job as SCHEDJOB, it assumes (just like using
RUNAS) that you want to use the drives available to SCHEDJOB - not the
non-local ones available to the current user. Since R is not a local drive
and the SCHEDJOB user has no drives mapped when you run the scheduled task,
R is not available to the scheduled task (since it is not available to
SCHEDJOB.)

If "SCHEDJOB" hass access to the share R is being mapped to - what happens
if you try UNC paths? Or does this NEED the actual drive letter?

 

[Guest]

We've mapped the R: drive under each user: JSMITH and SCHEDJOB. We'ev also
mapped the Q: and Y: drives under both so they are indentical. Q: and Y: are
required to run the actual program and output the resulting file.

Can this whole scenario be eliminated if we set the PC to NOT require a
password on scheduled jobs ?

That way it doesn't matter what user the jobs run under.

Thanks for the quick response !

 

[Shenan Stanley]

We have an XP PC.

User who logs in is JSMITH. User has three scheduled jobs set up
on the PC. (The jobs must run from a PC. Application software
limitation.)

When JSMITH password expires, jobs fail. User has to always
remember to reset all scheduled jobs every time they reset their
password.

So we created a new profile called SCHEDJOB whose password never
expires and has restricted access so it can only be used for
scheduled jobs.

We log onto JSMITH"s PC as SCHEDJOB and update the scheduled jobs
to the SCHEDJOB user profile. We also learned that we need to add
all drive mapping under SCHEDJOB as exists under JSMITH. We then
run each of the scheduled jobs while logged on as SCHEDJOB. They
all work fine.

We then log off and back on to the PC as JSMITH. We try to run any
of the jobs and get an error

'Can't find working directory'.

The command line in the scheduled job is
R:\rrww.exe.......

The R: drive is mapped under both the JSMITH and SCHEDJOB users.
(We know it is because the jobs run successfully under the SCHEDJOB
user profile.)

Can anyone assist with why the jobs won't run under the JSMITH user
profile ?

Because you cannot map the R:\ drive as both accounts at the same
time from the same computer.

Since you are running the job as SCHEDJOB, it assumes (just like
using RUNAS) that you want to use the drives available to SCHEDJOB
- not the non-local ones available to the current user. Since R is
not a local drive and the SCHEDJOB user has no drives mapped when
you run the scheduled task, R is not available to the scheduled
task (since it is not available to SCHEDJOB.)

If "SCHEDJOB" hass access to the share R is being mapped to - what
happens if you try UNC paths? Or does this NEED the actual drive
letter?

We've mapped the R: drive under each user: JSMITH and SCHEDJOB.
We'ev also mapped the Q: and Y: drives under both so they are
indentical. Q: and Y: are required to run the actual program and
output the resulting file.

Can this whole scenario be eliminated if we set the PC to NOT
require a password on scheduled jobs ?

That way it doesn't matter what user the jobs run under.

Thanks for the quick response !

Let me try to explain this again...

You already said you mapped the drives as SCHEDJOB as well as the original
user. The thing is - the drives are *not* mapped when you tell the schedule
job to run under the context of SCHEDJOB and you are logged in as JSMITH.
They may well be available to JSMITH - but by telling the job to run as
SCHEDJOB - they aren't mapped where the scheduled task can see it.

Telling a scheduled task to run as a user different than the one that is
logged on is like doing a RUNAS. All the network drives you have mapped as
the currently logged on user are not available to the RUNAS'd user. Test
this yourself. Logged in as JSMITH, open a command prompt. From that
command prompt you can easily go into the Q, R or Y drives. Now, in that
command prompt, type in:

runas /noprofile /user:SCHEDJOB cmd

--> Press enter and put in the password for the user when it asks.

The new command prompt window that opens (and states at the top it is
running as SCHEDJOB) - try to get into Q, R or Y. You can't - because that
user context does not have those drives mapped - nor can you map them as
that user while JSMITH is logged in with those or any other share on that
same server connected as JSMITH.

I'm guessing this job only works when the user is actually logged in (even
before you changed things.) Meaning they have the drives mapped, were
logged into the computer (although it may have been locked.) Which means
this scheduled job has to be run when someone is logged in and with the
drives already mapped - thus will likely only work as the user (with
password.)

What this sounds like to me is trying to resolve a human issue with a
technology solution. You could either write a simple script for JSMITH to
run when they change their password that asks them for the new password and
deletes/creates the tasks over again appropriately. (SCHTASKS command line,
for example.) You could just rely on them to change the passwords
(obviously that has failed.) You could try running the job as SYSTEM - but
I don't think that will work...

Redirected Drives on Microsoft Windows XP
http://support.microsoft.com/kb/180362/

*note the last paragraph.