EnsureDR 2.0.1 · 3 license to use and incorporate into the services any suggestion, enhancement...
Transcript of 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
Administrative permissions
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).
Administrative permissions
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).
Administrative permissions
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.
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