The Operation on Mailbox Failed Because It’s Out of the Current User’s Write Scope

The operation on mailbox failed because it's out of the current user's write scope. The action Set-Mailbox EmailAddresses can't be performed on the object because the object is being synchronized from your on-premises organization. This action should be performed on the object in your on-premises organization.

When you try to update certain attributes on your Office 365 user object you become victim of the following error message:

The Operation on mailbox "xyz" failed because it's out of the current user's write scope

It can happen in the Microsoft Office 365 Admin Center as well as in the Exchange Admin center and it may look like this:

The operation on mailbox failed because it's out of the current user's write scope. The action Set-Mailbox EmailAddresses can't be performed on the object because the object is being synchronized from your on-premises organization. This action should be performed on the object in your on-premises organization.

The same thing can happen if you’re using PowerShell to update Office 365 user attributes or Exchange Online mailbox attributes:

Write-ErrorMessage : | System.InvalidOperationException | The operation on mailbox "Lene Hau"
  failed because it's out of the current user's write scope. The action 'Set-Mailbox',
  'HiddenFromAddressListsEnabled', can't be performed on the object 'Lene Hau' because the object
  is being synchronized from your on-premises organization.
  This action should be performed on the object in your on-premises organization.

What’s going on…?

Attribute Source of Authority

When you’re running a hybrid environment, your on-premises Active Directory becomes the source of authority for many of the user attributes found in Azure/Office 365. This includes, e.g., these attributes:

  • FirstName
  • LastName
  • DisplayName
  • Office
  • ProxyAddresses
  • mailNickname
  • msExchHideFromAddressLists
  • etc…

Some of these attributes (e.g., proxyAddresses, mailNickname, etc.) directly affect the functionality of your Exchange Online mailbox but can only be configured via your on-premises Active Directory.

After configuring the attributes in AD, you must wait for them to replicate or force replication with Azure AD Connect.

To make things more complicated, some attributes change their name depending on their context.

They may have one name in your on-premises Active Directory and another name in the Azure AD Connect MetaVerse, and another name in Azure AD.

The attributes may even have different names in the Msol PowerShell module, the Azure AD module, and the Exchange Online module!

So, take care when managing your Office 365 users and mailboxes. Know where to change attributes and make sure to use the proper attribute names when doing so.

How to Permanently Fix Attribute Authority Errors

Easy365Manager is a tool that consolidates on-premises AD and Office 365 administration.

It does this by extending AD user properties with two new tabs that allow you to configure Office 365 licenses and Exchange Online mailbox properties directly from AD:

User Properties Tycho Brahe License Management
Click to enlarge
User Properties Tycho Brahe Mailbox Management
Click to enlarge

With Easy365Manager, you never again have to think about attribute authority.

Additionally, you no longer need to log in to multiple web consoles. You can even remove your on-premises Exchange Server.

Easy365Manager also saves you many roundtrips to PowerShell:

You can trigger Azure AD Connect synchronization from AD user properties.

And you can even perform complex configurations like calendar delegation, which is usually only available via PowerShell:

Easy365Manager makes no changes to your infrastructure and can run on any client with AD Users & Computers.

You can download and install Easy365Manager in just a couple of minutes.

Join hundreds of successful companies and organizations:

Download the fully functional free 30-day trial here.