In SRM 5 we have the same scripting capability we have had in the past – the ability to execute a script on the SRM console. Check out the blog about it here. It is still useful and correct information. However, we now have a new capability as well. We can now execute a script in a guest.
Lets see what it looks like. First, be in SRM, and access the Recovery Plans section. Now select the Virtual Machines tab. It should look something like below.
Notice on the far right we see Pre-power On Steps and Post-power On Steps columns (you may need to click on the image to see it all)? The Post has a command step labeled Date / Time Log – which is not there by default by something I added.
Now we highlight one of the virtual machines and use the blue button to edit it. You will see something like the screen below.
Note in the above screenshot we have 1 Step for Post Power On and none for Pre? You will normally have more steps in Post rather than Pre – remember pre means the VM is not running yet so hard to make changes inside of it. You can also see here were the script will process – SRM server or Guest. Guest means the script will process inside the VM.
You can use the Add button to add another step above, or you can use Edit to look at the existing one. If we highlight Date / Time Log as we see it above and use the Edit button we will see what we see below.
Here is another example where the script is not a batch file but a PowerShell script.
We can see above several important things. We can see that we can now in SRM 5 choose a Type that is a Command on Recovered VM or a Command on SRM server. You still also can do a prompt as well.
Executing something on the console of the recovery VM sounds easy and it is, but remember you will need to manage that script on that VM. It may be easier to hold the script on the SRM console and execute it from there – it can still impact the inside of the VM via things like PowerCLI – this may be a best practice kind of thing – create / edit / manage a script on each VM, or create / edit / manage a single script on the SRM console? Depends partly at least on your skills / knowledge and the needs of the situation.
Once you have this configured and you execute the plan, you will see in the history report the reference to this script.
Security and Scripts
The script that executes on the SRM console is executing under the rights of the account that is running the SRM service. You may have to change that to a different account depending on what your script does.
The script that executes on the VM is executed under the context of the account that is running VMware Tools. Again, that may need to be changed depending on what you are doing in the script.
Failback and Scripts
It is important to understand any scripts you run while failing over will run as well when you failback unless you modify or change them. This means you need to setup your script environment – whatever it is on both sides, as well as maintain the scripts in both places. The same script does not have to run in both directions but it will by default.
Conclusion
While in this example we have a batch file being executed you can really do what you need to do for scripting, I do mostly batch and PowerShell you can do something else. So long as it can actually run on the SRM console, or inside the guest you are good to go.
We have looked at how you can execute a script locally in a recovered VM or on the console of the SRM server. It is good that the method to do either of those is the same.
Update: 8/7/11 – thanks to the comments of Iwan, I thought I would add a little more. Since you have a script that can run both on the recovery side, and the protected side, sometimes it is important for the script to know which side it is running on. When a recovery plan is running SRM injects information into the environment. There is one variable called VM_VC_Host that can be used in your script to determine which vCenter host is part of the recovery. This will easily allow you to determine which side your script is processing on. Be sure to check the SRM 5.0 Admin guide to see the full list of variables you can work with.
