One of the gotchas you may encounter when migrating mailboxes to Exchange Online is none registered Accepted Domains in Exchange Online. For example you may encounter the below error;
ERROR: Migration Permanent Exception: You can’t use the domain because it’s not an accepted domain for your organization –> You can’t use the domain because it’s not an accepted domain for your organization.
This maybe due to an email alias on a particular mailbox or all your organisation mailboxes due to an Email Address Policy. When migration to Exchange Online on you need to register all your accepted domains and remove any that may cause you the above issue.
In my case, I had domain.com registered with EXO but not extension.domain.com, as the alias was a legacy address you could be removed from the mailbox either using the Exchange Management Console or my favourite utility PowerShell.
Please ensure that Azure Active Directory has synchronize this change to your mailbox
When working with customer environments it is very possible a 3rd party appliance maybe involved and for the purpose of this post I will be directly looking at Mimecast to see how its configured to work with Office 365.
An Office 365 administrator logon with permission to create a send connector.
Your internal domains must already be registered with us.
A Mimecast administrator logon with at view permission to the Gateway | Accepted Email menu item.
Mimecast recommend that if you are switching MX records, this task must be completed 3 days before changing the MX record to point at Mimecast. The reason for this allows Mimecast to build your Auto Allow list, based on recipients your users send messages to.
This has a positive impact on inbound email delivery speed, because many senders will already be known and consequently not be subject to our greylisting security feature.
Updating the SPF Record for your Domain(s)
You must have an SPF record for the domain(s) registered with Office 365. When implementing Mimecast with Office 365, this record must be updated in the DNS zone for the relevant domain to include the following:
Replace with or add: v=spf1 include:_netblocks.mimecast.com ~all
Important Note: If your outbound email is temporarily coexisting with Mimecast, you can leave the v=spf1 include:spf.protection.outlook.com –all SPF record. However, it must be removed once all your outbound email is routed through Mimecast.
Configuring Outbound Routing
Important Note: Mimecast has known issue with browsers that are not Internet Explorer and its recommend this process is completed using Internet Explorer only. All other browsers tested have issues.
Recommendation: Disable or remove any other Outbound Send Connectors. Failure to do this means your outbound email still uses these and isn’t routed through us.
Any send connectors used for other purposes (e.g archiving) may still be enabled. If in doubt, consult Mimecast Support.Any send connectors used for other purposes (login archiving) may login be enabled. If in doubt, consult Mimecast Support.
Adding the Office 365 Tenant Domain as an Internal Domain
Your Office 365 tenant domain must be added to the list of internal domains available in the Mimecast Administration Console. See the Configuring Internal Domain / Subdomains page for full details. This enables us to recognize certain auto response messages, where the sender address is not a normal internal domain. This is typically in the format @domain.onmicrosoft.com. Contact the Mimecast Support team if you have queries regarding this step.
Add your Office 365 domain as an internal domain in Mimecast
The Office 365 domain(s) must be added to the list of internal domain available in the Mimecast Administration console, if this action is missed. Mimecast are unable to recognise auto response message where the send address maybe @domain.onmicrosoft.com. Mimecast have a section about this on their website, please follow the link below. Configuring Internal Domain / Subdomains
Verify your configuration
To verify that Office 365 is successfully routing email outbound via us:
Log on to the Administration Console.
Click on the Administrationtoolbar button.
Select the Message Center | Accepted Messages menu item.
You should see messages from your organization’s internal users to external recipients. If you don’t see messages shortly after they’re sent, this indicates a configuration problem on your Office 365 send connector. Double check your configuration. Use the Office 365 Message Trace Tool in the Mail Flow | Message Trace menu of the Exchange Admin Center to help identify the issue.
Planning on taking the MS-200 Exam but don’t know where to start with your studying? Well do not fear I am in the same boat and looking for the best way to study the required elements to pass MS-200. I have started building a list of all the elements which might be covered in the exam and will continue to update this page until all the things we need know are covered.
If you have any suggestions, please leave a comment below.
May include but not limited to: Plan namespaces, plan high availability for client access, configure virtual directories and URLs, configure client access policies, configure global Outlook Web App (OWA) policies, configure Autodiscover for Exchange, troubleshoot client access connectivity problems, manage Exchange certificates lifecycle
When working with large organisations that have multiple SMTP Domains, you may run into a requirement where you need to know. How many mailboxes have blogabout.cloud as their PrimarySMTPAddress or have blogabout.cloud listed as their EmailAddress.
Using the below PowerShell snippet you can find out exactly
This script enables the Online Archiving Mailbox for users in Exchange Online. The script will generate the log and error outputs by checking if the users exists in Exchange Online based on the information provided in the csv file.
The script needs to be run from the On-prem Exchange environment.
Example of script block, this demonstrates the actions taken within the script to check the csv file row by row and output if sucessful or not.