Exchange - Hybrid?

[Sadiq_to222]

Hi Everyone,

 

Happy new year!

 

For a home project, I have setup an on premise Exchange server in a Hyper-V VM.

 

All working fine but just wanting to look at mail flow.

 

Anyways, going into detail, I currently have an office 365 tenant, but I like the management of Exchange, so can I use the hybrid tool to setup the link between my office 365 tenant, and then route all incoming emails from my exchange server through office 365 although I am not going to migrate any mailboxes? What connectors will I need to have setup? DNS Records? Azure AD Connect?

 

Sorry for all the questions, it's my first time doing this on my own at home.

 

Thanks

[chaplic]

In general the architecture you propose is doable but you will likely struggle to ship mail from a home broadband IP into office365 and you won’t be able to fix it with any combo of allow lists and spf records.

 

But let’s just assume your ISPs is not on the list of consumer IP adddress. Register an A record pointing to your home IP, and MX record for that domain pointing at the A record, and an SPF record which includes that IP and Office365 includes.

 

Then you setup Azure AD Connect, setup Exchange hybrid, in SMTP routing set on prem to ship * to Office 365 then it should ‘just work’

[ITGURU]

It's completely do able. I had local exchange for testing and development running on home ip with ddns and migrated to office 365 business account no problem.

[Sadiq_to222]

It's completely do able. I had local exchange for testing and development running on home ip with ddns and migrated to office 365 business account no problem.

 

Ah right so once you’ve setup the hybrid tool, it’s just the send and receive connectors on local and office 365 exchange which need configuring? And the dns records

[ITGURU]

Ah right so once you’ve setup the hybrid tool, it’s just the send and receive connectors on local and office 365 exchange which need configuring? And the dns records

Yes so that mail flows between both but obviously once everything is migrated you can change mx records to 365

[Sadiq_to222]

Do I not need to change the MX Records anyhow?

 

Basically the reason why I am doing this is because when I send emails from my local exchange to a hotmail.com account for example, it goes straight to the junk folder.

 

Therefore, If I setup the send connectors and have Office 365 dns records, can I send and receive emails from my local exchange mailboxes but sending through office 365 records?

 

Thanks

[ITGURU]

Do I not need to change the MX Records anyhow?

 

Basically the reason why I am doing this is because when I send emails from my local exchange to a hotmail.com account for example, it goes straight to the junk folder.

 

Therefore, If I setup the send connectors and have Office 365 dns records, can I send and receive emails from my local exchange mailboxes but sending through office 365 records?

 

Thanks

 

Depends on if you are removing exchange completely. As long as you have mailflow rules in place from local to 365 and 365 to local, your MX can point to 365 OR local exchange.

If you are removing local exchange entirely then yes just change MX records to 365.

[KK20]

this is normal use for a company transitioning mail. in fact it is what we did. Unless you are migrating active directory completely then you are stuck with a local instance of exchange for management anyway. This is what we did:

 

1) working onsite exchange and AD

2) created 365 tenant

3) sync ad with 365 tenant (AD connect)

4) setup hybrid but leave all mail flow as it is - leave MX and SPF etc - so all mail is flowing into onsite, all mailboxes are onsite. 365 tenant is aware that onsite mailboxes and server exists. The hybrid setup took care of all the connectors.

5) migrate a couple of mailboxes and test

at this point mail is still coming into the onsite then going up to 365 as necessary. If I send an email using a 365 migrated mailbox, the mail still egresses from the onsite exchange server. Likewise incoming mail still goes to onsite first. The only different part is that OWA will not work for migrated accounts, you need to use the 365 web portal - this meant we needed two web links for people depending on whether they were migrated or not.

6) migrate more mailboxes and test

7) change mailflow to go into 365 with MX, SPF, rules, dkim, anti spam etc

at this point all mail goes to 365 regardless of mailbox location. We could theoretically shutdown the exchange server and mail will work for all those migrated but not for those with onsite accounts.

8) lock down firewall for onsite exchange so it can only communicate with 365

9) migrate rest of mailboxes

10) semi decommission exchange (compact database, compact drive etc)

11) at this point I can shut down the exchange server unless I need to do administrative tasks. Email flow is all to 365, mailboxes are all in 365, although the connectors are in place we have no onsite mailboxes (well, I think there are a couple for test or service purposes but no mail flows to them anyway)

 

I still have a relay available on the local exchange server for a UPS and photocopier that wont accept 365 accounts. I could well have missed a step but this was done a number of years ago!

 

Basically you dont need to change a thing with hybrid if you dont want to. You could leave all the mailboxes and flow on the local exchange server should you require and only move a couple of test mailboxes as you see fit. Or even have all the mail flow into and out of 365 but leave the mailboxes local should you wish. A couple of gotchas. Dont expect AD to automatically link new 365 mailboxes to the onsite AD mail attributes, if you create a new onsite AD account, this will then sync to AAD normally, a 365 mailbox will be created but not necessarily synced back to the correct onsite AD attributes, you need to periodically update the onsite AD with AAD/365 mailbox - I use Enable-RemoteMailbox and Set-RemoteMailbox with the GUIDs as appropriate.

 

