Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm a programmer, but the problem encountered has stepped beyond the code and into the system administrator realm, at least that is what I think at this time. I will only use one bit of code to show where exactly the problem is encountered and I will also provide the command line alternative to what the code is essentially doing so if someone wishes to recreate the issue they can. I'm not the system administrator, but because I've been told it cannot be done without some workaround I've taken it upon myself to find the solution so I can move on the other tasks and not have to rewrite code or search for a programmatic solution. I've thought of C sharp user and permissions impersonation, but I would like to avoid that if possible.

The troubled program is a custom C sharp application, customApp.exe, running as a scheduled task on Server 2003. The issue is I have a C sharp application that checks its dependencies early in runtime. One of those dependencies is running as a service. I perform a query to verify the service is running. The act of checking the service running status causes the error. The failure is logged in the server event logs under security as a failure audit with notes regarding permissions as the cause of failure.

A dedicated service account exists for use to run the customApp.exe program. The rights are quite limited, but adequate for the application as seen during test runs. Problems are encountered when the application is run as a scheduled task.

The settings for the scheduled task that is failing are not viewable by me, but I've placed some checks into the debugger to verify proper settings. Basically I put in a whoami reporting line of code to verify the username and domain are correct. I also know the username, domain, and password must be correct because the application interfaces with a Microsoft SQL database which it is properly Selecting and Inserting from and to using Integrated Security in the connection string. The permissions settings are unknown to me, but I know that the system admin added the dedicated service account to the security tab under the specific scheduled task.

Here is the C# code snippet that is causing the fuss:

ServiceController sc = new ServiceController("Service Name Here");
            if (sc.Status != ServiceControllerStatus.Running)

Here is a command prompt alternative that is essentially same as the code:

sc query "Service Name Here"

Running customApp.exe logged into the server under the dedicated service account results in success. Running the above command prompt "sc query "Service Name Here" results in success when logged in as well. Running customApp.exe as a scheduled task started at a specified time without intervention while I'm logged in remotely to the server under the dedicated service account results in success.

Running customApp.exe as a scheduled task under any other condition results in failure. This is probably the part that confuses me the most. As said before, it succeeds as a scheduled tasks while I'm logged in remotely with the dedicated user account, but fails otherwise.

It is noteworthy that I'm not trying to start or stop a windows service. I've discovered that requires admin rights which I'm not interested in harnessing that kind of power. I'm a firm believer in running the application with the most minimalistic rights required to get the job done.

share|improve this question
up vote 1 down vote accepted

You will need to configure the Task Scheduler to run as a specific user. From within the Task Scheduler click on the Action drop down menu, then select "AT Service Account Configuration". Change this from system account to "Another User Account" then change it to the account which you want the commands to run under.

You'll probably want to specify an account which doesn't have to have the password be changed so that you don't have to reconfigure the task scheduler each time.

share|improve this answer
Just a minor correction, I think you mean Advanced instead of Action.This confuses me a little, but I'll tell the system admins to give it a go since it could alleviate the problem. I'm confused because Microsoft claims that schedtasks.exe was created to replace at.exe, yet shedtasks.exe is dependent on at.exe still? – Sn3akyP3t3 Aug 24 '11 at 17:06
On my machines (Windows 7 and Windows Server 2008 R2) the drop down is labeled "Action". I don't have anything called schedtasks.exe on my machines. – mrdenny Aug 24 '11 at 17:30
My bad, its schtasks not schedtasks. In the help command prompt output it states that it is the replacement for at.exe. SCHTASKS /parameter [arguments] Description: Enables an administrator to create, delete, query, change, run and end scheduled tasks on a local or remote system. Replaces AT.exe. – Sn3akyP3t3 Aug 24 '11 at 18:47
If it still uses the same task scheduler, then it still uses the same account to run everything. All the AT Service Account Configuration does is configure what account the scheduler is running under. – mrdenny Aug 24 '11 at 18:48
Understood, I believe this is the answer. The last thing I don't understand is why only one task scheduler is allowed to exist. That makes it difficult for anyone that is trying to create a service account to cover all necessary permissions for all the different scheduled tasks on the server. This may only be a problem for server 2003 and not task scheduler 2.0 found in OSs beyond server 2003. – Sn3akyP3t3 Aug 24 '11 at 19:12

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.