Forum Discussion
Will server to server migration work cross-domain/cross-active directory?
Back in 2016, I upgraded a client from Exchange 2008R2 to Exchange 2016. The way I did it was "the textbook way" I built the new Exchange 2016 server on the same network as the 2008R2 server, and migrated the mailboxes from the old server to the new server, using the migration tool in the ECP interface, then deinstalled the server. It was a pretty cake migration except for one problem - the internal AD domain name was "wonkulating.com" however the client had failed to maintain public registration for that domain, and had registered "wonkulatinggronkulator.com" for use on the Internet. So I set it up so that all internal and external access was to "email address removed for privacy reasons" User were happy, and the IT dept was able to kick the migration can down the road again.
Well fast forward a decade. Now I'm an employee for the former client and worse I manage the IT group there - so my can-kicking bandaid has come back to haunt me now that it's time to update to exchange SE. (it also adds to the fun that there's a couple hundred more users on the network than there were a decade ago) I decided to cut the Gordion knot and kill off "wonkulating.com" since there's not a snowball's chance in hades we could afford to buy it now. So I built a new AD for wonkulatinggronkulator.com, and did the jiggery pokery with the DNS servers and setup trust between the forests and so on and now, servers on both domains are happy happy, I can apply both wonkulating.com and wonkulatinggronkulator.com security objects to server filesystems, users can login to either domain at any workstation regardless of what domain the workstation was joined to, and so on, and we are getting ready to migrate the users and workstations off the old AD and on to the new AD.
My question to all of you is this. I'm planning on installing Exchange SE into the new AD forest wonkulatinggronkulator.com and we will move the users over in groups of 10 or 20 or so, so that staff can make sure everyone is happy, can login, get at their files, etc. But what I am wondering is if the exchange servers will cooperate with each other. I'm not using ADMT or any of that to move user objects over to the new server so userIDs will exist in parallel for some time to allow a gradual migration of file and application servers. (we are too big now for the come-in-on-weekend-and-hose-everything-up-in-a-mad-rush-migration-fueled-with-pizza-and-mountain-dew routine) It would be very nice to just kick off a migration job on one of the mailservers and have the inbox copied over, but if I have to I can tear out the mailbox on the old server into a PST file and jam it into the new server via import.
Documentation on microsoft.com seems to say at some points the servers will cooperate with each other and at other points it seems to say each mailserver is atomic. Like most orgs we have a bastion host mailserver that touches the actual Internet, the exchange server is only allowed to provide OWA services to the Internet, while the bastion host server (running Linux, by the way) does the actual heavy lifting of spam scanning and filtering out scam mails. Only cleaned mail is passed to the on-prem exchange server. So if the servers -won't- cooperate cross-forest, then I can adjust mail routing on a per-user basis on the bastion host to send incoming mail to the server in wonkulating.com or the server in wonkulatinggronkulator.com depending on which server they are on.
Technically, the ACTUAL user ID on the old AD is WONKULATING\exampleuser while on the new AD it will be WONKULATINGGRONKULATOR\exampleuser, so the servers SHOULD be smart enough to know they are different userIDs - except that the server on wonkulating.com was hacked up by me a decade ago to believe it was authoritative for BOTH "email address removed for privacy reasons" and "email address removed for privacy reasons" email addresses and that they were the same userID basically. So, I don't know what's going to happen until I try it and all of the documentation I can find on this matter is pretty fluffy, as it assumes you are moving from a domain name you own to a different domain name you own because you bought a company or something, or you are moving from one mailserver to the other inside of the same forest/domain.
Lastly, suggestions to install Exchange SE into wonkulating.com then move it later into wonkulatinggronkulator.com will be /dev/nulled immediately, I'm done kicking the can down the road. There's more than 20 years of garbage in the wonkulating.com AD and the nonsense described here is just the tip of the iceberg. (you should see the GPO's in wonkulating.com, simply horrifying)
Thanks!
4 Replies
Yes I have looked at the tooling and it's a non-starter for many reasons, expense not the least of them. But I don't want to get into ripping the commercial tooling apart. I'll just say that I've yet to see any commercial Exchange add-on program that I cannot duplicate with a Copilot-written PowerShell script running in Exchange Management Shell. As you are aware the analysis programs and reports that come with Exchange are nonexistent. So if you want to produce pretty graphs of what's going on in your email environment to wow the C-Suite, you better learn how to write PowerShell. And as it turns out, after Microsoft came out with Copilot, you don't need to do that you just need to learn how to talk to Copilot and tell it what you want it to script and with a few hours effort on your part, you will get usable PowerShell scripts out of it to do just that.
Fundamentally I'm a lazy admin. If I can have the computer do the work, I do it. If I can have the computer write the tool I need to have the computer do the work, that's even better. And so far I've been able to do that. I can coax Copilot to write me a batch migration script that will copy a group of mailboxes from one server to the other. The actual migration of mailboxes is the easy part.
The problem is to the world for the last 3 decades the only legitimate email addresses for this org are the wonkulatinggronkulator.com ones. So, in any phased move, there will be legitimate email addresses in wonkulatinggronkulator.com on BOTH the old and the new Exchange servers, with the old server in a separate forest from the new server. In other words, BOTH servers believe they are authoritative for wonkulatinggronkulator.com
In a "same org, different servers" AD, all in one forest, you can tell 1 server "you are the public face" and queries from Outlook, from Outlook Web Access, and so on, will all go through 1 server which will proxy them for the other server - the public server knows if the mailbox is on itself, or on the other server, and if it's on the other server, it will get the emails from the other server to present them to the user.
But in this case, that's not, apparently, going to work. At least not any way that I can see to do it.
Hi, the old "same org, new Exchange server, move mailboxes" method only works when both Exchange servers are in the same Exchange organization and Active Directory forest.
If the new server is in a different AD forest/domain with a separate Exchange organization, it becomes a cross-forest migration. In that case you need a different plan:
1. Establish name resolution and network connectivity between forests.
2. Decide whether you need AD trust, ADMT, or identity matching.
3. Use cross-forest mailbox moves or a third-party migration tool.
4. Plan mail flow, Autodiscover, certificates, and accepted domains carefully.
5. Move clients after mailbox and namespace cutover.
So yes, it can be done, but it is not the same as a same-org Exchange upgrade.
Hi Jamony thank you for responding!
"the old "same org, new Exchange server, move mailboxes" method only works when both
Exchange servers are in the same Exchange organization and Active Directory forest."
This is what I have felt all along was the correct answer - but the problem is I can't FIND any authoritative statement in any of the Microsoft documentation that just states this plainly. As I stated: "Documentation on microsoft.com seems to say at some points the servers will cooperate with each other and at other points it seems to say each mailserver is atomic"
This is what I'm tearing my hair out on. It's like Microsoft wants to play both sides. They want to make baloney marketing-driven claims "this is so easy the mailservers will always talk to each other" and they do this in some documents while in others they say "no you can't"
Do you have ANY authoritative link anywhere in the MS docs that says this is not possible flat out?
"If the new server is in a different AD forest/domain with a separate Exchange organization, it becomes a cross-forest migration. In that case you need a different plan:"
Yes it is absolutely in a different AD forest/domain. As I said: "the ACTUAL user ID on the old AD is WONKULATING\exampleuser while on the new AD it will be WONKULATINGGRONKULATOR\exampleuser"
WONKULATING is not the same forest as WONKULATINGGRONKULATOR (the fact the names are not the same should have clarified this)
"Establish name resolution and network connectivity between forests."
Completed. I can query any DNS server on the network in either forest/domain for machinename.wonkulating.com and machinename.wonkulatinggronkulator.com and get proper name resolution.
"Decide whether you need AD trust, ADMT, or identity matching."
Completed. A trust exists between the 2 domains/forests, a user can login to one domain and access files on servers on the other domain without having to authenticate into the other domain, as long as proper rights are applied to the files/directories. Microsoft no longer supports ADMT and after looking at it, there were far too many "gotchas" to mess around with it. As I said " I'm not using ADMT or any of that to move user objects over to the new server so userIDs will exist in parallel for some time to allow a gradual migration of file and application servers."
"Use cross-forest mailbox moves"
The description of THIS process is in these 3 links I found:
https://www.petenetlive.com/KB/Article/0001356
https://learn.microsoft.com/en-us/exchange/architecture/mailbox-servers/prep-mailboxes-for-cross-forest-moves
https://learn.microsoft.com/en-us/exchange/recipients/mailbox-moves
According to this, I can only issue a "pull" request from the new Exchange SE mailserver to the old 2016 mailserver for a cross-forest move. A "push" from Exchange 2016 to Exchange SE is not supported.
The first stumbling block here is the NEW mailserver -newmail.wonkulatinggronkulator.com- must be able to make a SSL connection to the OLD mailserver -exchange.wonkulating.com- But, since the old mailserver does NOT have a valid SSL certificate (since the org is using public certificates issued from public CAs who will of course not add wonkulating.com as an additional name into the certificate since we don't own it) it can't do that.
The OLD mailserver has a certificate with exchange.wonkulatinggronkulator.com, of course, and the new mailserver could contact it using that name. But, while a users ACTUAL active directory email address is user1 art wonkulating.com they have a secondary alias of user1 art wonkulatinggronkulator.com on the old mailserver.
So, even if we use MRS to make a migration, and it works, that global wonkulatinggronkulator.com needs to move to the new mailserver. That means before starting a MRS migration of a mailbox, that global chance must be made - which the moment it is - the old mailserver stops taking mail for all the users and the new mailserver can't take mail for the users because the mailboxes haven't been moved over yet. And the certificate likely becomes invalid.
Chicken, meet egg.
Basically, I'd have to stop incoming mail and then move all boxes at once. But there's more fun with this in store I'll get to later.
"or a third-party migration tool."
Any tool like this would be written to use the APIs that exist for MRS (Mailbox Replication Service) Proxy, with is what the textbook commands for cross-forest migration use, and would fail if those commands would not work. So it gets back once more to the certificate issue and the aliasing issue.
In summary, if I can't run New-MoveRequest in Exchange Management Shell, due to certificate issues like this, or the mailboxes not having the same GUID, then I can't run a third-party tool.
"Plan mail flow, Autodiscover, certificates, and accepted domains carefully."
I can't have one server forward mail to the other server because all incoming mail has destination email addresses of wonkulatinggronkulator.com so both servers believe the mail is supposed to go to itself, not to the other server. So, mail flow is scotched.
"Move clients after mailbox and namespace cutover."
In other words to borrow a line from "Tron Legacy," a full-on sprint to the new mailserver for all 300 mailboxes.
The moment I cut namespace over the old mailserver stops working. The only way to do this is to define an outage period, have all incoming mail spool on the bastion host, shut down incoming mail to port 25, tell all users any mail they send during the outage period won't be delivered and to GTF off the old mailserver and stay off of it, then try to migrate all mailboxes over during the outage period, then open back up and cross my fingers we can get all of them migrated over during the outage period.
There's a good chance I'm afraid that settings in all Outlook clients will be broken and we will have to go to each Outlook client and create a new Outlook profile and reconnect Outlook to the new mailserver. I say that because my experience is Outlook stores the real AD name of the mailserver in it's profile.
It just seems to me the only possible way to do this gradually, a batch at a time, is to do as I already said "I can adjust mail routing on a per-user basis on the bastion host to send incoming mail to the server in wonkulating.com or the server in wonkulatinggronkulator.com depending on which server they are on."
Since both servers think they are authoritative for wonkulatinggronkulator.com, it would get the mail flow properly done. But this does mean the servers have to remain independent - each thinking it's authoritative for wonkulatinggronkulator.com - even though each is in a different AD forest.
Worth considering: have you looked at dedicated Exchange migration tooling? Given the cross-domain complexity you are dealing with, tools in this space can handle mailbox migrations across different AD forests without requiring you to touch the server infrastructure itself.
From what you describe, you are building a net-new AD and Exchange environment in wonkulatinggronkulator.com while keeping wonkulating.com running in parallel. A migration tool lets you select mailboxes individually and schedule them in batches, which aligns well with your groups-of-10-or-20 approach, and sidesteps the PST export/import fallback entirely.
