Cannot Remove User From Mail Enabled Security Group

Question

Dear Microsoft Support,

We are currently experiencing an issue with a mail-enabled security group managed on-premises and synchronised to Exchange Online via Azure AD Connect, where we are unable to successfully remove a user from the group.

🔍 Issue Summary

• The group is on-premises mastered and synced to Exchange Online.
• We are attempting to remove a user from the group via the on-prem domain controller (AD).
• The removal does not appear to persist or reflect correctly in Exchange Online.

---

Troubleshooting Performed

So far, we have carried out the following steps:

• Re-enabled the user account
• Re-added the user to the relevant group
• Attempted removal and re-addition of group membership
• At the time of initial testing, the user account was located in a Leave OU, which is likely excluded from Azure AD Connect synchronization
• We then moved the account back into the Staff OU (within sync scope) and repeated the process
• Despite this, the change did not take effect in Exchange Online

---

⚠️ Additional Observations

• Our Third Line team has suggested the possibility that the group name may not match correctly between on-prem and Exchange Online, which could contribute to the issue
• It is also possible that the issue stems from:
  • The account being disabled
    • The account being moved to a non-synchronising OU before all group memberships were removed, potentially leading to a sync inconsistency

---

❓ Assistance Required

We would appreciate your guidance on:

1. How to resolve discrepancies between on-prem group membership and Exchange Online
2. Whether this behaviour could be caused by OU sync scope changes or account state during sync
3. Steps to force or correct group membership sync integrity
4. Any known issues with mail-enabled security groups in hybrid environments that could explain this

Regards

[Moderator note: Personally Identifiable Information removed] 

---

Answer 1

Please note that our forum is a public platform, and we will modify your question to hide your personal information in the description. Kindly ensure that you hide any personal or organizational information the next time you post an error or other details to protect personal data. 

Hi @Cleon Russell

Thank you for reaching out and I truly appreciate you taking the time to explain your situation.  

First, I’d like to clarify that we're not Microsoft support, this is a user-to-user support forum. Moderators participating here do not have access to backend systems, nor can we directly intervene in Microsoft product functionality. Our role is limited to providing technical guidance and sharing best‑practice recommendations based on reported issues, requests, and scenarios.      

As your description, the issue you’re experiencing is most likely caused by the user account being moved into a non-synchronized OU ( Leave OU) while group membership changes were still being processed. When an account temporarily falls out of Azure AD Connect synchronization scope (or is disabled), Entra ID de-provisions the object. Even after moving the account back into the Staff OU and re-adding/removing the user, the membership relationship for mail-enabled security groups can become stale between Entra ID and Exchange Online.  As a result, the removal performed on-premises is correctly reflected in Active Directory and Entra ID, but might not update in Exchange Online. 

You could try to follow these steps to troubleshoot it: 

Verify membership in all three directories (this will confirm where the mismatch is): On-premises AD, Entra ID (Microsoft Graph) and Exchange Online 

Remove the user using the on-premises Exchange Management Shell (not AD Users and Computers): 

Run:

Remove-DistributionGroupMember -Identity "GroupName" -Member "user account" -Confirm:$false 

Then you can force an Azure AD Connect delta synchronization, run: 

Start-ADSyncSyncCycle -PolicyType Delta 

Additionally, you could try to make a minor change to the group object in on-premises AD (for example, update the Description field or add a temporary proxy address), then run another Delta sync. This forces a full export of the group object. If the membership is correct in both on-premises AD and Entra ID but still incorrect in Exchange Online after the above steps, this might relate to a backend directory inconsistency between Entra ID and Exchange Online.  

To resolve this, Microsoft’s support team will need to step in. A technical support engineer can perform a remote session to investigate the situation, verify the backend configurations, and run any necessary synchronization tools to resolve the problem. If the issue requires further attention, they can escalate it to a specialized team for deeper analysis.    

Reference: Get support - Microsoft 365 admin | Microsoft Learn 

Note: To create a support ticket, you need to have Microsoft 365 admin privileges and if you aren’t admin of your organization, please contact the admin of creating a new ticket. 

I hope this helps. 

If you have any additional concerns, feel free to comment below. I would be more than happy to assist. 

---

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread. 

Answer 2

In a hybrid, on‑premises–mastered environment, group membership in Exchange Online is always driven by the on‑premises Active Directory object that Azure AD Connect synchronizes. If the membership change is not reflected online, the issue is almost always with:

• The on‑premises object (user or group) not being in scope for sync
• Attribute/state inconsistencies (disabled user, moved OU, or conflicting cloud object)
• A sync error in Azure AD Connect

Based on the context, use the following checks and steps.

1. Validate that the user and group are in sync scope and healthy
2. Confirm OU sync scope:
   • Ensure both the user and the mail‑enabled security group reside in OUs that are included in Azure AD Connect’s synchronization scope.
   • If the user was in a “Leave OU” that is excluded from sync, Azure AD Connect will have stopped updating that user in the cloud. Moving the user back into a synced OU is required before membership changes can flow.
3. Check for directory sync errors:
   • Use the guidance under “Check for DirSync errors” to identify any sync problems for the user or group:
     • Review sync errors in the Microsoft 365 Admin Portal as described in [Identify directory synchronization errors in Office 365] and [Identifying DirSync provisioning errors in Office 365].
     • Use the troubleshooting articles [Troubleshooting errors during synchronization] and [Troubleshoot an object that is not synchronizing to Azure AD] to resolve any reported issues.
