0

On Windows Server 2008 R2, one must specify a user for each scheduled task to run under.

We have a policy whereby each domain user must change their password every 30 days.

This creates a problem, as we have many scheduled tasks that need to run on a large number of servers. When the user associated with a given scheduled task's changes his/her password (as required every 30 days), the tasks all stop working (until you log in and change the password on the task).

We tried to run the scheduled tasks under the SYSTEM account but this did not work.

I have thought of creating a new account (SCHED_TASK) that can not log in interactively, is an administrator, and is exempted from the password change requirements.

This seems very much a "hack" to me. Is there a better way or a built in account of some sort that we should use?

What is the best practice in this instance?

SvrGuy
  • 1,002
  • 3
  • 16
  • 29
  • Wait. So, you can create an account that, because it has certain restrictions, can be exempted from your organization's password policy. Thus removing the problem with having to reset a crapload of task passwords. And you think that's a hack? That's using technology to cut through bureaucracy. Sounds like a win to me. Or you can split the difference - change the policy to say that accounts used for services and scheduled tasks must be changed once a quarter, or once a year, etc. Good mix of security and maintainability. – mfinni Aug 09 '10 at 18:59
  • I think of it as a hack because, it seems to me anyway, the #1 use of a scheduled task to perform the same actions, over and over again, no matter what indefinitely. I looked into it further and it turned out the SYSTEM account is the way to go. I just had to tweak SYSTEM permissions to enable the tasks to run et vollia -- success. – SvrGuy Aug 10 '10 at 00:17

3 Answers3

3

In AD you can set "Password Never Expires" (Account Tab) on the service account.

Chris S
  • 77,337
  • 11
  • 120
  • 212
  • 1
    and create your special accounts and maybe even servers under a new OU called "RESTRICTED" or similar. Block inheritance of GPOs to that OU and then set specific GPOs for that OU that you want for those RESTRICTED accounts. – TheCleaner Aug 10 '10 at 01:05
  • Also, we use _svc at the beginning of all our service accounts or special accounts like this. That way it is an easy AD search for all of these types of accounts. – TheCleaner Aug 10 '10 at 01:06
0

You should still be able to run it as SYSTEM. I have a few AT commands in a batch script for scheduled reboots and such. Just make sure that you "run them as administrator" or they will never run.

Tatas
  • 2,091
  • 1
  • 13
  • 19
0

Turns out SYSTEM account is the way to go. Another admin here had put some limits on the SYSTEM accounts that were stopping the processes from running. By removing these additional (not present out of the box) security settings everything now works fine.

And the SYSTEM account does not even have password, so it can't expire etc.

SvrGuy
  • 1,002
  • 3
  • 16
  • 29