STEPS TO DECOMMISSIONING YOUR EXCHANGE 2010 ON-PREMISES ENVIRONMENT

This was a great article released by the Exchange Team Blog today, and as I have been dealing with MANY customers still having Exchange 2010, I wanted to have this available for quick review! It has great links and steps to consider when finally getting off Exchange 2010.

Best practices when decommissioning Exchange 2010

As many of you know from the previous post regarding Exchange On-Premises Best Practices for Migrations from 2010 to 2016 the end of support for Exchange 2010 is quickly approaching. We’ve created this post to cover the best practices for decommissioning an Exchange 2010 environment after the migration has completed.

Uninstalling Exchange 2010 is as easy as running Setup and selecting to remove the server roles, but there are prerequisites to removing the roles and legacy items left over, which should be removed.

This post is intended to provide best practices to plan for and complete the Exchange 2010 decommission. Please note that since there are many different types of deployments and configurations it is difficult to cover all scenarios, but many of the common steps are included here. Please plan the decommission process carefully.

As a general statement, here are some things that we want to caution against:

  • Do not reuse Exchange 2010 server names (until they have been fully decommissioned).
  • Do not reuse Exchange 2010 server IP addresses (until they have been fully decommissioned).

This post assumes that your organization is maintaining some Exchange presence on-premises, whether Exchange 2013 or 2016 (we do not mention Exchange 2019 in this post because it cannot coexist with Exchange 2010). If your organization has moved all mailboxes to Office 365 and is in a Hybrid environment, we are assuming you will maintain an Exchange footprint per Scenario 2 in How and when to decommission your on-premises Exchange servers in a hybrid deployment.

Preparing for Soft Shut Down

Once you’ve completed the migration from Exchange 2010 to, let’s say, Exchange 2016, you should prepare the 2010 environment prior to decommissioning the servers. The following steps to consider are separated into server roles when preparing for a soft shut down and preparing for the removal of server roles.

Client Access (CAS) Role

Check Server FQDNs

Review all namespaces (e.g. DNS records and load balanced virtual IP addresses) used for client connectivity and ensure they are routing to the 2016 environment. These are all the names that are published for Outlook Anywhere, AutoDiscover, and all Exchange Virtual Directories.

Tip: Verify that all clients such as ActiveSync, Outlook, EWS, OWA, OAB, POP3/IMAP, and Autodiscover are no longer connecting to the legacy Exchange servers. Verification of this can be done by reviewing the servers’ IIS Logs with Log Parser Studio (LPS). LPS is a GUI for Log Parser 2.2 and it greatly reduces the complexity of parsing logs. LPS can parse large sets of logs concurrently (we have tested with total log sizes of >60GB). Please refer to the following blog post with tips and information on using LPS.

Check SCPs

Make sure that the Service Connection Point (SCP) is moved to Exchange 2016 as discussed in the Exchange On-Premises Best Practices for Migrations from 2010 to 2016 post under the Configure Autodiscover SCP for Internal Clients section.

If present, ensure that if the AutoDiscoverServiceInternalURI routes to an Exchange 2016 endpoint. You can also remove this value by setting the AutoDiscoverServiceInternalURI to $Null.

Hub Transport Role

Follow the items below to review all mail flow connectors. We will not be removing connectors themselves, simply auditing to ensure that the server is ready to be decommissioned.

Review the Send Connectors

Review the send connectors and ensure that the legacy servers have been removed and Exchange 2016 servers have been added. Most organizations only permit outbound network traffic on port 25 to a small number of IP addresses, so you may also need to review the outbound network configuration.

Review the Receive Connectors

Review the receive connectors on legacy servers and ensure they are recreated on your Exchange 2016 servers (e.g. SMTP relay; anonymous relay; partner, etc.). Review all namespaces (e.g. DNS records and load balanced virtual IP addresses) used for inbound mail routing and ensure they are terminating against the Exchange 2016 environment. If your legacy Exchange servers have any custom, third-party, or foreign connectors installed (for example, with fax services), ensure that they can be reinstalled on 2016 Exchange servers.

