ensuredr 2.0.1 · 3 license to use and incorporate into the services any suggestion, enhancement...

EnsureDR 2.0.1.0

User Guide Document revision 1.0

1

User license agreement

EnsureDR terms of use

EnsureDR® is disaster-recovery industry-leading software for ensure high availability. This agreement terms apply to

full license, beta license or trial license.

You should carefully read the following terms and conditions. Your purchase or use of our software implies that you

have read and accepted these terms and conditions. The terms "you", "your", "user", or "users" refer to anyone

accessing our services or site for any reason.

This is a legal agreement between you ("you" or "licensee") and EnsureDR Corporation and its affiliated entities

("licensor"). Before you choose the "I accept the agreement" button at the bottom of this window or use this

software, carefully read the terms and conditions of this agreement.

By choosing the "I agree" button you are (1) representing that you are over the age of 18 and have the capacity and

authority to bind yourself and your employer, as applicable, to the terms of this agreement; and (2) consenting on

behalf of yourself and/or as an authorized representative of your employer / company, as applicable, to be bound by

this agreement. If you do not agree to all of the terms and conditions of this agreement, or do not represent the

foregoing, choose the "I do not agree" button, in which case you may not download, install or use the software.

If you register on our website for a free trial, we will make one or more services available to you on a trial basis free of

charge until the earlier of (a) the end of the free trial period for which you registered to use the applicable service(s),

or (b) the start date of any purchased service subscriptions ordered by you for such service(s). Additional trial terms

and conditions may appear on the trial registration web page. Any such additional terms and conditions are

incorporated into this agreement by reference and are legally binding.

Any data you enter into the services, and any customizations made to the services by or for you, during your free trial

will be permanently lost unless you purchase a subscription to the same services as those covered by the trial,

purchase upgraded services, or export such data, before the end of the trial period. You cannot transfer data entered

or customizations made during the free trial to a service that would be a downgrade from that covered by the trial,

therefore, if you purchase a service that would be a downgrade from that covered by the trial, you must export your

data before the end of the trial period or your data will be permanently lost. During the free trial the services are

provided “as-is” without any warranty. Please review the user guide during the trial period so that you become

familiar with the features and functions of the services before you make your purchase.

Your use of this site to download any licensor evaluation software is your authorization to licensor to contact you

regarding your use of the software. Any use of the software other than pursuant to the terms of this agreement is a

violation of U.S. And international copyright laws and conventions.

License grant this agreement grants licensee a limited, personal, non-transferable, non-exclusive, limited right to use

one copy of the software programs available for download at this site (the "software") in object code form on a single

computer at a single location for the sole purpose of evaluating the software for purchase. "software" shall also

include any related documentation and other material or information provided by licensor. As a condition to receiving

the licenses granted in this agreement, licensee agrees not to (and not to permit any third party to): (a) use the

software for general production use; (b) rent, lease, distribute, sublicense, timeshare, assign, transfer, or otherwise

permit access to the software by any third party; (c) reverse engineer, disassemble, or decompile the software, in

whole or in part, except to the extent required by law to obtain interoperability with other independently created

software; (d) modify or translate the software; or (e) create derivative works based on the software.

Ownership of software licensor retains all title, copyright and other proprietary rights in the software. Licensee does

not acquire any rights, express or implied, in the software, other than those specified in this agreement.

2

If you downloaded the software and use this software you are agreeing to comply with and be bound by the following

terms and conditions of use, which together with our privacy policy govern company’s relationship with you in

relation to this software. The term ‘company’ or ‘us’ or ‘we’ refers to the owner of the software whose registered

office is your business address. The term ‘you’ refers to the user or viewer of our software. The use of this software is

subject to the following terms of use:

- The content and the use of the software is for your general information and use only. It is subject to change without

notice.

- Neither we nor any third parties provide any warranty or guarantee as to the accuracy, timeliness, performance,

completeness or suitability of the information and materials found or offered on this software for any particular

purpose. You acknowledge that such information and materials may contain inaccuracies or errors and we expressly

exclude liability for any such inaccuracies or errors to the fullest extent permitted by law.

- Your use of any information or materials on this software is entirely at your own risk, for which we shall not be liable.

It shall be your own responsibility to ensure that any products, services or information available through this software

meet your specific requirements.

- This software contains material, which is owned by or licensed to us. This material includes, but is not limited to, the

design, layout, look, appearance and graphics. Reproduction is prohibited other than in accordance with the copyright

notice, which forms part of these terms and conditions.

- All trademarks reproduced in this software which are not the property of, or licensed to, the operator are

acknowledged on the website.

- Unauthorized use of this software may give rise to a claim for damages and/or be a criminal offence.

- From time to time this software may also include links or OEM with other software’s.

We do not commit to make the services and content available to you pursuant to this agreement and the applicable

order forms. We don’t commit to provide our standard support for the purchased services to you at no additional

charge, and/or upgraded support if purchased. We will have no liability for any harm or damage arising out of your

use of the software or in connection with a service.

Exclusion of warranty the software is provided to licensee "as is" and is exclusive of any warranty, including, without

limitation, any warranties of merchantability, title, against infringement or fitness for a particular purpose, or any

other warranty, whether express or implied.. Limitation of liability in no event will licensor or its suppliers be liable to

licensee or any other person or entity for any incidental, indirect, special, multiple, punitive, or consequential

damages, arising out of or relating to the software, including without limitation, loss of profits, damage to personal

property (including data), harm any other third party software, network, cost of cover or any other similar damages or

loss, regardless of the form of action, in contract or in tort (including negligence), even if licensor or its suppliers have

been advised of the possibility of such damages. Licensor' liability for any and all damages that might arise out of or

relate to the software or this agreement, regardless of the form of action, will in no event exceed five hundred dollars

($500).

Subject to the limited rights expressly granted hereunder, we reserve all right, title and interest in and to the services

and content, including all of our related intellectual property rights. No rights are granted to you hereunder other than

as expressly set forth herein. We grant to you a worldwide, limited-term license, under our applicable intellectual

property rights and licenses, to use content acquired by you pursuant to order forms, subject to those order forms,

this agreement and the documentation. 7.3. License by you to host your data and applications. You grant us and our

resellers a worldwide, limited term license to host, copy, transmit and display your data, and any non-EnsureDR

applications and program code created by or for you using a service, as necessary for us to provide the services in

accordance with this agreement. Subject to the limited licenses granted herein, we acquire no right, title or interest

from you or your licensors under this agreement in or to your data or any non-EnsureDR application or program code.

License by you to use feedback: you grant to us and our resellers a worldwide, perpetual, irrevocable, royalty-free

3

license to use and incorporate into the services any suggestion, enhancement request, recommendation, correction or

other feedback provided by you or users relating to the operation of the services.

This agreement constitutes the entire agreement of the parties concerning its subject matter and supersedes any and

all prior or contemporaneous, written or oral negotiations, correspondence, understandings and agreements between

the parties respecting the subject matter of this agreement. No amendment to this agreement will be binding unless

evidenced by a writing signed by both parties. The failure of any party to enforce any of the provisions hereof shall not

be construed to be a waiver of the right of such party thereafter to enforce such provisions.

4

Table of content

1. Introduction ......................................................................................................................................... 6

2. Terminology ......................................................................................................................................... 7

3. EnsureDR main concepts ...................................................................................................................... 8

4. Supported Products and Scenarios ....................................................................................................... 9

4.1. Requirements common to all scenarios ...........................................................................................12

4.2. Requirements for Double-Take replication ......................................................................................14

4.3. Requirements for VMware for Double-Take ....................................................................................14

4.4. Requirements for Hyper-V hosts .....................................................................................................14

4.5. Requirements for Hyper-V Replica ...................................................................................................15

4.6. Requirement for VMware SRM ........................................................................................................15

4.7. Requirement for Zerto ....................................................................................................................16

4.8. Firewall requirements for tests........................................................................................................16

5. Installation and initial setup ................................................................................................................17

6. License Management ..........................................................................................................................21

7. Preparing for test failover ...................................................................................................................22

7.1. Host networking ..............................................................................................................................22

7.2. Guest networking ............................................................................................................................22

7.3. Guest Network Name and VM Display Name ...................................................................................23

7.4. Special network considerations .......................................................................................................23

7.4.1. VMware DV switch ......................................................................................................................23

7.4.2. DC or DNS are not present in auto test ........................................................................................24

7.4.3. IP is changing in DR site ...............................................................................................................24

7.4.4. Target DR in deferent segment than source .................................................................................25

7.4.5. EDRC is in deferent segment then source ....................................................................................26

7.4.6. Target DR in deferent segment than source and EDRC is in deferent segment then source ..........26

7.5. Windows Update on Guests ............................................................................................................26

7.6. Preparing the EDRC .........................................................................................................................26

7.7. Not using EDRC ...............................................................................................................................27

7.8. Managing snapshots .......................................................................................................................27

7.9. Preparing for Double-Take ..............................................................................................................27

7.10. Preparing for VMware for Double-Take .......................................................................................28

7.11. Preparing for Zero ZCM ...............................................................................................................28

8. Using EnsureDR ...................................................................................................................................29

5

8.1. Basic Configuration .........................................................................................................................29

8.1.1. Using the Getting Started Wizard ................................................................................................30

8.1.2. Using the console ........................................................................................................................30

8.2. Advanced Configuration ..................................................................................................................41

8.3. Using EnsureDR Job Management ..................................................................................................43

9. Performing a test failover ....................................................................................................................45

9.1. Summary report section ..................................................................................................................46

9.2. Servers detailed report section ........................................................................................................47

10. Performing an emergency live failover ............................................................................................49

11. Passwords .......................................................................................................................................49

12. Job1.ini Reference ...........................................................................................................................50

13. Command line options ....................................................................................................................59

6

1. Introduction

Most businesses today heavily rely on their IT infrastructures for maintaining their internal processes and

the relationships with customers and partners. To ensure the continuity of the business, virtualization and

replication technologies are widely used. However, it may happen that, in the event of a malfunctioning of

a single server or an entire datacenter, the replicated resources are found not ready to service the business

requests: servers cannot start, applications cannot run properly, data are corrupted, and so on.

EnsureDR helps make sure that the servers that are replicated to a Disaster Recovery site will work in an

actual disaster scenario. EnsureDR automatically tests the replicated servers in the DR site in an isolated

