Posted by Ken Werneburg Tech Marketing Twitter @vmKen
When you run a script on the SRM server during a failover, the credentials under which the script will execute is that of the SRM service. For example, if you have left the defaults when installing SRM, the SRM service likely runs as "Local System".
In order to change this credential for your script execution, the solution has always pretty much been to change the ID of the SRM service. This has some benefits and some drawbacks. The benefit is you can create a specific account for the service and tightly control its permissions, to avoid scripts running amok and clobbering things if you forget to close a bracket in the script or something like that. The drawback is that your entire SRM service has to run as this ID which can lead to further problems in terms of authentication, privileges to execute other things, and if you do the ID wrong you can accidentally shut down your SRM service.
Alex Fontana, one of our brilliant Solutions Architects at VMware and co-author of a book on Virtualizing Microsoft Tier 1 Applications came up with an excellent solution that avoids these pitfalls.
The solution is to run a command on the SRM server that executes a scheduled task instead of a script. The scheduled task is what then calls the script under its own credentials.
With this mechanism you can leave the credentials of the SRM service alone, and set permissions for each task that runs the script independently, giving you the freedom to run any script you want under any security context you want.
The process is to use schtasks as the command that runs on the SRM server, and have it call the task you have created with its permissions set as the userid you want.
First, create the command you want to execute as a scheduled task, within the server Server Manager under Configuration -> Task Scheduler:
Right-click on the Task Scheduler Library and choose "Create Task"
Set the user account you want the task to run as
Set the "Run with highest privileges" checkmark. This will allow the command to run without requiring approval if you're using an admin level account.
Please note, if you're using UAC make sure "User Account Control: Admin Approval Mode for built-in Administrator account" is disabled, or change "User Account Control: Behavior of elevation to prompt for the administrators" to allow elevation without prompting. Or turn off UAC. 🙂
Under the "Actions" of the scheduled task browse to the script you want to execute.
Personally I deselect any of the "Conditions" and ensure the the "Settings" tab includes "Allow task to be run on demand", but the details are of course specific to your use case.
Ultimately you will end up with a task that looks something like this:
Next, you create the command to execute on the SRM server.
At whichever step of your recovery plan you want the command to run, add the step. For example I might want to touch some log files with date stamps or whatever when a particular VM powers on, so I would add a post power on step to that VM.
Select the type as "Command on SRM server"
Name it appropriately
The content will be the execution of the scheduled task which is done by calling schtasks as follows:
schtask /run /TN "<whatever your task name is>"
It should look similar to the following. Make sure you put in quotes exactly what you named the task you created in the last step, otherwise the task will not be found.
The net result of this is that your SRM instance can run under any ID that is appropriate for your service, and you can have each script/command run with its own unique ID independently of the SRM service.
Enjoy your scripting, and many thanks to Alex Fontana for sharing his interesting work!