Tip: Check the SMTP logs to see if any outside systems are still sending SMTP traffic to the servers via hard coded names or IP addresses. To enable logging, review Configure Protocol Logging. Also, ensure we have “time coverage” for any apps relaying weekly/monthly emails that may not be caught in a small sample size of SMTP Protocol logs. There is a great script available here that can help find any applications that may be relaying off your legacy environment.

In general, the decommissioning process is a great time to audit your mail flow configuration to ensure that all the connectors are properly configured and secured. Maybe it’s time to get rid of any of those Anonymous Relay connectors that may be in use in your environment. Or, if Hybrid, possibly relay against Office 365.

Transport Rules

Exchange 2010 base transport rules are held in a different AD container than Exchange 2013 and newer rules. When installing Exchange 2016 in your environment it will import those Exchange 2010 based rules. However, any changes to Exchange 2010 rules after a later version of Exchange is installed must also be applied to your Exchange 2016 rules. This is further explained here under section Coexistence with Exchange 2010.

Run the following command to get all your Exchange Transport Rules. Must be run on Exchange 2016 to see all rules.

Compare the rules with RuleVersion of 14.X.X.X to those with 15.1.X.X. If any Exchange 2010 rules don’t exist on Exchange 2016, they must be created. Also review all settings of each Exchange 2010 rule and replicate them to Exchange 2016.  

Mailbox Role

Identity and move all Exchange 2010 mailboxes to Exchange 2016

Decommissioning Exchange 2010 cannot be initiated until all mailboxes have been moved to Exchange 2016. As an example, we cannot decommission Exchange 2010 Hub Transport servers completely until all of the mailboxes are moved off the legacy platform, this is due to how Delivery Groups are handled.

We encourage using the newest Exchange platform to process any move requests. If moving to Exchange 2016, move all mailboxes via Exchange 2016. Also, ensure that once all moves are completed, and that all associated Move Requests are removed as well. Any lingering move requests or mailboxes will prevent uninstallation of Exchange 2010.

To move all user mailboxes, run the following command to identify the mailboxes, and then plan to move them to the new platform.

Tip: Ensure that Archives are included with “Get-Mailbox -Archive” if you used Exchange Archives in 2010. Also, do not forget about your Discovery Search mailboxes – these can be found with: Get-Mailbox -Filter { RecipientTypeDetails -eq “DiscoveryMailbox”}. These will need to be moved (if they haven’t yet already), to Exchange 2016 as well.

Identify and Move Arbitration Mailboxes to Exchange 2016

It’s necessary to move the arbitration mailboxes from Exchange 2010 to 2016 for many Exchange Services to work properly, including the Exchange Admin Center (EAC). This is typically executed when Exchange 2016 is first installed, however, if that was missed, we will ensure that is handled now. The process to move is defined at: Move the Exchange 2010 system mailbox to Exchange 2013+. To verify which system mailboxes are located on 2010, use PowerShell on your Exchange 2010 server with the following example:

Note: If any mailboxes are present, move them to an Exchange 2016 database.

OAB Generation

Installing first Exchange Server 2013+ into Exchange 2010 organization creates a new OAB. It also marks the new OAB as default. The Exchange 2010 OAB is not used by Exchange 2013+ servers so moving the OAB is not necessary. Move the OAB to another Exchange 2010 server, if you are removing an Exchange 2010 server that’s currently hosting the OAB, and there are other Exchange 2010 servers in the org. If you are removing the last Exchange 2010 server in the org, remove the OAB.

Migrate All Legacy Public Folders

Verify that all the public folders have been migrated to Exchange OnlineOffice 365 Groups, or Exchange Modern public folders.

Mail Enabled Public Folders (MEPF) consideration

If the following is true:

  • Exchange Server 2010 public folders are migrated to Exchange Online
  • Exchange Server 2013/2016 was introduced on-premises
  • MEPF’s are still used on-premises to send emails to Exchange Online

