Exchange Online Migration: Single Tenant with Multiple Exchange Endpoints
Clash Royale CLAN TAG#URR8PPP
Planning out a migration for 3 separate Exchange Servers/AD forests with no AD trusts configured; there is site-to-site connectivity by way of IPSec tunnels.
These three mail servers share an email domain by way of Internal Relays (configured for MX lookup, which points to a central ISP-owned Linux mail server with forwarding aliases setup for each recipient's respective Exchange Server).
My question is, can you setup multiple Exchange endpoints for a single Exchange Online tenant? Hybrid Full/Minimal or Cutover? Are there 3rd-party solutions that can do this if not?
microsoft-office-365 exchange-migration
add a comment |
Planning out a migration for 3 separate Exchange Servers/AD forests with no AD trusts configured; there is site-to-site connectivity by way of IPSec tunnels.
These three mail servers share an email domain by way of Internal Relays (configured for MX lookup, which points to a central ISP-owned Linux mail server with forwarding aliases setup for each recipient's respective Exchange Server).
My question is, can you setup multiple Exchange endpoints for a single Exchange Online tenant? Hybrid Full/Minimal or Cutover? Are there 3rd-party solutions that can do this if not?
microsoft-office-365 exchange-migration
add a comment |
Planning out a migration for 3 separate Exchange Servers/AD forests with no AD trusts configured; there is site-to-site connectivity by way of IPSec tunnels.
These three mail servers share an email domain by way of Internal Relays (configured for MX lookup, which points to a central ISP-owned Linux mail server with forwarding aliases setup for each recipient's respective Exchange Server).
My question is, can you setup multiple Exchange endpoints for a single Exchange Online tenant? Hybrid Full/Minimal or Cutover? Are there 3rd-party solutions that can do this if not?
microsoft-office-365 exchange-migration
Planning out a migration for 3 separate Exchange Servers/AD forests with no AD trusts configured; there is site-to-site connectivity by way of IPSec tunnels.
These three mail servers share an email domain by way of Internal Relays (configured for MX lookup, which points to a central ISP-owned Linux mail server with forwarding aliases setup for each recipient's respective Exchange Server).
My question is, can you setup multiple Exchange endpoints for a single Exchange Online tenant? Hybrid Full/Minimal or Cutover? Are there 3rd-party solutions that can do this if not?
microsoft-office-365 exchange-migration
microsoft-office-365 exchange-migration
asked Feb 27 at 19:45
gravyfacegravyface
12.3k145494
12.3k145494
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
This is possible in general, although quite tricky to get right; here's the only offical documentation I was able to find: https://docs.microsoft.com/en-us/previous-versions/exchange-server/exchange-150/jj873754(v=exchg.150). It refers to Exchange 2013 and it's marked as "no longer updated content", but it should still be valid.
Here is another unofficial but more recent article:
https://practical365.com/blog/exchange-multi-forest-hybrid-tips-and-tricks/
However, you are using the same SMTP domain in all forests, and this adds a whole lot of issues, not only for mail routing (which probably can still be made to work) but mainly for the Autodiscover service, which can't possibly work for all your users in this scenario, since every Exchange forest doesn't know about users in the other ones; and without a properly working Autodiscover service, lots of things are going to break.
My suggestion would be to perform three cutover migrations in sequence; setting up and running a three-forests hybrid environment where all forests share the same SMTP domain is going to be painful, if it works at all.
Was thinking the same thing: logistically, being in 3 places at once, would be near impossible anyways. There will be a net new AD forest setup centrally, which is what we will be running DirSync on for password synchronization, but getting all those profiles flipped over is going to be a helluva lot of boot prints...
– gravyface
Feb 27 at 21:01
Yes, migrating everything to a single forest and then going to hybrid is the cleanest solution; I didn't mention it only because I was assuming you didn't want to add another forest to this mess :) But if you have enough time and resources, it's better indeed.
– Massimo
Feb 27 at 22:25
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "2"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f956031%2fexchange-online-migration-single-tenant-with-multiple-exchange-endpoints%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
This is possible in general, although quite tricky to get right; here's the only offical documentation I was able to find: https://docs.microsoft.com/en-us/previous-versions/exchange-server/exchange-150/jj873754(v=exchg.150). It refers to Exchange 2013 and it's marked as "no longer updated content", but it should still be valid.
Here is another unofficial but more recent article:
https://practical365.com/blog/exchange-multi-forest-hybrid-tips-and-tricks/
However, you are using the same SMTP domain in all forests, and this adds a whole lot of issues, not only for mail routing (which probably can still be made to work) but mainly for the Autodiscover service, which can't possibly work for all your users in this scenario, since every Exchange forest doesn't know about users in the other ones; and without a properly working Autodiscover service, lots of things are going to break.
My suggestion would be to perform three cutover migrations in sequence; setting up and running a three-forests hybrid environment where all forests share the same SMTP domain is going to be painful, if it works at all.
Was thinking the same thing: logistically, being in 3 places at once, would be near impossible anyways. There will be a net new AD forest setup centrally, which is what we will be running DirSync on for password synchronization, but getting all those profiles flipped over is going to be a helluva lot of boot prints...
– gravyface
Feb 27 at 21:01
Yes, migrating everything to a single forest and then going to hybrid is the cleanest solution; I didn't mention it only because I was assuming you didn't want to add another forest to this mess :) But if you have enough time and resources, it's better indeed.
– Massimo
Feb 27 at 22:25
add a comment |
This is possible in general, although quite tricky to get right; here's the only offical documentation I was able to find: https://docs.microsoft.com/en-us/previous-versions/exchange-server/exchange-150/jj873754(v=exchg.150). It refers to Exchange 2013 and it's marked as "no longer updated content", but it should still be valid.
Here is another unofficial but more recent article:
https://practical365.com/blog/exchange-multi-forest-hybrid-tips-and-tricks/
However, you are using the same SMTP domain in all forests, and this adds a whole lot of issues, not only for mail routing (which probably can still be made to work) but mainly for the Autodiscover service, which can't possibly work for all your users in this scenario, since every Exchange forest doesn't know about users in the other ones; and without a properly working Autodiscover service, lots of things are going to break.
My suggestion would be to perform three cutover migrations in sequence; setting up and running a three-forests hybrid environment where all forests share the same SMTP domain is going to be painful, if it works at all.
Was thinking the same thing: logistically, being in 3 places at once, would be near impossible anyways. There will be a net new AD forest setup centrally, which is what we will be running DirSync on for password synchronization, but getting all those profiles flipped over is going to be a helluva lot of boot prints...
– gravyface
Feb 27 at 21:01
Yes, migrating everything to a single forest and then going to hybrid is the cleanest solution; I didn't mention it only because I was assuming you didn't want to add another forest to this mess :) But if you have enough time and resources, it's better indeed.
– Massimo
Feb 27 at 22:25
add a comment |
This is possible in general, although quite tricky to get right; here's the only offical documentation I was able to find: https://docs.microsoft.com/en-us/previous-versions/exchange-server/exchange-150/jj873754(v=exchg.150). It refers to Exchange 2013 and it's marked as "no longer updated content", but it should still be valid.
Here is another unofficial but more recent article:
https://practical365.com/blog/exchange-multi-forest-hybrid-tips-and-tricks/
However, you are using the same SMTP domain in all forests, and this adds a whole lot of issues, not only for mail routing (which probably can still be made to work) but mainly for the Autodiscover service, which can't possibly work for all your users in this scenario, since every Exchange forest doesn't know about users in the other ones; and without a properly working Autodiscover service, lots of things are going to break.
My suggestion would be to perform three cutover migrations in sequence; setting up and running a three-forests hybrid environment where all forests share the same SMTP domain is going to be painful, if it works at all.
This is possible in general, although quite tricky to get right; here's the only offical documentation I was able to find: https://docs.microsoft.com/en-us/previous-versions/exchange-server/exchange-150/jj873754(v=exchg.150). It refers to Exchange 2013 and it's marked as "no longer updated content", but it should still be valid.
Here is another unofficial but more recent article:
https://practical365.com/blog/exchange-multi-forest-hybrid-tips-and-tricks/
However, you are using the same SMTP domain in all forests, and this adds a whole lot of issues, not only for mail routing (which probably can still be made to work) but mainly for the Autodiscover service, which can't possibly work for all your users in this scenario, since every Exchange forest doesn't know about users in the other ones; and without a properly working Autodiscover service, lots of things are going to break.
My suggestion would be to perform three cutover migrations in sequence; setting up and running a three-forests hybrid environment where all forests share the same SMTP domain is going to be painful, if it works at all.
edited Feb 27 at 22:23
answered Feb 27 at 20:17
MassimoMassimo
53.1k44168281
53.1k44168281
Was thinking the same thing: logistically, being in 3 places at once, would be near impossible anyways. There will be a net new AD forest setup centrally, which is what we will be running DirSync on for password synchronization, but getting all those profiles flipped over is going to be a helluva lot of boot prints...
– gravyface
Feb 27 at 21:01
Yes, migrating everything to a single forest and then going to hybrid is the cleanest solution; I didn't mention it only because I was assuming you didn't want to add another forest to this mess :) But if you have enough time and resources, it's better indeed.
– Massimo
Feb 27 at 22:25
add a comment |
Was thinking the same thing: logistically, being in 3 places at once, would be near impossible anyways. There will be a net new AD forest setup centrally, which is what we will be running DirSync on for password synchronization, but getting all those profiles flipped over is going to be a helluva lot of boot prints...
– gravyface
Feb 27 at 21:01
Yes, migrating everything to a single forest and then going to hybrid is the cleanest solution; I didn't mention it only because I was assuming you didn't want to add another forest to this mess :) But if you have enough time and resources, it's better indeed.
– Massimo
Feb 27 at 22:25
Was thinking the same thing: logistically, being in 3 places at once, would be near impossible anyways. There will be a net new AD forest setup centrally, which is what we will be running DirSync on for password synchronization, but getting all those profiles flipped over is going to be a helluva lot of boot prints...
– gravyface
Feb 27 at 21:01
Was thinking the same thing: logistically, being in 3 places at once, would be near impossible anyways. There will be a net new AD forest setup centrally, which is what we will be running DirSync on for password synchronization, but getting all those profiles flipped over is going to be a helluva lot of boot prints...
– gravyface
Feb 27 at 21:01
Yes, migrating everything to a single forest and then going to hybrid is the cleanest solution; I didn't mention it only because I was assuming you didn't want to add another forest to this mess :) But if you have enough time and resources, it's better indeed.
– Massimo
Feb 27 at 22:25
Yes, migrating everything to a single forest and then going to hybrid is the cleanest solution; I didn't mention it only because I was assuming you didn't want to add another forest to this mess :) But if you have enough time and resources, it's better indeed.
– Massimo
Feb 27 at 22:25
add a comment |
Thanks for contributing an answer to Server Fault!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f956031%2fexchange-online-migration-single-tenant-with-multiple-exchange-endpoints%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown