Anonymous Emails Between On-Premises and Exchange Online

Posted on 1 CommentPosted in Authentication, EOP, exchange, exchange online, Exchange Online Protection, Exchange Server, hybrid, smtp, spam

When you set up Exchange Hybrid, it should configure your Exchange organizations (both on-premises and cloud) to support the fact that an email from a person in one of the organizations should appear as internal to a recipient in the other organization. In Outlook that means you will see “Display Name” at the top of the message and not “Display Name” <email address>. An email from the internet is rightly treated as anonymous and so should appear as “Display Name” <email address> but when it comes from your on-premises environment or your cloud tenant it should be authenticated.

In the email headers you should see a header called AuthAs that reads internal. The SCL (Spam Confidence Level) should always be –1 and you should not have a header called X-CrossPremisesHeadersFilteredBySendConnector visible on internal emails.

Your hybrid setup can be incorrectly configured and cause this, and depending upon what Exchange Server version you are running and when you last ran the hybrid wizard you can end up with different results.

Lets take a quick view to some of the settings you should see:

  1. Exchange Server 2010 (with or without Edge Server 2010)
    1. Hybrid wizard will use Remote Domains to control internal vs external and authentication state. You should have a Remote Domain for tenant.mail.onmicrosoft.com that shows TNEFEnabled, TrustedMailOutboundEnabled, TargetDeliverDomain, and IsInternal all set to True on-premises
    2. TrustedMailnboundEnabled attribute is set to True on Get-RemoteDomain domain.com in the cloud
    3. The AllowedOOFType, which controls Out Of Office is set to InternalLegacy
  2. Exchange Server 2013 and later
    1. Your “Outbound to Office 365” send connector on-premises should have CloudServicesMailEnabled set to True
    2. The Remote Domains matter for Out of Office and moderated emails/voting buttons, but not for authentication as mentioned in #1 above
    3. The Inbound Connector for “Inbound from GUID” should have CloudServicesMailEnabled set to True
  3. Exchange Server 2010 with Exchange Server 2013 or later Edge (no 2013 on-premises, only Edge)
    1. The setting CloudServicesMailEnabled needs to be True, but 2010 does not support this setting, so you need to edit the directory using ADSIEdit and change the msExchSmtpSendFlags on the send connector from 64 to 131136. All this does is tell the 2013 or later Edge to enable CloudServicesMailEnabled
    2. See https://support.microsoft.com/en-us/help/3212872/email-sent-from-an-on-premises-exchange-2013-edge-transport-server-to for the steps to do this
  4. As #3 but with 2010 and 2013 on-premises – run the cmdlets and hybrid wizard from the 2013 server and not connected to the 2010 server!

Azure AD Single Sign-On Basic Auth Popup

Posted on Leave a commentPosted in AADConnect, AADSync, Azure Active Directory, Azure AD, AzureAD, conditional access, microsoft, modern authentication, SSO

When configuring Azure AD SSO as part of Pass-Through Authentication (PTA) or with Password Hash Authentication (PHA) you need now (since March 2018) to only configure a single URL in the Intranet Zone in Windows. That URL is https://autologon.microsoftazuread-sso.com and this can be rolled out as a registry preference via Group Policy. Before March 2018 there was a second URL that was needed in the intranet zone, but that is no longer required (see notes).

So this short blog post is how to fix SSO when you do see a popup for this second URL though it is no longer required. The popup looks like:

image

It has OK and Cancel on it as well, but my screengrab I made when I saw the issue was not brilliant, so I “fixed” the bottom of the image so its approx. correct!

The URL is aadg.windows.net.nsatc.net. Adding this to Local Intranet Zone even though it is not needed does not fix the issue. The issue is caused because on Windows 10 (version 1703 and maybe others) someone has enabled Enhanced Protected Mode. Azure SSO does not work when Enhanced Protected Mode is enabled. This is not a setting that is enabled on client machines by default.

