Storage Migration Service and Windows Server 2008 | Windows Server Summit 2019

>>Hey folks, my name is Ned Pyle. Thanks for joining us here in
Windows Server Summit for 2019. Today, I’m going to talk to you about the really big elephant
in the room and that is Windows Server 2008. Everybody here probably has run 2008, probably has 2008 still, I know from talking to
customers, from telemetry, from surveys, that it’s about maybe half of all servers
left in the world of Windows, and that is tens upon tens of
millions of servers are 2008, and that means for you, that we need to have some
options for getting you modern. Because on January 14th, it’s all over for 2008. So about eight months from now
as I talk to you here, we will no longer support
its operating system, and you will need to have
done something about it. You really have two major
options right now. You can either take those 2008
servers and move them to Azure, and get a few extra years
of support, Azure IaaS, and we have really great details
and information on how you can do that at our server webpage, which we will hopefully be
showing below me right now, as a URL for you to follow. But there’s one other option, and that’s an option
that I’ve been working on for the last few years, and bringing to you starting in 2019, which is Server 2019
Storage Migration Service. Now, why did I make
the migration service? Migrations are very complex, files can be in use, file ownership can be set. You have encrypted
files, permissions, this list goes on and on and on, and it makes it really
tricky for you to get away with migrating off of a box. It’s not something that
you can simply just copy some files and be done, you need all of that metadata, the configuration, those
network settings, that security, all that fidelity, in order to truly get your migration
done in a healthy way, so that your users and apps are not affected and that nobody shouting
at you on Monday morning. So storage migration service
is here to save the day. This is the storage
migration service. It’s a dashboard running
in Windows Admin Center. I’m sure you’re very familiar
with Windows Admin Center by now. It’s been around for about a year, and it is our modern way of running both existing old-fashioned workloads and pieces of Windows, but also new features
and pieces like SMS. This is the dashboard
showing me doing a couple of migrations
right now in line, pushing my way through getting
off of some 2008 servers. Today I’m going to go
real demo heavy here, slide like, and show you what I mean when I talk about a storage
migration service, really saving your bacon. What is the vision of SMS? The vision is; we migrate
your data from anywhere. I don’t care if they
are physical machines. I don’t care if they
are virtual machines. I don’t care if they’re in VMware, or in Hyper-V, or wherever, and we will take them and put them
onto brand new Windows servers, later OS’s especially like 2019, running wherever you like. So if they were physical, they can become virtual. If they were virtual on-prem, they can become IaaS in
Azure. It’s up to you. I’m carrying about from the server
piece to the server piece, and wherever you want to
run those, is fine by me. It’s super fast, it’s very
consistent, it’s very scalable. It’s the design you saw in that little quick little
dashboard demo we showed, that I was running a couple of
server migration simultaneously, it takes care of all the complexity, and you saw my first piece there, the Cloud of complex items. It knows about all those things, it takes care of all those things, and it’s really nice
elegant graphical workflow. Windows Admin Center gives us
the ability to wrap up all of our PowerShell in
a really nice wizardly type option to make sure you go through
things step-by-step, you don’t miss steps, and you’re not basically following documentation and running
commands forever and ever, but instead getting a nice
visual graphical representation. So what are we doing
right now at 2019? You’ve maybe seen SMS already. I’ve talked about it at Ignite, I’ve demoed it at Ignite. Obviously 2019 came
out later last year, and that really hit
its stride this year. What do we do right now? We take 2003, 2008, 2012, whatever your source
Operating System is, with SMB on it, and by placing this orchestrator
service in the middle, we can take your data and your configuration and migrate
it over to modern targets. So for example, a 2019 box
running Azure file sync, or some servers running on Hyper-V or maybe a brand
new physical server. Then from those, we can take
those pieces up into Azure itself, and either push that data
through Azure Files, use Azure file sync, or directly copy these into IS VMs, using say Azure Migrate, and your rocking and rolling with a public Cloud implementation of
your file server at that point. We’re just living in
the middle there as a free piece of server 2019. This thing doesn’t come separately. It’s not an extra charge, as long as you have a 2019 server
somewhere, you have SMS. So how does this thing work? It operates in three basic phases. The first one is inventory, the second one is transfer, and the last one is cutover. Rather than bombarding you with
too many more slides here, I’m going to have just one
little piece on each of these, and then just ride right in
some demos and show you what I mean. So let’s start with inventory. Inventory is totally
passive, there’s no agent, you don’t install anything
on source machines, you don’t worry about having to
roll out a service somewhere else. You’re just putting SMS
on your orchestrator, and this is going to
reach out and look at whatever servers you decide you
are thinking about migrating. So they run from that orchestrator
and we create a job. Jobs contain one or more servers, they name that job, I figure out who’s going to be
the migration account for it, who’s going to be
a good administrator account that has access to those source machines. It’s going to go through
and we’re going to point at which shares
we’re going to look at. It is going to scan
the configuration, look at the network, look at the volumes, look at the operating system info, make sure that what we’re
looking at is going to work, that it’s supported, and
then fill up our database, and the orchestrator with lots of knowledge about
what’s going to happen. Then it’s going to scan SMB. Look at all the shares on there, look at the counts of the files, look at the sizes, look
at the share properties, get a hold of that stuff
into our database as well. We talk about all the
small little pieces that go into a migration. There are these little
knobs and hooks and idiosyncrasies that
had been set on servers, and the older they are, probably the less likely you
are to be aware of them. I said I support 2003. I see about 78 percent of our migrations through my telemetry
are still 2003 sources. Even though that OS has not
been supported for many years, there’s plenty of
them still out there. The odds are that whatever configurations have
been put on that box and tinkered around with for the last 12, 13, 14, 15 years, you may not even be aware of it, and the SMS’s job is to go through and find all those little nooks
and crannies and make sure that they get copied
over to your destination server, so that your apps don’t break
and your users aren’t affected. So this inventory is going
to go through and run, and we’re ready to go ahead at
the end of it and do a transfer. Let’s take a look at what
an inventory is going to look like. So here’s my WACC dashboard, you hopefully are
familiar with it by now, and the first thing I’m going to do is connect to my orchestrator server, and if the SMS service
isn’t installed, we’ll go ahead and
install it for you. So we’ve tried to make
this as seamless and easy process as we possibly
can and really leverage luck. Here’s my dashboard you saw before. Of course, it’s empty right now. I’m going to go ahead
and plug in a job name, and go ahead and hit “Yes” to go, and we’re going to start putting
together our first inventory. So I need to give
some administrative credentials to the source machines that
I plan on connecting to, and I need to give it
a password obviously, and then I can check “Decide.” Do I want to copy the entire volumes or just want to copy some shares? In this case I’m just
going to copy some shares. Now, I need to provide
some source machines. So I’m putting in
these two file servers. Once these things are plugged in, I will kick off my inventory. So first, I type in these two
file servers. That’s my list. I could do one. I could do 10. We’ve actually tested up
to a 100 at one time. Hopefully, you’ve got a nice beefy server for
running something like that. Then I’m going to go ahead
and start my inventory. It’s going to read those machines. Remember my phases I was
talking about before, it’s going through
and looking at SMBs, looking at the configuration and noting it all down
in these details. So I can see the source
operating system, I can see free disk space, I can see how many
shares are configure, what’s going on with those shares, I can look at the details of shares. All these little
weird nooks and hooks of people have been messing
around with for years and maybe I’ve just lost track of in your endless IT pro technical debt. These are real servers here. So I have a couple of machines. I have a 2012 and a 2016 machine
here I’m just poking around with. You can see those
shares really do exist, those in the old share
Explorer tool there. They really do have files in them. In this case, they are
many many files of my dogs. We’re going to migrate all of
my dogs over to brand new server. So as I go through
here and look at this, I have kept my inventory pieces
all done and I’m ready to go. So the next phase for us is transfer. This is really the meat phase
of the operation. So I’m going to copy all the data. I’m going to copy all the security. I’m going to copy all of
the shares themselves. Before, if you were
doing a migration, I mean anybody can run Robocopy relatively
safely and get that data. But things like share configurations
and share security or the security itself on files is
much trickier to get copied over. So SMS does as well as Robocopy does but
then it doesn’t much more. I mean, it does multi-threaded, it’s doing multiple servers, it has retry options, it does multiple passes, it will do delta copies. So if I run a transfer
once, I get everything. If I run it again,
I get what changed. If I find things already
existing on the destination, I will back them up for you
on the very first pass in case somebody accidentally
picked the wrong server. We don’t want to overwrite data. In case somebody
accidentally was using the destination server which
isn’t quite ready yet, we don’t want to overwrite data. So I’m going to map the destinations, my source machine and
my destination machine. I’m going to map the volumes. I’m going to decide if I want
all these shares or not. Maybe I’ll skip some, skip others. Maybe there’s one server in my big batch I decided
not to do today and I might just opt out of it for now and come back and
run a job on it later. I can set my retry flags,
my preservation rules. I can decide if I want
to use checksums or not. We have two levels of checksum. We can SMS ones very fast, and lightweight ones much slower but incredibly accurate in case
you are very very paranoid. Then we can validate
this is going to work. My absolute favorite piece of SMS is that we go
through and validate steps rather than making you go read what you’re
supposed to be doing. So we then do the transfer, we do the delta rerun, we make a report for you, then we’re moving on to cutover. So let’s see this now. So I’m here, we’re going to
get into my transfer again. This is where we just left off. I’m going to need
some another new set of credentials for the
destination machine. I’m not entirely sure if the same administrator
account works as well on the destination
as it did on the source. It might be the same user,
it might not. Then I’m going to fire up, lining up each of these servers
that I’ve migrated previously, looking at it from the inventory. So I need to give the source machine a new destination in
order to get migrated. So I had the FS Servers. I’m going to type in
my new destination server. I’m going to scan it. That’s going to get me all of
the storage on that machine. So I need to line up the storage to make sure that if I’m
migrating from D, there’s a D there to migrate to. If I’m migrating several drives,
those drives exists. We can line it all up and that
there’s no loss of fidelity for users and data once
this migration is done. I can choose not to migrate
a server, like I mentioned before, but I really do want to
migrate servers otherwise this would be a really boring demo. So I’m going to add my second box. As I go through that, this one’s got a few more drives. Make sure those look good. I could decide I don’t like
the share, I do like the share. You can make all your choices here. Then I can do various
amounts of settings for whether or not I want to
do more complex Checksumming. If I want to retry
and use files or not. I have the option, a little sneak peek here, for things that are just coming out. The ability to copy
local security and principles, something that nobody
else can do inside of Robocopy in other tools and keep old security working from local
users and groups on a new machine. That was never possible. Then, I’m going to just about
get into the bitty part. I’m going to run my validate. This is going to reach out
to the destination machine and make sure that it’s ready to go. The firewall rules are ready, that the privileges are right, that I’ve installed the proxy service which will make performance much much faster on 2019 destinations and
it wouldn’t say 2016 destination, and then ready to go. So I’m going to start my transfer up. Let it start running here right now. You’ll notice this little banners
we have popping out. They reminds you things like, “We have Azure file sync and other hybrid services to
attach right at the end.” it might seem like an advertisement but actually really
it’s just a good idea. Believe me. So now I’m going to start my transfer and we’re going to
get this thing rolling along. You can see that there’ll start
being some progress coming along. I’m going to time compress this because who’s got
time to sit there and wait 15 minutes for all of my dog files to copy
over between machines? When that’s all done, both my servers have finished their transfers, and we can actually go
through and look at some of those details on there
about what happened. So I can see which shares
copied, which files copied, and have a really interesting
set of ability to look through also at
a detailed output files. We have a database like I said. If you want to go look at
event logs of other operations, you are free to but I am
more of a Excel guy myself. So we give you the option to save a report of your entire
transfer into CSV, which you can pop open in Excel, organize whichever way you want, look at all the data, look at any errors for any files
that got skipped, see exactly why it got skipped. Keep all audit trail for yourself and your own peace of mind so when your migration is done
and somebody says, “You didn’t copy my files.” you can say, “I totally
copied your files. You deleted them later. You owe me lunch.” So that’s transfer. Nice and easy. All those steps
you might have done previously in migrations we’ve just sort of pushed that out of the way
and taken care of for you. Let’s talk about
the last piece, Cutover. This is the super novel part of SMS. In the past, you could
inventory things yourself, you could look at those machines and write down how their Config is, and look at their space use, and make yourself a reasonable
understanding of what SMS is doing, and you could probably
transfer files at least, maybe not all of the security
and pieces that we do, but pretty reasonable
approximation by hand. But the Cutover piece is
really a pain in the neck. What we want to be able to do is take that old source machine
and make it no longer be reachable by users, but still reachable by admins. We want you just to
be able to get to it, but your users and apps not to, we want them to go to
that brand new server, which is filled with brand new data,
and as far as they can tell, looks like that old server
they’ve been used to using for years or decades. So we will take over its name, we’ll take over
its Active Directory identity, we will take over its network, all of that old source machine, and it will be like
nothing ever happened. Any user that was in
the middle of working, when you started this Cutover, would notice this small brown app here where they couldn’t
reach the server, which would then
magically resolve itself, hopefully before they
came and bothered you. All their data would be
there and the server name wouldn’t have changed and the
IP address wouldn’t have changed, and they’ll scratch
their head and say, “I don’t know computers,”
and get back to work. So what we’re doing is we’re
actually mapping the network, setting IP addresses,
setting a new name, setting up things like
alternate computer names, and other subtle name resolution, and security options
that come with Windows. We’re setting a max duration for
how long this Cutover can take. We’re going to validate again, validation is
my favorite part of SMS, to make sure that we
think it’s about to work. So you can read the documents and make sure you’re
following the requirements, and then validate will
check your homework to make sure that you’re
really ready to go. We will start that Cutover, it will run, and that will be it. The job will be done. Our old server will be obfuscated, re-IPd and accessible by you, but no longer accessible by
any user or application that was trying to reach that server by
any of its entry points at all. Anybody trying to use
any little entry points will end up on the new server, which is a brand new machine, brand new OS, no cruft from
the old server whatsoever, other than just keeping data
and network and security. No operating system,
no in-place upgrade, nothing that you would probably
be missing is on that server. Okay. So here is how Cutover looks. I’m in my third and final phase, my credentials are still good
from last time probably, not probably going to change
them in this case in this demo, and then I am ready to fire
this up with network settings. I can choose to skip
network settings, entirely do some network settings. This is a brand new piece, again, I’m giving away
some sneak peeks here, for something which is just
coming out very very soon. But in reality, what I’m
mainly doing is saying, “Yes, I want to
migrate the networks.” Then we line up the source and
destination machines networks, and give the chance to name
the old server something, either random name or
something that I like, and decide if I want to use DHCP or a static IP address
for my old server, so that it can live on on
the network and let me get to it until I’m confident
that the Cutover was good. If I’m migrating to a cluster, this is new, if you’re
familiar with SMS, you’re going to be very
excited about this, we also added some
extra options there for joining and setting up
cluster setups for File Servers. So I have all my stuff lined up, it’s ready to go, I
press “Validate “, again validate goes through and make sure that all of
those things that need to happen for Cutover to
work are ready to go. So once it’s done
examining each machine, it will give us the green light
or not if things aren’t, we could take a look
and see the list. Make sure we’re happy and
confident, ready to go, and we’re going to fire
this thing up with Cutover. So as this thing runs, it’s going to go pretty quickly, it really just depends on how
fast your machines can reboot, how fast your DNS
propagation will happen, and how quickly your AD object
replication can happen. If you’re in a smaller or
medium size environment or a low latency environment or environment with
good change notification, really the longest part of
this process is the reboots. When these servers get
disjoined from the domain, rejoined to the domain, we have to restart them
and change their names, and identities and take
over those pieces, so each server will reboot
twice, and you’ll see here, as I go onto my destination server, which is 2019,
all my files are there. These are all the pieces
that got copied over. All my shares are there. Just like they were on
the original machine, that was years and years old. The beauty of this piece is, every last little nook and
cranny’s been changed. Look at the name, hasn’t changed now, as far as the user’s concerned,
the name hasn’t changed, but that server just got renamed, when we did that Cutover. It’s IP address got set to
the old machine’s IP address. Everything is there
that it needed to come over from the source
and nothing else. If you look at
the source machine here, you’ll actually notice that the computer has been
rejoined to the domain again, but if I was to look very carefully, I can see that the
server’s been renamed, it’s no longer going to be
accessible as its old name by anybody and anybody
trying to connect to that box wouldn’t be
able to find it anymore, except you, the administrator. Pretty cool. That takes
all those pieces and steps out that you might not
have been thinking about when you started
planning your migration. So in 2019 in October, when we release Server 2019, this was SMS’s state of the world, but I just basically showed you. Coming really soon in
2019’s first major update, which is 19H1, we will be adding in all of
these new plumbed pieces that I was just talking about. So the ability to
migrate from clusters, from Samba, which is
all new from Linux, the ability to push
things straight into clusters takes standalone boxes
and migrate them into clusters, and that networking piece
allowed me to migrate straight into Azure IaaS, which obviously has a new network, there’s no way in Azure IaaS to
have your old network migrate, so those pieces I was showing
earlier, give you the option to say, “Migrate everything except the
networking pieces,” and we’ll let Azure IaaS’s private and
public network interfaces be the ones that are used, and that’ll be the one little piece
of fidelity will decide not to bring along with
us, which is pretty nice. So coming in 19H1, but here’s the really big surprise; coming in a cumulative update, a backport update of all of these
features that I’m going to push down to regular Server 2019
through Windows Update, you’ll get Samba-Linux support, cluster support, local group
and user migration, and network list migration. So even though I said 19H1 and
you’re thinking to yourself, “Oh, it’s the semi-annual channel releases,” those core servers
that come out for SA customers is also coming to regular Windows Server
2019, just for everybody. Because in the end, my goal
is not to sell SMS, my goal was for you to run
the latest version of Windows. So for me, the ideal situation is that you have
the migration tools that you need to get off of 2008, which is my enemy. So real quick, one last little demo, here is the Samba migration, and I wanted to prove to you
that we’re actually doing this. I’m not a terrific
Linux admin myself, I had to sit there
and scratch my head, read my way through
the Linex again, obviously, we had two developers set aside to work on this
more carefully than me. But notice that I have the option
to choose Samba right now. So I take Samba, and
the difference here is, there are a lot of
other ways to login to Samba in Linux than
there are to Windows. For a Samba Server, server emulating
Windows SMB services, there’s still regular
Windows login, the admin login that it’s
using through emulation, but there’s also all of the Linux pieces that have
nothing to do with that, and if I want to be able
to start looking at IP addresses and storage
configuration and all those things, I need to support
those, and we do know. We look at this long mama jama, I can put in certificates,
private keys, passphrases, I can use the root accounts, whatever I need to get onto my particular distro of
Linux, and there are many. We support, CentOS, Fedora,
RHEL, SuSE, Ubuntu, the big five basically, I’ll be able to do that here
with Storage Migration Service, going forward, and you can see here, I’m doing an inventory. I’m not going to run through
the entire thing again, the cool part is the Inventory. I’ll be able to login with all those credentials that are
Linux-related and Samba related. Take a look at the configuration. You can see here that I picked out this one server and you can
see that it’s actually, even though it’s looking
like Windows to users, it’s actually Linux,
so you can see here, and it has Windows shares from Samba, and I can go on with my migration
just like normal, after that. The experience won’t
change at all after that. So I go from Samba,
maybe some appliance, maybe some server, I
end up on Server 2019. There are a lot of servers out there. Tens upon tens of millions of
Windows servers out there, on-premises, in public clowns, wherever, and a lot of
them really are old. Here’s my thing, I need you, in the next eight months, to take SMS, find
all your 2008 servers, hunt them down, and make me proud. Thank you so much for
watching this presentation. I really hope you enjoy
the rest of Server Summit. My name’s Ned, and have a great day.

Leave a Reply

Your email address will not be published. Required fields are marked *