environment. By reading the report that is periodically sent to their mailboxes, the IT staff members can

easily detect and proactively solve problems that could prevent an actual DR process to fully succeed.

Moreover, should an actual disaster occur, EnsureDR is able to perform an actual fail over to the DR site,

with the same settings configured for test failover.

EnsureDR works with some of the most common virtualization and replication technologies: VMware ESX,

Hyper-V and Double-Take Availability. The Supported Products and Scenarios section of this document

contains details on the use of these technologies.

NOTE: This document is not intended as a complete guide for implementing supported technologies. Please

refer to online documentation and media published by vendors to obtain guidance. Also it is strongly

recommended that a certified reseller or integrator is contacted before starting the installation to make

sure all works smoothly.

7

2. Terminology

Please refer to this section to find explanation of technical terms and acronyms used in this guide.

Bubble Network An isolated network in the DR site on the host server not connected to any physical network. It prevents duplication of IP address and network names while doing test to the DR environment.

Disaster Recovery (DR)

A planned and structured process that is executed when some critical resources in the main site are not available due to the occurrence of an unpredictable, harmful event.

Disaster Recovery Site (DR site) A secondary site where the organization replicates the most critical IT resources. If the main datacenter is unavailable, the disaster recovery process starts those resources to ensure business continuity.

Double-Take Availability Replication solution that replicates servers from production data center to DR site.

EnsureDR Controller (EDRC) A virtualized server that helps EnsureDR to connect to isolated servers in test DR environment.

Hyper-V Replica Microsoft virtual machine replication solution that protect servers running on a Hyper-V host in production by replicating them to another Hyper-V host in a DR site.

Recovery Time Objective (RTO) The amount of time it takes to the DR site to be fully functional after a failover.

SRM Site Recovery Manager – Vmware DR solution for Storage base replication or VSphere replication

Test Fail Over A process that fails over the replica servers in the DR site in the Bubble Network to ensure that they are fully functional.

Undo Fail Over Undoing the Fail Over of servers in the DR site and returning them to replication and protection

vNetwork Distributed Switch (vDS) A VMware virtual switch that is centrally configured in vCenter. Only vSphere Enterprise Plus supports the vNetwork Distributed Switch.

VRA Target server used by Double-Take that receives the replication data from source servers and store it to the target data store at ESX or local disk in Hyper-V. It acts as a proxy server. Used in Double-Take jobs such as Full server to ESX or Full server to Hyper-V.

VSphere Replication VMware replication solution between ESXi servers to protect VM servers between sites

Zerto Replication solution for VMware / Hyper-V infrastructures that replicate VMs to DR site.

8

3. EnsureDR main concepts

EnsureDR typical scenario is comprised of a main (production) site that contains physical or virtual servers

that are critical for the business, and a DR site those servers are replicated to. The purpose of EnsureDR is

to ensure that the replicated resources are consistent and always ready in the event an actual disaster

occurs.

When running a test DR, EnsureDR takes care of the following activities:

1) Connects one or more replica VMs to a dedicated, isolated network (the “bubble”). This ensures

that tests don’t impact the production network in any way

2) Starts the VMs

3) Performs a selected set of checks on the running VMs

4) Optionally takes a snapshot of the VMs that passed the test

5) Stops the VMs and cleans up the environment

6) Generates and sends to a defined list of email addresses a report with detailed results

EnsureDR can perform four kinds of test:

Test Explanation

Power On This is the most basic and fundamental test. It checks if the replica VM can start. A successful test ensures that the hardware, the virtualization platform and the VM are not corrupted.

Network Test This test checks if the VM is reachable from the network and/or it can reach other computers on the network. A successful test ensures that the virtual NIC and its IP configuration are not corrupted.

Service Test This test checks if a selected service is able to start at boot. A successful test ensures that the service binaries and configuration are not corrupted.

Custom Test This command-line based test runs a command on the target server. Output from the command is searched for the occurrence of a word or phrase. Test is successful if the specified word or phrase is contained in command output.

In the simplest scenario, the same set of tests is performed on each VM selected for DR test. An advanced

configuration is available to specify granular test settings on each VM.

Network, Service and Custom tests require a dedicated virtual server, called EnsureDR Controller (EDRC), in

the DR site.

The report generated by EnsureDR includes a summary result of the test and, for each VM tested, the result

of each test performed, with details of the detected errors (if any).

9

4. Supported Products and Scenarios

EnsureDR supports the following replication scenarios:

Source Target Replication Technology Double-Take Agent Required

Physical ESX Double-Take Source server, VRA Physical Hyper-V Double-Take Source server, Hyper-V host ESX ESX Double-Take Source VM, VRA ESX Hyper-V Double-Take Source VM, Hyper-V host Hyper-V ESX Double-Take Source VM, VRA Hyper-V Hyper-V Double-Take Source VM, target Hyper-V host Hyper-V Hyper-V Double-Take Source and target Hyper-V host Hyper-V Hyper-V Hyper-V Replica N/A ESX ESX VMware SRM via Storage

Replication N/A

ESX ESX VMware SRM VSphere replication

N/A

ESX ESX Zerto N/A Hyper-V Hyper-V Zerto N/A

The Double-Take with ESX target scenarios are depicted in the following diagram:

The replication target endpoint is the Double-Take VRA. The EnsureDR server instructs the EnsureDR

Controller, which is a VMware virtual machine, to perform the tests in the bubble network.

10

The Double-Take with Hyper-V target scenarios are depicted in the following diagram:

The replication target endpoint is the Hyper-V host. The EnsureDR server instructs the EnsureDR Controller,

which is a Hyper-V virtual machine, to perform the tests in the bubble network.

The Hyper-V replica scenario is depicted in the following diagram:

The replication target endpoint is the Hyper-V host. The EnsureDR server instructs the EnsureDR Controller,

which is a Hyper-V virtual machine, to perform the tests in the bubble network.

11

The VMware SRM scenario is depicted in the following diagram:

The replication done by storage and VMware SRM is the orchestrator of the fail over to DR. The EnsureDR

server instructs the EnsureDR Controller, which is a virtual machine, to perform the tests in the bubble

network.

Different requirements apply to each scenario. These requirements are detailed in the following sections.

The Zerto scenario is depicted in the following diagram:

The replication done by Zerto, host to host from VMware/Hyper-V to VMware/Hyper-V at the DR site. The

EnsureDR server instructs the EnsureDR Controller, which is a virtual machine, to perform the tests in the

bubble network.

Different requirements apply to each scenario. These requirements are detailed in the following sections.

12

4.1. Requirements common to all scenarios

EnsureDR has the following requirements:

Environment EnsureDR software can be installed on a physical or virtual machine. A dedicated VM running on the DR site is recommended. Another dedicated server, called “EnsureDR Controller” (EDRC) must run on the virtualization platform in the DR site. See requirements below.

Hardware 4GB RAM, 2 CPUs, 50 GB hard disk.

Operating System Any edition of Windows Server 2012 / 2016 or Windows Server 2012 R2 / 2016. Server Core installation is not supported. EnsureDR can be installed on a cluster node, but EnsureDR itself is not cluster-aware.

Additional software .Net Framework 3.5.

Network The EnsureDR server must be able to connect to all the virtualization hosts and physical servers involved in replication, and to the EnsureDR Controller. A static IP address is recommended on the network interface card used for the connection.

The EnsureDR Controller (EDRC) is a virtualized server required to perform network, service and custom

tests in every scenario. Requirements for EDRC are the following:

Environment EDRC is a dedicated VM hosted on the DR site, running on the same host/cluster as the VMs to be tested.

Operating System Any English edition of Windows Server 2012 R2 / 2016. Full or Server Core installation. Windows installed on C: drive.

VM tools Latest VMware VM tools or Hyper-V integration tools must be installed on the Windows.

Additional software Based on the virtualization platform, VMware Tools or Hyper-V Integration Services must be installed, updated and running.

Anti-Virus If Anti-Virus will be installed on EnsureDR console server, make sure to exclude EnsureDR.exe and EDRMS.exe in the Anti-Virus repository.

Network A single network interface card is required. The NIC is automatically connected to the production or test network during test operations. A static, routable IP address valid on the DR site network is required .

Other requirements File sharing enabled, including access to administrative shares (C$, Admin$). The C drive must be also shared with share name “C”, with full control to the local administrators group.

The source servers (both physical and virtual) have the following requirements:

Network If the DR site uses the same IP subnet as the main site, a static IP address is recommended. If dynamic IP addresses are used, a DHCP server must be available on the test DR network. This scenario is not recommended because tests may fail due to name resolution issues. To mitigate issues, a dynamic DNS server should also be available on the test DR network, and the DNS server list configured on the EDRC must contain its static address (if this

13

DNS server is among the VMs to be tested, it must be the first one to start. See the Test Group configuration in Advanced Settings). If the DR site uses a different IP subnet, the replication engine (Double-Take or Hyper-V Replica) must be configured to assign valid IP addresses to the replica VMs. Firewall exceptions are detailed in a specific section.

Administrative permissions If the servers to be tested belong to one or more Active Directory domains or forests, it is recommended that a DC for each domain and a Global Catalog server for each forest is included in the test job. In this scenario, credentials of a domain user with administrative privileges on each server are required to perform tests. Membership in Domain Admins group is recommended. If no DCs are included in the test job, or if not all servers are domain members, a local administrator with same name and password are required on each source server, on the EnsureDR server, on the EDRC, on the VRA (if VMware is used) and on Hyper-V hosts (if Hyper-V is used). This user’s credentials are required to perform tests. When running manual test form EnsureDR console, the logon user must have administrative permissions on target VRA ,VC or Hyper-V host.

14

4.2. Requirements for Double-Take replication

The following requirements apply to all scenarios using Double-Take Availability for replication.

Version 7.1 – 8.2

Job types Full server to ESX V to ESX Agentless Hyper-v

Source server for replication VMs on ESX VMs on Hyper-v Physical Machines Any Windows-based system supported by Double-Take Linux RH 7 / CentOS 7 / Suse 4

Target server VMware ESX 6.5 / 6.0 / 5.5 / 5.1 / 5.0.1 or Hyper-V on Windows Server 2012 R2 / 2016

Double-Take Console Must be installed on the EnsureDR server.

