Scheduled Tasks in a 2003 R2 Cluster
2 Windows Server 2003 R2 Enterprise Edition in an Active/Passive cluster
Microsoft Cluster Version 5
I've created a series of jobs with the following script:
I've scrubbed this code by entering %xxx% type variables for purposes of viewing the script without the parameters I actually entered.
The script seems to work fine as far as creating the scheduled task type resource.
The jobs also fail-over successfully between nodes.
The problem seems to be the credentials under which the job executes, the job being a *.CMD script that executes every 5 minutes (purposefully).
If I look at the scheduled tasks folder on each node, the jobs will only appear on the active node. Now I can open the properties of these tasks in Task Scheduler and set the credentials and the jobs will run.
Doing a failover the jobs disappear from Server1 and appear on Server2, however the credentials revert to NT Authority and the job fails. I changed the credentials, this time on Server2 and the jobs succeed again. Fail-over again and the credentials are once again gone.
How can I set these jobs to use specific credentials?
Microsoft Cluster Version 5
I've created a series of jobs with the following script:
cluster /cluster:%clustername% res "%Taskname%" /create /group:"Scheduled Tasks" /type:"Volume Shadow Copy Service Task"
cluster /cluster:%clustername% res "%Taskname%" /priv ApplicationName="cmd.exe"
cluster /cluster:%clustername% res "%Taskname%" /priv ApplicationParams="/c %path-to-cmdfile%"
cluster /cluster:%clustername% res "%Taskname%" /priv CurrentDirectory="%WorkingDirectory%"
cluster /cluster:%clustername% res "%Taskname%" /prop Description="%Comments%"
cluster /cluster:%clustername% res "%Taskname%" /prop RestartAction=1
cluster /cluster:%clustername% res "%Taskname%" /OffI've scrubbed this code by entering %xxx% type variables for purposes of viewing the script without the parameters I actually entered.
The script seems to work fine as far as creating the scheduled task type resource.
The jobs also fail-over successfully between nodes.
The problem seems to be the credentials under which the job executes, the job being a *.CMD script that executes every 5 minutes (purposefully).
If I look at the scheduled tasks folder on each node, the jobs will only appear on the active node. Now I can open the properties of these tasks in Task Scheduler and set the credentials and the jobs will run.
Doing a failover the jobs disappear from Server1 and appear on Server2, however the credentials revert to NT Authority and the job fails. I changed the credentials, this time on Server2 and the jobs succeed again. Fail-over again and the credentials are once again gone.
How can I set these jobs to use specific credentials?
Paul MacDonald
Is it not possible to create the job/set the credentials in the Task Scheduler itself? The permissions would surely persist then...
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
paulmacd: If I generate the tasks in the Task Scheduler the tasks will not fail over because they are not clustered resources.
ryanmccauley: if I am using the SQL Agent does this allow me to run non SQL tasks such as launching a CMD script or powershell script? And schedule it?
ryanmccauley: if I am using the SQL Agent does this allow me to run non SQL tasks such as launching a CMD script or powershell script? And schedule it?
The schedule is handled by the clustered SQL Agent process, so as long as the Agent is running, you can schedule the tasks on any frequency you wish - the Agent is really flexible in what it allows.
Also, in addition to SQL tasks, you can run OS commands, Powershell scripts, and anything you could otherwise run from a command line. By default, it runs as the user who owns the SQL Agent process, but you can configure proxy users in the agent and have your jobs run as one of those, so you can use any credentials you want.
Also, in addition to SQL tasks, you can run OS commands, Powershell scripts, and anything you could otherwise run from a command line. By default, it runs as the user who owns the SQL Agent process, but you can configure proxy users in the agent and have your jobs run as one of those, so you can use any credentials you want.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thank you I need to look into how I can implement both of these and if they offer all the options I require. I will endevor to get back to you both soon.