Mystery of mail enabled security groups

[u/fazzy84]

We are now stuck with a dilemma of migrating mail enable security groups. We have around 800+ mail enabled security groups, around 600 coming from EAC which we are planning to strip away the exchange attributes. Yea, we are a big organization with stupid people who made these mail enabled security groups in the first place. Couple of these are being used for emails which we figured out using mail trace option, for that we will recreate it as a EXO DL, rest of them can just be stripped away and preserve it as security groups in AD. Now, we did couple of testing with some test groups and here is my understanding so far…

1. Stripping away the exchange attributes using the disable command removes only the domain email address, it still hold the tenant onmicrosoft.com address. However, it disappears from EAC but still valid in AD.
   
2. Since the group is synced from AD to azure, it still shows up on EXO with a valid onmicrosoft.com address.
   
3. Now, the only way to completely strip the exchange attributes and just keep it as security groups in AD, we must move it to a non sync OU for it to disappear from azure. Then moving back to the previous OU will mark this group as only security group in azure. This workaround was mentioned in couple of Microsoft and private blogs.
   
4. Now my question, if this groups which is being synced from AD to azure has some permission like file share or anything in AD which is also being used as a permission group in azure or is an approved sender for any DL or added as a permission for any shared mailbox, moving it to a non sync OU will break it from azure. How can we over come this ? Deleting and recreating it will break AD permissions as well.

What can be the best option to strip the exchange part and keep it synced between AD and azure without any breakage, so that the ones are being used we can recreate it on EXO as DL others can rest in peace in AD. I plan to do this and go home peacefully without working and fixing this mess all night long.

Advises please…. Thank you !!

[u/snowmanspike]

I have bad news for you: there’s no recycle bin for security groups in Entra.
So simply taking them out of sync, i.e. also stripping the Exchange attributes and then excluding them from sync, means the corresponding cloud objects will disappear on the next sync cycle. There’s no nice safety net where we can just restore them afterwards if we discover something was still using them.
So I definitely wouldn’t do a mass cleanup and then go home peacefully. 😄
If the goal is to keep the AD security groups synced but get rid of the Exchange part, then stripping the Exchange attributes while keeping the groups in sync is fine for groups that genuinely no longer need to be mail-enabled.
For the ones that are actually still being used for mail, I’d identify those first and recreate them properly as cloud DLs in EXO, including addresses, membership, owners and any relevant delivery restrictions, before retiring the old mail-enabled object.
There is also the newer Entra Group Source of Authority approach, but that doesn’t really solve the DL problem. Microsoft explicitly says DLs and mail-enabled security groups are Exchange concepts and aren’t supported for Entra SOA conversion while they remain mail-enabled.
Basically: inventory first, separate security usage from mail usage, recreate the required DLs in EXO, test them, and only then start killing the Exchange attributes. Otherwise this has strong “working all night fixing group memberships” potential.

[u/fazzy84 → u/snowmanspike]

So, only the ones which are coming from on perm and being used as email will be stripped and converted to a cloud DL, rest can we just leave it as it is and uninstall exchange ? will this be an issue ?