In that case, you may need to run the SetMailPublicFolderExternalAddress.ps1 script to ensure Exchange 2013+ servers can continue sending emails to Exchange Online MEPFs.

Decommission the Database Availability Group (DAG)

Assuming best practices were followed for the Exchange 2010 environment, we will have a DAG for HA/DR capabilities. Now that all mailboxes have been removed from the 2010 environment, we are ready to tear down this DAG to move forward with decommissioning Exchange 2010.

Remove Database Availability Group (DAG) Copies

First, we start with the copies. For every mailbox database copy in the environment hosted on Exchange 2010, we will need to remove the Mailbox Database Copy. This can be done via the UI, or via PowerShell:

NOTE: Removing the copy will not remove the actual .edb database file from the Server.

Remove All Nodes from Database Availability Group(s) (DAG)

For each Exchange 2010 server in the environment, we will need to remove the individual server from the DAG. This is evicting the server from the cluster. This can be done via the UI, or through PowerShell.

Remove DAGs

Lastly, once the Database copies are removed, and the servers are evicted from the cluster, the last thing is to finally remove the DAG from the environment. This can be done with the following PowerShell command:

Tip: If you have an even-membered DAG, and leveraged a File Share Witness, don’t forget to decommission the file share witness that was used for the Exchange 2010 DAG.

Unified Messaging Role

Configuration steps are required to move Exchange 2010 UM to Exchange 2016 servers. The following link can be used to guide through removal of UM from Exchange 2010. If moving to a third-party UM solution, remove the UM components to allow un-installation of the UM role.

Edge Role

If you have an Edge server, you will need to install Exchange 2016 Edge and recreate the Edge Subscription on the E2016 server. This is further documented here.

Other

As mentioned in the beginning of the document, due to so many different types of deployments and configurations, it’s difficult to cover all scenarios however it’s recommended to check any other possible scenarios that apply to your environment.

Third Party Applications

Make a list of applications that may be using Exchange 2010 (e.g. EWS, mail transport, database-aware) and make sure to configure these applications to start using Exchange 2016 infrastructure.

Shut-Down Exchange 2010 Servers

Test shutting down the Exchange servers for a few days to a few weeks to see if there are any issues. You are auditing for any applications that are trying to connect to the Exchange 2010 servers or trying to send email through the Exchange 2010 servers.  Enabling protocol logging on the Hub Transport roles prior to shutting down the servers is an option. That way if any mail is processing through these servers, upon restart, the logging will begin immediately.  If applications or servers are trying to connect you can remediate those or power on the Exchange 2010 servers until remediation can happen.

Tip: Check Active Directory DNS Zone settings to see if DNS Scavenging is enabled.  If this is enabled, the DNS record could become stale during the shutdown time frame and cause DNS issues for the Exchange 2010 server.

Preparing for Removal of Server Roles

As you begin the process of removing servers, you should go through the list below and ensure you have everything tested and ready to go.

CAS

Remove CAS Arrays

Remove Any Exchange 2010 Client Access Arrays from Active Directory and DNS. Refer to the following document to remove the Client Access Array object with Shell using the following example:

Be sure to also remove any references in DNS to the CAS Array Name.

Remove Unused 2010 ASAs

If you followed either the Best practices for Migrations blog or the Coexistence with Kerberos blog, we recommend that any old alternate service accounts (ASAs) used for E2010 be removed. If you are using a different namespace than Exchange 2016, please verify old SPNs are also removed.

Remove Exchange 2010 OAB

Use the following command to remove Exchange 2010 OAB:

Remove Mailbox Databases

Now that all mailboxes are migrated from the Exchange 2010 platform, and the DAG is properly removed, we will want to decommission any leftover databases from the Exchange 2010 environment. To remove all Exchange 2010 databases, review the output of the following, and remove individually:

And then remove the database with:

NOTE: If there are any mailboxes currently residing on the database, we will not let you remove the database, it will fail with the following error:

e2010decom1.jpg
Remove Legacy Public Folders

If you chose not to migrate public folders, refer to the following document to remove public folders with either EMC or Shell using the following example:

