Exchange

Microsoft Exchange – 420 4.2.0 Recipient deferred because there is no Mdb

Last few weeks I'm responsible for migrating users from Office 365 to Office 365. Part of this migration process is to set up new Exchange 2016 server that will work as relay instead of using IIS server. No users are supposed to be created on Exchange On-Premises. I've setup hybrid, added Accepted Domains, prepared Connectors, set Accepted Domains to Internal Relay, but there's one thing missing. Any time an email is sent via relay to a user that exists on Office 365 and at the same time exists in Active Directory email never gets there. Following error message is shown

What error looks like?

Delivery has failed to these recipients or groups:
test.user@domain.com (test.user@domain.com)

There's a problem with the recipient's mailbox. Please try resending the message. If the problem continues, please contact your email admin.

 

Diagnostic information for administrators:
Generating server: PLSERVER.domain.local
Total retry attempts: 3
test.user@domain.com
Remote Server returned ‘420 4.2.0 Recipient deferred because there is no Mdb'
Original message headers:
Received: from PLSERVER.domain.local (10.0.0.5) by
PLSERVER.domain.local (10.0.0.5) with Microsoft SMTP Server
(version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id
15.1.1531.3; Wed, 14 Nov 2018 15:26:21 +0100
Received: from PLSERVER.domain.local ([::1]) by
PLSERVER.domain.local ([::1]) with mapi id 15.01.1531.003; Wed, 14 Nov
2018 15:26:21 +0100
Content-Type: application/ms-tnef; name=”winmail.dat”
Content-Transfer-Encoding: binary

However, it works just fine when the user is created only in Office 365 as strictly cloud user. That means connectors are set up and working correctly.  So what is wrong? Why does it work for one user and not the other?

How do I fix it?

The difference is that if you introduce On-Premises Exchange in your infrastructure it can see your Active Directory users, but it doesn't see their mailboxes (because they were created and used only in Cloud). For cloud only users, it can't find those users in Active Directory, so it forwards emails for non-existing accounts using Internal Relay setting. Knowing this we can address our issue. As you can see on below screenshot that's how proper Active Directory user should look like. Mailbox Type for this user should be set to Office 365.

So how do we get our Office 365 mailboxes to show up as Office 365 Mailbox Type in Exchange 2016 (Exchange 2013)?

Enable-RemoteMailbox "Test User" -RemoteRoutingAddress "test.user@mydomain.mail.onmicrosoft.com"

Above command, while simple is required to fix our problem, 420 4.2.0 Recipient deferred because there is no Mdb. Now we only need to set this for all remaining users so that this issue is no more.

Przemyslaw Klys

System Architect with over 14 years of experience in the IT field. Skilled, among others, in Active Directory, Microsoft Exchange and Office 365. Profoundly interested in PowerShell. Software geek.

Share
Published by
Przemyslaw Klys
Tags: exchangeexchange onlineoffice 365
5 years ago

Recent Posts

Active Directory Replication Summary to your Email or Microsoft Teams

Active Directory replication is a critical process that ensures the consistent and up-to-date state of…

1 week ago

Syncing Global Address List (GAL) to personal contacts and between Office 365 tenants with PowerShell

Hey there! Today, I wanted to introduce you to one of the small but excellent…

5 months ago

Active Directory Health Check using Microsoft Entra Connect Health Service

Active Directory (AD) is crucial in managing identities and resources within an organization. Ensuring its…

7 months ago

Seamless HTML Report Creation: Harness the Power of Markdown with PSWriteHTML PowerShell Module

In today's digital age, the ability to create compelling and informative HTML reports and documents…

8 months ago

How to Efficiently Remove Comments from Your PowerShell Script

As part of my daily development, I create lots of code that I subsequently comment…

8 months ago

Unlocking PowerShell Magic: Different Approach to Creating ‘Empty’ PSCustomObjects

Today I saw an article from Christian Ritter, "PowerShell: Creating an "empty" PSCustomObject" on X…

9 months ago