Search
StarWind is a hyperconverged (HCI) vendor with focus on Enterprise ROBO, SMB & Edge

PowerShell wizard script: Configure Hyper-V Replica in different scenarios (domain, workgroups, and mixed option)

  • February 26, 2020
  • 58 min read
IT and Virtualization Consultant. Dmitriy is specializing in Microsoft technologies, with a focus on storage, networking, and IT infrastructure architecture.
IT and Virtualization Consultant. Dmitriy is specializing in Microsoft technologies, with a focus on storage, networking, and IT infrastructure architecture.

INTRODUCTION

As an admin, I’m fully aware that while working with the virtual infrastructures, plan A doesn’t always relay a guarantee, so you have to have plan B up your sleeve. Microsoft Hyper-V Replica inbuilt technology is a massive help in a lot of cases. If you want to find out more about why exactly this technology is a life-saver in the matters of Hyper-V disaster recovery, look it up here.

Since one way or another, you have to add and configure new Hyper-V hosts or to improve already existing ones, no wonder I came upon a set of the same actions, that are quite simple in use and not complicated at all, of course, if we’re talking hosts in the domain. However, what one supposed to do if one doesn’t have a domain? Or if your goal is a mixed replication between a host and a domain, or vice versa? Recently I faced a task just like that. After a long time spent on researching how it works and finding a working algorithm, I realized that there are no existing means of automating this process. So, I had to develop a one myself. As a result, long hours of tiresome, albeit productive work, brought me this quite large yet very efficient script that I have decided to share with you!

Bear Grylls

So, first things first. The journey started with these two articles. My highest regards to the authors: your work hasn’t been in vain. For the same reason, I won’t dedicate too much time to describe the process itself in all preciseness, just take my time explaining the most critical stages of the script.

DO keep in mind, however, that this script is designed for replication between the hosts with the same OS version! If you try and apply it for the hosts that have different OS versions, don’t blame me for damaging your infrastructure. The script was tested on Windows Server 2019 and Windows Server 2016. I can’t deny that it might work on Windows Server 2012 R2 as well, but if you must, do it at your own risk, since it wasn’t tested for this version.

HOW IT WORKS

Replication scenarios:

Replicated host\host with replica Hyper-V domain member Hyper-V workgroup member
Hyper-V domain member + +
Hyper-V workgroup member + +

As we can see from the sheet, the script will help to configure all the possible hosts’ combination for the replication. Although a mixed combination of the domain hosts with the hosts outside the domain is supposedly possible, I would rather avoid that if I were you, so that there won’t be any problems in the future. The only problem with these scenarios (except for replication inside the domain) is that you’ll have to perform a series of additional steps, such as authentication between the hosts based on certificates and several other configuration settings. However, the script still takes it all into account, so don’t worry.

This script works perfectly with the hosts not engaged in replication processes before. If we are talking hosts that already have existing replication configuration, I’m afraid you’ll have to disable it. The script won’t be performing if even one of the hosts involved has active replication configuration, and the VMs with such configurations won’t be available to you unless you disable these settings manually. I did it on purpose to avoid a chance of disrupting an already working scheme. The script is equipped with numerous testing tools to deal with possible errors, and I just hope you won’t be needing them.

What does it do?

Preserving the current value of Trustedhosts variable on the host where the script is running or on the remote host should you decide to run this script remotely, so that you could return the previous value of the variable once the work is done.

Verifying of the IP addresses and their credentials for correctness.

Verifying of the necessity to create self-signed certificates and to apply additional settings.

If necessary, creating and adding self-signed certificates to the hosts (these certificates remain valid for two years); performing all required actions in the registry, firewall rules, and hosts files of both configured hosts.

Turning on and configuring replication on both hosts using Kerberos (for replication inside the domain) or certificates (for everything else).

Enabling the selection of one VM or defining all VMs available for replication to start the processes of replication and configuration, providing a possibility to exit the script if necessary.

PIECE OF ADVICE

To start it up, you’ll need to copy the text of the script, save it locally with the name «VM_Replication.ps1» on one of the hosts or a PC that has network access to the both of them. Run it with PowerShell as Administrator.

Run as Administrator

What you need as well are credentials and IP addresses of local or domain admins from both hosts. You need to run the script as an admin; otherwise, you simply won’t have enough rights to run commands correctly.

Start the script and follow the commentaries to enter the information required for the replication process to begin (hostnames, usernames, their credentials).

Start the script

In my specific case, the replication was configured between two hosts in the workgroup «Work». Make sure there are no errors in configuration stages: you’ll have no hard time finding errors since they will be highlighted with red if they should occur.

Select the required scenario. It can be all the VMs with disabled replication, in case you need a remote copy of this host.

Select the required scenario

Make sure the script is finished successfully!

Also, while selecting a specific scenario, you can go with replicating one of the VM from the list of the VMs available for replication. This is more of a testing option. Replication for the rest of the VMs you can configure later with GUI or PowerShell.

Make sure the script is finished successfully

If you ever enter the wrong information, you’ll be notified of this immediately and will be able to try again. These are several examples of notifications you may receive:

Examples of notifications

The script also takes care of even more serious errors, such as previously configured replication or multiple command errors. Take a look at this one, for example:

Multiple command errors

Keep in mind that after the work is done, you won’t be able just to restart the script and start over. For the next replication, you would need to clear everything and disable the existing configuration!

TO SUM UP

I’m not saying that this is the best option: code isn’t perfect. However, it is a useful option, and I’m sharing it with you as it is. If you want to improve, go ahead. Moreover, I’m not the one to avoid a discussion. That’s all, folks, hope this script will come in handy!

Found Dmitriy’s article helpful? Looking for a reliable, high-performance, and cost-effective shared storage solution for your production cluster?
Dmytro Malynka
Dmytro Malynka StarWind Virtual SAN Product Manager
We’ve got you covered! StarWind Virtual SAN (VSAN) is specifically designed to provide highly-available shared storage for Hyper-V, vSphere, and KVM clusters. With StarWind VSAN, simplicity is key: utilize the local disks of your hypervisor hosts and create shared HA storage for your VMs. Interested in learning more? Book a short StarWind VSAN demo now and see it in action!