Discovering Azure

Today, I want to write about a real-life example of an issue you may encounter in a hybrid Microsoft environment — and, more importantly, show you how to deal with it step by step.

In many organizations, access to web-based applications is tied directly to a user’s email address. If you’re working in a hybrid setup, your users are usually created in on-premises Active Directory and then synchronized to Azure / Entra ID.

Let’s imagine the scenario in which external users, let’s call them partners, need to keep their business email addresses to connect to some of their client’s applications. To make sure the correct email address appears in Entra ID, you should not assign a license to the user, and you should keep the proxyAddresses attribute empty.

As long as this rule is followed, everything works as expected. The problem starts when it isn’t.

How You End Up with an Unwanted Mailbox

If a user was licensed at any point in the past — even briefly — Exchange automatically created a mailbox. From that moment on, you are dealing with a mailbox-backed user, whether you want it or not.

Removing such a mailbox is not straightforward, and this is where most administrators get stuck.

If a user has a mailbox, you will usually see a proxyAddresses entry starting with 500 in Active Directory. When you want to remove the mailbox, the first thing you need to do is identify where it lives.

You should:

1. Check whether the mailbox exists in on-premises Exchange
2. If it doesn’t, check Exchange Online

In most hybrid environments, you’ll find that the mailbox exists in the cloud. At this stage, you may also see an error similar to:

Exchange: An unknown error has occurred. Refer to Correlation ID

This happens because the user does not have a license, but Exchange still considers the mailbox active.

Your First Attempt to Disable the Mailbox

At this point, you need to connect to Exchange Online using PowerShell and try to disable the mailbox. However, in many cases, this attempt will fail.

Why?

Because the mailbox is protected by retention policies.

Understanding InPlaceHolds

Before you can remove the mailbox, you must identify which retention policies are blocking you. You should start by listing all retention policies in your tenant:

Get-RetentionCompliancePolicy | Select Name, Guid

Next, you need to check which holds are applied directly to the mailbox:

Get-Mailbox user@domain.com | Format-List InPlaceHolds

Compare the values:

The InPlaceHolds property tells you exactly what is preventing the mailbox from being removed. These holds can come from:

• Retention policies configured in Microsoft Purview
• eDiscovery cases (Legal or Litigation Hold)
• Retention labels
• Teams chat retention
• Hidden service-generated holds (for example, Teams or Copilot)

Excluding the User from Retention Policies

Once you know which policies are involved, you should sign in to Microsoft Purview and navigate to Data Lifecycle Management → Policies.

For many policies, you can simply exclude the user via the GUI. Once excluded, the policy will no longer apply to the mailbox, and you can proceed with deletion.

However, you should be aware that not all policies support exclusions through the UI.

A common example is Global Retention Policy – Teams Chats 1:1. If this policy is blocking the mailbox, you need to handle it using PowerShell.

First, inspect the policy details:

Get-RetentionCompliancePolicy `

  -Identity “Global Retention Policy – Teams Chats 1:1” `

  -DistributionDetail | Format-List

Then exclude the user explicitly:

Set-RetentionCompliancePolicy `

  -Identity “Global Retention Policy – Teams Chats 1:1” `

  -AddTeamsChatLocationException user@domain.com

Permanently Removing the Mailbox

After all retention holds are removed, you should retry disabling the mailbox using the –PermanentlyDisable parameter. If everything is configured correctly, the mailbox will finally be removed.

When the Proxy Address Comes Back

Sometimes, even after you remove the mailbox, you may notice that the proxyAddresses attribute reappears. This usually means Exchange-related data is still cached in the cloud.

In this case, the cleanest solution is to:

1. Desynchronize the user
2. Wait until the user appears in Entra ID → Deleted Users
3. Permanently delete the user from Deleted Users
4. Synchronize the user again from on-premises Active Directory

After this process, the user is recreated cleanly, and the email address in Entra ID is finally correct.

Final Thoughts

If you work with hybrid environments, you will run into issues like this sooner or later. Problems between Entra ID and Exchange are common, often subtle, and usually time-consuming.

Knowing what to check, where to look, and in which order to act will save you a lot of troubleshooting time—and a lot of frustration.