In this demonstration,
I'll show you how to synchronize IIS website content between
servers, and we'll also examine Hyper‑V live migration.
We are on, I believe, my win, well, let's just check. Let
me bring up VS Code and do a hostname.
Yes,
I'm on my source server, the Windows Server 2019 box, and the exam alert here
with regard to migrating IIS servers in your environment is to use msdeploy.
Now as my UK‑based friends say, it's a fiddly technology, and so you'll see
in my sample PowerShell script here,
I've got several calls of msdeploy. There's quite a few dependencies really.
You need to make sure that your IIS website is configured properly.
It's just fiddly,
it's not necessarily overly complex, as I said. You'll just want to
check the documentation. There's a great docs article actually
called Sync, S‑Y‑N‑C, Sync IIS Websites.
Again, just for completeness,
let me show you sync iis websites docs, and let's see,
yeah there it is, Synchronize IIS.
This one right here is what you're after. Now, I have just a simple,
lightly modified, very lightly modified, IIS website on WIN2019OLD.
All I have here actually is the default IIS splash screen image
that I've modified with this banner so that we can see what it is.
And, you'll also want to have Web Deploy installed on both your
source and destination computers.
Just do a google search,
you can download Web Deploy from the Microsoft Download Center, but
make sure that you've installed all the components,
particularly on the target machine you need to have this Remote Agent
Service running. If you want to do bidirectional sync,
you'll need to have it installed on both machines.
I found I had errors unless I installed everything in Web Deploy
on both my source and destination machines.
Once I had that,
then we can add msdeploy to your path, and then we can start to set it up.
And the idea is that to do periodic website synchronization,
you can just maybe create a script and run it using scheduled task, or
whatever, to periodically perform that synchronization.
Let me bring my terminal up and do an msdeploy/?, the old‑school
help. And as you can see, there's quite a bit here,
what might work better actually is to do the msdeploy and then redirect that to,
I'm going to call this, msdeploy.txt, and then I'm going to do a code,
msdeploy.txt, to bring that into a separate file here.
It's worth your studying for sure because number
one, the syntax is not that great,
but number two, it's actually a very powerful command line executable, you can
do a lot of powerful stuff. You can grab multiple websites,
you can grab just selected elements of the configuration.
There's a lot going on here as you can see, the Supported Verbs here, sync is
what we're concerned with, but you can gather dependencies,
you can just retrieve metadata, very powerful.
So what I've done is, ultimately what I got to work is down here on lines 60
and 63, where I did an msdeploy verb:sync, the source type is webServer, and
what I found in my particular environment,
I was having network problems doing a direct over the network transfer,
that's what you have up here, for instance. You've got msdeploy
‑verb:sync source: apphostconfig, the friendly name of the website,
destination, and then providing the computername. As an alternative, you
can do a two‑step approach, and like I said,
this is what I had the best luck with, where I would do an msdeploy and
export that website as a package on my C drive. And then on the
destination, or I could actually run it here,
I'm doing a ‑verb:sync, specifying the source path to that
package and then the FQDN of my destination server, and then I'm
putting that in an msdeploysync.log.
I think I've got that file right here, let me do a dir, yeah,
so let me do a code .\msdeploy log, and we can take a look at it.
It's in the traditional IIS format so it's not particularly easy to
parse, and as you can see in the mini map,
it's actually a very long document. Now, if it creates this much
output for just a stock IIS website with one page,
you can see how robust that synchronization is,
at least initially, when you have a more substantial application.
So, that's the idea. You'll periodically run that msdeploy to do your
synchronization, and I can test that I've already done this just by
pointing my browser to the destination server, mem1, and you can see
it's got the same content.
All right, so, mission accomplished on that. Now,
as far as the live migration,
that's pretty straightforward as well, actually. Let me open
up Hyper‑V Manager here, and let's see, we've got our vm9 virtual machine.
This is, if memory serves, just a Windows Server core box, yes,
here it is right here.
And, the idea is that we want to move this to a new server.
So let's bring in that new server by right‑clicking the Hyper‑V Manager node
and connecting to mem1. Mem1 has its own machines of course,
but it doesn't yet have the one from WIN2019OLD.
Now the catch here is that you need to make sure that the receiving machine,
that is the Windows Server 2022 machine, is configured to support incoming
live migrations. So we can right‑click the machine and go to Hyper‑V
Settings off the shortcut menu, and come over to Live Migrations, and
there's two elements here to configure.
One is we have to explicitly enable incoming and outgoing live
migrations, how many in parallel do you want to support, and then you
can constrain to particular networks, but I'm doing any available
network for live migration, and I have that configured on both
machines to support bidirectionality.
Let me verify that, enable, and yes, so that's good.
If I go back to my PowerShell script one more time, scroll down, you can
also set up the machines, the hosts that is, for live migration support
using PowerShell as you can see, Enable‑VMMigration, you can constrain the
migration network, and then you've got a Set command where you can specify
what kind of authentication.
And then lastly, as you can see on 76, we're calling Move‑VM,
against the name of the VM specifying the FQDN of the
DestinationHost and we want to include storage.
What is the DestinationStoragePath on that remote machine, and then we have a
whatif. I like to do a whatif just as a final check that says here that the
whatif will move the virtual machine to that computer. Now I want to make sure
that that DestinationStoragePath exists.
Let me do a quick Enter‑PSSession on mem1, and let's do a cd
c:\vms. Yes, it looks like there is a VMs director,
I just wanted to verify that quickly.
So let's get rid of that whatif flag here and let me add in Verbose so I
can see as much output as possible, and there we go.
We can expect that's going to take a little while to do,
but the value proposition here is that this is indeed a
live migration over the network, so it's going to involve no downtime of the VM.
If we come back to Hyper‑V Manager,
we've got this machine running, and we could have connected users who are
consuming it and having a good time. Whoop, there it is, it looks like it went
away from WIN2019OLD, and if we head over to mem1, there we have vm9 running
over there, and if we double left‑click it, do a Ctrl+Alt+Delete, and there we've got our machine. Migration completed.