If you would like to read the other parts in this article series please go to:
Introduction
Now that we covered most of the basic features and components of FOPE we can focus on the transition process. In this final article, we will take two companies to transition at the same time: MSExchange.org that has a single server and AndersonPatricio.ca which has two sites. One site is able to receive e-mails from the Internet and a second site which is the backup MX for the domain.
To make the transition process in our scenario easier, we will document the changes as we go (Figure 01) and we are going to use orange color (highlighted icons) for the servers that are in production/active in the SMTP communication with the external world. The gray color will be used for all external SMTP servers and blue color for servers that are part of the solution but do not have any impact on the transition.
Figure 01
Pre-requisites…
As we have mentioned in the first article we need to identify our MX records and identify the order that they will be migrated. The main point here is whether the current Public IP is going to be used for FOPE or you are going to deploy a new Public IP just for the new FOPE deployment.
My recommendation is to use the current infrastructure since there is no harm when the transition is done correctly. The MX gathering information is crucial for a flawless transition and based on your scenario we can come up with a couple of strategies, as follows:
- MSExchange.org domain (single server): The administrator does not have a lot of options here. The strategy boils down to two main options: switch over directly to FOPE or add FOPE as secondary MX and then, after you feel confident with the solution, change FOPE to the primary and only MX record (my favorite choice).
- AndersonPatricio.ca (Multiple sites): The administrator here can play around adding FOPE to the MX with a high priority and then start removing the existent MX until the domain has only two MX records – the primary MX (on-premises) and FOPE as secondary MX. At this stage the administrator can switch them (FOPE becomes primary and on-premises become secondary), wait a couple of days/weeks and then remove the secondary which will leave only FOPE as primary and MX record for the domain.
As you may have noticed it doesn’t matter which environment you have, the idea is to add FOPE to the MX and then after making sure everything works we should start removing the on-premises MX and at the end FOPE should be the only MX record on your Public DNS zone.
Configuring Inbound Traffic (First Phase)
The first step here is to configure FOPE to forward any message arriving over there to the on-premises servers using the Public IPs that we already have in production. After having that portion done we can change our Public DNS zone to have mail.messaging.microsoft.com, and from that point onwards some messages will arrive on FOPE, however the regular traffic will use your primary MX record that is what you had before FOPE services were introduced (Figure 02).
Note:
The environment with two sites should have both Public IPs on the FOPE to make sure that it is able to deliver to both places.
Figure 02
At this point, you may want to set up some reporting capabilities to see how the message flow is going.
Configuring Outbound traffic
The scenario proposed so far was showing only inbound traffic, however we can configure all outbound traffic to go through FOPE services. In order to do that we need to go to FOPE Admin Console and configure the IPs of all Exchange Servers to relay on FOPE servers and then configure our Send Connectors to start using FOPE. All steps required can be seen in Part 2 of this series.
The result from the outbound perspective will be similar to the diagram below (Figure 03), where all servers send to FOPE and then Microsoft is responsible to deliver the message to external recipients.
Figure 03
Configuring Directory Synchronization and Security
We have a good portion of the solution configured and now it is time to lock it down. The first step is to enable Directory Synchronization and give some amount of time for testing before moving to production.
In order to configure Directory Synchronization you can check Part 3 of this series and part 4 for security best practices.
On the security side, a good practice is to clean up your current rules and then migrate to the FOPE. Unfortunately, this is a manual process and you should reserve some time for this task, depending on your environment you may consider a couple of days or perhaps weeks to finalize this task. Using FOPE Admin console we can always test the filters and it is a good idea to use such options to make sure that the new filters are performing the same actions that you have on your on-premises environment.
Are you ready? Go, go, and go!
Lock and load, and let’s finish this thing. At this stage the following tasks should have be done: test the outbound, test the inbound, configure and validate reports, configure security, enabled Directory-based edge blocking, and configured filters.
If all that I wrote before is done, then we can move to the key component that is to bring FOPE to be the primary MX of your domain, as shown in Figure 04. The good thing about our strategy is that we have a backup route for the single server scenario (MSexchange.org domain). During the DNS replication the old server will still be available and you won’t lose any messages during the process.
Figure 04
The diagram shows that FOPE will be delivering all messages, however some external SMTP will still use the backup MX (your on-premises servers) for a while and our mortal enemies (spammers) will use them. We are going to get rid of those connections in the next section.
After performing these changes, it is time to see the solution working properly and to stay in standby mode for any outstanding issues that may arise.
Wrapping it up and final tasks…
One of my favorite proverbs that I learned from my old man can be translated in English as “measure twice and cut once” and it is exactly what we are going to do here.
Before going any further, make sure that on the reports you have an increase of your SMTP traffic, also make sure that you do not have deferrals.
Okay… It has been a couple of days, and you have more free time, your users are happier and everybody says “hello” and “have a good day” to you in the cafeteria because they don’t have to deal with spam. You are the hero of the week! When you get to this point, it means that you are ready for the next step.
The first step is to clean up the environment and finalize the process by removing the secondary MX records of your Public zone. This results in the FOPE as primary and only MX record, as shown in Figure 05.
Figure 05
The second step is to allow only FOPE servers to connect to your SMTP servers and it can be done using the information provided from the tab Configuration of the FOPE Admin Console main page (figure 06). The first piece of information is about the IPs and ranges of FOPE servers that you should configure on your firewall.
Note:
If there is no way you can configure the IPs on the Firewall, you can always configure that at the Receive Connector level, however that is not a best practice and should be used as a last resource.
Figure 06
After locking down your Firewall you can do manual tests, however I would like to recommend that you open a ticket with FOPE (we covered that in the Part 1 of this article series) and ask them to test your current servers responsible to receive e-mail from FOPE. They will send you the results of the tests (Figure 07). The tests will check if the FOPE servers are able to reach your servers and as soon as you receive the report make sure that all of them have a PASS on the Status column. If there is a fail it may be a firewall rule issue.
Figure 07
Conclusion
I hope you enjoyed this journey into the FOPE universe as much as I had writing this article series. At the end of the day you may realize that using a solution like this simplifies and improves your messaging environment without adding extra layers on your network.
If you would like to read the other parts in this article series please go to:
