Category Archives: Office 365 Grid

“Enable Centralized Mail Transport” / “Route all Internet-bound messages through your on-premises Exchange servers” and NDR Remote Server returned ‘550 5.7.1 Unable to relay’

BACKGROUND

You configure the Hybrid with the option to route back e-mail from Exchange Online users to your On-premise organization Before sending them to the Internet.

  • In the Exchange 2013 Hybrid Configuration Wizard, this option is called: “Enable Centralized Mail Transport”
  • In the Exchange 2010 Hybrid Configuration Wizard, this option is called: “Route all Internet-bound messages through your on-premises Exchange servers”

This is not the default option, but is necessary for some organizations due to compliance or message tracking reasons.

What it does is that it is adding a wildcard (*) in the send connector in FOPE/EOP, that normally only is used for your shared domains, to route back e-mail to users On-premise that have not been migrated to Exchange Online. The wildcard enables this send connector for all domains on the Internet, thus route the e-mail back to your On-premise Exchange Environment.

Your On-premise Exchange Environment can without any problem route e-mail to your internal, not yet migrated users, because that Exchange Environment knows about those domains and their recipients. Internet recipients, on the other hand, will require your message from the Exchange Online user to be RELAYED outside your On-premise Exchange, back to the Internet.

This fails with the following NDR (bounce message) information to the sender in Exchange Online:

Remote Server returned ‘550 5.7.1 Unable to relay’

CAUSE

The receive connector that the Hybrid Configuration Wizard creates on-premise to Catch the e-mail that Exchange Online sends back is not fully configured and ready for use after running the Hybrid Wizard.

RESOLUTION

To fix the “Inbound from Office 365” receive connector, you need to both populate the list of allowed IP-addresses and enable the receive connector for relaying.

Follow these steps:

  1. Open the Receive Connector properties in EMC or ECP (2010 or 2013 on-premise)
  2. First, open the Network tab/settings to investigate the list of remote servers, “Receive mail from remote servers that have these IP addresses”.
  3. The list of allowed IP-addresses is supposed to be populated by the Hybrid Configuration Wizard – BUT IT IS NOT COMPLETE! Use this article to verify each address space is included in this list: http://help.outlook.com/en-us/140/gg263350.aspx . Make sure to read the complete article to understand that the list of IP-addresses is subject to change etc.
  4. After making sure that your list of allowed IP-addresses is complete, you still need to enable the receive connector to allow further relaying to Internet recipients when the message origins from Exchange Online:
  5. Fire up Exchange Management Shell and run this PowerShell command to enable the “Inbound from Office 365” receive connector for relaying:

Get-ReceiveConnector ” Inbound from Office 365 ” | Add-ADPermission -User “NT AUTHORITY\ANONYMOUS LOGON” -ExtendedRights “Ms-Exch-SMTP-Accept-Any-Recipient”

After filling up the list of allowed IP-addresses and enabled it for relaying to Internet recipients, your mail flow will work as expected with the “Centralized Mail Transport” / “Route all Internet-bound messages through On-premise” option enabled.

Note: Be careful not to add excessive IP-address ranges to your receive connector. You do not want to create an open relay – make sure that you only allow Exchange Online hosts to relay.

 

 

This mailbox exceeded the maximum number of large items that were specified for this request. (Fatal error TooManyLargeItemsPermanentException has occurred.)

POST UPDATED TO REFLECT THE EXCHANGE ONLINE ONBOARDING SIZE LIMIT INCREASE (FROM 35 to 150 MB) ANNOUNCED JANUARY 2015 (INFO).

BACKGROUND

When moving mailboxes to Exchange Online, the Remote Move Request fails with the following error message in Exchange Management Console (EMC):

Error: This mailbox exceeded the maximum number of large items that were specified for this request.

When viewing the log file for the mailbox migration, you see the following details:

Fatal error TooManyLargeItemsPermanentException has occurred.

CAUSE

The message size limits for Exchange Online migrations is 150 MB. It used to be 35 MB prior to January 2015, but have now been increased (info). If larger items than 150 MB are attempted to be moved through a default Remote Move Request initiated from the EMC wizard, the job will fail with the error message above because Exchange Online refuses the messages due to their size. If you have mailboxes containing messages that are +150 MB in size, you can still migrate these mailboxes but you will need to tell Exchange that it should simply skip the large messages that are refused and not abort the complete move request when encountering them.

RESOLUTION

If a mailbox has items that are 150 MB+ in size, you can solve this error in two ways:

  1. Either instruct the end-user to remove the item. Send an instruction on how to sort items on size in Outlook and tell them to Shift+Del Everything above 150 MB in size. Elite users can maybe even handle an instruction on Search Folders/Filter. After the users have removed the items, remove the Move request and start over again (resuming it will fail).
  2. Or, allow the move request to skip the 150 MB+ items that are refused by Exchange Online and continue the migration without aborting the entire job. Here is how:

Unfortunately, you cannot use the EMC wizard for this, you will need to use the Exchange Online Control Panel (where the migration wizard will allow you to adjust the parameters) to run the migration or use PowerShell. Using the Exchange Online Control Panel works for both Exchange 2010 and Exchange 2013 hybrid configurations.

2.1: USING THE EXCHANGE ONLINE CONTROL PANEL INSTEAD OF EMC (RECOMMENDED)