Enhanced Protected Mode provides additional protection against malicious websites by using 64-bit processes on 64-bit versions of Windows. For computers running at least Windows 8, Enhanced Protected Mode also limits the locations Internet Explorer can read from in the registry and the file system.

It is probable that Enhanced Protected Mode is enabled via Group Policy. It will either have the value Isolation (or Isolation64bit) set to a value of PMEM at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main or HKEY_CURRENT_USER\SOFTWARE\Microsoft\Internet Explorer\Main or the policy equivalent at  HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Internet Explorer\Main or HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\Internet Explorer\Main when set via GPO settings.

This issue is listed in the Azure AD SSO known issues page at https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-troubleshoot-sso. The reason why Enhanced Protected Mode does not work with Azure AD SSO is that whilst Enhanced Protected Mode is enabled, Internet Explorer has no access to corporate domain credentials.

Send-On-Behalf Permissions in Exchange Online

Posted on 2 CommentsPosted in exchange, exchange online, Exchange Server, hybrid, permissions, send-on-behalf

This document is up to date as of March 2018 and is therefore unlike many earlier documents on this issue as this feature set is in the process of changing.

First, Send-On-Behalf is changing so that it is supported across a hybrid Exchange Server to Exchange Online connection. At the time of writing this is in the process of being rolled out, so it might well be in your tenant by the time you read this.

