I have something of a conundrum with our company's Exchange environment. The current issues are not pressing, but at some point they will have to be dealt with and I want to get input on possible plans to deal with it.
Our situation is that two years ago, we made a determination to host our email in house with Exchange 2013. At the time, we did not have sufficient budget to purchase two servers, so Exchange and our DC went in on the same box. Yes, I understand
this is not recommended, but we did not have a choice at the time. Our topology also forced us into a configuration I've never been happy with. Specifically, our DC / Exchange is multihomed because it has one public facing IP address (I've managed
to deal with this issue by not allowing the public IP address to register in DNS). Despite these issues, we've had minimal problems once we understood what the challenges were and took steps to mitigate them.
Budgets have gotten better over the past two years, however, and I have more options at my disposal. We still have Server A, the Exchange 2013 / DC machine. We also now have Server B and Server C, both of which takes care of some other functions for us. Server A is a 2012R2 machine acting as a file server, Server C is a 2008R2 machine acting as an application server. Life would be easy if I could simply promote Server B or C to be a DC, transfer the FSMO roles to it, then demote Server A as a DC. Unfortunately, this is not supported by Microsoft: https://technet.microsoft.com/en-us/library/ms.exch.setupreadiness.warninginstallexchangerolesondomaincontroller%28v=exchg.150%29.aspx
"Demoting a domain controller to a member server isn’t supported."
I admit that it is irritating that Microsoft tells us that this is not supported, but then doesn't even bother to say why, but that's a discussion for a different thread.
So, to recap, the current environment: Server A hosts Exchange and DC, and has a private LAN address and a public facing IP address for mail flow. Server B is a file server only, and has only a private LAN address. Server C hosts a custom application
that we are retiring within the next year and also has only a private lan IP address.
My goal is to separate Exchange from the DC. Here's my current thought:
Step 1: Promote Server C to be a DC and transfer FSMO roles to it (our domain and forest function levels are already at 2008R2 levels. This should not cause a problem).
Step 2: Spin up a hyper-v VM on Server B and join it to the domain, then install Exchange 2013 on the VM as part of the already existing Exchange organization. The VM will initially have only a private lan IP address.
At this point is where I get fuzzy. I search for information on what configurations you can use when running two Exchange servers in one organization, and I'm not getting clear answers. So if what I say from here is wrong, don't be shocked :)
Step 3: Bring down mail flow entirely. We have a smart host that hands off incoming email to Exchange and I can make it hold incoming email in its queue for as long as needed.
Step 4: Move all mailboxes from Server A to Exchange on Server B. Move all public folders (we don't actually have any right now) to Server B. Move offline address book to Server B. Change URLs for OWA, ActiveSync, ECP to point to Server
B.
Step 5: Make whatever changes needed to receive and send connectors so that the new Exchange server can handle mail flow in the same fashion as the original Exchange installation on Server A.
Step 6: Modify internal DNS to point clients to new Exchange installation on Server B. Shutdown Server A. Test mail flow internally for functionality.
Step 7: Assign the public facing IP address of Server A to the new Exchange installation on Server B.
Step 8: Test mail flow from external sources, inbound and outbound.
Step 9: Up until this point, I should be able to roll back to my original configuration without much difficulty if something goes wrong. After this step, changes occur that can't be undone.
Step 10: Boot up Server A. Uninstall Exchange 2013 from Server A.
Step 11: Test mail flow again for thoroughness.
Step 12: Demote Server A to member server. Remove Server A from the domain.
Step 13 (maybe...I don't know if this is necessary or not. Input would be appreciated): Reinstall a fresh copy of Windows Server 2012 on Server A.
Step 14: Join Server A to domain as a member server.
Step 15: Install Exchange Server 2013 on Server A.
Step 16: Repeat the migration steps. Move all mailboxes back to Exchange on Server A, move offline address book, change URLs for appropriate virtual directories, reconfigure connectors, modify internal DNS to point to Server A, shutdown Exchange VM on Server B, test internal mail flow, assign public facing IP address to Server A, test external mail flow.
Step 17: Boot up Exchange VM on Server B. Uninstall Exchange 2013 from hyper-v VM on Server B.
Step 18: Remove hyper-v VM on Server B from domain.
Step 19: Kill hyper-v VM on Server B.
Naturally, this is a long arduous process, fraught with the possibility of failures. Many mailbox database backups will be made along the way, undoubtedly. If there is an easier way that I'm missing, I'm open to it. One other idea I considered was setting up High Availability for both Exchange servers, on the idea that all data would replicate between them, then bringing down Exchange on Server A, leaving the VM on server B to handle everything.