Remove Legacy Public Folder Databases

Refer to the following document to remove the public folder databases with PowerShell using the following example:

Tip: Remember the .edb files linger after the above is done. Feel free to delete, backup, or do with these as you please.

Uninstall Exchange 2010

It’s recommended to uninstall in the following order: CAS, Hub, UM (if any), then Mailbox.  

Starting the Uninstall Process

When you begin the uninstall process, close EMC, EMS, and any additional programs that could delay uninstall process (i.e. programs using .NET assemblies; antivirus and backup agents are examples). You can either run Exchange 2010 Setup.exe or navigate to Control Panel to modify or remove Exchange 2010 (either server roles or the entire installation). Specific steps are discussed in Modify or Remove Exchange 2010.

Tip: Exchange will protect itself! If you properly uninstall via Add/Remove Programs, it will ensure that it is ready to be uninstalled via Readiness Checks! If all the above prep work is completed before hand, it should uninstall just fine.

After Uninstall of Exchange 2010

After uninstalling Exchange there will be some general “housekeeping” tasks. These may vary depending on the steps taken during your upgrade and depending on your organization’s operational requirements.

Examples include:

  • Removing the legacy Exchange computer accounts from AD (including the DAG’s Cluster Name Object and any Kerberos ASA object).
  • Removing the legacy Exchange name records from DNS (including the DAG’s Cluster Name Object and any Kerberos ASA object).
  • Ensure the folder on the DAG file share witness (FSW) servers were successfully removed, possibly removing Exchange’s rights on the server if it isn’t serving double duty for Exchange 2016.
  • Removing old load balanced IP addresses and routes from your network load balancer.
  • Remove old firewall rules that open ports to Exchange 2010 environment.
  • Removing and disposing of the legacy Exchange environment’s physical equipment.
  • Deleting of the legacy Exchange environment’s virtual machines.

Conclusion

With the uninstall of the last server, hopefully Exchange 2010 treated your organization well. The Exchange product team takes great pride of the success of the platform and hope that you see the same success with Exchange 2016 (or Exchange Online!). Messaging sure has come a long way since it was released way back in 2009.

REFERENCES
Exchange Team Blog article on Decommissioning Exchange 2010 On-Premises

CHECK FOR CONTINUED UPDATES!
THANKS FOR STOPPING BY!

Exchange 2016 Deployment MUST READ Documentation

In my role as a PFE for Microsoft, I have been going through many deployments of Exchange 2016 from Exchange 2010 due to the end of life deadline for Exchange 2010. I am actually in the middle of three enterprise level deployments this month.

Because of this, I wanted to provide some MUST READ links with consideration to the Exchange 2016 Deployment process. Please click on the links below, and they will take you to the documentation needed when preparing for a Exchange 2016 migration and deployment from Exchange 2010.

IMPORTANT READ:
Exchange On-Premises Best Practices for migration from Exchange 2010 to Exchange 2016 (Lots of important links and articles within this document!)

Other relevant articles:
Exchange 2016 System Requirements
Exchange Deployment Site Consideration
What changes in AD when Exchange 2016 is installed
Exchange 2016 Schema Changes to AD
Exchange Server Virtualization
Exchange Server Preferred Architecture
Load Balancing in Exchange Server
Load Balancing Exchange 2016 In Depth

Hybrid Considerations:
Decommissioning Exchange 2010 servers in a Hybrid Deployment
How and when to decommission On-Prem Exchange Hybrid Servers
Hybrid Deployment Prerequisites

I will add more articles as they become relevant in my experiences with my customers and feel they could be relevant here as well. If you have a suggestion for a link that should be considered added to this post, feel free to leave a comment!

THANKS AGAIN FOR READING!
SUGGEST A LINK!
GOOD LUCK ON YOUR DEPLOYMENT!

How to address Federation Trust issues in Hybrid Configuration Wizard (HCW)

