- [Instructor] I'm about to use a term
that some network administrators consider offensive.
Now I'm not one to commonly use vulgar expressions
in the workplace,
but I feel that this one needs to be discussed.
The term is in-place upgrade.
Every version of Windows Workstation and Windows Server
has come with a list of operating systems
that you can upgrade from.
Meaning if you're running a listed operating system
you can install in a way that keeps
all of the existing configurations,
drivers, and applications,
but changes to a newer version of Windows.
For the most part, that list is the two previous versions
of Windows Server.
But doing this kind of upgrade comes with some obstacles.
There is never a guarantee that the hardware
and drivers supported by a previous operating system
will be supported by a newer, more demanding version.
Second, over a period of time most computers inherit clutter
from different applications, user preferences,
updated drivers, and so on.
If all the settings are kept through an upgrade
that means the clutter stays as well.
A third challenge is that not all roles and features
can survive an upgrade,
because they're just too different from one version
to the next to survive a simple transfer of settings.
And there are other obstacles,
but consider this your starter list.
Given these insurmountable obstacles
you may ask why someone would ever want
to upgrade a server in the first place?
Well, when Microsoft first announced
a semi-annual release channel for Windows Server
it became clear to me that an in-place upgrade option
was going to need to become a reality at some point.
These additions of Windows Server
are designed to come out every six months
and have a life cycle of only about a year and 1/2.
New features are being released at breakneck speeds
and servers are going to need to be upgraded
almost as fast as these new releases are coming out.
It stands to reason then
that if Microsoft is going to work out the capability
of in-place upgrades for the semi-annual release
that that same capability is going to be transferable
to the long-term service releases,
the Windows Server 2019 and beyond.
For that and I'm sure other reasons
in-place upgrade is being touted
as one of the noteworthy new features
in Windows Server 2019.
So I decided to give it a try.
I've mentioned a fairly robust role before, adfs.
This is a Windows 2016 Datacenter server
and it's a member of an Active Directory domain
that is hosted by, also, Windows Server 2016.
And this machine is installed with the role adfs.
All of those features are there,
there are configurations to do,
federated identify across domain lines.
Let me show you what happens when we've inserted
the Windows Server 2019 DVD
and go ahead and run setup.
Now this startup screen may look familiar
if you've upgraded desktop operating systems before.
I'm going to go ahead and say yes, download updates,
because I know it's not really going to take all that long
just to do the check.
And I'm being asked to enter my product key,
so let me go ahead and put that in.
And it will take a couple of screens
where it asks me which version I want to install.
Let's continue with at least the same resources
that we have to begin with.
And after checking with whether or not
I accept the license terms
it asks me what I want to keep.
Well, if we're testing out in-place upgrades
I'm going to tell it that I want to keep everything
and move onto the next screen.
So you can see this takes a couple of screens
before it gets to any warnings.
But take a look at what we're being told right away.
This tells us that the Active Directory
Federation Service role is installed on this machine
and it goes on to tell us
that this isn't going to work.
That that role is not going to be here
when we finish the upgrade.
It will need to be configured differently
later on down the line.
Microsoft has no expectations
that everyone is going to want to perform in-place upgrades
and they have these reminders in place
for those that try to do it
on servers where it's a bad idea.
Now I'm not going on record as saying
that in-place upgrades don't work.
I have successfully run this upgrade process
on file servers, a DHCP server, and even on a RADIUS server,
and they all worked out fine.
But there are roles that shouldn't be upgraded.
We've talked a little bit
about how these processes may vary,
we've discussed ADFS
and briefly reviewed Active Directory Domain Services.
We've briefly discussed Active Directory Domain Services.
So you should already be on board
with the idea that these types of upgrades
have a little more involved.
Now in addition to performing in-place upgrades
where they will work
and doing the role-specific migration processes,
there's another option available to us
in migrating a role.
The Server MIGration tools, often abbreviated to SMIG,
will allow you to create a special tool
on your new 2019 Server
that you can take to an older machine,
a 2016 or a 2012 RT server
and export or pack up the configuration of say a DHCP server
or some other role or feature that is running
and has been for some time on an existing server.
You can then take that wrapped up export,
bring it over to your 2019 server,
and import the SMIG feature.
That allows you to port an entire configuration
from an old box that needs to be retired to a new server.
SMIG tools are something that you're probably going to want
to become more familiar with,
especially if you have a Windows Server 2012 or 2016 network
that you would like to migrate to new installations
of Windows Server 2019.
These tools are usually preferred over in-place upgrades
and are explored in greater detail
in courses on installing and configuring Windows Servers.