If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
scheduled jobs under a different user profile
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 ? -------------------------------------------------------------------------------- KenC |
Ads |
#2
|
|||
|
|||
scheduled jobs under a different user profile
Extra spacing (triple spaced?!) removed due to... just being too long. heh
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 ? 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? -- Shenan Stanley MS-MVP -- How To Ask Questions The Smart Way http://www.catb.org/~esr/faqs/smart-questions.html |
#3
|
|||
|
|||
scheduled jobs under a different user profile
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" wrote: Extra spacing (triple spaced?!) removed due to... just being too long. heh 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 ? 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? -- Shenan Stanley MS-MVP -- How To Ask Questions The Smart Way http://www.catb.org/~esr/faqs/smart-questions.html |
#4
|
|||
|
|||
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 |
Thread Tools | |
Display Modes | |
|
|