Welcome to Setting Up for Success With Exchange Online:
learning path:
Decommissioning On-Premises Exchange Server video
with your hosts, Charlene Stephens and Chad Solarz.
Today, we'll be discussing
how to have a stress free removal of Exchange Server.
And the process of migrating to Exchange Online.
Some point you'll need to reduce your on-premises footprint.
Now, this should be in a visible process to the end-users.
We all know that bad reputation can spread quickly.
So a clean, thorough, not impactful
removal of Exchange Server is paramount.
We want to ensure we're not leaving anything behind,
either in the configuration
or any artifacts in the directory services.
So let's layout a complete plan
that we can successfully execute
and make you look like the rockstar that you are!
In this presentation,
we'll discuss the way to align for a successful Decom.
We'll talk about considerations that you want to factor in,
and things that might cause hiccups along the way.
We'll go through the stages of Decom.
And we'll tell a few stories about common missteps
to help you avoid any issues.
Next, let's talk about the Decom Don'ts!
A common misstep we see often
is attempting to test a Decom of a server
just by stopping the services.
Unfortunately, this can cause other issues,
and it isn't an effective test of Decom.
There are certain...
Those services are still considered
available in active directory.
Possible issues with stopping services you may experience
are backpressure, which can help mail flow.
Some administrative functions will be impacted.
For example, adding a mailbox permission can fail
because WS-Management service
is trying to connect to that server
where the mailbox resides.
Clients can still be proxy to those servers as well.
And this could cause outlook connectivity failures.
Another issue with we see that can cause problems
is not removing Anti-Virus
before you attempt to an install exchange.
What can happen is A/V may lock some files
causing an uninstalled to be incomplete.
You can end up with a partial an uninstall of the server
and have to manually make adjustments.
Chad.
Now, far too often,
we see or hear stories of you, the customer,
having unrealistic timelines
or expectations of how quickly
or easily this whole process can be completed.
So having this thorough plan
will be the key to your success.
Make sure it includes anything Exchange related.
Now, what we're really meaning here
is we'll want to include other stakeholders or integrators
who may have dependencies or hooks
into your Exchange Server.
You may be surprised to hear other services or applications
have a reliance on your services
that you weren't even aware of.
Now, this could impact line of business applications,
and what would the potential cost to the business be
if something like this occurs?
Now, once we're all done with the removal of Exchange,
don't forget to circle back
and re-run that Hybrid Configuration Wizard.
It will be auto-updating.
So you'll always have the latest version of it.
Now this Wizard will help us remove
references to the old servers
we're no longer participating in those Hybrid operations.
Another important note to think about
is Third Party Applications and Integrations.
There's many other programs that rely heavily on Exchange.
We've already mentioned A/V, but it's worth noting it again.
There are so many other applications
that can be impacted by removal of Exchange
that we should consider digging further into these.
Consider programs like backup agents.
IIS extensions, ISAPI filters,
archiving, Fax, and so on.
Another thing to consider
is what Third Party Applications might be tied to
pop or IMAP accounts or other accounts.
So verify those clients can connect to Exchange Online
or the newer version of Exchange prior to removing it.
Now let's move on to Client Access Decom.
If you're moving to a newer version of Exchange
and not Exchange Online,
it's important to verify that your server FQDNs
and load balancer devices are pointed to the new versions.
For internal clients, the service connection point
should also be moved to the newer version.
Here are the examples of the coagulants you would use
to check the location of the SCP and change the location.
You would just use Get-ClientAccessServer
using the AutoDiscoverServiceInternalUri,
and then you can set it using set.
Now let's move on to another slide
related to Decom of Client Access Server.
For the client, this slide,
the Client's Server Decom is only specific
to Decom of 2010
if you're moving to a newer version of Exchange.
Everyone may not have implemented Kerberos,
but those of you that have let's talk about possible impact
if that's done incorrectly.
Clients will fail to connect.
This can have a huge impact,
and we've seen hundreds of customers with this problem.
The big takeaway from this slide
is that 2010 cannot share an SPN
with any of the newer versions.
We must remove the HTTP/Autodiscover
and HTTP/domain.comSPN
from the legacy version
prior to implementing those SPNS on the newer version.
You might ask, why will the clients fail to connect?
This is because the client can obtain a Kerberos ticket
from that older version
and then attempt to pass that ticket to the new version.
And that will fail because it's a bad ticket.
Getting a bad ticket is one of those few scenarios
where a client will not fall back to NTLM.
This is very different from the client,
not being able to obtain that ticket
where in that case, we know they will fall back to NTLM.
We've included a link to the slide.
Please note step four,
that is the most commonly skipped section
that leads to critical outage.
Now let's discuss Transport Decom.
Thanks, Charlene.
Now with transport decommissioning specifically,
we need to address the per server configurations
and global configurations for mail flow.
Now this will focus on the per-server configs,
such as receive connectors,
and those or wide configs, or send connectors.
Now, these will need to be complete
prior to actually performing the un-installation itself.
The installer tends to get a little angry
if we haven't cleaned this up.
Now, it's very likely you're using
some custom send connectors for third party
or application-specific traffic via a connector.
This can include the Hybrid Connectors as well.
We'll want to ensure that we remove the server
that is about to be removed from this configuration.
On the received connector side,
this will include configurations listening
on ports 25 or 587 for authenticated or anonymous traffic.
Now here we see these are mostly used
for purposes like application relay,
notification processes for alerts.
Or multifunction devices,
they use services like Scan to Email.
This configuration here will include the IP addresses
as well as any permission groups that they may use.
Here on the slide, we see some PowerShell examples
on how to pull that information.
Now this will need to be documented
and then ported over to the newer version of Exchange
or one of the remaining servers in the organization.
Now we can use PowerShell, scripts,
or just variables to lift those settings from the old
and move them over to the new servers handling this load.
Cannot stress this enough,
but the most important part is to test this
prior to removal.
Use tricks like DNS host Centuries
to try to force or massage the traffic
towards the new servers that should be successfully
handling this load.
So now that we've discussed client access and transport
let's move on to Mailbox Decom.
Now with these decommissioning steps,
now we've also seen this
during our normal upgrade processes.
We should have already moved our special mailboxes
to a remaining server.
Now, here we see how we can query
for some of those special mailboxes,
like with get-mailbox -Arbitration.
And then piping that into a MoveRequest
to get it into a remaining database.
Now, these special mailboxes include system mailboxes,
which are the framework
for things like the approval processes,
arbitration mailboxes, and any mailbox
that may have special responsibilities,
also known as our persistent capabilities.
Think of our new OAB here.
Now here, we see some examples
on how to move, not just the mailboxes,
but later on, and we'll also show you
some public folder syntax that we can use.
Now, once all of the mailboxes are vacated
from the old databases,
then we can go ahead and proceed.
Now it may not appear like it,
but there really are some dependencies to the mailbox role,
specifically those special mailboxes.
And the last thing we want to do is impact end-users
or line of business applications
just because of an uninstallation.
Now, our OAB we're specifically referencing
the 2010 OAB here,
was previously linked directly to the server object.
So this will be going away.
So let's make sure that we have a newer version
that has an OAB with persistent capabilities,
tied to a new mailbox that is fully working.
We'll also want to verify no remaining databases
are referencing that older OAB.
Now last but not least, are public folders.
Everyone's favorite topic.
Now, all public folders,
whether they're the legacy 2010 folders
or the newer modern public folders,
we should still document fully.
Now, in this example, we're querying for the public folders
and exporting that information
out to a text file or XML file.
Now, once we have this listed out,
we can use this as a confirmation system or validation step.
This way, we can ensure
that those public folders that need to stay
on the remaining Exchange Servers
are active, accessible, and healthy.
Ideally, we'd like to see this content mood possibly
not just to newer Exchange Servers
but obviously exchange online modern public folders.
But let's not forget
that we can also migrate this information
to Microsoft 365 groups.
Now in the next phase,
we'll go ahead and tackle-breaking down
the Database Availability Group, or the DAG.
Now because we have highly available copies
of the mailbox databases,
we'll need to remove those additional copies
before we can go ahead and proceed.
Now, once we are down to a single copy,
then we'll be allowed to remove that final copy.
Now, remember if we're going to be repurposing the server
in any way, shape, or form,
these files the EDBs,
the log files are not cleaned up automatically for us.
Now, once we have the databases removed,
then we can go ahead and start breaking down the DAG.
Now, here we can go ahead and remove membership.
We can use the Exchange Admin Center
or the browser-based UI or these PowerShell examples.
Now once the DAG object has no members anymore,
then we can remove the DAG object itself from Exchange.
Now, remember if we're using a classic DAG or IP-based DAG,
we will be later on required to clean up
that Cluster Node Object or CNO from active directory.
All right, so let's go ahead and move on with Char,
to talk about Unified Messaging & Edge Decom.
Thank you.
Last but not least, if you're utilizing UM
you should already be moving to another option
such as Cloud Voicemail.
We suggest that you remove all components related to UM
such as your dial plans, attendance,
and other UM functions listed here.
For Edge Decom, if you're planning to move to EXO,
you should check Edge
for any other functions that it might be doing,
such as SMTP Relay or any other connectors on it
before you decommission that server.
If you're moving to a newer version of Exchange,
you will need to recreate the subscriptions
on the new version.
Next, we will discuss Uninstalling Exchange.
Chad.
Thanks, Char.
So we're in that final phase,
we're ready to start cleaning up the actual server itself.
But after we've ran the setup DAGXE
and we removed all the rules from the server,
now we actually have to clean the slate.
Now here's where we're going to make sure
there are no references to that server left
both on DNS, active directory.
So we're going to look for those lingering DNS entries,
maybe any folder or share permissions
that we use for the DAG
more specifically on the file share witness,
have removed any version-specific routes or VIPs
on the network, or load balancing layers.
Now, remember we do not support firewall rules
between Exchange Servers.
If you've had to create an all type of rule
to allow that traffic between may be data centers,
these servers won't be leveraging that anymore.
So we'll want to make sure that we go back
and clean this up.
So no server-specific
or IP specific configurations left behind.
Now, once we have this all done,
what are we going to do with the actual servers?
If this is a physical machine, at 2U rack unit,
what's our process for reclaiming that Rackspace?
If we have a Virtualized Exchange Server,
do we have access to the host?
Is there another team or member we need to leverage
to help us remove that virtual machine?
Or we also then cleaning up the files, those VHDX files
from those host machines
to make sure that we reclaim those resources
to give to the other VMs as well.
Now, this should be a clean, safe, graceful,
and successful removal of Exchange if we followed this plan
from front to back.
Now, if this isn't working,
we do support but not recommend the ADSI method
of removing of the server from active directory.
It should only be a last-ditch option.
All other methods have failed.
Now, to get more information on our series
and our learning path focusing on
Setting up Success with Exchange Online,
please feel free to follow the following URL,
aka.ms/MicrosoftIgnite2020/SuccesswithEXO.
If you wish to find out even more,
we do have other paths and tracks
that you may be interested in,
Exchange, Outlook, Time Management, Bookings,
as well as Mailbox Protection.
Thanks.