The most simple way to solve this problem is to run the migration from the Exchange Control Panel (as said, this works with both Exchange 2010 and 2013 hybrid configurations). Follow these steps:

  1. Log in to you Office 365 Admin Portal and navigate to Exchange Control Panel (Admin\Exchange).
  2. Navigate to Recipients (left pane) and then the tab Migration (top pane/tabs)
  3. Click + (plus) and Migrate to Exchange Online
  4. Select the first choice to initiate a remote mailbox move
  5. Select users to migrate or use a CSV to create a new migration batch
  6. At the next step, enter your MRS endpoint, that is where EWS is published (your hybrid server). Example: ews.company.com
  7. At the next screen, you can give the batch a name for tracking and logging purposes, select if you want to migrate an Archive Mailbox, and most importantly set the allowed number of large and corrupt/bad items to be skipped for the migration. Increase this number to be able to run the migration that failed. As an example, you can set both values to 50.
  8. At the next screen, enter who will have reports when the migration batch is completed, set scheduling options (start now or later) and select if the migration should be completed directly or if it should be automatically suspended when the mailbox replication have reached 95%, so that you can switch over the user when you want in a controlled manner. If using the auto suspend option, the user will not notice anything until you choose to complete the migration, then the last 5%/delta will be synchronized and the user will be switched over (email will be forwarded to Exchange Online mailbox and Outlook will re-configure for use with the Exchange Online mailbox etc).
  9. When completing the wizard, you can then track the migration from the Migration view in the control panel. If you are using automatic suspend, here is also where you can complete the migration after reaching 95% (mark the job and select complete).

2.2: USING POWERSHELL

As stated above, using Exchange Online Control Panel is recommended. If you would like to use PowerShell instead, follow this method.

If you are moving just one user, follow these steps:

New-MoveRequest -remote -Id firstname.lastname@smtpdomain.com -RemoteHostName “ews.companydomain.com” -RemoteCredential $Cred -TargetDeliveryDomain ‘tenantdomain.mail.onmicrosoft.com’ -SuspendWhenReadyToComplete -LargeItemLimit 50 -BadItemLimit 50

Note that I added LargeItemLimit and BadItemLimit. These parameters will allow up to 50 large (over 150 MB) messages to be refused and skipped, and up to 50 corrupt messages to be skipped as well.

If you are moving several users, you could use a CSV file with a column that says UPN, filled with your migration batch users UPN-names:

Import-Csv C:\MigrationBatch.csv | foreach {New-MoveRequest -Identity $_.UPN -Remote -RemoteHostName ews.companydomain.com -TargetDeliveryDomain ‘tenantdomain.mail.onmicrosoft.com’-BadItemLimit 50 -LargeItemLimit 50}

For both single and bulk, consider adding the following parameter to use the AutoSuspend feature:

 -SuspendWhenReadyToComplete -Suspend

Moving mailboxes with EMC is very convenient, but it will not give you the option to allow corrupted or large (150 MB+) items to be skipped and overseen in the migration job. Go Exchange Online Control Panel or PowerShell to save the day.

Certificate referenced by property OrgPrivCertificate in the FederationTrust object is expired. (Be PATIENT!)

BACKGROUND

You are running this command to see if you are on top of your Hybrid Configuration or not:

Test-FederationTrust | fl

It looks pretty good, but fails at the end with this depressing statement:

Id      : OrganizationCertificate
Type    : Error
Message : Certificate referenced by property OrgPrivCertificate in the FederationTrust object is expired.

 Naturally, you investigate the Exchange Delegation Federation Certificate on your side and find that is good for another five years! So why is it telling you that it is expired?

CAUSE

If you start investigating this issue, you will find pointers to ADSIEdit and how to cycle up new certificates etc. My advice: Don’t go there. If this configuration is against Office 365/Exchange Online/Microsoft Federation Gateway – it is probably more simple than that. Microsoft Federation Gateway (MFG) is very sensitive when it comes to time.

RESOLUTION

Notes from the field:

  1. MFG is sensitive about time. Investigate your time zone settings, external time source (AD PDC Emulator settings and VM hypervisors etc.)
  2. If time settings are OK, just WAIT!

Waiting will solve this problem. For the configuration that made me write this blog post, it took 45 minutes, but I suggest that you should wait as long as time allows you. Just leave all remote PS sessions for the Office 365 tenant in question for a couple of hours and try again. The result after waiting  (no configuration made in the meantime):

[PS] C:\>Test-FederationTrust | fl

Id      : FederationTrustConfiguration
Type    : Success
Message : FederationTrust object in ActiveDirectory is valid.
Id      : FederationMetadata
Type    : Success
Message : The federation trust contains the same certificates published by the security token service in its federation metadata.
Id      : StsCertificate
Type    : Success
Message : Valid certificate referenced by property TokenIssuerCertificate in the FederationTrust object.
Id      : StsPreviousCertificate
Type    : Success
Message : Valid certificate referenced by property TokenIssuerPrevCertificate in the FederationTrust object.
Id      : OrganizationCertificate
Type    : Success
Message : Valid certificate referenced by property OrgPrivCertificate in the FederationTrust object. Id      : TokenRequest
Type    : Success Message : Request for delegation token succeeded.
Id      : TokenValidation
Type    : Success
Message : Requested delegation token is valid.

 

After cracking one of these, you really feel like an Exchange genius. Awesome.