4. Confirm the cloud objects and their source
   • Use PowerShell to verify that there is only one cloud object for the user and the group, and that they are directory‑synced (not cloud‑only):
     • For the user:
       • Get-MsolUser -SearchString <UserPrincipalName or DisplayName> | fl UserType,ImmutableId,ObjectId
       • Get-AzureADUser -SearchString <UserPrincipalName or DisplayName> | fl UserType,ImmutableId,ObjectId
     • For the group:
       • Get-MsolGroup -SearchString <EmailAddress or DisplayName> | fl ObjectId
       • Get-AzureADGroup -SearchString <EmailAddress or DisplayName> | fl ObjectId
   • If UserType is Member and ImmutableId is populated, the object is synced from on‑premises. If there is a conflicting cloud‑only object (for example, a guest or a separate cloud group) with the same SMTP/UPN, it must be removed or updated to eliminate conflicts, as described:
     • “If there is a conflict with another object but that object can't be found in your on-premises Active Directory, confirm that there isn't a cloud-only object that causes the problem… The object should be removed or updated to reduce the conflict with a syncing object.”
5. Address possible causes related to OU moves and disabled accounts
6. User moved to a non‑synchronizing OU before membership cleanup:
   • When the user was moved to the Leave OU (excluded from sync), Azure AD Connect stopped updating that user’s memberships in the cloud. Any subsequent membership changes on‑premises would not be reflected online.
   • After moving the user back into the Staff OU (in scope), ensure a full sync cycle completes and that there are no sync errors for that user.
7. Disabled account state:
   • A disabled account can still be synchronized and remain a member of groups in the cloud, depending on configuration. The key is whether the object is still in a synced OU and has no sync errors.
   • If the user was disabled and moved out of scope, the cloud object may have become “stale” (no further updates). Moving it back into scope and ensuring successful sync is required for membership changes to apply.
8. Verify the group object and attributes
9. Confirm the group is on‑premises mastered and syncing:
   • Use Get-MsolGroup / Get-AzureADGroup to confirm the group exists once in the cloud and is directory‑synced.
   • Ensure the group has a valid display name and mail attributes. Mail‑enabled groups without a display name are known not to sync correctly:
     • “This issue occurs if a display name isn't specified for the on-premises mail-enabled group.”
10. Check for mail‑enabled group anomalies:
    • If the group’s email address was changed or removed on‑premises, Exchange Online may have retained an onmicrosoft.com address as primary, which can cause unexpected behavior:
      • “When a mail-enabled security group is synchronized to Microsoft Entra ID, the email address that uses the original domain (onmicrosoft.com) is appended… If you delete the primary email address, the email address that has the original domain becomes the primary email address.”
    • If the group’s mail attributes are in an inconsistent state and cannot be corrected via normal sync, use one of the documented workarounds:
      • Delete the security group from the Admin Portal, then let it be recreated by sync.
      • Or move the group to an OU that is excluded from sync so it is removed from the cloud, then move it back into a synced OU to recreate it.
11. Steps to force/correct membership sync integrity
12. End‑to‑end path to correct membership:
    1. Ensure the user and group are both in OUs that are in Azure AD Connect sync scope.
    2. On‑premises AD:
       • Explicitly remove the user from the mail‑enabled security group.
       • Confirm in AD Users and Computers (or ADSI Edit if needed) that the group’s member list no longer contains the user.
    3. Run or wait for Azure AD Connect synchronization.
    4. Check for sync errors as described above and resolve any conflicts.
    5. In Microsoft 365 / Exchange Online, verify that the group membership now reflects the removal.
13. If the object is still not updated after fixing errors:
    • Use the guidance under “Exchange Online object is not present or updated in Azure AD Connect”:
      • Confirm the UPN suffix (for users) or SMTP suffix (for groups) is an accepted domain.
      • If a change was made to correct a sync error but the issue persists, contact Microsoft support to submit the object for a forward sync from Azure AD to Exchange Online using the UserPrincipalName and ObjectId values.
14. Known hybrid issues relevant to this scenario

• Mail‑enabled groups without a display name do not sync properly to Microsoft 365.
• Mail‑enabled security groups can retain an onmicrosoft.com address as primary if the original primary SMTP is removed, leading to unexpected mail behavior.
• Conflicts with cloud‑only objects (guest users, contacts, or groups) that share identifiers (UPN/SMTP) with synced objects can block or distort synchronization.
• Objects moved out of sync scope (for example, to a “Leave OU”) stop receiving updates in the cloud; any membership changes made while out of scope will not flow to Exchange Online until the object is brought back into scope and sync completes successfully.

Following the above checks—ensuring both objects are in scope, resolving any sync errors or conflicts, verifying group attributes, and allowing/forcing a clean sync—restores alignment between on‑premises group membership and Exchange Online.

---

References:

• Mail-enabled groups that have an email address aren't synchronized to Microsoft 365
• Security group is still mail-enabled after it is disabled through a sync in on-premises AD
• Exchange Online object is not present or updated in Azure AD Connect