During my time as a PFE for Microsoft, I have encounted many issues with Federation in a Hybrid Exchange Deployment. Recently, the following support announcement came out and I wanted to share as I hope this can help others that may be having issues out there.

One of the more common causes of HCW failures is the Federation Trust step for the Exchange on-premises organizations in Full hybrid configurations (Classic or Modern topologies).

Federation trust is a mandatory step in the on-premises Exchange organizations when configuring Full hybrid deployments, as this allows us to create organization relationships (for features like hybrid free/busy or OWA/EAS redirection) and sharing policies (1:1 hybrid calendar sharing). In Exchange Online multi-tenant organizations, federation trust is already in place.

Below is an illustration of an Exchange hybrid deployment where both the Exchange on-premises organization and the Exchange Online organization have a trust with Azure Authentication System (formerly called Microsoft Federation Gateway):

Example of Hybrid Federation

Before getting to our subject, let’s quickly go over different hybrid configurations and Hybrid Configuration Wizard (HCW) – as this is the supported tool to configure hybrid deployments.
There are 2 flavors of hybrid configurations:
Classic hybrid
Modern hybrid

At this time, each of those supports the following hybrid modes:

  • Full
  • Minimal (which further breaks down into…)
    • Express (a one-time sync)
    • “Actual minimal”

A quick overview of Full / Minimal / Express options, can be found here. More info on HCW is here.

As mentioned earlier, a federation trust is created by HCW only in Full Hybrid.

HCW logs are located at %appdata%\Microsoft\Exchange Hybrid Configuration on the machine from where HCW was ran. The easiest way to get to them is to press F12 in the HCW window to open the Diagnostic tools and from there you can Open Folder Logging or Open Log File directly.

When you have issues with federation trust, the log will usually show errors when one of the following cmdlets are executed:

Set-FederationOrganizationIdentifier
or
Add-FederatedDomain (but can be other cmdlets as well).

Once you identified the exact cmdlet failing and where (Session=OnPremises – means Exchange Management Shell and Session=Tenant means Exchange Online PowerShell), you should copy-paste the failing command and try to execute it manually and see if that is failing as well (most likely it will). You can also open the shells from F12 Diagnostic tools windows in HCW.

In order to get more details on the error and to rule out this is not an issue with HCW itself, you will need to separately run the same command that threw exception in HCW log and add Verbose switch to get verbose details of the error and the serialized remote exception.

For example, if the Exchange server version is Exchange 2010, you will run the failing command with Verbose switch in Exchange Management Shell (EMS), see if that fails and then get the serialized remote exception.

Example:

If the Exchange Server version is Exchange 2013/2016 and the above commands didn’t show more details on the error, we can also try the following:

  • Open regular Windows PowerShell (blue background) on the Exchange Server 2013/2016
  • Run command: add-pssnapin exchange
  • Run command that gave error in HCW and add a Verbose switch

Example:

Once you’ve gathered the verbose error / serialized exception, try to understand where it is failing (or provide it to Microsoft Support together with the HCW log).

Common Errors with Remediation Steps

  • Federation trust fails with “Object reference not set to an instance of an object”

This is a known old issue on Exchange 2016 CU7 servers, make sure your Exchange servers are updated to the latest CU.

Full error in the HCW log:

Resolution: Install the latest CU for Exchange 2016


  • Federation fails with “Proof of domain ownership has failed”

Full error in the HCW log:

Resolution:

• Check the TXT record for your domain(s) in HCW log or in Exchange Management Shell with command Get-FederatedDomainProof -DomainName
• See if it matches your published TXT record with either nslookup utility or by checking internet websites like https://www.whatsmydns.net/ put your domain in hostnames, type=txt, Nameservers – Authoritative

You would look for errors, missing records or unusual formatting (characters, spaces, quotes, TXT record split in half).


  • Federation fails with “An unexpected error occurred on a receive” or “An unexpected error occurred on a send.”

Full error in the HCW log:

Resolution:

Check outbound access from all your Exchange Servers to Microsoft Federation Gateway by browsing using Internet Explorer with PSEXEC tool (with -s and -i switches) from the Exchange Server (this will use Internet Explorer under System Account / Exchange Server Account).