Firewall Port 902 must be open between the EDR server and the target ESX servers. Configure it in the VC, ESX server configuration, security profile.

4.3. Requirements for VMware for Double-Take

Version ESX 6.7 / 6.5 / 6.0 / 5.5 / 5.1 / 5.0.1

Network A test DR virtual switch must be created on target host/cluster. In a single target host scenario, the virtual switch is configured as internal (not bound to any physical network interface). In a cluster target scenario, each node requires a dedicated virtual switch connected to the same isolated network segment. The name of the virtual switches must be the same on all nodes. If more than one Double-Take VRA is used with multiple target hosts, a vCenter is required to configure vNetwork Distributed Switch (vDS).

Administrative permissions

Credentials with root access to all ESX are required. If multiple ESX are used, username and password must be the same.

4.4. Requirements for Hyper-V hosts

The following requirements apply to the Hyper-V target scenario, regardless of the replication technology

used.

Operating System Windows Server 2012 R2 / 2016

Cluster Failover Cluster and Highly Available Virtual Machines are supported as long as the failover cluster is configured following the recommendations and best practices from Microsoft.

Network A test DR virtual switch must be created on target host/cluster. In a single target host scenario, the virtual switch is configured as private. In a cluster target scenario, each node requires a dedicated external virtual switch connected to the same isolated network segment. The name of the external virtual switches must be the same on all nodes.

15


It is recommended that the Hyper-V hosts are configured as member server of the same domain. In this scenario EnsureDR must be run by a domain user with administrative privileges on EnsureDR server. In a workgroup or mixed (domain and workgroup) environment, a local administrator account with same name and password must be available on each host and on the EnsureDR server. If a Failover Cluster is included in target list, all targets must be joined to the same domain.

Other services Windows remote management and remote WMI must be enabled (they are enabled by default) and firewall exceptions must allow them.

4.5. Requirements for Hyper-V Replica

There are no special requirements for Hyper-V Replica.

The replication infrastructure must be configured following guidance and best practices from Microsoft.

Kerberos authentication in a domain environment is recommended.

4.6. Requirement for VMware SRM

Version ESX 6.7 / 6.5 / 6.0 / 5.5 / 5.1 / 5.0.1

VMware VC VMware VC on source and target environment full configured version 5.5 / 6.0 / 6.5 / 6.7

Storage Replication Source storage in production site replicating to target storage in DR site. RPO is not an issue and can very.

VMware SRM SRM configured with recovery plan and protection groups. Also recommended boot order and network bubble setup in SRM so when EnsureDR run the recovery plan the VMs will boot correctly to the right network.

Network A test DR virtual switch must be created on target host/cluster. In a single target host scenario, the virtual switch is configured as internal (not bound to any physical network interface). In a cluster target scenario, each node requires a dedicated virtual switch connected to the same isolated network segment. The name of the virtual switches must be the same on all nodes. In cluster with multiple target hosts, a vCenter is required to configure vNetwork Distributed Switch (vDS).


Credentials with VC administrative access is needed. EnsureDR server should be on same domain as target and source VC with admin privileges. If the environment is in workgroup, administrator user should have same password for all servers.

SRM Data Base SRM data base on top MS SQL or PostgerSQL. For MS SQL, a user name with admin rights. For PostgerSQL see document – "Necessary settings for PostgreSQL and EnsureDR" in pgSQLSRM directory for more information.

16

4.7. Requirement for Zerto

Version Zerto 5.0 / 5.1 / 5.5 / 6.0

Zerto Zerto configured with ZVM and VRA on source and target configured with VPG that are replicating and fully configured

VMware VC VMware VC on source and target environment full configured 5.5 / 6.0 / 6.5

VMM System Center Virtual Machine Manager 2012 R2 configured and accessible

Hyper-V Hyper-V on source and target version 2012 R2

VMware ESX ESXi on source and target sites version 5.5 / 6.0 / 6.5

Network A test DR virtual switch must be created on target host/cluster. In a single target host scenario, the virtual switch is configured as internal (not bound to any physical network interface). In a cluster target scenario, each node requires a dedicated virtual switch connected to the same isolated network segment. The name of the virtual switches must be the same on all nodes. In cluster with multiple target hosts, a vCenter is required to configure vNetwork Distributed Switch (vDS).


Credentials with VC administrative access is needed. EnsureDR server should be on same domain as target and source VC with admin privileges. If the environment is in workgroup, administrator user should have same password for all servers.

4.8. Firewall requirements for tests

If Windows Firewall or other firewall software is enabled on source servers, some exceptions are required

to perform the tests.

Test type Exceptions required

Power on None

Network ICMP in

Service At least one of the following:

• Remote WMI

• File sharing

• Windows Remote Management (only if PowerShell 2.0 or greater is installed. Must enabled with the Enable-PSRemoting cmdlet if not yet enabled)

Custom At least one of the following:

• File sharing

• Windows Remote Management (only if PowerShell 2.0 or greater is installed. Must enabled with the Enable-PSRemoting cmdlet if not yet enabled)

17

5. Installation and initial setup

Before starting EnsureDR setup, check if the system requirements are met and close all open applications.

When all prerequisites are met, the following procedure can be used to install EnsureDR:

1. To start setup, logon with a user with required privileges (Administrators group member on EDR Server, virtualization hosts, and EDRC if used). Double click on the EnsureDR-2.0.1.0.xxxx-setup.exe file (the version number in the file name may be different).

Note: during the setup process, there may popup few CMD windows. DO NOT CLOSE them since they preform setup tasks that are necessary for the setup process.

2. On the Welcome to the EnsureDR Setup Wizard page, click Next.

3. On the License Agreement page, read the terms of use and click Next.

4. On the Select Destination Location page, choose a different installation path if needed, ore leave

the default path. If you choose a different path, take note of it. Click Next.

18

5. On the Select Start Menu Folder click Next.

6. On the Select Additional Tasks select Create a Desktop Icon and click Next.

7. On the Ready to Install page click Install.

19

Note: Ensure in this part will scan for .net 3.5 and if don’t find it, it will try to install it from the internet. This installation process may take time up to 30 minutes.

9. On the Completing EnsureDR Setup Wizard click Finish.

10. If the Launch EnsureDR was selected in the last wizard page, EnsureDR starts. At first startup the system is checked for User Account Control (UAC) configuration. If UAC is enabled, the following dialog box is displayed:

Click Yes and restart the server. Logon again and double click the EnsureDR desktop icon.

11. The first time EnsureDR is started, this screen will be displayed:

20

Enter your license key and click Ok.

21

6. License Management

There are two kind of license: trial and full.

Trial license expires after a specified number of days. After expiration, the license key must be replaced in

order to run the product.

Full license has no expiration, and includes yearly maintenance.

EnsureDR licensing is per server to be tested, so the maximum number of servers that can be selected for

testing is limited by the license count. If this number is exceeded, the test will not start. This apply to all

EnsureDR jobs on EnsureDR server. For example, there is a EnsureDR license key for 10 servers. You can

create one job of 10 servers or 2 jobs of 5 each etc. You cannot create two jobs of 10 servers with this

license.

To see current licensing and change the license key, in the console toolbar click on the Manage License

button:

If you need to enter or replace the license key, type it in the Enter Your License box, and click OK:

22

7. Preparing for test failover

Some planning and preparation activities, both on physical and virtual environment, are recommended

before starting the first test with EnsureDR.

7.1. Host networking

To perform test DR without impacting the production network, a dedicated bubble network is required.

This network is implemented as a virtual network (or virtual switch) on the target virtualization platform.

If the target is comprised of a single standalone hosts, that host must be configured with a dedicated,

private virtual switch on which the VM to be tested will be connected.

If the target is a cluster, a virtual switch connected to an isolated physical network available on all nodes is

required on each node. This network must be configured so that each connected VM can communicate

with each other, but cannot reach production servers. The virtual switch must have the same name on all

the hosts.

The same requirements apply when multiple standalone hosts are used as target. A single EDRC is used to

test all VMs, and it must be able to reach the VMs on each node (both the local one and the remote ones).

If more than one VRA is used on multiple ESX target hosts (regardless they are cluster members or not),

vNetwork Distributed Switch (vDS) are needed. Please read the following articles in VMware Knowledge

Base for more information on how to configure a vDS:

• Overview of vNetwork Distributed Switch concepts (1010555)

• Private VLAN (PVLAN) on vNetwork Distributed Switch - Concept Overview (1010691)

7.2. Guest networking

To be sure that the tests performed on the DR network (bubble) are reliable, the environment in the bubble

should be as close to the production environment as possible.

Servers need valid IP addresses. The best way to ensure that addresses are valid is to configure static IP

address on each involved server.

Network tests also rely on name resolution. The replicated VMs and the EDRC should be able to resolve

network names of other servers in the bubble. Some tests also need authentication services to be available.

When servers belong to an Active Directory domain, it is recommended that a Domain Controller with DNS

role installed is replicated in the DR site and is included in the DR test job list. This server should be

configured to start before other servers by using the Group Test feature, described in the Advanced

Configuration section. All tested server and the EDRC should contain the IP address of this DC/DNS Server in

the list of DNS Server configured at the TCP/IP level. If server in the bubble belong to different domains, a

Domain Controller for each domain should be included in the test.

http://kb.vmware.com/selfservice/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=1010555

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1010691

23

Note: do not keep a Domain Controller on the isolated test network with the sole purpose of

authenticating the replicated servers during test failover. Domain Controllers must have persistent network

connection to each other. The isolated Domain Controller will eventually become out-of sync and fail to

authenticate servers and users. Moreover, if the out-of sync Domain Controller comes back to the

production network, replication issues may arise.

If the IP addresses of the servers are static, the hosts file on EDRC can be used for name resolution. This is

not the recommended approach, but may help when other name resolution mechanisms are not available

in the bubble.

7.3. Guest Network Name and VM Display Name

EnsureDR can check both the health of the virtualization environment and of the virtualized operating

system that runs in the VM. Often the same name is used to identify the virtual machine in its virtualization

environment (the VM display name) and the virtualized system on the network (Windows computer name,

or network name). As said before, a name resolution method that can resolve the network name must be

available in the DR network. If this requirement is not met, only the power on test can be successfully

performed. Other tests (network, service, custom) are going to fail.