Dont forget that everything needs to work to begin with. I know this sounds silly but your certificates need to be trusted, an external "proper" domain needs to be used for your servers, you need to have control of your DNS so you can change MX later, outlook needs to work with the same domains, tenant needs to trust the domains. We use letsencrypt so that will do just fine for your SSL.

Edited January 3, 2023 by KK20

[ITGURU]

this is normal use for a company transitioning mail. in fact it is what we did. Unless you are migrating active directory completely then you are stuck with a local instance of exchange for management anyway. This is what we did:

 

1) working onsite exchange and AD

2) created 365 tenant

3) sync ad with 365 tenant (AD connect)

4) setup hybrid but leave all mail flow as it is - leave MX and SPF etc - so all mail is flowing into onsite, all mailboxes are onsite. 365 tenant is aware that onsite mailboxes and server exists. The hybrid setup took care of all the connectors.

5) migrate a couple of mailboxes and test

at this point mail is still coming into the onsite then going up to 365 as necessary. If I send an email using a 365 migrated mailbox, the mail still egresses from the onsite exchange server. Likewise incoming mail still goes to onsite first. The only different part is that OWS will not work for migrated accounts, you need to use the 365 web portal - this meant we needed two web links for people depending on whether they were migrated or not.

6) migrate more mailboxes and test

7) change mailflow to go into 365 with MX, SPF, rules, dkim, anti spam etc

at this point all mail goes to 365 regardless of mailbox location. We could theoretically shutdown the exchange server and mail will work for all those migrated but not for those with onsite accounts.

8) lock down firewall for onsite exchange so it can only communicate with 365

9) migrate rest of mailboxes

10) semi decommission exchange (compact database, compact drive etc)

11) at this point I can shut down the exchange server unless I need to do administrative tasks. Email flow is all to 365, mailboxes are all in 365, although the connectors are in place we have no onsite mailboxes (well, I think there are a couple for test or service purposes but no mail flows to them anyway)

 

I still have a relay available on the local exchange server for a UPS and photocopier that wont accept 365 accounts. I could well have missed a step but this was done a number of years ago!

 

Basically you dont need to change a thing with hybrid if you dont want to. You could leave all the mailboxes and flow on the local exchange server should you require and only move a couple of test mailboxes as you see fit. Or even have all the mail flow into and out of 365 but leave the mailboxes local should you wish.

 

Dont forget that everything needs to work to begin with. I know this sounds silly but your certificates need to be trusted, an external "proper" domain needs to be used for your servers, you need to have control of your DNS so you can change MX later, outlook needs to work with the same domains, tenant needs to trust the domains. We use letsencrypt so that will do just fine for your SSL.

You no longer need local exchange for administrative tasks once migrated. not had any issues inheriting sites where server is decommissioned completely.

[KK20]

Do you have a source for that?

 

https://techcommunity.microsoft.com/t5/exchange-team-blog/removing-your-last-exchange-server-faq/ba-p/3455411

 

MS still advise to keep a local exchange even with the new tools - i.e. dont actually remove the server as it is intrinsically linked to onsite AD. So I suppose you can run the new tools and mothball your exchange server, just never power that VM on again :-)

Edited January 3, 2023 by KK20

[TechMonkey]

Do you have a source for that?

 

https://techcommunity.microsoft.com/t5/exchange-team-blog/removing-your-last-exchange-server-faq/ba-p/3455411

 

MS still advise to keep a local exchange even with the new tools - i.e. dont actually remove the server as it is intrinsically linked to onsite AD.

 

They advise, but it is not needed. You can leave the AD bits intact while removing Exchange. The only annoyance is having to manage some email bits in Attribute Editor.

[3s-gtech]

Some interesting points. I’d thought about moving all MX records to point at 365 instead of onsite, so that mail flow is independent of our onsite server (which I keep for management, relay, and a couple of onsite mailboxes)

 

Is it really that simple, despite MS advising to keep the onsite server in the mail flow?

 

It’d be nice to not need commercial certs for it too - I did use LE for a while but due to the 3 month expiry and me not being able to get automation to work properly, it was a mare.

[chaplic]

Some interesting points. I’d thought about moving all MX records to point at 365 instead of onsite, so that mail flow is independent of our onsite server (which I keep for management, relay, and a couple of onsite mailboxes)

 

Is it really that simple, despite MS advising to keep the onsite server in the mail flow?

 

It’d be nice to not need commercial certs for it too - I did use LE for a while but due to the 3 month expiry and me not being able to get automation to work properly, it was a mare.

MS have never recommended keeping an onsite server in the mail flow.

 

You should also check if you have centralised mail transport in place which is an easy-to-make bad decision which means email arriving at O365 and sending out will go through on-prem.

 

It's also a good time to consider autodiscover, does that point at on prem boxes and what about your autodiscover SCP?

 

It is pretty straightforward to point where your MX delivers mail to, one thing to bear in mind is what environment is authoritative for email addresses. If O365 thinks its authoritative for email and you send email direct to O365, there is a risk external email will not hit your on premise mailboxes. Also, email that should NDR will NDR only because it gets in a routing loop.

 

Finally if you have something in front of exchange to receive email and you intend to keep it, you need to configure EXO to 'know' about that service otherwise everything will appear spoofed.