In this example, “Windows Live” is actually this exact URL: https://domains.live.com/service/managedelegation2.asmx

From on-premises Exchange to Office 365, the Exchange 2010 MBX & CAS or 2013 MBX (backend) or 2016 / 2019 would need outbound Internet access to the Microsoft Federation Gateway in addition to https://outlook.office365.com/ews/exchange.asmx

Verify the machine/system account can access these Microsoft Federation Gateway URLs:

For a complete list of O365 URL & IP addresses, see these articles:

Note: If the Exchange requires a proxy server to access the Internet, specify the proxy server using “Set-ExchangeServer myExchange01 -InternetWebProxy http://myproxy:80”. Notice such proxy can’t require any user authentication for outbound Internet access, and the proxy must start with HTTP: and not HTTPS: (secure SSL).

You can also set the proxy using netsh as well.

set proxy proxy-server=”http=myproxy;https=sproxy:88″ bypass-list=”*.contoso.com” 

In rare instances, you can use the machine/system account to access the URLs from the browser, but Exchange cmdlets still failed with “Could not establish trust relationship for the SSL/TLS secure channel.” If that happens, make sure the certificate authorities for the urls are installed at the Third-Party Root Certification Authorities of the machine local certificate location.

REFERENCE:
Netsh Commands for Windows Hypertext Transfer Protocol (WINHTTP)
Firewall Considerations for Federated Delegation 

Federated delegation features require that the Mailbox and Client Access servers in your organization have outbound access to the Internet by using HTTPS. You must allow outbound HTTPS access (port 443 for TCP) from all Exchange 2010 Mailbox and Client Access servers in the organization.


  • There is no specific error / exception, in HCW log you would see it stops without any specific error.

Full error in the HCW log:

Resolution:

Look for orphaned federation trust:

Get-FederatedOrganizationIdentifier | FL

or

in HCW log if you see something with “DEL“: “contoso.com/Configuration/Deleted Objects/Microsoft Federation Gateway/DEL: <xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx>”.

Solution is to remove the orphaned federation trust and re-run HCW.

Reference here.

NOTE: as a first step, you can try to run the command remove-federateddomain with the switch -Force. Also, you don’t need to recreate federation trust manually, just re-run HCW (this will recreate federation trust for us)


  • Federation Trust fails with “InternalError InternalError: Internal error.”.”.””

Full error in the HCW log:

Resolution:

Open request with Microsoft Support or check if any Service Incident is published. Please see this for more information.


  • Federation trust fails with “1007 Access Denied”

Full error in the HCW log:

Resolution:

“1007 Access Denied” error is usually when we have issues with:

  1. Windows Time on the Exchange Server. See this article or this article.
  2. Outdated federation trust (for example, federation trust certificate expired) and in this case you would remove federation trust by following these steps.

If the federation trust certificate is not found on any of the servers, then proceed with resolution from the next error.

As an example, from one HCW log, there seems to be this federation trust certificate expired on 05/13/2019:


  • Federation trust fails with “Federation Certificate cannot be found”

Full error in the HCW log:

Resolution:

Follow the procedure here to manually cleanup the federation trust from AD. Once this is done, re-run the HCW to re-create it automatically.

KEEP TROUBLESHOOTING!
REMAIN VIGILANT USING FOCUSED INTENT, NEVER EMOTIONALIZING (FINE)!

REFERENCE:
How To Address Federation Trust Issues using the Hybrid Configuration Wizard

Exchange 2010 Extended Support will end on October 13th, 2020

I wanted to pass this announcement along to everyone so that they are aware of the support ending for Exchange 2010. I personally have noticed a large number of Exchange 2010 environments starting to show age as the newer Outlook clients are having performance issues with Exchange 2010. If your team has not planned an upgrade to Exchange 2016 (you cannot upgrade directly from Exchange 2010 to 2019), I would advise that your team do so very soon. Exchange 2010 has been a great product for many years, but it is finally time for it to retire and allow the next generation of Messaging Services take the stage.