The only exception to this requirement is when Hyper-V replica is used. In this scenario, if the source VM is

powered on and has Integration Services running, the network name can be automatically retrieved and

used to perform network, service, and custom tests, even if it is different from the VM display name. The

network name, if available, is displayed in the NetworkName column in the job list.

Moreover, EnsureDR for Double-Take requires that the VM display name is the same as it displayed at the

original Double-Take Job. For example, if Double-Take created a target server named "Server1_Replica",

EnsureDR will look for it. Do not changed it to "Server1_Replica (2)" or any other name.

7.4. Special network considerations

There are few special network configurations that need to be considered when implementing ENsureDR.

Please read carefully and implement as needed.

7.4.1. VMware DV switch

When replicating to DR site that got DV switch (VMware Distributed Virtual Switches) the target replica

VMs may configured to connect to it in live DR scenario. EnsureDR change the networking configuration

when doing tests and connect them to bubble test network and in the end of the test need to connect

them back. EnsureDR supports DV switches when writing the DV switch name in "VM Network PROD" or

"VM Network TEST" on main console. Also VC must be configured in "Target VC" button.

24

7.4.2. DC or DNS are not present in auto test

When creating an automatic test in EnsureDR without a DC or DNS part of the job, the network test may fail

since EnsureDR Controller won't be able to resolve the DNS name of the servers inside the bubble network.

When starting new job in or changing the servers to test in console, EnsureDR will present a question if the

user has a DC part of the test.

If not EnsureDR can automatically update the hosts file in the EnsureDR Controller allowing the network

test work successfully. The user can choose to make this change manually. User can manually ask EnsureDR

to automatically update the hosts file with servers selected by pressing the button "Update Hosts File" in

"DR Test Settings" in console.

7.4.3. IP is changing in DR site

In some cases, users decide to change the IP of target replica servers in DR site. This can cause EnsureDR

tests to fail since the EnsureDR controller won't find the servers in bubble network. When starting new job

in or changing the servers to test in console, EnsureDR will present a question if the user has a DC part of

the test. If not EnsureDR can automatically update the hosts file in the EnsureDR Controller with new IP

allowing the network test work successfully. The user can choose to make this change manually. User can

manually ask EnsureDR to automatically update the hosts file with servers selected by pressing the button

"Update Hosts File" in "DR Test Settings" in console.

25

7.4.4. Target DR in deferent segment than source

In some cases, users decide to change the IP and segment of target replica servers in DR site. This can cause

EnsureDR tests to fail since the EnsureDR controller won't find the servers in bubble network. When

starting new job or changing the servers to test in console, EnsureDR will present a question if the user

want to EnsureDR use a scondary IP setup in EDRC while the test runinig.

If user press YES, a window with the current IP and subnet

mask of the server the target IP and subnet mask of the

source server and allow the user to add a new IP in the

same segment of the target IP and subnet.

EnsureDR will insert the secondary IP and Segment to the

EnsureDR controller in the start of each test allowing it to

communicate with target replica servers in bubble network

that got IP in a different segment than original source. In

the end of the test EnsureDR will remove the secondary IP

to prevent any network issues when EnsureDR controller is

in production network. EnsureDR will also update the hosts

file with the target IP. This window will popup for any server

that marked for test and got defrent IP and segment on

target site. EnsureDR support multi secondary IP and

segment so you can enter defrent IP and Segment for each

defrent segment. As long as the target Network is flat EDRC

will be able to comunictae to all segments for the tests. If

target environment got a spesifc DNS server, it is

recomanded to add a new DNS server that can be used during the test for EnsureDR controller to resolve

any server is will connect to. In cases where the target server need to "return" to a specific VM network

that is not the EnsureDR network, setup at "VM Network" the current network so EnsureDR may return to

the "working" network (same as EnsureDR consol).

You can open this secondary IP window also manually by clicking "Secondary IP" in the EDRC settings in

EnsureDR console. EnsureDR support adding multi IP / Segment and DNS by seperating them with ";". Fro

exmaple, if you want to test few server with defrent IP addresses you can write in "IP Adress": x.x.x.x;y.y.y.y

and on "Subnet Mask": 255.2555.255.0;255.255.0.0. Same for DNS entry.

26

7.4.5. EDRC is in deferent segment then source

In some cases, the target DR site is in deferent segment than source segment but user keep replica servers

in same segment as source. By that EnsureDR controller being in target segment cannot communicate with

target replica server in test. When starting new job or changing the servers to test in console, EnsureDR will

present a question if the user want to EnsureDR use a scondary IP setup in EDRC while the test runinig. If

user press YES, a window with the current IP and subnet mask of the source server the target IP and subnet

mask of the EnsureDR controller and allow the user to add a new IP in the same segment of the target IP

and subnet. EnsureDR will insert the secondary IP and Segment to the EnsureDR controller in the start of

each test allowing it to communicate with target replica servers in bubble network that got IP in a different

segment than EnsureDR Controller. In the end of the test EnsureDR will remove the secondary IP to prevent

any network issues when EnsureDR controller is in production network. EnsureDR will also update the hosts

file with the target IP.

7.4.6. Target DR in deferent segment than source and EDRC is in

deferent segment then source

EnsureDR will present the secondary IP window only once.

7.5. Windows Update on Guests

Depending on the Windows Update settings on servers, it may happen that the failover test fails because

the server that starts in the bubble has pending updates that perform installation activities at reboot. In

this scenario the server may appear unresponsive and be reported as “failed” even if its overall state is

good. To avoid this issue, it is recommended that production servers are rebooted as soon as possible after

installing updates, so that there aren’t pending updates on replicated server when next test cycle is

performed.

7.6. Preparing the EDRC

To set up the EDRC, install Windows Server 2012 R2 / 2016 on a VM in the same host or cluster in which

tested VMs are replicated, and connect it to the production network. If an Active Directory domain is

available, join the server to the domain. If the EDRC is configured as a workgroup server, it is recommended

that the firewall is disabled.

Ensure that VMware tools or Hyper-V Integration Services are installed, up to date and enabled on the

EDRC.

If there are more than one host and if the network used for test (the bubble network) is shared among the

hosts, a single EDRC on a single host is required. If the networks are isolated on each host, an EDRC is

required on each host.

27

Create an empty EDRC folder in C: root drive and give everyone full control access in NTFS and Share. Share

C: drive ac "C" and give everyone full control access. Give access to domain admins group and local

administrator to hosts file at c:\windows\system32\dirvers\etc\host. Make sure you can access c:\EDRC

folder and hosts file from EnsureDR server before starting.

7.7. Not using EDRC

EDRC is used for testing the target VMs inside bubble network. It is recommended to always use EDRC as it

is the best way to communicate between the EnsureDR process and the target VMs. With it, EnsureDR can

connect to internal bubble network. In target Hyper-V environment, you must use EDRC. The only situation

where you can choose not to use EDRC is in environment where source and target are using VMware in

same version, all source VMs are with up to date VM tools and there is a security or other resone where

you cannot or will not want to use EDRC. When choosing not to use EDRC you can disable network change

for source and target since EnsureDR will communicate directly to VM via VMtools.

7.8. Managing snapshots

EnsureDR is able to create a recovery point (snapshot) on each VM that successfully passes all required

tests (In Zerto we refer to it as checkpoint). Only the most recent good snapshot of each VM is kept. In case

of actual DR scenario, the recovery point can be restored if the current state of the replica is not good.

To correctly manage snapshots, knowledge of snapshot implementation in the specific virtualization

platform used is required. Some general guidelines are the following:

Active Directory Domain Controllers should not be restored from a snapshot. Server operating systems

before Windows Server 2012 / 2016 are not able to deal with a DC that is restored to a previous state from

a snapshot, and the AD replication process can be severely corrupted. Restoring a DC based on Windows

Server 2012 / 2016 or Windows Server 2012 R2 / 2016 is possible, but not recommended.

Hyper-V has a built-in feature that creates hourly recovery points. If you use both the built-in feature and

EnsureDR snapshots, it is recommended that, in a DR scenario, automatically generated recovery point are

used first, and the EnsureDR snapshot is used only if other recovery points are not good. This requires

manual deletion of all other recovery points.

Double-Take manages its own snapshots to give a previous recovery point in time. This snapshot is

internally done in the VRA and focused on giving a solution for logical disaster such as viruses or DB

corruption. If failing over to a specific snapshot fails, then you may use the last known good EnsureDR

snapshot.

7.9. Preparing for Double-Take

If you use Double-Take as replication engine, you must be aware of the time needed to run mirror

checksum. At the end of each test session, an Undo Fail Over operation is performed. This causes the

Double-take jobs to run mirror checksum that may take some time (even days) depending on the size of

source machine, bandwidth etc. The best practice is to run EnsureDR manually the first time and measure

28

the time taken by the job to complete the undo. The days interval between two subsequent scheduled test

job should be greater that the measured time. Note that while mirror checksum is running, the job is in

warning state, and EnsureDR will not run on any Double-Take job that is in such a state. While in this state

the servers are not protected in real time so that, if a fail over to DR is needed, the data may not be current

and applications may not be consistent. Going back to a previous snapshot in VMware or Hyper-V made by

EnsureDR may solve the issue but it will make servers going back in time.

7.10. Preparing for VMware for Double-Take

If a VMware cluster is used as target, the VMs (replicated VMs, Double-Take VRA, EDRC) must be

configured so that they don’t move from a node to another with DSR or vMotion. Affinity rules can be used

to ensure that each VM is fixed on a selected host.

Multiple VRA can be specified. Make sure that this single host can hold up all VMs replicated to VRA on it in

test fail over.

7.11. Preparing for Zero ZCM

If you use Zerto in ZCM multi-tenant environment, you need to make sure you do not add EnsureDR server

or EDRC server to any domain. Leave them at workgroup. Set on both serves admin user with the same

name and password. Since EnsureDR doesn’t have any connection to source site, make sure not to add

"Zerto source" or "VC production" in "VPG settings" window. At "EDRC settings", add the user credentials

that you set up front for EDRC by pressing on "EDRC credentials". If you know that the source servers are in

deferent segment from EDRC or Zerto will change the IP of the servers to deferent segment after fail over,

enter a secondary IP for the EDRC at "Secondary IP" in EDRC settings. Create each schedule job for deferent

time slot since EnsureDR supports running only one job at the same time.

