Virtually Sober

If there is free booze and Virtualization; I'm there!

Tag Archives: Zerto

REST API changes in Zerto Virtual Replication 5.0 U3

Since my first post back in 2014, many of the example scripts that I’ve shared integrate with Zerto using their bolt-on REST APIs. After 4 years of stability, in 5.0 U3, Zerto changed the requirements of the authorization header to require the content type in addition to the session token as a “security” feature.

Unfortunately, this means that any Zerto script you have downloaded from my blog, customized, or written, needs to be edited to continue working after the upgrade. Without any modification, your REST API calls to Zerto won’t even give you an error, they will just return null. Pretty annoying huh? I’ll be honest in that I was completely livid when I found out. To me, this looks like a pointless change to fix a problem that didn’t exist while creating a heap more by how it is was implemented and communicated.

On top of this, the Zerto API documentation leaves a lot to be desired as it hasn’t even been updated (as of 06/25/17) to reflect the new requirements! But that’s why I’m here to help. So how do you go about fixing your Zerto scripts?

Read more of this post

See you next week at ZertoCON 2017!

Hi all,

Just a quick Friday update to say that I’ll be at ZertoCON next week as a blogger to catch up on all the latest things Zerto, attend some interesting sessions I have penciled in, and to catch the cool keynote from General Michael Hayden! And of course, there ain’t no party like a Zerto party! If you see me walking around feel free to grab me to talk about any scripts you have ideas for, as I’m always on the hunt for requests.

ZertoCON2017

If you haven’t already registered for the biggest virtualization event on the East Coast (are you crazy?!) then you still have time:

http://www.zerto.com/zertocon/

Tip: use the code ZHALF17 at checkout for a tasty last minute 50% discount.

Have a great weekend and hope to see you at ZertoCON 2017,

Joshua

Catching Ransomware infections with a Honeypot script & integration into Zerto Virtual Replication

Through my work at Zerto I’ve delivered multiple presentations and webinars on ransomware and how Zerto enables you to recover VMs, files and folders from seconds before the data was encrypted to minimize data loss and avoid having to pay a ransom. One question I’ve often been asked is how do I know what point in time my files were encrypted? And in one recent presentation a customer told me that their user didn’t tell IT until 3 days after the infection had occurred!

This got me thinking on how we could alert on this which led me to evaluate the different ransomware honeypot example scripts available online. These scripts validate a file placed on a user mapped share, where everyone has write permissions, against a gold or witness copy to catch the ransomware infection then perform a set of actions when found. In testing the multiple examples I struggled to find one that coped with the file itself being changed, I.E the extension changing, that ran consistently and none indicated this alert in the Zerto journal so I decided to write an example that did all of this and more. Read more of this post

Scripting a Recovery Plan

To protect VMs with Zerto they need to be placed into Virtual Protection Groups (VPGs) which are consistency groupings of VMs that are typically configured on a per application basis. A VM can only exist in 1 VPG at once, you can only failover the entire VPG and you can define the boot order of VMs inside each VPG.

A common request I receive is to specify a boot order between VPGs (a recovery plan) so that you can bring VPGs online in a specified order with time delays and pre/post failover scripts. A perfect use case is bringing Application 1 (I.E a Finance DB) online before Application 2 (I.E a CRM). You could work around this by placing all the VMs that form both applications in the same VPG, but this then removes the fidelity of failing over an individual application in the cases of logical failures. Another use case is running a site wide script that should only be initiated when failing over everything.

Based on this requirement I decided to create the Recovery Plan script. Read more of this post

Adding Zerto cmdlets to a script

In order to run Zerto cmdlets inside a script you have to add the snapin. This is easily done with the following command:

add-pssnapin Zerto.PS.Commands

Read more of this post

Selecting Zerto Checkpoints in PowerShell

When using Zerto PowerShell cmdlets it can be required to select a checkpoint (a point in time) in the journal of changes from which to perform an operation. The Zerto PowerShell cmdlets which require a checkpoint to be defined are:

Start-failovertest
Clone-vpg

A checkpoint is also required for the POST APIs “Performing a Failover of a Specified VPG” and “Test a VPG for Failing Over”. To select a checkpoint the following cmdlet is used:

get-checkpoints -virtualprotectiongroup WebApp1 -zvmip 192.168.0.116 -zvmport 9080 -username root -password Zerto123 -confirm:$false

Read more of this post

Scripting with Zerto Basics

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:

  1. PowerShell 3.0 installed (available here)
  2. Zerto PowerShell Cmdlets 3.1 onwards (available from the Zerto Self-Service Portal here)
  3. Zerto PowerShell Security configured (see below)
  4. vSphere PowerCLI 5.5 (available here)
  5. Remote signed scripts allowed to run by running PowerShell as admin then the below cmd:
    “set-executionpolicy remotesigned”
  6. 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”

Read more of this post