Re: scheduled jobs under a different user profile

KenC1231 wrote:
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 wrote:
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?

KenC1231 wrote:
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.

--
Shenan Stanley
MS-MVP
--
How To Ask Questions The Smart Way
http://www.catb.org/~esr/faqs/smart-questions.html


.

Relevant Pages

  • Re: scheduled jobs under a different user profile
    ... We've mapped the R: drive under each user: JSMITH and SCHEDJOB. ... User has three scheduled jobs set up ... RUNAS) that you want to use the drives available to SCHEDJOB - not the ...
    (microsoft.public.windowsxp.newusers)
  • Re: scheduled jobs under a different user profile
    ... When JSMITH password expires, jobs fail. ... remember to reset all scheduled jobs every time they reset their ... We log onto JSMITH"s PC as SCHEDJOB and update the scheduled jobs ... RUNAS) that you want to use the drives available to SCHEDJOB - not the ...
    (microsoft.public.windowsxp.newusers)
  • Re: schedule jobs under different user in XP
    ... User has three scheduled jobs set up on the PC. ... When JSMITH password expires, jobs fail. ... it is because the jobs run successfully under the SCHEDJOB user profile.) ...
    (microsoft.public.windows.mediacenter)
  • schedule jobs under different user in XP
    ... User has three scheduled jobs set up on the PC. ... When JSMITH password expires, jobs fail. ... it is because the jobs run successfully under the SCHEDJOB user profile.) ...
    (microsoft.public.windows.mediacenter)
  • Re: DB Maintenance Plan seems corrupted
    ... parsing the strings in the scheduled jobs to determine how to display the ... reasons why I recommend creating your own jobs and dumping the wizard. ... > The maintenance plan looks corrupted although the ...
    (microsoft.public.sqlserver.server)