29

8. Using EnsureDR

EnsureDR requires some basic information to be ready for testing the DR process. Ensure that the following

information are available before starting:

Information required Explanation

Administrative credentials EnsureDR connects to host and guest machines using the specified credentials. No password is ever stored in clear text.

A list of target hosts This list is the starting point of the test DR process. All the replication jobs that have their target on one of the hosts in the list are available for testing.

The names of the production and test DR virtual switches

When the VM to be tested is prepared for testing, the NIC that is connected to the production network is moved to the test DR virtual switches.

The name of the VM used as EnsureDR Controller (EDRC)

Some testing scenarios require a dedicated VM that performs tests against other VMs. Both the VM (display) name and the network name (the one that is resolved in an IP address) of the VM are required.

8.1. Basic Configuration

EnsureDR configuration is managed by the Getting Started Wizard, by the console, or by editing a setting.ini

file. It is recommended that the initial configuration is done by using the Getting Started Wizard, and that

the setting.ini editing is performed only if the desired configuration cannot be fully obtained with the GUI

only. Details on the setting.ini file are available in the Passwords

All passwords are stored per job in job file. Passwords are encrypted in AES 256 key.

30

Job1.ini Reference at the end of this document.

8.1.1. Using the Getting Started Wizard

The Getting Started Wizard can be run just after the setup, or at any time by using a button in the toolbar

of the console:

It is the recommended tool to setup the first DR test. Since the settings available in the wizard are a subset

of those that are available in the console, further configuration may be done by using the console after the

first test is successful. Detailed explanation of the meaning of the settings is included in the following

section.

8.1.2. Using the console

After successful installation, EnsureDR will be usually available by double-clicking a desktop shortcut, if the

option to create a shortcut was selected during setup. If the shortcut is not available, it can be run by

pressing +R and typing the full path to the executable. The default path is:

C:\Program Files (x86)\EnsureDR\EnsureDR.exe

The main interface is comprised of three pages, which are shown in sequence:

• Main Settings

• DR Test Settings

• Mail and Scheduler

The first page shown is the Main Setting page:

31

The Main Settings page contains the following items:

DR Software solution (Also configured in the DR replication product wizard page)

The type of replication used. Currently supported options are:

• Double-Take - Target VMware

• Double-Take - Target Hyper-V

• Hyper-V Replica

Expected RTO in minutes Each test session duration is compared to this value. If it is greater, the test is reported as non-compliant.

User settings: Domain User and Password (Also configured in the Domain/Local Account Information wizard page)

The identity EDR will use to run the test jobs. Must be local administrator on source servers, EDRC, and also on the VRA or the Hyper-V host. To use a domain user, use the form: domain\user.

User settings: Host User and Password (Also configured in the VMware Account Information wizard page)

The identity EDR will use to connect to ESX. This setting only available when VMware is used as virtualization platform. When using VMware SRM enter the VC admin user credential here.

Target Host/Cluster (Also configured in the Target Environment wizard page)

The network name or IP address of one or more virtualization hosts or clusters that are configured as replication target (Hyper-V or VMware). If more than one target host or cluster is available, use a semicolon (;) to separate items in the list.

Target Cluster (Also configured in the Target Environment wizard page)

Used only with VMware virtualization. If the target is a cluster, select this checkbox. If it is a standalone host, leave it cleared.

Double-Take VRA (Also configured in the Target Environment wizard page)

Used only with Double-Take replication. Specify the network name or IP address of the Double-Take Virtual Recovery Appliance (VRA). More than one VRA name or address can be specified, separating them with a semicolon (;). Note that using multiple VRA will slow the start up of EnsureDR since it need to scan all of them for compatible jobs.

Enter VC (Double-Take for VMware only)

Click to enter the name or IP address of the vCenter and to select the type of credential (domain or host) used to access it. This setting is needed if vNetwork Distributed Switches are used in VMware. Chose the authentication method used in vCenter. Domain user credential or host user credential from the main console. Not applicable for SRM.

SRM Settings (SRM only) Click to enter the SRM details and choose the right SRM recovery plan to include in the Fail Over test. See next section for more information.

VPG Settings (Zerto only) Click to enter the Zerto VPG details and choose the right VPG to include in the Fail Over test. See next section for more information.

Change Network Depending on the network configuration in your DR site, a dedicated, isolated network (bubble) may be available for tests. If the VMs need to be connected to a test network, select Yes. If the default network configuration of the VM is ready for tests, select No.

VM Network PROD (Also configured in the Network Information wizard page)*

If Change Network is set to Yes, type the name of the virtual switch connected to the production networks. After test DR completed, replica VMs are connected to this switch to be ready for actual DR. The EDRC needs also to connect to this network. Type the name with correct capitalization.

32

VM Network TEST (Also configured in the Network Information wizard page)

If Change Network is set to Yes, type the name of the test DR virtual switch. Type the name with correct capitalization. Note: If the replication solution change to a bubble network automatically as part of its workflow, you can change this setting to "No" but you mast write the correct network name in order for EnsureDR to move the EDRC to this network for the tests. You can configure EnsureDR to change the network for the tested VMs to a deferent network then the one configured in the DR solution workflow. For example: VMware SRM recovery plan "A" configured to change the network to TEST-NET vswitch when run the test manually. You can setup here to change the network of the tested VMs in recovery plan "A" to TEST-EDR vswitch that was configure up front. When EnsureDR run the specific job, it will fail over for test VMware SRM recovery plan "A". When the Fail Over was finished, it will change for all VMs in the recovery plan at the DR site the network to TEST-EDR then start the tests.

DC Clone In domain environment, it is very important to include a DC in the test scenario since EnsureDR won't be able to do internal test to VMs in the domain without DC in the same network that could authenticate it. It is recommended to include a DC VM in the test scenario. If there no DC in the replication solution but there is a live DC in DR site (replicated via DC standard replication), use this setting. Click to add special treatment for DC that is not part of the replication. This setting will clone the DC in DR site during the job workflow, configure it to join the bubble network and then delete it in the end of the test. It won't be connected to the production or DR network to prevent "split brain". See next section for more information.

More Settings More settings such as: Company name for job order and reference Name of summery CSV result file Run this job always silently without presenting the console on start Show summery message at the end. Ask if to run when pressing on finish or start now. Record animation of servers boot up to show in HTML report. Amount of time to wait for servers to finish the boot (from the stage where the fail over was finished until EnsureDR start to do the actual tests).

* In some cases, such as in Zerto and VMware, in the recovery plan, VMs will get the bubble network from

the replication solution it self so there is no need to ask EnsureDR to that as well. So, changing the "VM

Network PROD" and VM Network TEST" to "No" will save time during the test.

IMPORTANT NOTE: Make sure to write the correct PROD network and TEST network so EnsureDR

Controller will know to which network to connect to test the VMs.

33

In case "VMware SRM" scenario is used, a recovery plan need to be choose. Press on "SRM Settings" button

to get in to VMware SRM settings.

In VMware SRM settings write the SRM production name/ip, then press "Update" to get the source SRM

Data Source and SRM Data Base automatically to console. If they not appear, write them manually. Write

the SRM DR name/ip and SRM Data Base port. For MS SQL, it is usually it is 1433. For PostgreSQL, it is

usually 5678.

Press "Scan Now" to get the recovery plan list. Then choose the recovery plan to include in the EnsureDR

job. You can change the boot order of the Recovery Plans in test by pressing on the value number and

change it manually to the order. If no Recovery Plan appear, try to check settings and the user credentials

(Host User in console) on: VC, SRM and SQL server.

Press ok to save settings.

34

In case "Zerto for VMware" or "Zerto for Hyper-V" scenario is used, a VPG need to be choose. Press on

"SRM Settings" button to get in to VMware SRM settings.

In "Zerto VPG settings" write the Zerto source ZVM production name/ip, Zerto target ZVM name/ip and

production VMM or VC (depends if this settings from VMware or Hyper-V infrastructure). Port should be

9669 always. Only ZVM target (Zerto Target) is mandatory.

Press "Scan Now" to get the VPG list. Then choose the VPG to include in the EnsureDR job. You can change

the boot order of the VPG in test by pressing on the value number and change it manually to the order. If

