Beware of pitfalls – changing the primary email address in Exchange Online
Krähe mit HutIn my projects, I repeatedly encounter special circumstances. Typically, these special circumstances did not occur in previous similar projects or only arise in a specific constellation.
These special circumstances can then lead to major disruptions if they are not identified and remedied in time. One such circumstance is the seemingly simple change of a mailbox's primary email address.
Initial situation
In everyday life, there may be a need to change the primary email address of a mailbox:
- Change of user name (e.g., due to marriage or divorce)
- Change of intended use or adjustment as part of a change in communication strategy (e.g., German to English)
- Adjustment of email domain (e.g., in the event of company acquisitions or changes to the company name)
The actual steps for changing the email address are straightforward and therefore will not be described in detail here.
After the change, users may lose access to other mailboxes, for example, the “Send as” and/or “Full access” rights.
Issue analysis
The analysis did not initially reveal any abnormalities. The users are still listed in the respective permission list (“Send as” or “Read and manage (full access)”).
However, when users attempt to access the mailbox in Outlook, they receive an error message (e.g., “Access denied,” “A client operation failed,” or “You do not have permission to send on behalf of the specified recipient…”).
A query to Microsoft Support yielded the following statement:
In Exchange Online, permissions such as Send As and Full Access are linked to the mailbox identity. This identity is strongly associated with the primary SMTP address, which acts as the authoritative reference for the mailbox. When the primary SMTP address is changed, the identity reference is updated. As a result, previously granted permissions no longer align with the updated identity and need to be re-applied.
This behavior is expected and by design, as permissions are identity-based rather than alias-based.
This behavior is therefore not an error, but expected.
Incidentally, Exchange Server behaves differently in this regard. There, the primary email address can be changed at any time and permissions for other mailboxes are retained.
Solution
The most obvious solution is to remove the user from the authorization list and then add them back again. This may be feasible in individual cases. However, if this happens as part of a larger operation such as a company merger, then it must be automated. Accordingly, the following steps show the procedure for a mass reconfiguration of authorizations:
- Determine and plan a suitable time for changing the primary SMTP address.
- Reset permissions using the following commands. These perform the following actions:
- Identify the affected mailboxes using a filter.
- Identify and temporarily store the currently configured permissions.
- Reset the current permissions to their initial state.
- Reset the permissions from the temporary storage.
# Check whether the module is installed and install it if it is not available.
(!(Get-InstalledModule ExchangeOnlineManagement -ErrorAction SilentlyContinue)){Install-Module ExchangeOnlineManagement -Scope CurrentUser}
# Connect to Exchange Online
Connect-ExchangeOnline -ShowBanner:$False
# Retrieve all affected mailboxes—e.g., based on the email domain
$Mailboxes = Get-Mailbox -Filter "PrimarySmtpAddress -like '*@contoso.com'" -ResultSize Unlimited
# Perform actions for each mailbox
ForEach ($Mailbox in $Mailboxes)
{
# Retrieve current permissions
$FullAccessUsers = Get-MailboxPermission -Identity $Mailbox.Name | Select User
$SendAsAccessUsers = Get-RecipientPermission -Identity $Mailbox.Name | Select Trustee
# Reset current permissions
Write-Host "Reset permissions for $($Mailbox.PrimarySmtpAddress)..." -ForegroundColor Yellow
Remove-MailboxPermission -Identity $Mailbox.DistinguishedName -ResetDefault -Confirm:$False
Get-RecipientPermission -Identity $Mailbox.DistinguishedName | Where-Object {$_.Trustee -ne 'NT AUTHORITY\SELF' | Remove-RecipientPermission -Confirm:$False
# Add user to permission "full access"
ForEach ($FullAccessUser in $FullAccessUsers)
{
# Skip system permissions and mailboxes without permissions
if ($PermittedUser -ne 'NT AUTHORITY\SELF' -AND $PermittedUser -ne $null)
{
Write-Host ''
Write-Host "User $PermittedUser is assigned full access for $($Mailbox.PrimarySmtpAddress)..." -ForegroundColor Yellow
Add-MailboxPermission -Identity $Mailbox.DistinguishedName -AccessRights FullAccess -User $PermittedUser.User -InheritanceType All -Confirm:$False
}
}
# Add user to permission "Send As"
ForEach ($SendAsUser in $SendAsAccessUsers)
{
# Skip system permissions and mailboxes without permissions
if ($PermittedUser -ne 'NT AUTHORITY\SELF' -AND $PermittedUser -ne $null)
{
Write-Host ''
Write-Host "User $PermittedUser is assigned 'Send As' for $($Mailbox.PrimarySmtpAddress)..." -ForegroundColor DarkYellow
Add-RecipientPermission -Identity $Mailbox.DistinguishedName -AccessRights SendAs -Trustee $SendAsUser.Trustee -Confirm:$False
}
}
}
Recommendation: Using permission groups instead of direct assignment can make such processes considerably easier. This also corresponds to best practices (using groups for assigning permissions).
Liked this article? Share it!
