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 that shows TNEFEnabled, TrustedMailOutboundEnabled, TargetDeliverDomain, and IsInternal all set to True on-premises
    2. TrustedMailnboundEnabled attribute is set to True on Get-RemoteDomain 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 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!

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”


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:                  {;1}
AuthenticationCredential :
CloudServicesMailEnabled :      True
Comment : ConnectedDomains :    {}
ConnectionInactivityTimeOut :   00:10:00
DNSRoutingEnabled :             True
DomainSecureEnabled :           False
Enabled :                       True
ErrorPolicies :                 Default
ForceHELO :                     False
Fqdn :                
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 :     
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=*, O=Acme Limited, L=London, S=London, C=GB
TlsDomain :           
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 ( 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 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, -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 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 ( for example).

Testing the connector

In the above new send connector, is a domain hosted in a different Office 365 tenant. 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 and Do not set the connector up to use gmail or, 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:

  • 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 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.

Duplicate Exchange Online and Exchange Server Mailboxes

Posted on 4 CommentsPosted in duplicate, EOP, exchange, exchange online, Exchange Online Protection, Exchange Server, mailbox, MX, Office 365

With a hybrid Exchange Online deployment, where you have Exchange Server on-premises and Exchange Online configured in the cloud, and utilising AADConnect to synchronize the directory, you should never find that a synced user object is configured as both a mailbox in the cloud and a mailbox on-premises.

When Active Directory is synced to Azure Active Directory, the ExchangeGUID attribute for the on-premises user is synced to the cloud (assuming that you have not do a limited attribute sync and not synced the Exchange attributes – as that is required for Exchange Online hybrid). The Exchange Online directory takes a sync of information relating to Exchange from Azure Active Directory (Azure AD), which is known as forward sync. This ensures that the ExchangeGUID attribute from the on-premises mailbox is synced into your Exchange Online directory.

When a user is given an Exchange Online licence, it becomes the job of Exchange Online to provision a mailbox for this user. When Exchange Online needs to provision a new mailbox, it will not do so where the ExchangeGUID attribute already exists. The existence of this attribute tells the provisioning process that the mailbox already exists on-premises and will be migrated here later and so not to create a conflicting mailbox. A cloud user who does not have an ExchangeGUID attribute synced from on-premises will get a mailbox created by the Exchange Online provisioning process upon a licence being assigned, and on-premises users that do not have a mailbox on-premises (who also have no ExchangeGUID attribute) will also find that granting them an Exchange Online licence will trigger the creation of a mailbox for them.

This is all well and good, and the above is what happens in most cases. But there is an edge case where an on-premises user with a mailbox (and therefore has the ExchangeGUID attribute populated) will also get a mailbox in Exchange Online. This happens where the organization manually created cloud mailboxes before enabling AADConnect to sync the directories, and these cloud users match the on-premises user by UserPrincipalName and they are given an Exchange Online licence.

In this above case, because they are cloud users with an Exchange Online licence they get a mailbox. Deleting the cloud user and then enabling sync will cause the original mailbox to be restored to the user account as the UserPrincipalName matches.

For example, the below shows a user being created in the cloud called “”:


The user is granted a full Office 365 E3 licence, so this means the user has an Exchange Online mailbox. There is no AADConnect sync in place, but the UPN matches a user on-premises who has a mailbox.

In Exchange Online PowerShell, once the mailbox is provisioned we can see the following:


PS> get-mailbox twomailboxes | fl name,userprincipalname,exchangeguid

Name              : twomailboxes
UserPrincipalName :
ExchangeGuid      : d893372b-bfe0-4833-9905-eb497bb81de4

Repeating the same on-premises will show a separate user (remember, no AD sync in place at this time) with the same UPN and a different ExchangeGUID.


[PS] >get-mailbox twomailboxes | fl name,userprincipalname,exchangeguid

Name              : Two Mailboxes
UserPrincipalName :
ExchangeGuid      : 625d70aa-82ed-47a2-afa2-d3c091d149aa

Note that the on-premises object ExchangeGUID is not the same as the cloud ExchangeGUID. This is because there are two seperate mailboxes.

Get-User in the cloud will also report something useful. It will show the “PreviousRecipientTypeDetails” value, which is not modifiable by the administrator, in this case shows there was not a previous mailbox for the user but this can show that a previous mailbox did exist. For completion we also show the licence state:


PS > get-user twomailboxes | fl name,recipienttype,previousrecipienttypedetails,*sku*

Name                         : twomailboxes
RecipientType                : UserMailbox
PreviousRecipientTypeDetails : None
SKUAssigned                  : True

Now in preparation for the sync of the Active Directory to Azure Active Directory, the user accounts in the cloud are either left in place (and so sync will do a soft-match for those users) or they are deleted and the on-premises user account syncs to the cloud. In the first case, the clash on the sync will result in the cloud mailbox being merged into the settings from the on-premises mailbox. In the second case, there is no user account to merge into, but there is a mailbox to restore against this user. And even though the newly synced user has an ExchangeGUID attribute on-premises that is synced to the cloud, and they have a valid licence, Exchange Online reattaches the old mailbox associated with a different GUID.

The impact of this is minor to massive. In the scenario where MX points to on-premises and you have not yet moved any mailboxes to the cloud, this cloud mailbox will only get email from other cloud mailboxes in your tenant (there are none in this scenario) or internal alerts in Office 365 (and these are reducing over time, as they start to follow correct routing). It can be a major issue though if you use MX to Exchange Online Protection. As there is now a mailbox in the cloud for a user on-premises, inbound internet sourced email for your on-premises user will get delivered to the cloud mailbox and not appear on-premises. Where the invalid mailbox has no email, recovery is not required. Finally, where there is a duplicate mailbox, move requests for those users for onboarding to Exchange Online will fail:


This reads “a subscription for the migration user <email> couldn’t be loaded”. This occurs where the user was not licenced and so there was not a duplicate mailbox in the cloud, but the user was later licenced before the migration completed.

Where the invalid duplicate mailbox exists in the cloud and is getting valid emails delivered to it, the recovery work described below additionally will involve exporting email from this invalid mailbox and then removing the mailbox as part of the fix. Extraction of email from the duplicate mailbox needs to happen before the licence is removed.

To remove the cloud mailbox and to stop it being recreated, you need to ensure that the synced user does not have an Exchange Online licence. You can grant them other licences in Office 365, but not Exchange Online. I have noticed that if you do licencing via Azure AD group based licencing rules then this will also fail (these are still in preview at time of writing) and that you need to ensure that the user is assigned the licence directly in the Office 365 portal and that they do not get the Exchange Online licence. After licence reconciliation in the cloud occurs (a few minutes typically) the duplicate mailbox is removed (though I have seen this take a few hours). The Get-User cmdlet above will show the RecipientType being a MailUser and not Mailbox.

You are now in a position where your duplicate cloud mailbox is gone (which is why if that mailbox had been a target to valid emails before now, you would need to have extracted the data via discovery and search processes first).

Running the above Get-User and Get-Mailbox (and now Get-MailUser) cmdlets in the cloud will show you that the ExchangeGUID on the cloud object now matches the on-premises object and the duplication is gone. You can now migrate that mailbox to the cloud successfully.

We can take a look at what we see in remote PowerShell here:

Recall from above that there were two different ExchangeGUIDs, one in the cloud and one on-premises. These in my example where:

Cloud duplicate ExchangeGuid      : d893372b-bfe0-4833-9905-eb497bb81de4

On-premises mailbox ExchangeGuid  : 625d70aa-82ed-47a2-afa2-d3c091d149aa

Get-User before licences removed in the cloud, showing a mailbox and that it was previously a mailbox as well:


PS > get-user twomailboxes | fl name,recipienttype,previousrecipienttypedetails,*sku*

Name                         : Two Mailboxes
RecipientType                : UserMailbox
PreviousRecipientTypeDetails : UserMailbox
SKUAssigned                  : True

Get-Mailbox in the cloud showing the GUID was different from on-premises:


PS > get-mailbox twomailboxes | fl name,userprincipalname,exchangeguid

Name              : Two Mailboxes
UserPrincipalName :

ExchangeGuid      : d893372b-bfe0-4833-9905-eb497bb81de4

Once the licence is removed in Office 365 for Exchange Online and licence reconciliation completes (SKUAssigned is False) you will see that Get-User shows it is not a mailbox anymore:


PS > get-user twomailboxes | fl name,recipienttype,previousrecipienttypedetails,*sku*

Name                         : Two Mailboxes
RecipientType                : MailUser
PreviousRecipientTypeDetails : UserMailbox
SKUAssigned                  : False

And finally Get-MailUser (not Get-Mailbox now) shows the ExchangeGUID matches the on-premises, synced, ExchangeGUID value:


PS > get-mailuser twomailboxes | fl name,userprincipalname,exchangeguid

Name              : Two Mailboxes
UserPrincipalName :
ExchangeGuid      : 625d70aa-82ed-47a2-afa2-d3c091d149aa

Note that giving these users back their Exchange Online licence will revert all of the above and restore their old mailbox. As these users cannot have an Exchange Online licence assigned in the cloud, for risk of their old mailbox returning you need to ensure that within 30 days of their on-premises mailbox being migrated to the cloud you do give then an Exchange Online mailbox. Giving them a licence after migration of their on-premises mailbox to the cloud will ensure their single, migrated, mailbox remains in Exchange Online. But giving their user a licence before migration will restore their old cloud mailbox.

For users that never had a matching UPN in the cloud and a cloud mailbox, you can licence them before you migrate their mailbox as they will work correctly within the provisioning system in Exchange Online.

Enable Report Message Add-In For Office 365

Posted on Leave a commentPosted in add-in, EOP, exchange online, Exchange Online Protection, Office, Office 365, Office 365 ProPlus, phish, phishing, spam

There is a new add-in available for Outlook and OWA in Office 365 that can simplify spam and phishing reporting to Microsoft for content in your mailbox. I recommend rolling this add-in out to everyone in your Office 365 tenant and for Office 365 consultants to add this as part of the default steps in deploying a new tenant.

This can be done with the following steps:

In the Exchange Control Panel at go to the Organization > Add-Ins section


Click the + icon and choose “Add From Office Store”.

In the new tab that appears, search for “Report Message” via the search bar top right:

I’ve noticed that a set of search results appear, then the website notices I am logged in, logs me in and presents a second smaller list of results. It is in this small list that you should see Report Message by Microsoft Corporation


I’ve noticed that clicking “Get it now” does not seem to work all the time (the popup has a Continue button that does nothing)! So if that happens, cancel the popup, click the card for the app and install the add from the Get it now button rather than the get it now link on the card. The Report Message app page is shown below with a “Get It Now” button to the left:


Either the link or the button should work, and you should get this popup:


Click Continue. You are taken to Office 365 to continue. This is the step I eluded to above that sometimes does not work


You are asked to confirm the installation of the App into Office 365


Click Yes and wait a while. I’ve noticed also that sometimes you need to refresh this page manually for the process to continue, though waiting (with no indication that anything is happening for one or two minutes is usually enough as well)


The message above says that the add-in is now visible in the gray bar above your messages. For this add-in this is not correct as this add-in extends the menu in Outlook (2013 and later, as add-ins are not supported in Outlook 2010) and also the app is disabled by default.

Close this tab in your browser and return to the add-in page in Exchange Control Panel that is open in a previous tab.

Refresh the list of apps to see the new app:


From here you can enable the app, select a pilot audience, though this app is quite silent in the users view of Outlook and OWA so a pilot is not needed for determining impact to users, but can be useful for putting together quick documentation or informing the help desk of changes.

Select the app and click the edit button:


I recommend choosing “Mandatory, always enabled. Users can’t disable this add-in” and deploying to all users. Unchecking the option to make it available for all users makes it available for none. For a pilot choose “Optional, disabled by default”.

You are now done installing the add-in.

Users will now see the add-in in Outlook near the Store icon when a message is selected open:


Clicking the icon allows you to mark a messages as “junk”, “phishing” or “not junk” and options and help. Options gives the following:


Where the default is to ask before sending info to Microsoft.

Selecting Junk or Phishing will result in the message being moved to Junk Email folder in Outlook, and if in the Junk Email folder, marking a message “Not Junk” will return it to the inbox. All options will send info on the message, headers and other criteria to Microsoft to help adjust their machine learning algoriths for spam and phishing detection. This add-in replaces the need to email the message as an attachment to Microsoft.

For a pilot, users need to add the add-in themselves to Outlook. Mandatory deployment means it is rolled out to users (usually within a few days). To enable the add-in in OWA, click the options cog to the top right of the OWA interface:


Then click Manage Add-Ins and scroll down until you find the Report Message add-in (or search for it)


And turn the add-in on to view it in OWA as shown:


And also it will appear automatically in Outlook for iOS and Outlook for Android and Outlook (desktop, classic).

Once the app is enabled for all users, and recall the above where it takes a while to appear for all users, then your spam and phish reporting in Office 365 is very simple and easy to do and easy to remove from a helpdesk call and on to the end user directly to report and move messages.

DMARC Quarantine Issues

Posted on Leave a commentPosted in dkim, dmarc, EOP, exchange, exchange online, Exchange Online Protection, Exchange Server, spf, spoof

I saw the following error with a client the other day when sending emails from the client to any of the Virgin Media owned consumer ISP email addresses (,, etc.) gave this error:
vLkg1v00o2hp5bc01Lkg9w DMARC validation failed with result 3.00:quarantine

In the above, the server name (… might change as will the value before the error, but either DMARC validation failed with result 3.00:quarantine or 4.00:reject is the end of the error message.

We resolved this error by shorting the DMARC record of the sending organization. Before we made the change we had a DMARC record of 204 characters. We cannot find a reference online to the maximum length of a DMARC record, though we could successfully add a record of this length to Route 53 DNS provided by AWS, though a record of 277 characters was not allowed in AWS. Other references online to domain character length seem to imply that 255 characters is the max, but not specifically for DMARC.

So, shortening the DMARC record to remove two of the three email addresses in each of the RUA and RUF values was the fix that we needed. This change was done for two reasons, first the above error occurred only with emails to Virgin Media and sometimes an NDR would be received and other times the NDR would fail, but the original email never made it through and secondly the two removed email addresses where not actively being checked for DMARC status messages anyway and so there is no harm in the removal of them from the DMARC record anyway!

The original DMARC record we had this issue with looked like this (xxx.xxxxx representing the client domain):

v=DMARC1; p=quarantine; fo=1;rua=mailto:admin@xxx.xxxxx,,mailto:dmarc@xxx.xxxxx;ruf=mailto:admin@xxx.xxxxx,,mailto:dmarc@xxx.xxxxx;

Then we changed the record to the following to resolve it:

v=DMARC1; p=quarantine; fo=1;;;

Reducing the length of the record resulted in DMARC analytics and forensic email not going to mailboxes at the client (one of whom those mailboxes did not exist anyway) and only going to the UK government DMARC policy checking service, but most importantly for a client that has a requirement to respond to citizen’s emails (and whom could easily be using Virgin Media email addresses) we resolved the issue.

Forcing Transport Level Secure Email With Exchange Online

Posted on Leave a commentPosted in EOP, exchange online, Exchange Online Protection, Exchange Server, Office 365, security, starttls, TLS

In Exchange Online there are a few different options for forcing email to require an encrypted connection. These depend upon the level of licence you have, and some of them are user based (Office 365 Message Encryption for example), but there are two ways to force TLS (transport layer security) for the email between when the message leaves Office 365 and arrives with the recipient email system.

The first of these is a Mail Flow rule, and the second of these is a Conditional Connector. Only the second of these works!

The first, just for clarity, appears to work but it is not 100% reliable and will end up with stuck emails unless you configure the rule 100% correct. The second option is the recommended option ongoing.

For completion, we will also look at forcing TLS inbound to Exchange Online

Force TLS with Mail Flow Rules

This option relies on a Transport Rule (or mail flow rule) setting called “Require TLS”. This below example shows a UK Government requirement that states that emails to certain government departments (by domain name) should enforce the use of TLS:


This rule uses the condition “if the recipient address includes” and the list of UK Government domains that should be secured. This list is found at and for test purposes I have added my own domains to the list. The action for this rule is “to require TLS encryption”.

As mentioned above, this rule is not 100% reliable, and the the issue is when you have a Hybrid Exchange Online environment back to on-premises Exchange, though that connector back to on-premises uses TLS, the rule to force TLS conflicts and the email stays in Exchange Online in a pending state and is never delivered.
To avoid this issue, an exception is required to the rule to exempt it for your on-premises domains.

Force TLS with Conditional Connectors

This is the recommended route for forcing TLS. It requires two settings created. The first is a Conditional Connector as shown:


You must select “Only when I have a transport rule set up that redirects messages to this connector” on the connector use page.


MX delivery is the most likely option, and then either any digital certificate or issued by a trusted third party depending upon your requirements.


If you have more than one domain to force TLS to, then do not enter the end certificate info here, as it will be different for each domain.

Now that you have the connector in place, which will only be used is rules route the emails to that connector, you can create the rule.


We have purposely excluded the domains we had an issue with when using “Require TLS”, but Microsoft say that workaround should not be needed – I will update this post once I know that for sure! Also, as the rule shown in the screenshots adds a disclaimer so that we can check that the rule is being executed.

Inbound Required TLS with Connectors

To force inbound TLS requirements, so that email from given domains are rejected if they do not open a TLS session with your organization to send an email you create a Partner to Office 365 connector. This connector will force TLS or reject the email inbound if that cannot happen:




And then choosing “Reject email messages if they aren’t sent over TLS” as part of the connector conditions:



XOORG, Edge and Exchange 2010 Hybrid

Posted on 2 CommentsPosted in 2010, Edge, EOP, exchange, exchange online, Exchange Online Protection, Exchange Server, Office 365

So you have found yourself in the position of moving to Exchange Online from a legacy version of Exchange Server, namely Exchange 2010. You are planning to move everyone, or mostly everyone to Exchange Online and directory synchronization plays a major part (can it play a minor part?) in your plans. So you have made the option to go hybrid mode when you discover that there are manual steps to making Exchange 2010 mail flow to Exchange Online work if you have Exchange Edge Servers in use.

So, what do you do. You look online and find a number of references to setting up XOORG, but nothing about what that is and nothing about what you really need to do. And this you found this article!

So, how do you configure Exchange Server 2010 with Edge Servers, so that you can have hybrid mode to Exchange Online.

Why You Need These Steps

So you ran the hybrid wizard, and it completed (eventually if you have a large number of users) and you start your testing only to find that emails never arrive in Office 365 whilst your MX record is still pointing on-premises. After a while you start to get NDR’s for your test emails saying “#554 5.4.6 Hop count exceeded – possible mail loop” and when you look at the diagnostic information for administrators at the bottom of the NDR you see that your email goes between the hub transport servers and the edge servers and back to the hub transport servers etc. and about three or so hours after sending it, with the various timeouts involved, the email NDR arrives and the message is not sent.

The problem is that the Edge Server sees the recipient as internal, and not in the cloud, as the email has been forwarded to the, and Exchange 2010 is authoritative for this namespace. You are missing a configuration that tells the Edge that some emails with certain properties are not internal, but really external and others (those coming back from the cloud) are the only ones to send internal to the on-premises servers.

So what do you do?


Before you run the hybrid wizard you need to do the following. If you have already run the wizard that is fine, you will do these steps and run it again.

  1. Install a digital certificate on all your Edge Servers that is issued by a trusted third party (i.e. GoDaddy, Digicert and others). The private key for this certificate needs to be on each server as well, but you do not need to allow the key to be exported again.
  2. Enable the certificate for SMTP, but ensure you do not set it as the default certificate. You do this by using Exchange Management Shell to Get-ExchangeCertificate to key the key’s thumbprint value and then running Enable-ExchangeCertificate –Thumbrint <thumbprintvalue> –Services SMTP. At this point you are prompted if you want to set this certificate as the default certificate. The answer is always No!
  3. If you answer yes, then run the Enable-ExchangeCertificate cmdlet again, but this time for the certificate thumbprint that was the default and set the default back again. If you change the default you will break EdgeSync and internal mail flow for everyone. And you must use the self-signed certificate for EdgeSync and this third party issued certificate for cloud mail flow, as you cannot use the same certificate for both internal and external traffic.
  4. The certificate needs to be the same across all your Edge Servers.
  5. If you are doing multi-forest hybrid, then the certificate is only the same across all the Edge Servers in one Exchange Organization. The next organization in your multi-forest hybrid needs to use a different certificate for all its Edge Servers.
  6. Then take this same certificate and install it on a single Hub Transport server on-premises. The hybrid wizard cannot see what certificates you have on the Edge Servers, so you need to help the wizard along a bit. Again, this certificate needs enabling for SMTP, but not setting as the default certificate.

Running The Hybrid Wizard

Now you can run the hybrid wizard. The important answers you need to include here are that the hub transport server that you pick must be the one that you placed the certificate on, as you cannot pick the Edge Servers that you will use for mail flow in the wizard. But you will need to enter the IP addresses that your Edge Servers are published on the internet as, and you will need to enter the FQDN of the Edge Servers as well.

Complete the wizard and then time for some manual changes.

Manual Changes

The hybrid wizard will have made a send connector on-premises called “Outbound to Office 365”. You need to change this connector to use the Edge Servers as the source servers. Note that if you run the hybrid wizard again, you might need to reset this value back to the Edge Servers. So once all these required changes are made, remember that running the wizard again could constitute an unexpected change and so should be run with care or out of hours.

Use Set-SendConnector “Outbound to Office 365” -SourceTransportServers <EDGE1>,<EDGE2> and this will cause the send connector settings to replicate to the Edge Server.

Next get a copy of the FQDN value from the receive connector that the hybrid wizard created on the hub transport server. This receive connector will be called “Inbound from Office 365” and will be tied to the public IP ranged of Exchange Online Protection. As your Edge Servers receive the inbound emails from EOP, this receive connector will serve no purposes apart from the fact that its settings are the template for your receive connector on the Edge Servers that the wizard cannot modify. The same receive connector will also have a setting called TlsDomainCapabilities and the value of this setting will be AcceptOorgProtocol is the XOORG value that you see referenced on the internet, but it is really called AcceptOorgProtocol and this is the value that allows the Edge Server to distinguish between inbound and outbound mail for your Office 365 tenant.

So on each Edge Server run the following cmdlet in Exchange Management Shell to modify the default receive connector: Set-ReceiveConnector *def* -TlsDomainCapabilities -Fqdn <fqdnFromTheInboundReceiveConnectorOnTheHubTransportServer>.

This needs repeating on each Edge Server. The FQDN value ensures that the correct certificate is selected and the TlsDomainCapabilities setting ensures you do not loop email to Office 365 back on-premises again. Other emails using the Default Receive Connector are not affected by this change, apart from now being able to offer the public certificate as well to their inbound partners.

You can now continue with your testing knowing that mail flow is working, so now onto AutoDiscover, clients, free/busy, public folders etc. etc. etc.

Malware Filter Policy Updates in Office 365

Posted on 3 CommentsPosted in EOP, exchange online, Exchange Online Protection, malware, Office 365

In March I wrote a blog post that showed how to take the attachment filter list from Edge Server and add those attachment block types to EOP, as EOP had a very small list of attachments.

Today on one of my client tenants I noticed this precanned list of attachment extension types is now at 96 items, which is a considerable change from the list back in March 2017. The list in March was ace, ani, app, docm, exe, jar, reg, scr, vbe, vbs and still is for some tenants at the time of writing.

But while Microsoft has added new attachment types to the picker UI, there was no notification to the end client administrators that they might want to update their MalwareFilterPolicy to take account of these new attachment types that Microsoft have considered worthy of being blocked.

Therefore, now is the time to check your existing MalwareFilterPolicy to include the new extension types (listed below).

For reference, the new attachment filter types that have been added since March 2017 are


But notice that some of these are initial capital versions of entries that are already there (i.e. hta was in the list or on Edge server a few months ago, but now Hta is on the list as well).

I am assuming attachment blocking is not case sensitive and so the following extensions are if added from the attachment list picker will be duplicates – Hta, Inf, Ins, Jse, Ksh if you imported a matching, but lower case, list from your Edge servers.

OWA and Conditional Access: Inconsistent Error Reports

Posted on 1 CommentPosted in AzureAD, conditional access, EM+S, enterprise mobility + security, exchange, exchange online, Exchange Online Protection, IAmMEC, Outlook

Here is a good error message. Its good, because I could not find any references to it on Google and the fault was nothing to do with the error message:


The error says “something went wrong” and “Ref A: a long string of Hex Ref B: AMSEDGE0319 Ref C: Date Time”. The server name in Ref B will change as well. It also says “more details” and if you click that there are no more details, but that text changes to “fewer details”. As far as I have seen, this only appears on Outlook Web Access (OWA).

The error appears under these conditions:

  1. You are enabled for Enterprise Mobility + Security licences in Azure AD
  2. Conditional Access rules are enabled
  3. The device you are on, or the location you are at etc (see the specifics of the conditional access rule) mean that you are outside the conditions allowed to access Outlook Web Access
  4. You browsed directly to or

What you see in the error message is OWA’s way of telling you that you cannot get to that site from where you are. That you have failed the conditional access tests.

On the other hand, if you visit the Office 365 portal or MyApps ( or and click the Mail icon in your Office 365 menu or on the portal homepage then you get a page that says (in the language of your browser):

image or in Welsh, image

This says “you can’t get there from here” and the reasons why you have failed conditional access.

If you were on a device or location that allowed you to connect (such as a device managed by Intune and compliant with Intune rules) then going to OWA directly will work, as will going via the menu.

So how can you avoid this odd error message for your users. For this, you need to replace with your own custom URL. For OWA you can create a DNS CNAME in your domain for (lets say) webmail that points to (for this it will not work if you point the CNAME to Your users can now go to This will redirect the user via Azure AD for login and token generation, and as you are redirected via Azure AD you will always see the proper, language relevant, conditional access page.