Formal Announcement:

Exchange 2010 End of Support extended to October 2020

Announced today, and in alignment with Office 2010 and SharePoint 2010, and after investigating and analyzing the deployment state of an extensive number of Exchange customers, Microsoft has decided to move Extended Support date for Exchange Server 2010 from January 14th 2020 to October 13th 2020.
After October 13th 2020, Microsoft will no longer provide technical support for problems that may occur with Exchange 2010 including:

– bug fixes for issues that are discovered and that may impact the stability and usability of the server
– security fixes for vulnerabilities that are discovered and that may make the server vulnerable to security breaches
– and time zone updates

Customer installations of Exchange 2010 will, of course, continue to run after this date; however, due to the changes and potential end of support risks, Microsoft strongly recommends customers migrate from Exchange 2010 as soon as possible.

FAQ’s

  • Can customers upgrade directly to Exchange 2019?
    Customers cannot upgrade directly from Exchange 2010 on-premises to Exchange Server 2019. They may upgrade to Exchange 2013 or 2016 directly from Exchange 2010 and we of course recommend Exchange 2016.
  • Since Exchange 2010 runs on Server 2008 and 2008R2, are those operating systems still supported?
    On January 14, 2020, support for Windows Server 2008 and 2008 R2 will end. That means the end of regular security updates for these Windows customers. Since Exchange Server 2010 runs on top of Windows Server 2008 and Windows Server 2008 R2, it’s important for customers to consider how they will obtain security updates for the underlying operating system. Extended Security Updates for Server 2008 and 2008 R2 are now available for purchase and can be ordered from Microsoft or a Microsoft licensing partner. The delivery of Extended Security Updates (ESU) will begin after the End of Support dates, if and when available. 
  • Does Microsoft support Exchange 2010 on any other Server versions?
    Exchange Server 2010 SP3, with Update Rollup 26 or higher, installed on Windows Server 2012 R2 is supported until October 13, 2020.
  • That didn’t quite answer my question. If a customer calls between January 14 and October 13 2020, and is running Exchange 2010 on Server 2008 or 2008 R2, and does not have an ESU for Windows, can they still be assisted?
    Yes. Per the Lifecycle FAQ.
    If I am running a Microsoft product that is currently supported under the Lifecycle Policy, but my operating system is no longer supported, can I still receive support?
    If the problem is specific to the Microsoft product and it is within the Lifecycle Policy, Microsoft will provide support.
    If the problem is a result of the combination of the operating system and the Microsoft product, the problem will not be supported.
    More simply::
    Exchange 2010 on Server 2008 or 2008 R2: Starting January 14, 2020, provide support until a proven issue is found with the OS. This ends in October 2020.
    Exchange 2010 SP3 RU26+ on Server 2012 R2: We support regardless, but Exchange support still ends in October 2020.

  • Will Microsoft be offering Extended Support Updates (ESU’s) for purchase for Exchange 2010 customers?
    No.
  • What resources are available for customers? 
    – An upcoming Exchange Team blog post, titled “Exchange On-Premises Best Practices for Migrations from 2010 to 2016,” will provide great technical guidance for customers and support agents with their on-premises migrations.  
    – If migrating to Office 365 and Exchange Online, customers may be eligible to use the free Microsoft FastTrack service. FastTrack provides best practices, tools, and resources to make migration to Office 365 and Exchange Online as seamless as possible.
    – For customers that run into any problems during their migration to Office 365 and are not eligible for FastTrack, or if migrating to a newer version of Exchange Server, customers can of course utilize Support or the Exchange Technical Community.
    – Customers may also choose to engage a partner to help.  Microsoft has a great number of partners with deep skills in Exchange, and you can browse a list of Exchange partners at
    https://www.microsoft.com/en-us/solution-providers/home.

HAPPY UPGRADING!
CONTACT ME FOR QUESTIONS CONCERNING UPGRADING YOUR EXCHANGE ENVIRONMENT!