Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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

What's the best practice for setting up a scheduled job (like a software build) so that it's not tied to a single user?

Our situation is that we need to schedule a job that runs overnight on a Windows 7 box, and we want anyone in our group to make changes or restart the job as necessary (i.e. in case the owner is on vacation or out sick). I can make the files themselves accessible to multiple users, but the problem is the job itself. I'm guessing our security group would balk at a local account with a known password, and our group policy seems to not allow jobs that auto-log-in as a user.

share|improve this question

I think you should manage the two aspects separately, but you could solve it all with my first recommendation.

Restarting the job

You could make everyone who needs to be able to restart the job an administrator on the build box.

Making changes to the job

Keep your build scripts in version control and have your job check out the build scripts before each run. Then you can grant commit access to anyone who should be allowed to modify the build job.

share|improve this answer

If you're trying to do Software builds (as mentioned in the OP) check out a system designed for this fuctionality such as CruiseControl.Net ( or Hudson. These will even provide nice easy restart functionality.

If you're doing software dev and don't have a Source Control system, get one NOW!!! CVS, SVN and Git are all relatively simple to use source control systems that are open source and freely available.

share|improve this answer

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.