In this demonstration, I'll teach you how to set up Hyper‑V Replica.
We're on a Windows Server 2022.
domain member server.
Let me bring up Hyper‑V Manager.
The machine we're on as MEM1.
I've right‑clicked the root node,
did a Connect to Server so I could bring in MEM2 as well.
MEM2 is going to be my replica, specifically.
And you can see I've got one machine running,
one that's in a critical state,
but we're just going to replicate vm02 in this example.
You can see down in the thumbnail it looks like I haven't
yet installed Windows on the machine, but it's ready to be installed.
That's fine.
We'll want to go to our replica machine and set it up.
First though as a preliminary step.
I want to make sure that my networking is sorted out on
both the primary and the replica, so let me go to Virtual Switch Manager.
I've got an external switch there, and then on the source server, same thing.
I made sure to have an identically configured switch
that's connected to that machine.
I'm going to want to now go to the replica machine,
right‑click Hyper‑V Settings, and go to Replication Configuration.
We first enable this computer as a Replica server and then
either use Kerberos or certificates.
I don't have a public key infrastructure at this time, so I'm doing Kerberos.
And then down at the bottom,
we can either allow replication from any authenticated server
or allow repl from only specified servers.
I'm going to do any for now and click OK.
So MEM2 is sorted out.
Let's go back to MEM1,
and let's right‑click vm02 and come down to Enable
Replication from the shortcut menu.
I'm going to suppress the welcome page so I don't see this ever again.
I'm going to resolve mem2, press Enter.
It verifies the fully qualified domain name of the replica,
what port we're going to use.
Now we're going to need to make sure that TCP 80 is
allowed inbound to this machine, and, of course,
that's the case.
I've already sorted out my firewall stuff,
but it's just something to think about.
Compress the data.
That's fine.
Kerberos is what we're doing.
Next.
Verifying the VHDs.
Note that we could omit VHDs.
If we had a big data disk that for whatever reason we
did not want in scope for replication, we could opt that out.
Let's click Next.
Our replication frequency, 30 seconds, 5 minutes, or 15 minutes.
I'm going to choose 30 seconds.
That's pretty aggressive, but I want my changes to move very quickly.
It says here you can choose to store only the latest recovery point
of the primary virtual machine on the replica,
or we can add additional, allowing to recover to an earlier point of time.
That, again, has echoes of Azure Site Recovery, doesn't it?
That notion of the replication snapshot.
So we can have additional hourly recovery points to
give us a particular time objective.
I'm just going to do the most recent one here and click Next.
This is kind of cool.
If your replica is going to be offline in an air‑gapped network or it's
just going to be too time and bandwidth intensive,
you can, instead of sending the initial replication over the network,
you can use external media.
We also can schedule that replication to take place,
for instance,
at a period of low network utilization so that we minimize
impact on our services and our users.
I'm going to do Send initial copy over the network
and start replication immediately.
Let's click Next and Finish, and here we go.
Note that this process is not interrupting vm02.
It's continuing to run.
It's continuing to stay online.
And if we go over to MEM2, we now see vm02,
but notice that it's in an off state.
We can right‑click on the replica, come down to Replication,
and we can View Replication Health to see what's happening,
that this machine is in a Replica state,
replication's enabled, the health is normal,
that's what we want to see, no errors encountered,
last synchronization date/time, also, test failover metadata as well.
Let's refresh that.
So it's gradually bringing that data over.
Click Close.
And I had mentioned the exam alert,
understanding what options are available on the primary,
what options are available on the secondary.
So if we right‑click the secondary and go to Replication,
we can do both production and test failovers.
We can also extend replication to yet another host.
If we go to our source machine and go to Replication,
all we can do is a planned failover.
And that just makes sense logically, I hope,
because planning is something that we do while the
environment is in a status quo or healthy state,
but an actual failover, we're presuming the primary is inaccessible,
so, of course, we would configure that from the secondary.
I hope that makes some semblance of sense.
I also want you to see that now that we've enabled Hyper‑V Replica,
the Hyper‑V Manager has an additional tab that can just save us a little bit of viewing when we're using the user interface.