ardolino
asked on
Scheduled Task could not start
I have a scheduled task that is I setup identically on a Windows 2000 Server and a Windows 2003 Server. It is setup to run a BAT file using a domain user account. The task executes correctly on the Windows 2000 Server, but reports "Could not start" on the Windows 2003 Server. Both servers are member servers of a Windows 2000 domain.
I can only get it to run on the Windows 2003 Server when I make the domain user account a member of the local administrators group. I have tried to give the domain user the "log on as a batch job" right using local security policy on the Windows 2003 Server, but it does not help. I also checked the security permissions on both servers and they are identical.
Why can't I get this task to run as this user on Windows 2003 Server?
I can only get it to run on the Windows 2003 Server when I make the domain user account a member of the local administrators group. I have tried to give the domain user the "log on as a batch job" right using local security policy on the Windows 2003 Server, but it does not help. I also checked the security permissions on both servers and they are identical.
Why can't I get this task to run as this user on Windows 2003 Server?
ASKER
The task is being setup by an install program (VS.NET Setup and Deployment Project) using the schtasks.exe program that comes with Windows Server.
I even tried to recreate the task manually, and I did the same thing that is specified in the link you gave me.
I did confirm that when you schedule the task on the Windows 2000 Server, it automatically grants the permission "logon as a batch job" when you create the task. However, this is not happening on the Windows 2003 Server when I create the task. Perhaps this has something to do with it.
I even tried to recreate the task manually, and I did the same thing that is specified in the link you gave me.
I did confirm that when you schedule the task on the Windows 2000 Server, it automatically grants the permission "logon as a batch job" when you create the task. However, this is not happening on the Windows 2003 Server when I create the task. Perhaps this has something to do with it.
ASKER
Never mind, it does grant the "logon as a batch job" right to the domain user. However, it still will not run unless I make the domain user a member of the local administrators group.
What is the bat file doing? If it's something that a normal user could not do, then the bat file will not be able to do it. The security is increased on 2003, so maybe that's why. Also, did you try adding the user to the Server Operators group. By default, that group can run scheduled tasks. If you check the group policy you can check the policy called: "allow server operators to run scheduled tasks".
There is also policies for "log on as a batch job" and "act as a part of the OS". Remember, when you make a GP change, run gpupdate to refresh the policy.
There is also policies for "log on as a batch job" and "act as a part of the OS". Remember, when you make a GP change, run gpupdate to refresh the policy.
Does the user have a password? If not, set one.
Does the Path to the batchfile contain a space ? If yes, enclose the path portion of the task between slashes and quotation marks combination.
e.g.:
not-working: schtasks /create /tn "my task" /tr "c:\foldername containing spaces\script.bat arguments" /sc once /sd 07/29/2003 /st 10:01
working: schtasks /create /tn "my task" /tr "\"c:\foldername name containing spaces\script.bat\" arguments" /sc once /sd 07/29/2003 /st 10:01
Does the Path to the batchfile contain a space ? If yes, enclose the path portion of the task between slashes and quotation marks combination.
e.g.:
not-working: schtasks /create /tn "my task" /tr "c:\foldername containing spaces\script.bat arguments" /sc once /sd 07/29/2003 /st 10:01
working: schtasks /create /tn "my task" /tr "\"c:\foldername name containing spaces\script.bat\" arguments" /sc once /sd 07/29/2003 /st 10:01
ASKER
cfairley:
I changed the bat file to do something very simple, like the following: "echo %time% %date% > log.txt", and it still does not work. There is no "Server Operators" group on the Windows 2003 Server (its a member server, not a domain controller). No "Domain Security Policies" have been defined. I am making all changes to the "Local Security Policy" on the member server.
WeHe:
Yes, the user has a password. I know that the task is setup correctly (with spaces and all) because it runs when I make the user a member of the local Administrators group. Something else is preventing the task from running.
I changed the bat file to do something very simple, like the following: "echo %time% %date% > log.txt", and it still does not work. There is no "Server Operators" group on the Windows 2003 Server (its a member server, not a domain controller). No "Domain Security Policies" have been defined. I am making all changes to the "Local Security Policy" on the member server.
WeHe:
Yes, the user has a password. I know that the task is setup correctly (with spaces and all) because it runs when I make the user a member of the local Administrators group. Something else is preventing the task from running.
ASKER
Forget even the domain account for a minute.
I created a new local user called "test" password "test" on the Windows 2003 server. I then created a new task to run "test.bat", which does the following:
@echo off
echo %date% %time%
I placed the test.bat file in the c:\windows\temp directory.
Then I tried to create a scheduled task to run test.bat using the test account. Still "Could not start".
What am I missing?
I created a new local user called "test" password "test" on the Windows 2003 server. I then created a new task to run "test.bat", which does the following:
@echo off
echo %date% %time%
I placed the test.bat file in the c:\windows\temp directory.
Then I tried to create a scheduled task to run test.bat using the test account. Still "Could not start".
What am I missing?
ASKER
Ok, this is weird.
Given my test scenario (user test, password test, running test.bat), I added the local "test" account to all user groups and the eliminated them one by one.
What I noticed is that if I do not add the user to the local Administrators group, the task will only run if the user is in the "TelnetClients" group. Why is this? Does the TelnetClients group have permissions that somehow lets the user run a scheduled task?
I think I am on to something here, but I still do not know why I cannot get the task to run when the user is just part of the local User group. I know it has something to do with access rights or group policy, but I am not sure how. This is the question that still needs answering.
Given my test scenario (user test, password test, running test.bat), I added the local "test" account to all user groups and the eliminated them one by one.
What I noticed is that if I do not add the user to the local Administrators group, the task will only run if the user is in the "TelnetClients" group. Why is this? Does the TelnetClients group have permissions that somehow lets the user run a scheduled task?
I think I am on to something here, but I still do not know why I cannot get the task to run when the user is just part of the local User group. I know it has something to do with access rights or group policy, but I am not sure how. This is the question that still needs answering.
ASKER
I found the problem. The user does not have permission to c:\windows\system32\cmd.ex
This article solved the problem:
Article ID: 867466
Title: "Access is denied" error message when you run a batch job on a Windows Server 2003-based computer
URL: http://support.microsoft.com/default.aspx?scid=kb;en-us;867466
This article solved the problem:
Article ID: 867466
Title: "Access is denied" error message when you run a batch job on a Windows Server 2003-based computer
URL: http://support.microsoft.com/default.aspx?scid=kb;en-us;867466
Sorry we could not help you out more. Thanks for posting the fix.
yes, thanks for this article.
learning never ends.
learning never ends.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Awesome find! Helped a ton!
http://support.microsoft.com/default.aspx?scid=kb%3Ben-us%3Bq324283