To run PowerShell scripts with Zerto I recommend the following requirements be fulfilled, on the host running the scripts, as a best practice to cover running anything and everything:
- PowerShell 3.0 installed (available here)
- Zerto PowerShell Cmdlets 3.1 onwards (available from the Zerto Self-Service Portal here)
- Zerto PowerShell Security configured (see below)
- vSphere PowerCLI 5.5 (available here)
- Remote signed scripts allowed to run by running PowerShell as admin then the below cmd:
- Ignore invalid certificate option set ignore to speed up connect-viserver operations by running PowerShell as admin then the below cmd:
“set-PowerCLIConfiguration -invalidCertificateAction “ignore” -confirm:$false”
In order to use Zerto PowerShell cmdlets you need to configure a username and password for authentication on each Zerto Virtual Manager (ZVM) server using the following file:
C:\Program Files (x86)\Zerto\Zerto Virtual Replication\users.txt
The default username and password is administrator and password. To configure additional users it is required to generate a SHA-1 hash of the password then enter a new line with the username, a space using the tab key, then the SHA-1 hash of the password. The website below is a simple tool to create the hash:
Below is an example of a configured users.txt file:
After making changes to the user.txt it is required to restart the ZVM service.
In order to integrate scripts into Zerto operations they need to be specified as either pre-recovery or post-recovery scripts on a per Virtual Protection Group (VPG) basis, which you can see below:
The script is specified in “Command to run” and will be run on the target site ZVM Windows server. If the same script is required for Failback then it should be placed with the same name and folder structure in the source site ZVM also.
Any script specified will run for all 3 Zerto operations of Move, Failover and Failover Test. This means that you should use a logical filter script in front of your desired script to handle when and when not to run the script. Otherwise you could perform Failover Test operation and a script that is only required for Failover is run in production. A great example is a script to automatically update companywide DNS servers after failover, which definitely shouldn’t be run when performing a failover test.
To create a logical filter it is required to pass parameters to a script and use a batch file to intercept and process them as per below:
By specifying the %ZertoOperation% it is possible control which scripts to run from the start.bat for Move, Failover or Failover Test. The %ZertoVPGName% allows the name of the VPG to be passed through to a PowerShell script so a separate script is not required for each VPG (if required). Below is an example of a start.bat file acting as a logical filter and passing the VPG name to the PowerShell scripts specified:
As you can see from the start.bat example, different PowerShell scripts can run depending on the operation. It is also possible to run different scripts depending on the operation being Failover or Failback by specifying a ZVM hostname check. I prefer to do this from within PowerShell, but to do this from within the batch file use:
“if %computername%==TargetZVMHostName c:\FailoverScriptToRun.ps1”
“if %computername%==SourceZVMHostName c:\FailbackScriptToRun.ps1”
For performing the same operation in PowerShell use:
Now that we have covered the basics you can start to think about what you’d possibly like to automate with Zerto scripting. In subsequent posts in this series I am going to give examples and explain the logic behind each.
Not all examples will be run as part of failover operations. Many scripts can be run independently for extending the functionality of Zerto, but they will still have the same basic requirements as above. Happy scripting,