no VPG appear, try to check settings and the user credentials ("Host User" in console for VMware or "User

Name" for Hyper-V).

Press "ok" to save settings.

35

In a case where the DC is replicated to a live DC in the DR site, use this setting to clone the DC in DR to the

bubble network during the job workflow so EnsureDR can authenticate while doing the internal tests to the

replica VMs.

Mark the "Clone DC to test environment" to enable this functionality. Add the name/ip of the DC VM name

in the DR site Add the name/ip of the target host server that host the DC VM in the DR site.

For VMware, add the "Datasotre" name to export the VC to.

For Hyper-V, add the local DC VM host path to import the DC VM to. Add also the target UNC path to

import the VM DC to on deferent host. They can be both on same host or deferent hosts.

Press on "Check DC" to make sure all the settings are ok and there is enough disk space to clone the DC.

Press ok to save settings.

Note: the DC clone process will run only during the job workflow.

36

After the Main Settings page is complete, click Next to see the DR Test Settings page.

The DR Test Settings page is used to define the scope of the test. It contains the following items:

Do test DR EnsureDR will run Fail Over Test to the selected DR solution.

Perform Undo EnsureDR will run Undo/CleanUp to the selected DR solution when test will over.

Snapshot VMs Create a snapshot/checkpoint in the target environment if all test where ok to keep certified point it time to go back to if a live fail over go bad.

All Linux All tested VMs got Linux OS.

Linux credentials Configure user / password for Linux test. This user must have same name and password for all Linux tested servers. Also configure a server where EnsureDR will test the user and password to determine if they are correct.

Pre / Post scripts Click to setup main scripts that will need to run during the full workflow process. This script will run in specific points during the workflow to do specific custom task that will help determine a successful and better test. See next section for more information.

Test the VMs Do internal test to the VMs in this specific job or just run the process without testing them (will do Fail Over and Undo as configured in previous settings)

Power on A mandatory test where EnsureDR will test if the selected VMs where power on after Failing over to DR

Networking

Mark if you want to perform a ping to check if the replica VMs network is working. Select No if the network test is not needed.

37

Service

Mark and type the name of a service if you want to check the state of the service on the replica VM. The test is successful only if the service status is Running. Valid service names can be obtained with the sc query command in a Command Prompt session, or with the Get-Service cmdlet in a PowerShell session. If different services need to be tested on different servers, use the Advanced feature (see Advanced Configuration). Unmark if the service test is not needed.

Custom

If you want to check the output from a command executed on the replica VMs, mark and type the command. Try the command in a Command Prompt session to be sure that it works and to see which is the expected output. If different commands need to be executed on different servers, use the Advanced feature (see Advanced Configuration). Unmark if the custom test is not needed.

Custom Results If the Custom Command is specified, you need to type a word or phrase that is expected in the output to ensure that the command completed successfully. The text must be typed exactly as it appears in command output, except for case (the keyword is not case sensitive). The test is successful only if the text specified is included in command output. More than one keywords can be specified, separated by a semicolon (;). The test is successful if each keyword is found in command output.

AutoFix EnsureDR will try to fix failed test of VMs by trying the test again, start tested application services etc.

Use EDR Controller Check it when using EnsureDR Controller for the tests. It is highly recommended to always use EnsureDR Controller to prevent any unexpected errors in results after the VM tests. This VM is the gateway between the EnsureDR server and the rest of the tested servers in the bubble network. You may consider not using it when there is a security concern or you want to reduce this server from the end design. The only option not to use it is in environment with target VMware where all VMs tested got the latest VM tools.

Credentials Add user and password for authenticating with EDRC. Use this only if EDRC in workgroup environment and source VMs are in deferent domain. Also in case where user and password are deferent between EnsureDR server and EDRC.

2nd IP Add a secondary IP to EDRC. Use it when tested VMs got deferent IP then EDRC. The VMs may be in deferent segment or may change their IP after fail over.

Hosts file Click to update the local hosts file of the EDRC. This setting is used when there won't be any DNS in the DR test bubble network. During the test when EDRC will try to ping and connect to VMs the hosts file will help it resolve to IP addresses. You can choose it to automatically update hosts file, manually (it will open the hosts file in the EDRC server) or not to update at all.

Display Name (Also, configured in the EnsureDR Controller wizard page)

Type the name of the EnsureDR Controller VM as displayed in the virtualization management tool

38

Computer Name (Also, configured in the EnsureDR Controller wizard page)

Type the Windows computer name assigned to the EnsureDR Controller (this must be a name that can be resolved in the VM IP address).

Server List (Also, configured in the Server List wizard page)

This list contains all the replication jobs that have a target on one of the hosts specified in the Main Settings page, with details on the job state and configuration. Select one or more checkbox to perform tests on the related VM. Check the details in the various column to ensure that the correct servers are selected and the job health is Normal.

All… Click to check all the VMs. Click again to clear all the VMs.

Re-scan Click to reload the job list. This is useful if some replication job was added or if the state of some job has changed while EnsureDR was running.

Advanced Open the advanced interface (see Advanced Configuration).

General to all Click to extend the execution of tests defined in the DR test settings page to the VMs that are configured with Advanced settings. If not selected, only tests specified in the Advanced interface are performed on VMs with advanced configuration.

39

When the DR Test Setting page is complete, click Next. The Main and Scheduler page is displayed:

The Mail and Scheduler page contains the following settings:

Send Mail with report when finished

Select Yes if you want to send an e-mail with detailed results at the end of each test. Select No if the e-mail is not needed.

SMTP server Use Cloud when sending mail via Office365 or Gmail. Use Local when using local SMTP server such as Exchange.

Mail SMTP Host Type the name or IP address of a valid SMTP server that will be used to relay e-mail.

From Type the e-mail address to be specified as the sender of the message.

Mail to Type a semicolon separated list of e-mail address that will receive the message.

Mail User Name If the SMTP Host requires authentication, type the username for authentication.

Mail User Password If the SMTP Host requires authentication, type the password.

Mail Port Type the TCP port number used by the SMTP host to receive e-mail messages. Common ports are 25 and 587.

Test Mail Click to send a sample email with the above settings, so that they are validated.

Edit Mail Change mail settings such as: Edit the subject, Add more text to mail body and add a logo to summery PDF that send to user. Clean job history from EnsureDR data base for clean charts in report.

SMS Add a mobile number to send alert SMS to when job completed. Port 443 need to be open for EnsureDR to the internet.

Set schedule task for test Click Yes if you want to periodically perform an unattended test. Click No if you want to run tests manually.

40

Click Manual if you want to run the job manually only and ignore the schedule test. EnusreDR wont alert it in the report.

Set Start Date Select a day in which to begin scheduled tests.

Time to start test Select hour and minute in which to start the test.

Set Days Intervals between tests Specify how many days to wait after a test before performing a new test. You can choose Days, Weeks or Months to specify what the interval be. Days – one day interval, Week – 7 Days intervals, Months – 28 days interval. EnsureDR will multiply this amount with number in interval.

Note: If a schedule task of EnsureDR start while a process of EnsureDR is running, EnsureDR schedule task

will not start since EnsureDR can run only one process at a time. It will create a one-time schedule task to

start after 3h from the original time slot and then delete this one-time schedule task. It will do it twice. This

setting can be edited in job file. See

After the Mail and Scheduler page is complete, click Finish. You will be asked if you want to start a test, or

only save configuration data.

41

8.2. Advanced Configuration

The advanced configuration lets you define a custom Test Groups and granular test settings for specific

VMs. To display the advanced configuration interface, on the DR Test Setting page select one or more jobs

and click the Advanced button. The advanced configuration of the first selected job is displayed:

Advanced configuration is disabled by default. When advanced configuration is enabled for a VM, only tests

selected in the Advanced page are performed on that VM by default. Test that are not checked selected are

not performed.

To change this behavior, the General to all option in the Job List section of the DR Test Setting page can be

used. When the General to all checkbox is selected, tests that are not explicitly enabled in the Advanced

page are run using the setting defined in the DR Test Settings page.

Advanced Test – Select this option to enable advanced test to the VM in console.

Linux – By default EnsureDR configure to test Windows. Select this option to mark this VM as Linux so

EnsureDR my do the appropriate adaption for Linux test.

2nd Restart – EnsureDR will do a secondary restart before it starts the test for the specific server. Use this if

the specific VM got issue that usually are solved after secondary restart.

Primary – When VM mark as primary, EnsureDR will fail all the tests if this server fails. Also EnsureDR will

try to fix small issues automatically to prevent it to fail the test for all (same as marking "Auto fix" in general

or advanced test.

42

Auto Fix – EnsureDR will try troubleshoot common issues when tests fail for this VM.

Block - General to all – Blocks all tests that was configure on main console to this VM.

Test Group – Boot order for Double-Take and Hyper-V Replica. Run the test in order of test Group. Present

the servers sorted by groups.

Network – Ping to – run ping command from the current VM to target IP/name

Service – check specific service on local VM

Custom Command- run specific command or script. Can run scripts from network but make sure script are

available on bubble network in DR test.

Custom command results – the desired command result EnsureDR will look for to mark the test as

successful.

The following table describes the available setting for enabling and configuring advanced features:

Advanced Test Select Yes if you want to configure one or more advanced settings for the selected VM. Select No to use the setting configured in the DR Test Setting page.

Linux Mark this server as Linux. All test will be made as a Linux target.

Test Group Select a numeric value for the test group. The VMs with lower values will be tested first, the VMs with higher values will be tested later. Use this feature if there are dependencies among VMs. For example, a Domain Controller should start before any member servers; a Database server should start before any application servers that rely on it. This setting will enforce boot order for Double-Take and Hyper-V replica.

Use Default General Test Use the default test from main console as default for any test that was not configured in the advance console.

Pre script Run a script on target tested server before running any test.

Test Network – ping to Select Yes and type an IP address that you want the selected VM to ping (outgoing ping). The IP can belong to another VM in the bubble or, if external connectivity is available in the test DR network, any available address. The test will be successful if the VM receives a reply from the target.

43

Select No if you don’t want to test network, or if you want to test network with the setting defined in the DR Test Settings page.

Test Service Select Yes and type the name of a service if you want to check the state of a specific service on the selected VM. Select No if you don’t want to test a service on the selected VM, or if you want to test the service specified in the DR Test Settings page.

Test Custom Command Select Yes and type a prompt command if you want to run a specific custom command on the selected VM. Select No if you don’t want to run a command on the selected VM, or if you want to run the command specified in the DR Test Settings page.

Custom Command Results If the Test Custom Command is specified, you need to type a word or phrase that is expected in the output to ensure that the command completed successfully. The text must be typed exactly as it appears in command output. The test is successful only if the text specified is included in command output.

After configuring the advanced setting for the first VM in the list, click Next and configure subsequent VMs

if needed.

Click Exit and Save to return to the DR Test Settings page.

8.3. Using EnsureDR Job Management

The job management feature gives the ability to manage multiple sets of test configuration so that different

groups of servers can be tested with different schedules. The EnsureDR Job Management can be configured

from the main console toolbar. Furthermore, Job Management will start automatically each time the user

starts EnsureDR. In the job management, there are information such as Job name, Company, DR replication

tool used, number of servers in that job, last time the job run, next time the job will run, what wat the total

RTO for last run, how many servers tested ok last run and the product license key.

Click Manage Jobs to open the job configuration interface:

44

Job configuration is contained in .ini files. Job1.ini is the default setting file. New job settings can be created

by clicking the New button. Unused job settings can be deleted by selecting the file name and clicking

Delete. To load the settings from a file, select the file name and click OK or double click a job. If there are

more than one job in the list, the job selection interface will be show each time EnsureDR is started. Select

a job and click OK to load its settings. Each time a new job is created, it has no schedule run configured.

Since EnsureDR cannot run in multiple instances on the same server, schedules must be configured so that

test jobs don’t overlap. If a job is still running when a new job starts, the second one will fail. Jobs can be

run directly from the Job Management console by choosing a job and clicking Run Now. Last test result can

be open directly from the Job Management Console by choosing a job and clicking Last Result.

Only when there is one job to choose from, you can disable the option to prevent the Job Management

console from appearing when starting EnsureDR.

You can update the data of the jobs in the job management console by pressing on the sync button. It will

refresh the job list with information in the EnsureDR data base:

45

9. Performing a test failover

Before a test failover, always ensure that the all replication jobs are in good state. The value in the Health

column in job list should be Normal.

The test failover can be launched in the following ways:

• Interactively, by clicking Yes in the dialog box that appears when the Finish button is clicked in the

Mail and Scheduler page of the console.

• On a scheduled basis, by configuring the scheduled job in the Mail and Scheduler page of the

console.

• From a command prompt or a script, by using the command line syntax described in the

• Command line options section.

During the process, there will be a progress bar showing the workflow stat of the process.

If the Summary Message option in Main Setting is set to Yes, at the end of an interactive test the following

screen is displayed:

46

The test report can be viewed by clicking Show Results. The same report is attached to the email sent to

addresses configured in the Mail and Scheduler page of the console.

The report contains the following sections:

Summary report Includes:

• Total RTO

• Number of server that passed the test

• For each server, a graphical representation of the result of each test (Power On, Network, Service, Custom)

Servers detailed report Contains details for each server, including reason for failed tests

Detailed description of these sections follows.

9.1. Summary report section

The summary report contains:

• The total RTO compared with desired RTO

• The number of server that passed the test compared to the total number of tested servers

• The current schedule configuration, including next scheduled run time

• The current configuration of the snapshot feature

• A pie chart representing the number of good and failed tests

47

• A graph representing the number of good and bad servers over time

• Details of test results for each server and each enabled test

9.2. Servers detailed report section

48

• The server detailed report contains, for each server, the following details:

• Live Screenshot

• The test group

• The name of the target server

• The health of the replication job before testing

• The name or IP address of the virtualization host running the replica VM

• The type of the host

• The power on status after test failover

• The result of the network test (with error details, if any)

• The result of the service test (with error details, if any)

• The result of the custom test (with error details, if any)

• The result of the undo operation

49

10. Performing an emergency live failover

The ability to perform a live failover to the DR site can be useful if a fast and automated failover of the

servers is required due to an unpredicted and impairing problem occurred on the main site.

Server are started with the same setting used in test failover, including boot order, but are placed on the

production network instead of the bubble network. Servers in the main site that are still running and

reachable from the EnsureDR server are turned off before failing over.

Note: This feature support only Double-Take and Hyper-V replica.

To perform the live failover, open the Start screen and click the down arrow near the bottom left corner:

Locate the Emergency Live Failover icon and click it:

The live failover can also be run from the command line. Open a command prompt on the EnsureDR server

and run the following command:

"C:\Program Files (x86)\EnsureDR\EnsureDR.exe" /sosnow

If the path chosen during setup was different from the default one, adapt the command accordingly.

11. Passwords

All passwords are stored per job in job file. Passwords are encrypted in AES 256 key.

50

12. Job1.ini Reference

The Job1.ini file contains all settings for EnsureDR. Some of these settings cannot be seen or changed with

the GUI. All settings except passwords can be seen and changed by opening Setting.ini with an editor such

as Notepad. Password can be enter only using the EnsureDR console. The first time EnsureDR is run, the

GUI must be used to specify passwords. After that, EnsureDR can be run be in silent mode.

The meaning of the settings in Job1.ini is explained in the following table:

[Main] Main settings are the settings for the general operation of EnsureDR.

WorkingDir The directory where the program is installed.

TestCSVFile The name of the target file where results are being kept.

ChangeNetwork Change to DR network while testing: 1=yes, 2=no.

VMProdNetwork The name of the VM target production network. It is case sensitive.

TestDRNetwork The name of the VM test DR network. It is case sensitive.

HostServer Name or IP address of target host(s).

VC The name or IP address of a VCenter. Only relevant if using VMware ESX with vNetwork Distributed Switches on DR site.

VCCRD Authentication method for the VC. 1 for domain user and 2 for host user.

VRA The name on the target Double-Take VRA server(s).

SRMProd SRM server IP or Name at production site

SRMDR SRM server IP or Name at DR site

HostUser The name of the ESX administrator user. The default is root.

DomainUser The name of the domain user or local administrator user of the server that are replicated in DR.

EDRCUser The name of EDRC user. This setting is optional. Only if EDRC in deferent domain then source tested VM or in workgroup.

LinuxUser The name of the Linux user to use to connect to all Linux servers tested in DR

LinuxServerCrd The name or IP of a Linux server to check the Linux user and password input in console.

TargetHost Name or IP of target host (VMware / Hyper-V)

51

Silent This setting controls if EnsureDR will show the GUI or run unattended. 2 = Show GUi. 1 = Run unattended (same as running with the schd argument).

EndSummaryMsg 1=Show a summary message when finished, 0=don’t show message.

AskEachTimeToRun 1=If not running in silent mode, ask the user to confirm the start of the test, 0=don’t ask.

UpdateHostsEDRC EnsureDR update the EnsureDR Controller hosts file with the server to be tested so it can find them in bubble network. 1 to update, 0 not to update.

CustomerLogoFile Add full path to logo file for end report. Must be 200x100 pixels and in PNG format

SRMPlanName SRM recovery plan to scan and use when using VMware SRM workload. You can write few plans to manage, keep this rulls: each plan should be

with single dash, for example: 'Recover Plan1'. If you add more than one plan, seperate ech one with two line, for example: 'Recovery Plan1'||'Recovery Plan2'.

Put double qoute over the full parameter, for exapmle final to plans should look: "'Recovery Plan1'||'Recovery Plan2'". The order of test fail over is

by the order of the Recovery Plans from left to right. You can change the order manually by changing the order of the Plan Names.

SRMDataSource SRM Data Source - server\Instance name.

SRMDataBase SRM SQL data base name.

SRMPort SRM SQL port using to comunicate with DB when collecting the SRM Recovery plan details. Usually it is 1433

SRMWaitTime How much time to wait to SRM process to finish

SRMDRver The version of the SRM to test

SRMMaxRepCount How many times to try test fail overs

SQLtype The type of VMware SRM data base. Supporting MS SQL or PostgreSQL. SQL - For MS SQL psSQL - for PostgreSQL.

CloneDC Clone a DC in DR site that is not part of the replication tool

DCDiskSourceImport The source path to import the DC to

DCVMName VM name of DC

DCHostTargetServer Host server to export the clone DC to

DCHostServer Host server that host the DC

DCDataStoreTarget Name of ESXi datastore to export the DC to

52

DCCheck Do acceptance test for DC clone

DomainNetBiosName Domain NetBIOS name

zertoVMPort The default Zerto port

zertoVPGNAME Zerto VPG to scan and use when using Zerto workload. You can write few plans to manage, keep this rulls: each plan should be

with single dash, for example: 'VPG1'. If you add more than one plan, seperate ech one with two line, for example: 'VPG1'||'VPG2'.

Put double qoute over the full parameter, for exapmle final to plans should look: "'VPG1'||'VPG2'". The order of test fail over is

by the order of the VPG from left to right. You can change the order manually by changing the order of the VPG names.

zertoCheckpoint What checkpoint to use in test. The default is "Latest" but you can change it to "Latest VSS" so EnsureDR will automatically fail over to the latest checkpoint that got VSS snapshot or to "Latest Tagged", the latest manually tagged checkpoint

zertoWaitTime How much time to wait to Zerto process to finish

zertoMaxRepCount How many times to try test fail overs

zertoVMPortCMDLET Zerto CMDLER port number

CleanUpInErr Cleanup the tested Recovery plan of SRM or the tested VPG fail over of Zerto if plan was failed to fail over.

SRMUser User name for SRM DB. Applicable only if SRM is working with MSSQL DB in workgroup environment and it got deferent name and password than the user

edited at the main console (DomainUser=). Password can be edited only in the console.

DCCloneEsxUser ESX user to use only when cloning a DC on DR site. If none specified, EnsureDR will use the host\VC user instead.

[General] General definition for all jobs and all settings

Version The version of the software

FirstRun Whether this is the first time the software runs

FOttl How much time to wait for a server to finish Test Fail Over and Undo Fail Over

ParallelRun Running the tasks in parallel

LastTimeRun When EnsureDR was run last.

53

TestGroupGap Time gap between Fail Over server groups when creating test groups only for Double-Take and Hyper-V replica

ServerUpDelay Time to wait for each server to boot

LicenseKey License

VMToolsTTL Time to wait to VMtools to respond and time out for internal test command inside a VM

PS1TTL Time to wait for test job to finish

MailSendFlag Mail security flag.

EnsureDR supports ESMTP and CRAM-MD5 mail security. The default is CRAM-MD5 “c” flag. In domain environment that do not need credential to send mail in ESMTP, use blank user and password with port 25 and blank MailSecurity in Job1.ini.

To use ESMTP security, specify user and password and change the flag to “e”.

You can also use external SMTP mail servers as GMAIL. For example, in GMAIL use smtp.gmail.com in smtp host, user name (gmail address) and password, TLS in MailSecurity on Job1.ini and port 587.

HvTmpDrive Temporary network drive to use for Hyper-v target and EDRC.

InIBakreg Number of test sperformed before the ini file is backed up

HVinvTTL Wait for process in EDRC in Hyper-v test environment

FOGroups Number of groups in which to group servers when doing Undo Fail Over so there will not be too high load on target

FOGroupsGap Gap of time between groups of server in UNDO Fail Over

ServerFirstUpDelay Time to wait the first time after Test Fail Over for all servers to finish booting up

HVTrace Get more data from target Hyper-v when running tests on it. 1 = get more data in log.

DelayBadJob Time to wait if a bad job is found before testing it again.

ESXPing Check if host server exists

SRMRepeateRPTime How much time to wait between failed test fail over

zertoRepeateVPGTime How much time to wait between failed test fail over

ErrorMsgForReportLenth How long should be the error message in the PDF / HTML report

ErrorMsgForReportLenthDBG

How long should be the error message in the PDF / HTML report in debug mode

54

LoadUserProfInTestExprs Load user profile to tested server while doing remote command test with execpars. Relevant for user using that never login to remote server for tests.

PSTTLADPT Who much time to wait for a PS1 script to run at total from adapter

WaitADPT Who much time to wait for a PS1 script to run for each failed attempt

VCscanTry How many times to try scan the DR VC after Fail Over to get rest of the details needed for test such as target VM server ip

TimeRetryFileOpen If there is a temp log file busy, wait for it to be release. Wrtie the amount of retry here. Each retry will wait 5 secpns. If number of retry reach its limit,

EnsureDR will exit.

DT81issue If Double-Take 8.1 detected, make sure to skip any snapshot of successful test since the fail over test has change.

TestEngine Choose version of test engine.

TooldebugE2 Show more visual details while test engine 2 is running for debugging.

ParalelTest How many test to run in praralel

GlobalTestTTL How much time to wati for all the test to finish (in seconds).

TestTTL How much time to wait for each individual test (in seconds).

VCscanTry How many times to try scan the DR VC after Fail Over to get rest of the details needed for test such as target VM server ip

LinTTLSec How much time to wait for Linux user authentication

[CustomerInfo]

CompanyName Company Name – for self-service portal

ConactName Company Contact name – for self-service portal

Location Company Location – for self-service portal

email Contact email – for self-service portal

[DRTests]

DoTestD Do test fail over to source servers. 1=Yes, 2=No

DoUndoTestDR Do Undo test fail over to source servers. This will start the Double-take mirror checksum process or the Hyper-v Replica Undo test fail over. 1=Yes, 2=No

TestVMs Test the target VMs when they are finished failing over on test environment. 1=Yes, 2=No

55

TestNetworking Test if networking is ok. EnsureDR will run a local ping to make sure the networking is OK. 1=Yes, 2=No

TestService Test a selected service if it Running ok. 1=Yes, 2=No

ServiceToTest Name of the service to check

TestCustomCommand Test a custom command on all source servers. 1=Yes, 2=No.

TestCyber Test servers for viruses and maleware in the DR

CustomCommand Command to run on target VM. This example check free space on C drive. For example: "wmic logicaldisk where DeviceID='C:' get FreeSpace /format:value"

TestCustomResult Check result of custom command

SnapShotOnSuccess Create a snapshot on successful test. The snapshot will be created on the VMs in which all selected tests report OK. 1=Yes, 2=No.

EDRC Name of the VM hosting the EDRC, as displayed in virtualization management tools

EDRCVM EDRC Network name. This is the name that can be resolved in an IP address

GeneralToAll EnsureDR will run all test in main console to all selected VMs even if they changed in advanced console. Will NOT overwrite test created in advanced console, only complete blank tests.

LinuxAll All servers tested are with Linux OS. All the tests to all the servers will use Linux user credentials and Linux tests. Use this only if there are no Windows

in the server list to test.

ScreenShot Create a screenshot of VM that was tested to make sure if it was alive.

SendKeys Send key to wake up a VM before a screenshot to prevent black screen.

SecIPEDRC Secondary IP for EDRC in cases where source IP is deferent from target IP, Source segment is deferent from target segment, source segment is deferent from EDRC segment.

EnsureDR will add a secondary IP to EDRC only in the beginning of test and remove it in the end to prevent IP conflicts and mix segments.'

EnsureDR support multi secondary IP. Use ";" to separate IP address.

SecSegEDRC Secondary segment only applicable with SecIPEDRC.

EnsureDR support multi secondary segments. Use ";" to separate segments.

EDRCautoSecIP Automatically add a secondary IP to EDRC if EDR detect that target IP on replica VM will be in deferent segment than EDRC IP. Will work only if SecIPEDRC value is empty.

56

EDRCEthernet Name of the main Ethernet card that EnsureDR will add secondary IP to.

EDRChostsAuUPdt Automatically scan and update the hosts file in the EDRC server so it could resolve the servers names during the test when in bubble network. 0 = do not update. 1 = update automatically. 2 = update manually.

EDRCdnsNew New DNS address for the EDRC so it could resolve IP address during the test. EDR will remove the DNS address on the EDRC when test is over. You can add multiple IP with ; between them.

EDRCbackNet Specify the original network the EDRC should go back to. Configure this only if the target servers should go back to specify DR network at (TestDRNetwork under Main).

If not configured, EDRC will connect to the network specified at TestDRNetwork when test finished.

Autofix EnsureDR can try to fix simple issues during the auto test. Set 1 if you wish EnsureDR will try to fix the issues for all servers. In the console under advance test you can block the auto fix or configure auto fix for specific servers.

TestInGroups Run the tests in separated groups. Each group will run in different test session. Keep in mind that in may cause the test to take more time.

TestInGroupsGap Create a gap between test group sessions. Gap in seconds.

[AnimBoot] Control the animated boot in reports

AnimBootIn Use animated boot in report. 1 for yes and 2 for no. EnsureDR will use a static screenshot if the "Screenshot" will be set to 1 in [DRTests] section.

AnimTTL The amount of time to wait for animation process to finish (in minutes).

TTLScreenGap The amount of time between LIVE frames in animation (in seconds).

TotalShots Total LIVE frames to capture.

TargetDir Target directory to keep animation

BIgGif Total number of frames in target gif file that holds the full animation

BIgGifImageGap Gap between frames in big gif

SmallGif Total number of frames in target gif file that holds the small animation

SmallGifImageGap Gap between frames in small gif

log Log details. Verbose for full log or small for limited log.

AnimBoottoReport Create an HTML report with animation inside and send it to the mail recipient. 1 for yes and 2 for no.

57

LoadImageB64 Images in HTML report will be built in or load from the internet. It applicable only if AnimBoottoReport set to 1. 1 for build in or 2 for download from the internet.

BigRes The resolution of the big boot animation that pop up in final report. Write format: 400-300

SmallRes The resolution of the small boot animation preview in report. Write format : 150-100

framerate Set the frame rate - gap between each frame in the boot animation in milliseconds. The default is 25mls.

ChartCodeHtml Add the chart code to the html report so chart on html can be viewed on Windows without chart external java files. 1 for yes and 0 for no.

[Scripts] Run pre and post scripts during the EnsureDR workflow

PreFOScript Run a script in EDRC connected to DR network before starting Fail Over

PreFOScriptTTL Maximum time to wait for the pre script to end

PostFOScript Run a script in EDRC connected to DR network after starting Fail Over

PostFOScriptTTL Maximum time to wait for the post script to end

PreUndoScript Run a script in EDRC connected to DR network before starting UNDO Fail Over

PreUndoScriptTTL Maximum time to wait for the pre script to end

PostUndoScript Run a script in EDRC connected to DR network After starting UNDO Fail Over

PostUndoScriptTTL Maximum time to wait for the post script to end

PreTestInBBLScript Run a script in the bubble network from the EDRC before starting all tests.

PreTestInBBLScriptTTL Maximum time to wait for the pre script to end

PostTestInBBLScript Run a script in the bubble network from the EDRC after starting all tests.

PostTestInBBLScriptTTL Maximum time to wait for the post script to end

[ScheduleJob] Schedule Job controls the schedule task that is created on Windows task scheduler.

SetSchedule Create or update a task to run EnsureDR automatic. 1=Yes, 2=No, 3=Manual. Manual run mean that EnsureDR will ignore the schedule task and will run the job only

in manual mode. It won't alert it in the report.

StartDate The date and time to start running the schedule task. Enter the data as follow:

58

Year:Month:Day:Hours:Minutes:Seconds. For example:

StartDate=2015:02:05:00:00:00

SetDaysInterval Interval between tests in days

SetDayWeekMonth Set if the interval in days, weeks or months. 1 for days, 2 for weeks, 3 for months and 4 for one time

RetrySchd Only one EnsureDR.exe process is allowed. If EnsureDR.exe will start run from a schedule job while another thread of EnsureDR.exe process still running

(EnsureDR server is busy), new EnsureDR thread will create a new TMP one time schedule task that will run in a later time and close.

RetrySchdTime The amount of time to wait to run the TMP schedule run if EnsureDR server is busy.

RetrySchdAmount How many times to retry TMP schedule run if EnsureDR server is busy.

[Mail] The Mail section controls the delivery of summary message that is sent when job is finished.

SendMailWhenFinish Enable sending emails. 1=Yes, 2=No.

MailHost SMTP server for delivery (local or public. Example - smtp.gmail.com)

MailFrom Email address used as sender.

MailUser User name used for authenticating on the SMTP server, if required (password can be entered only from GUI).

MailPort The TCP port used by the SMTP server. It is often 25, sometimes 587.

MailTo Semicolon-separated list of recipient email addresses.

MailBCC Send mail to BBC recipient list. 0 for no, 1 for yes, 2 for both. In 1 you must put at list 1 working recipient in Mailto=. It will send regular mail in the first in the list.

All test rest in BCClist and the mail to will get the mail as BCC. If you mark 2, all MailTo recipient will get a regular mail and all BCClist will get BCC mail.

BCClist List of recipients that will get the mail as BCC.

MailSecurity Mail server security protocol such as TLS or SSL

MailSubject Alternative mail subject to send to user.

MailText Add custom text to mail send to user.

MailFullLogAtt Attach full log to mail send to user

MailJobLogAtt Attach job log to mail send to user

59

MailPastLogAtt Attach past tests results csv log to mail send to user

MailSumLogAtt Attach PDF results to mail send to user

LoadImageB64M Make EnsureDR put the images inside the HTML mail as BASE64 format

[SMS] Send SMS message alerting that job was finished with main details

SendSMS Send SMS to mobile device when job was finished - 0=No 1=Yes

MobileNumber Provide the phone number to send SMS to. Write up to four numbers with semi column (;) between them.

SMStext Provide an extra text to send in the SMS

[JobList] List of Double-Take GUID jobs that will be tested with EnsureDR. The list must be created with the console and should not be changed manually.

13. Command line options

EnsureDR supports some command-line options that help automating tasks and manage advanced

scenarios. Run EnsureDR.exe from a CMD.exe session, in the install location.

Option Explanation

EnsureDR.exe /schd EnsureDR runs in silent mode without GUI. Use this option when running EnsureDR from Windows Task Scheduler or from any scheduler service or software.

EnsureDR.exe /sosnow EnsureDR runs actual fail over for a real disaster recovery process. It will fail over all servers with the same boot order used in test mode. No test will be made except the power on test. EnsureDR will generate and send a report to configured email addresses with details on the process.

EnsureDR.exe /settings:<ini file full path> EnsureDR runs with alternate settings, specified in the ini file.

Options can be combined in a single command line, for example:

EnsureDR.exe /settings:C:\users\public\edr\settings2.ini /schd

ensuredr 2.0.1 · 3 license to use and incorporate into the services any suggestion, enhancement...

Documents