Forum Discussion
Solved
Moving mx records to O365
Hello We are medium sized company, around 7000 mailboxes. We own several domains that we accept email for. Currently all mx records point to IronPorts. The emails are go through the messaging hy...
- You're so welcome!
So that's the beauty of TABL (see above link) - it will be honoured and is the correct new way to allow senders that are caught incorrectly, rather than in the spam filter policies or transport rules. (Please also do an admin submission!) - this way you can use secure presets and not need to edit them.
I'd like to preface my reply by pointing out that I'm 4 years away from Asyncos; the last release note in my library is for version 11 and I can't remember if I implemented that or was still on 10 when I moved my MXs over to O365.
Definitely move a smaller domain first, just to get an idea of the differences in the two services and familiarity with the tools. With on-prem appliances you could make changes instantly and would have an accurate idea of message delivery within 3 to 5 minutes of the fact. With the cloud, you are waiting up to 30 minutes for mail flow rule changes and your delivery information is "near real-time" which can mean anything from minutes to hours.
How much work you have to do depends on how much effort you put into those IronPort configs. If you made your HAT more aggressive then you will probably want to set your SCL and BLC thresholds to be a little lower. If you differentiated your service (for example to allow devs or techs to handle file types you don't want near your ordinary recipients) then one-size-fits-all policies aren't going to work and you are back to writing policies for groups. If you ran a variety of different quarantines then now there's only one. You can differentiate items placed in the hosted quarantine by mail flow rules by adding an action to a rule to add a subject line stamp, but you can't do anything similar for policies.
If you used the Cisco Reporting plug-in for Outlook then that's got to go and be replaced by the Report Message add-in. That in turn may need a test as it's a bit picky on resources and uses a few things not in the published O365 resource list. If you enabled End User Quarantine, be aware that all Microsoft equivalents are serious phishing targets. If you ever regretted enabling EUQ, now could be an opportunity to reconsider.
You mention a lot of safe and blocked senders. Have you kept records of why they were included in their lists? Are we talking user decisions or tech decisions? Most tellingly, when did you last find time to review those listing? Safe list entries necessitated by sending organisation ineptitude will probably need to be replicated. For blocked senders, based on my own experience 4 years ago I would surprisingly agree with Ben's posting. I started with a reset of my block position and since then have only reinstated IP range blocks on a dozen ESPs. Again, having Report Message available and familiar to your recipients on day 1 will make that process easier.
Bear in mind that with Cisco the Talos list is transparent. The equivalent Microsoft edge protection is highly opaque, and you may not even be aware that it is blocking a sender unless they contact your organisation by other means. Your IronPort service will give you an aging view on what sending IP and envelope they used to use, after which the problem may become obvious. Your spam inflow is likely to radically change (as opposed to getting better or worse) when your MXs move. Mine did.
In summary, don't look for exact equivalences between Asyncos and MDO because you won't always find or need one. Accept that your organisation has chosen to use O365 and that it is going to be a major change in itself. No-one should expect things to be exactly as they were before.
Definitely move a smaller domain first, just to get an idea of the differences in the two services and familiarity with the tools. With on-prem appliances you could make changes instantly and would have an accurate idea of message delivery within 3 to 5 minutes of the fact. With the cloud, you are waiting up to 30 minutes for mail flow rule changes and your delivery information is "near real-time" which can mean anything from minutes to hours.
How much work you have to do depends on how much effort you put into those IronPort configs. If you made your HAT more aggressive then you will probably want to set your SCL and BLC thresholds to be a little lower. If you differentiated your service (for example to allow devs or techs to handle file types you don't want near your ordinary recipients) then one-size-fits-all policies aren't going to work and you are back to writing policies for groups. If you ran a variety of different quarantines then now there's only one. You can differentiate items placed in the hosted quarantine by mail flow rules by adding an action to a rule to add a subject line stamp, but you can't do anything similar for policies.
If you used the Cisco Reporting plug-in for Outlook then that's got to go and be replaced by the Report Message add-in. That in turn may need a test as it's a bit picky on resources and uses a few things not in the published O365 resource list. If you enabled End User Quarantine, be aware that all Microsoft equivalents are serious phishing targets. If you ever regretted enabling EUQ, now could be an opportunity to reconsider.
You mention a lot of safe and blocked senders. Have you kept records of why they were included in their lists? Are we talking user decisions or tech decisions? Most tellingly, when did you last find time to review those listing? Safe list entries necessitated by sending organisation ineptitude will probably need to be replicated. For blocked senders, based on my own experience 4 years ago I would surprisingly agree with Ben's posting. I started with a reset of my block position and since then have only reinstated IP range blocks on a dozen ESPs. Again, having Report Message available and familiar to your recipients on day 1 will make that process easier.
Bear in mind that with Cisco the Talos list is transparent. The equivalent Microsoft edge protection is highly opaque, and you may not even be aware that it is blocking a sender unless they contact your organisation by other means. Your IronPort service will give you an aging view on what sending IP and envelope they used to use, after which the problem may become obvious. Your spam inflow is likely to radically change (as opposed to getting better or worse) when your MXs move. Mine did.
In summary, don't look for exact equivalences between Asyncos and MDO because you won't always find or need one. Accept that your organisation has chosen to use O365 and that it is going to be a major change in itself. No-one should expect things to be exactly as they were before.