Tuesday, February 16, 2010

Who can run what, when?!

I am a big fan of encapsulation.  I like it in OO code and I like it in my operating system and applications where I can implement it.  What do I mean?  I mean I always run SQL Server and Agent under a user account rather than the 'Local Administrator' account.  I do this for IIS' application pools and I do it for scheduled jobs on the system.  Previously I posted a cleanup script and talked about how it was scheduled to run every Monday morning.  I pretty much left it at that, but it recently occurred to me that there was some struggle around making that happen without having administrative privileges on the server.

In our domain, or locally on a machine (as required), I create a standard non-privileged user account to run scheduled jobs under.  For the sake of this post we'll call that user "executioner."  Go create your executioner account now and open Scheduled Tasks.

If you created your own .vbs file to do cleanup work as I did you'll quickly learn that it works as described.  But who wants to run that script when they login every Monday morning?  Or what if it needs to run at 1:00 AM every night?  I don't know about you, but I want to be snugly in bed at 1:00 AM.  You can create the stub of a scheduled job simply by dragging your .vbs file onto the schedule tasks window.

Double click your newly scheduled task in the Scheduled Tasks window.  Change the username field from to "[{machine name}|{domain name}]\{account name}.  You did use Executioner, right?! ;)  If I created a local account mine would read:


And if I created a domain account it would read:


Change your schedule and click "OK."  You'll be prompted to enter "Executioner's" password.

All set?  Right click on your job and choose "Run."  It should fail.  :(  I guess that's no so bad.  It's what we want actually.

If you examine the filesystem  using filemon.exe from http://live.sysinternals.com you'll notice that Executioner is failing when trying to open cmd.exe.

Grant Read & Execute permissions to Executioner and try again.  Viola!  Now you have a mostly-non-privileged user account to run your local jobs.

1 comment: