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 have a simple executable to run as a scheduled task on some Windows Server 2008 R2. The executable downloads a file from a couple of locations, then writes the time to download the files to a SQL database.

The problem I am having is that when I run the EXE using my account, it works absolutely fine.

When I run it as an account set up specially for use with this scheduled task the task fails. It manages to download the files ok, but fails when trying to write to the database. The user used to write to the database is hard coded within the EXE.

My account is a Domain Admin, whereas the account to run the task as is not. I am trying to figure out which of the Security Settings in Group or Local Policy might be missing, or if their is something else.

The EXE throws an error message:

System.ArguementOutOfRangeException: Index was out of range.  
Must be non-negative and less than the size of the collection.  
Parameter name:index

This is also logged in the Appication Windows log as an Unhandled Exception for the .Net app.

Both the developer and I suspect this is related to the Security Settings on the server. The account in question is already added to the Allow log on locally and Log on as a batch job. There are SO many options, millions of permutations, that it will take ages to figure out what is correct.

If I set the account as a Domain Admin then it works, but I don't like just setting things to the equivalent of root rather than figuring out the appropriate security level.

Does anyone recognise this specific issue, or have any pointers for how to figure out which security settings need changing?

share|improve this question
Does the user the exe uses to connect to your SQL database have permissions? It's likely related to a permissions issue between that and your SQL server. – Nathan C May 23 '13 at 15:19
There is a hard coded SQL server account in the EXE that has the permission to write to the database. This is separate from the AD user used to run the scheduled task. When the executable is run as an AD Domain Admin, it works, when it is run as a normal user, it doesn't. Are you suggesting that the AD user the task is run as has a bearing on whether the exe can talk to SQL? – dunxd May 23 '13 at 15:24
I would toss this app in a debugger and find out what line throws the exception. You can probably reproduce it by running the app as a non-admin from within the developer program itself (assuming you're using Visual Studio, just run it as a different account). If SQL Server has AD integration, then domain admins by default have superuser-level access to the database. – Nathan C May 23 '13 at 15:26

Your Answer


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

Browse other questions tagged or ask your own question.