Change of SOA of mail users, groups and contacts - does Adaxes understand this?

Question

Hi! I'm wanting to perform the retirement of the last Exchange server in an installation, but I need to adjust the SOA (Start of Authority) of mailboxed users, as well as a bunch of distribution groups and contacts.

Does Adaxes understand the "onPremisesSyncBehavior/isCloudManaged" change on the onprem objects?

Comments

I also tried to get clarification on this and didnt really get anywhere and looks like Adaxes is NOT able to read and identify the exchange attributes - cloud managed behavior. I hope they take this into consideration as most of us would like to switch over to using "Exchange Attribute Source of Authority (SOA" to be managed in Exchange online, just for those attributes and keep the acount sourced from Local AD. With Adaxes NOT understanding this - Adaxes will continue to update exchange attributes for the user (for example extension attributes), which would NOT be synced over to EntraID.

I wonder if this is even on the Roadmap for a future update.

---

Hello,

We apologize that our previous responses did not fully address your questions.

To clarify, Adaxes fully supports objects whose Source of Authority (SOA) has been changed to Exchange Online. Once the change is made and synchronized by Microsoft Entra Connect, Adaxes starts treating the on-premises AD object and its corresponding Microsoft Entra object as two separate, unrelated objects. As a result, you can view and manage these objects separately in Adaxes.

If this is not the behavior you are experiencing, we will be glad to investigate it further. To start with, could you please clarify how exactly you change the SOA? As far as we know, this can be done either through the Microsoft Entra admin center UI or by using scripts.

There may be differences in how these approaches work on the Microsoft side, so knowing which method you use would help us investigate the issue.

---

Support - appreciate the response.

Hopefully the below is helpful (and not too long), and we can make sure we are referring to the same change. My intention is for Adaxes team to understand this change and account for this change in an upcoming update.

In a nutshell, the "Exchang attribute SOA change" from an Entra standpoint- spilits the Source of authority for user object between Local AD and some object Fields/attributes AD stays the Authority, while Exchange attributes become EXOnline as the Authority.

How/Where to make the User Exchange Attribute SOA changes

• Managed by "ISExchangeCloudManaged" field and tracked only on EXO and can be set at INDIVIDUAL USer object level
• Change has to be done via EXO PowerShell ONLY
• This setting can also be set at ORG level (instead per user object), which allows this behavior by default for any new eligible mailbox

Before SOA transfer:

• Identity attributes (name, department, title, etc.) = On-prem AD authoritative
• Exchange attributes (proxyAddresses, aliases, HideFromAddressLists, CustomAttributes, etc.) = On-prem Exchange authoritative
• Changes made in EXO are blocked or overwritten by sync.

After SOA transfer:

• Identity attributes remain mastered on-prem.
• Exchange-specific attributes become cloud-managed.
• User Exchange attributed are managed in EXO and any changes on Local Exchange attributes are Ignored by cloud

---

Hello,

Thank you for the detailed explanation and for clarifying the changes you are referring to.

We would like to point out that the original discussion was about the isCloudManaged attribute, which is quite different from isExchangeCloudManaged. Here are the key differences:

isCloudManaged

Setting this attribute for an object disables synchronization of the object between on-premises Active Directory and Microsoft Entra and unlocks the ability to edit all attributes directly in the cloud.

isExchangeCloudManaged

Setting this attribute disables synchronization of Exchange-related properties only. As a result, Exchange attributes are managed directly in Exchange Online, while identity-related attributes continue to be managed in on-premises Active Directory and synchronized to Microsoft Entra.

We will review how Adaxes handles both attributes and investigate whether any adjustments are needed to ensure proper support for these scenarios.

Answer 1

Hello,

I'm wanting to perform the retirement of the last Exchange server in an installation, but I need to adjust the SOA (Start of Authority) of mailboxed users, as well as a bunch of distribution groups and contacts.

With Adaxes, there is no need to change the SOA after retiring your last on-premises Exchange server. Everything can keep working just fine. For more details about Adaxes functioning after the procedure and recommended actions, have a look at the following article: https://www.adaxes.com/questions/16903/does-adaxes-function-after-decommissioning-exchange-server.

Does Adaxes understand the "onPremisesSyncBehavior/isCloudManaged" change on the onprem objects?

The attribute does not influence Adaxes functionality. If you are still going to change the SOA, you will also need to make sure that only the corresponding objects are actually updated by your workflows. However, updating the attribute might influence your Adaxes licensing. With the current settings, if you register a Microsoft Entra domain and a synchronized Active Directory domain in Adaxes, synchronized users will only be counted once toward the license limit. With the update you mentioned, it will be two separate accounts consuming two Adaxes licenses.

Comments

OK, maybe i should re-phrase it a bit differently - I have a number of contacts and groups that i want to change the SOA on before I start the Exchange server decom process. I converted a few samples and tested, and when adjusting the object directly in 365 and Exchange Online, it works, but when trying to do this in Adaxes, it adjusts the "old" onprem object even though with SOA changes, anything onprem will no longer be synced up. Should I either set up a Cloud Sync configuration to try and re-sync that info back up, or consider performing a manual migration of those groups and contacts?

---

Hello,

If you set the isCloudManaged attribute to True, the synchronization is no longer in place. The behavior comes from Microsoft and that is the way it works. It is not related to Adaxes. As a result, setting the attribute gives you two separate accounts. For the on-premises AD object in Adaxes you can manage AD properties and on-premises Exchange settings. For the cloud account you can manage their properties and Exchange Online settings. There is no such thing as re-sync or anything like that.

For your information, managing cloud-only (Exchange Online) contacts is not supported in Adaxes.