But even if the config for this is enabled in the cloud, there is config that is needed on-premises. In Exchange Server 2013 you need to be on the latest CU and then run Set-OrganizationConfig  -ACLableSyncedObjectEnabled $True (as mentioned in https://technet.microsoft.com/en-us/library/mt784505%28v=exchg.150%29.aspx). For Exchange 2010, this is not an option (and the ACL sync needs to be done manually) and for Exchange 2016 this cmdlet is enabled already. [Note, discovered April 2018 that this is not true, and Exchange Server 2016 needs treating in the same way as Exchange Server 2013 regardless of what the Microsoft article says at the time of writing]

So what does -ACLableSyncedObjectEnabled $True do – well it changes Exchange Server so that all MoveRequests completed after the change leave behind a RemoteMailbox object where msExchRecipientDisplayType is -1073741818. For reference before the change to the OrganizationConfig this value on a RemoteMailbox was -2147483642.

msExchRecipientDisplayType Value
SyncedMailboxUser

-2147483642

ACLableSyncedMailboxUser

-1073741818

An ACLableSyncedMailboxUser is one that can have Send-On-Behalf permissions set or maintained across on-premise and the cloud – that is once your tenant is  updated as well.

This though leaves a few issues – the main one is that the RemoteMailbox left behind by the MoveRequest is only set to -1073741818 where the RemoteMailbox is made by a MoveRequest. If once you have moved all your users you start provisioning users directly in the cloud, then New-RemoteMailbox or Enable-RemoteMailbox will not set msExchRecipientDisplayType to -1073741818.

Therefore provisioning of users directly into the cloud with –RemoteMailbox will need the addition of Set-ADUser to update the msExchRecipientDisplayType after the RemoteMailbox is created. The cmdlet for this is the same cmdlet that you need to run if you are using Exchange 2010. This cmdlet is Get-AdUser <Identity> | Set-AdObject -Replace @{msExchRecipientDisplayType=-1073741818}

This  cmdlet would need to be added to your provisioning scripts, and if you don’t have scripts to provision users in AD and have a mailbox in the cloud, then now is the time to look at this as the number of moving parts is growing.

If you do not do the msExchRecipientDisplayType change then some of your remote mailboxes in Exchange Online will be able to be granted permissions for Send-On-Behalf and other permissions as they are added to the cloud, as they are ACLable (as in we can set them in Access Control Lists, ACLable!), and others users will not be. To make these changes you need to change the msExchRecipientDisplayType on-premises to -1073741818 and wait for this to sync to Azure AD and then wait for that to sync from Azure AD in the Forward Sync process to your Exchange Online directory.

New Underlying Search Functionality in Exchange Online

Posted on Leave a commentPosted in bing, exchange online, search

Mentioned during Microsoft Ignite 2017, there is a new search functionality in place within Exchange Online. Not all mailboxes are able to make use of the new functionality, such as hit highlighting and search results being shown in-line with the results highlighted in context with the results. The reason that the functionality is not available is that the feature has not been rolled out to all mailboxes in the service. At Microsoft Ignite, a percentage of enabled mailboxes was announced, and of course this will change over time. So how can you tell if the functionality is enabled on your mailboxes.

The answer is to use Get-MailboxStatistics via Exchange Online Remote PowerShell. The Get-MailboxStatistics cmdlet returns two sets of values, one starting with BigFunnel, which is the new search functionality code name and also values returned starting MCDB, which is the new MetaCache Database feature also announced at Microsoft Ignite.

 

image

PS> Get-MailboxStatistics email@address| fl *funn*,*mcdb*
BigFunnelIsEnabled                             : False
BigFunnelUpgradeInProgress                     : False 
BigFunnelMaintainRefiners                      : False 
BigFunnelFilterTableTotalSize                  : 0 B (0 bytes) 
BigFunnelFilterTableAvailableSize              : 0 B (0 bytes) 
BigFunnelPostingListTableTotalSize             : 0 B (0 bytes) 
BigFunnelPostingListTableAvailableSize         : 0 B (0 bytes) 
BigFunnelLargePOITableTotalSize                : 0 B (0 bytes) 
BigFunnelLargePOITableAvailableSize            : 0 B (0 bytes) 
BigFunnelTotalPOISize                          : Unlimited 
BigFunnelMessageCount                          : 
BigFunnelIndexedSize                           : Unlimited 
BigFunnelPartiallyIndexedSize                  : Unlimited 
BigFunnelNotIndexedSize                        : Unlimited 
BigFunnelCorruptedSize                         : Unlimited 
BigFunnelStaleSize                             : Unlimited 
BigFunnelShouldNotBeIndexedSize                : Unlimited 
BigFunnelIndexedCount                          : 
BigFunnelPartiallyIndexedCount                 : 
BigFunnelNotIndexedCount                       : 
BigFunnelCorruptedCount                        : 
BigFunnelStaleCount                            : 
BigFunnelShouldNotBeIndexedCount               : 
BigFunnelMailboxCreationVersion                : 
MCDBBigFunnelFilterTablePercentReplicated      : 
MCDBBigFunnelLargePOITablePercentReplicated    : 
MCDBBigFunnelPostingListTablePercentReplicated : 
MCDBMessageTablePercentReplicated              : 
MCDBBigFunnelFilterTablePercentReplicated      : 
MCDBBigFunnelLargePOITablePercentReplicated    : 
MCDBBigFunnelPostingListTablePercentReplicated : 

In the above BigFunnelIsEnabled shows if the feature is on, and then the rest of the values will contain information such as the size of the index within the mailbox (as the index is stored within the mailbox and not separate as it is with Exchange Server 2013/2016 and how it was in Exchange Online before this feature).

The MetaCache Database is SSD based storage within Exchange Online and where the index s read from – so the MCDB* results show things like the replication status of the database across the servers in Exchange Online.

420 4.2.0 RESOLVER.ADR.Ambiguous; ambiguous address

Posted on Leave a commentPosted in active directory, exchange, exchange online, Exchange Server, migration, smtp

This error can turn up in Exchange Server when Exchange Server is trying to resolve the object that it should deliver a message to. Exchange queries Active Directory and expect that if the object exists in the directory, that the object exists only once. If the object exists more than once, this is the error – as Exchange does not know who to deliver the email to.

The error is visible when running Get-Queue in Exchange Management Shell, and seeing that there are lots of emails in the Submission Queue. If you run Get-Message –Queue servername\Submission | FT Identity,FromAddress you can pick one to look at, and for that one run Get-Message server\submission\ID | FL where server\submission\ID is the Identity value from Get-Message cmdlet. Here you will see LastError and Recipients showing the ambiguous address error.

There are a number of articles on the internet covering this issue, but I came across a unique one today.

The easy way to search for the issue is to find the address that is in duplicate. This will be listed in Event Viewer under MSExchangeTransport as the source and Event ID 9217. The Task Category will be Categorizer, as the job of working out who is going to get the message is the role of the Categorizer.

image

An example of this error is shown.

So the fix. Often suggested is to do a custom AD query for “proxyaddress=smtp:name@domain.com” where name@domain.com is the email address shown in the event log error. If this returns two or more recipients, and this will be across all the domains in the forest, then you need to decide which is the primary one and carefully delete the rest.

By carefully I mean that you want to leave either one contact, or one mail user or one mailbox etc. If the duplicate is two contacts, then find the one with the most correct information on it and carefully delete the other. If you find two mailboxes, work out which the user is actually logging into and has email in it – and carefully delete the other etc.

And by carefully, here I also mean that on the object you are going to delete, copy the legacyExchangeDN value and then delete the object. Then find the real correct object and add a new x500 email address to the proxyAddresses attribute of the correct user. The value of the x500 address will be the legacyExchangeDN that you copied from the deleted contact.

This will ensure that users who have previously emailed the now deleted contact before, will still be able to email the remaining object.

But what is unique about that? At the customer I am working on at the moment the issue was that doing the proxyaddresses=smtp:name@domain.com search only returned one object across the entire forest – what is duplicate about that? Well in my case, the user had user@domain.com added to their proxyaddresses twice – they were the duplicate object to themselves.

image

Opening this user via the search results as shown above, and with Advanced Features enabled from the View menu, you can see the Object tab:

image

Opening the object value directly, redacted in the picture above, I can change to the Attribute Editor tab and open proxyAddresses attribute. Here i saw the following:

name@domain.com

name@mail.domain.com (used as a target for forwarding emails from another system)

smtp:name@old-company.com

SMTP:name@domain.com

x500:legacyExchangeDN from Exchange 2007 migration

Note that the name@domain.com value, the one in error in the logs, appears twice but not starting SMTP (primary address) or smtp (secondary address) but without an address protocol at all!

Querying the user in Exchange Administration Console returned:

image

And also then opening the user in Exchange Management Console showed that the address without the smtp: value was shown with it.

Remove one of the two addresses and within ten minutes the emails queued to this user in the submission queue will be delivered. Restarting the transport service will also kick start the submission queue as you cannot use Retry-Queue against this queue.

Exchange Online Migration Batches–How Long Do They Exist For

Posted on 5 CommentsPosted in exchange, exchange online, Exchange Server, hybrid, microsoft, migration, Office 365

When you create a migration batch in Exchange Online, the default setting for a migration is to start the batch immediately and complete manually. So how long can you leave this batch before you need to complete it?

As you can see from the below screenshot, the migration batch here was created on Feb 19th, which was only yesterday as I write this blog.

image

The batch was created on the morning of the 19th Feb, and set to manual start (rather than the default of automatic start, as did not want to migrate lots of data during the business day) and then it was started close to 5:30pm that evening. By 11:25pm the batch had completed its initial sync of all 28 mailboxes and there were no failures. There were other batches syncing at the same time, so this is not indicative of any expected or determined migration performance speeds.

So what happens next. In the background a new mailbox move request was created for each mailbox in the batch, and each individual mailbox was synced to Exchange Online and associated with the synced Mail User object created in the cloud by the AADSync process. When each move reached 95% complete, the move was suspended. It will be resumed around 24 hours later, so that each mailbox is kept up to date once a day automatically.

If you leave the migration running but not completed you will see from the migration batch status above that the batch will complete in 7,981 years (on the 31st Dec 9999 and one second before the next millennium bug hits). In the meantime the migration batch sync will stop doing its daily updates after two months.

After two months of syncing to the cloud and not being completed, Exchange Online assumes you are still no closer to migrating and they stop keeping the mailbox on-premise and the mailbox in the cloud in sync. You can restart this process by interacting with the migration batch before this time, or if it does stop by just clicking the Resume icon, and this will restart it for a further period of time.

Office 365 Retention Policies and Hybrid Public Folders

Posted on Leave a commentPosted in exchange online, Exchange Server, hybrid, Office 365, Public Folders, retention, retention policies

If you create an Office 365 Retention Policy (in the Security and Compliance Center) that applies to all Exchange Online content then you might find that after the retention policy has been deployed (a day or so later usually) that the policy is in error and there is a message at the top of the retention policy pane that shows “1 distribution result(s) found”.

image

The “Notify support” link does nothing but help you call support, and a post on the Microsoft Tech Community implies that that does not help.

The place to look for the answer is in a Security and Compliance Remote PowerShell session. Here you can run Get-RetentionCompliancePolicy -DistributionDetail | fl Name,Distribution* to return the name of each of your retention policies along with the DistributionStatus (which will be “Error”) and DistributionResults.

In my example I found I had a DistributionResults message of “{[Exchange]AllPublicFolderUnderRoot:Recipient not found: }”.

image

In the example that I was trying to resolve this issue for, the Exchange Online organization was utilizing on-premises Public Folders for Exchange Online mailboxes. That is, in Exchange Online, the PublicFoldersEnabled property of Get-OrganizationConfig was set to remote and we had a few RemotePublicFolderMailboxes (aka mailboxes that proxy the online mailboxes connection to the on-premises organization).

image

Therefore there seems to be an error in Office 365 Retention Policies where the retention policy distribution fails when you set it to archive public folders, but your public folder infrastructure is still on-premises.

So what can you do – either you ignore the error, after all it is telling you that your retention does not include objects that do not yet exist – but when you do have public folders in Exchange Online, the retention policy should take effect without you doing anything else.

The other thing you could do is to to remove public folders as a retention source, not forgetting to enable it again when you have moved your public folders to the cloud.

image

Journal Rule Testing In Exchange Online

Posted on Leave a commentPosted in EOP, exchange online, Exchange Online Protection, Exchange Server, journal, journaling, Office 365, smtp

I came across two interesting oddities in journaling in Exchange Online in the last few weeks that I noticed where not really mentioned anyway (or anywhere I could find that is). The first involces routing of journal reports and the second the selection of the journal target.

The journal report, that is the message that is sent to the journal target mailbox when an email is sent or received from the mailbox(es) under the control of the Journal Rule. This journal report is a system message, that is Exchange Online marks it as such so that it is treated and considered differently within the Office 365 service. This though means that Conditional Routing does not apply to journal reports. Conditional routing is where you have a mail flow (or transport) rule, that routes the emails based on passing the conditions in the rule. Journal messages are never subject to rules, and this includes conditional routing as well.

This means that journal rules leaving Exchange Online will always route via the default connector or a standard connector for the SMTP namespace of the journal report target. If Centralized Mail Flow is enabled in hybrid mode, the standard connector for the SMTP namespace is ignored, as all mail routes via the * connector apart from that that is already affected by mail flow rules. As journal reports cannot be routed via conditional routes due to not being processed by the mail flow rules, this means in a scenario where Centralized Mail Flow is enabled, journal reports will only follow the routing to *.

In a multi-organization hybrid deployment, this means that your journal reports from the cloud may end up in the wrong on-premises organization and you will need to route them appropriately.

The second issue I came across is more for a journal test scenario. It is against the terms of service in Exchange Online to store journal reports in a mailbox in Exchange Online, but its only in the last few days I have noticed that you now (and not sure for how long) you have been unable to enter a target mailbox that is in Exchange Online.

For example, I created a new journal rule and entered a target mailbox in a different Office 356 tenant. I was not allowed to use that mailbox. The error message was not clear though, and it took some time to work this out. The error message you get is “The JournalEmailAddress can only be a mail user, a mail contact or an external address”

image

Of course where the journal target address is external to your tenant (an external address), then this error makes no sense. Also if you create a mail user or mail contact that points towards the target it will not be accepted whilst that mailbox exists elsewhere in Office 365. You can enter an address for a domain that is hosted in Office 365, as long as that mailbox is not hosted in Office 365. It is just where the address is currently in Office 365 you cannot make a journal rule to send email to it.

You cannot also work around this limitation anymore either – if you enter a journal target address that is not in Exchange Online so that the Journal Rule setup completes, then go and add that target address to your other tenant, you will see that the journal report messages never arrive. Change it for an on-premises mailbox and it will work straight away.

Therefore it is now no longer possible to even test journaling unless you have an external mailbox. Shame the error is not clearer – would have saved a bit of time!

Outbound Email Via Exchange Online Protection When Using Hybrid Exchange Online

Posted on 1 CommentPosted in dmarc, EOP, exchange, exchange online, Exchange Online Protection, Exchange Server, hybrid, mailbox, spf

In a long term hybrid scenario, where you have Exchange Online and Exchange Server configured and mailboxes on both, internet bound email from your on-premises servers can route in two general ways.

The first is outbound via whatever you had in place before you moved to Office 365. You might have configured Exchange Online to also route via this as well.

The second is to route Exchange Server outbound emails via Exchange Online Protection. Your Exchange Online configuration does not need to be adjusted for this to work, as the default route for all domains to the internet (or the * address space as it is known) is via EOP as long as you create no alternative outbound connector for *.

This blog post looks at configuring Exchange Server so that your on-premises mailboxes also route out via Exchange Online Protection, and does it without changing the connectors made by the hybrid wizard. If you change the hybrid wizard connectors and then run the wizard again, it will reset things to how it wants them to be, which will remove your configuration changes.

This configuration setup results in a single new send connector created on-premises in Exchange Server (or one connector per site is you route emails from more than one Active Directory site). This new connector is not the Outbound to Office 365 connector that the hybrid wizard creates and so changes here do not break hybrid and changes to the hybrid wizard do not impact outbound mail flow.

This blog post also assumes you already have a working route outbound for all internet emails and you are swapping over to outbound via EOP, so these steps work though ensuring that is correct and will work before changing the route for *.

Examine the hybrid send connector to Office 365

[PS] C:\ExchangeScripts\pfToO365>Get-SendConnector out* | fl

AddressSpaces:                  {smtp:domainuk.mail.onmicrosoft.com;1}
AuthenticationCredential :
CloudServicesMailEnabled :      True
Comment : ConnectedDomains :    {}
ConnectionInactivityTimeOut :   00:10:00
DNSRoutingEnabled :             True
DomainSecureEnabled :           False
Enabled :                       True
ErrorPolicies :                 Default
ForceHELO :                     False
Fqdn :                          mail.domain.uk
FrontendProxyEnabled : 	        False
HomeMTA :                       Microsoft MTA
HomeMtaServerId :               SERVER01
Identity :                      Outbound to Office 365
IgnoreSTARTTLS :                False
IsScopedConnector :             False
IsSmtpConnector :               True
MaxMessageSize :                35 MB (36,700,160 bytes)
Name :                          Outbound to Office 365
Port :                          25
ProtocolLoggingLevel :          None
RequireOorg :                   False
RequireTLS :                    True
SmartHostAuthMechanism :        None
SmartHosts :                    {}
SmartHostsString :
SmtpMaxMessagesPerConnection :  20
SourceIPAddress :               0.0.0.0
SourceRoutingGroup :            Exchange Routing Group (DWBGZMFD01QNBJR)
SourceTransportServers :        {SERVER02, SERVER01}
TlsAuthLevel :                  DomainValidation
TlsCertificateName :            <I>CN=GlobalSign Organization Validation CA - SHA256 - G2, O=GlobalSign 
                                nv-sa, C=BE;<S>CN=*.domain.uk, O=Acme Limited, L=London, S=London, C=GB
TlsDomain :                     mail.protection.outlook.com
UseExternalDNSServersEnabled :  False

The above PowerShell from the on-premises Exchange Management Shell shows you the hybrid send connector. As you can see this is set to route emails only for your hybrid address space (domainuk.mail.onmicrosoft.com in this example)

The other important attributes for EOP mail flow here are AddressSpaces, CloudServicesMailEnabled, DNSRoutingEnabled, Fqdn, RequireTLS, SmartHosts, and TLSAuthLevel. Setting these correctly on a new send connector will allow you to route other domains to EOP and then onward to the internet.

Create a new send connector

This blog is based upon information found in https://technet.microsoft.com/en-us/library/dn751020(v=exchg.150).aspx but it differs from the scenario described there within. In this scenario, as you have already run the hybrid wizard, the connector to the cloud from on-premises and from the cloud to your servers already exists. Therefore all we need to do is create an additional send connector on-premises to route all the other domains to EOP and the internet.

New-SendConnector -Name <DescriptiveName> -AddressSpaces testdomain1.com,testdomain2.com -CloudServicesMailEnabled $true -Fqdn <CertificateHostNameValue> -RequireTLS $true -DNSRoutingEnabled $false -SmartHosts <YourDomain_MX_Value> -TlsAuthLevel  CertificateValidation -Usage Internet

In the above, the connector is originally created being able to route for two test domains (written as testdomainx.com above, comma separated in the list with no spaces). This ensures that you do not break your existing mail flow but allows you to test that the connector works and then later change the connector to support * address space. The “YourDomain_MX_Prefix” is the same value as you would use in your MX to route emails to Exchange Online (tenant-prefix-com.mail.protection.outlook.com for example).

Testing the connector

In the above new send connector, testdomain1.com is a domain hosted in a different Office 365 tenant. Testdomain2.com is a domain who’s email is not hosted in Office 365 at all. You need both test scenarios, as routing to domains inside Office 365 is more likely to work if the connector is not configured properly.

So from a mailbox on-premises, send an email to a recipient at both testdomain1.com and testdomain2.com. Do not set the connector up to use gmail or Outlook.com, as that will impact other senders within your organization. Use domains that no one else is likely to want to email.

Ensure that you do not get any NDR’s and check the recipient mailboxes to ensure delivery. Note that you are possibly likely to need to update your SPF record for the sending domain to additionally include the following:

  • include:spf.protection.outlook.com
  • ipv4:w.x.y.z (where w.x.y.z is the external IP address(es) of your on-premises Exchange transport servers)

Updating the connector

Once your mail flow tests work, and you can check the route by pasting the received message headers into http://exrca.com you should see that email routes into your Office 365 tenant, then leave EOP (the word “outbound” will be in one of the FQDNs – this server is on the external edge of EOP), then routed inbound to your email provider (or back into your recipient tenant).

Once mail flow works, you can either add more recipient domains to increase the scope of the test – for example add a domain that you email occasionally, such as the partner helping you with this work and a few other domains. Once all your testing is ready change this connector to have * as the address space and not list specific domains.

As your other connector for * is still up and running you will find that 50% of your email will use the new connector and 50% the old. Then you can disable the old connector to go 100% email outbound through EOP (you need an EOP licence per sender to do this, or if you have an Exchange Online licence for each user you are already covered).

Finally when you have been routing on-premises email through EOP for a few weeks with the old connector disabled, you can delete the old connector and tidy up the configuration rather than leaving disabled connectors around.