On Premises Exchange Server Case Study

Our client faced a choice to migrate their Exchange database and transport to the cloud or keep their email databases and transport locally on their premises.

Project Summary

Our team at KNS was tasked with replacing a legacy Exchange 2010 server with Exchange 2016
After being presented with different options suited to their needs, the client opted to have an on-premises physical (VM) Exchange server installed

We troubleshooted the previous server work the client had done to prep for installation of Exchange 2016; several errors were found before we could continue

After installing Exchange 2016 on the new server, we set up the environment so the transition from their old set-up was as seamless as possible

Finally, we migrated data from the old server to the new one and decommissioned the client's old Exchange server

Key Successes

Clear and concise explanation of possible solutions to client

Migration of data to new server

Successful set-up of new server

Smooth transition resulted in no down-time for client

Phase 1: The Problem

Objective - To replace a legacy Exchange 2010 server with Exchange 2016

Exchange 2010 has been retired by Microsoft. After October 13th, 2020 (originally was January 14th, 2020, but Microsoft has since extended this) Microsoft will no longer offer support or create patches for vulnerabilities in the platform. In order to stay up-to-date and be able to perform vital business functions, ABC Industries (name protected) faced a choice to either migrate their Exchange database and transport to the cloud or keep their email databases and transport locally on their premises. Due to the nature of their work, ABC Industries has elected to go with an “on-prem” exchange server and a mailbox migration from one server to the other.

Kitsap Networking presented ABC Industries with a breakdown between the two options. Including total cost of ownership over 5 years, on both the Cloud and On-prem solutions. We explored the upfront costs as well as the month to month reoccurring costs for both. After careful deliberation ABC Industries elected to go On-prem. Its important to note that this is not the most cost-effective solution. Kitsap Networking provided two options and helped the client make the best choice possible per their unique situation.

With the decision made, KNS goes to work. Exchange migrations can be daunting, especially ones as extensive as the 2010 to 2016 upgrade. Many areas of your computers network and domain must be within compatible parameters including, DNS, Domain and Forest functionality levels, service packs, Domain controllers, Operating systems, and certificates to name a few. With the initial information in hand, KNS was able to get the project up and going.

“It’s not about the cheapest solution, it’s all about the right solution.”

– Dan Posey, I.T. Engineer

Phase 2: Design Solution

Once the initial decision to move forward has been made, the next phase of this process is to decide which solution is suitable for the client. Kitsap Networking Services (KNS) prepared two solutions; 1) a cloud-based Office 365 Exchange Online migration; 2) an On-Prem physical (VM) Exchange server. Both solutions have their advantages and disadvantages. It’s important to provide our clients with choices and reasons for any solution so they can make the best decision for their business.

The cloud-based Office 365 migration is a subscription-based service that gives access to the suite of Office products. There are several subscription levels from the very basic of, just need connectivity via web access, all the way to full blown developer tools to create your own intranet, as well as several levels in between. The Cloud based solution offers the lowest initial cost. Generally, a setup fee and the monthly reoccurring per user is all it takes.

The On-prem solution is a hardware based locally dedicated server that handles all of the mail functions. The server needs the software, licensing and hardware capable of handling all of the mail traffic. On-prem deployments make sense when a single initial investment is a better financial decision rather than a monthly bill. This decision becomes more palatable especially when you have existing hardware capable of handling the load.

With a final decision in hand we can begin. Our client chose to go on–prem. Their decision was based on available hardware, control, and financial obligations tied into a few other projects. As with any major undertaking KNS created a road map plan with perquisites discovery, milestones, anticipated down times and a completion date. These initial tasks give the project a structure that we can work within to keep our client informed of progress as well as track any issues that arise.

Perquisites discovery is the first and arguably the most import part. Knowing what the customer has, and comparing that with the needs of the project. These items can range from the right domain environment, do we have enough resources, is our current software/environment up to date. Based on those finding we can create milestones.

Milestones for this project would include, Domain is ready for new Exchange, old Exchange is ready for new Exchange, the VM is built to spec and ready for software, date for database migration, scheduling downtime, and finally completion target date. Once this info is in place, we can work on getting each piece ready. Bring on the actual fun!!

Phase 3: Execution

Installation is comprised of several parts: 1) prerequisites, 2) system installation, 3) data migration, and 4) Go Live-Cleanup. Each part must be completed before moving to the next and have their own set of challenges. It's at this stage where you find out if any previous IT work has been done properly or not. We have found that if proper procedures are not followed to remove a workstation or decommission a server, it can have long lasting effects that may not affect performance but will impede upgrades such as this.

Part 1: Prerequisites

Exchange has a healthy list of prerequisites. A quick google search and you can get a list. This is the first step to installing Exchange. This is also where you find out if previous server work was done correctly. For our example, a prerequisite for Exchange 2016 is a Domain function level of 2012r2 or later. Before we could continue, we had to figure out what was causing that error. As it turns out a previous Domain Controller wasn’t properly removed. This can happen when a server dies, or with OS corruption. The solution is to find the erroneous data and remove it. We found 6 prerequisites that wouldn’t pass muster during the entire process and 4 of them were related to erroneous data left over.

Part 2: Installation

With the Domain proper and all pre-installation tasks handled we were able to install Exchange 2016 on our new VM server. The installation went fairly smooth. Exchange 2010 and 2016 can live together and function in tandem, or so the documentation says. The idea is to have 2010 house your mailbox database and use the 2016 server for client access and transport roles. In our environment this worked out just fine. We used the new server to host the connection point for mail clients, and to transport email to and from the internet. We kept the 2010 server in play to house the mailbox database. We kept this setup for a few weeks until the client had a maintenance window.

Part 3: Data Migration

The new server is up and running, mail flow is working, it is time to transfer the mailboxes database to the new server. Exchange 2016 has a built-in utility to make this a very easy process.....until it doesn’t work. At this stage I have dotted every I and crossed every T, in fact it is a necessity to get to this point. But none-the-less I have an error message and I cannot transfer the databases. Research of the error indicated that we were not using the SP3 version of 2010. With all the other checks and balances, that just cannot be the case. At this point the client is informed of the error and that the project was not going to be completed as per the original timetable and project outline.

In the end what happened, was during a prerequisites step to get the domain to the proper function level and get Exchange SP3 installed a key change was missed. Once we found the missed key, and the proper value was plugged in, the database transfer went off without a hiccup.

Part 4: Go Live – Cleanup

Our go live date for this migration was somewhat ambiguous as with the first appointment we were running on the new server already, just not the full system on the server. Go live for this project was the day we fully utilized the new server and the old server no longer stored or transferred emails. We came across a certificate issues that was fixed for remote and outside access. Other than the wrong key this was the one thing that was missed in the planning process, but a very simple and quick fix.

The last task for this project was the decommission of the old Exchange server. This is a bit of a process as it needs to be done a specific way otherwise lingering metadata will be left in the domain and will cause problems later. Cleanup for this project involved the Exchange installer. It was used to properly uninstall Exchange 2010. We then demoted, removed any roles and features, and retired the VM. As a just in case we archived the VHD file from this server if they ever needed any old data.

Final Thoughts

Some projects are easy, others can be difficult. Expect the unexpected and be flexible. The problems encountered were nothing we could have anticipated. Some projects are smooth and others you learn a lot.