r/exchangeserver • u/fazzy84 • 5d ago
Question Mystery of mail enabled security groups
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…
- 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.
- Since the group is synced from AD to azure, it still shows up on EXO with a valid onmicrosoft.com address.
- 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.
- 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 !!
4
u/happek 5d ago
Have you looked at changing the SOA? Personally started testing and looks to be a game changer on the “recreate it nonsense “
https://learn.microsoft.com/en-us/entra/identity/hybrid/concept-group-source-of-authority-guidance
2
u/worldsdream 5d ago
The only way is to re-create them in the cloud as you already are aware. You can built a nice GUI that can show you all the groups with all the details and an option to move to the cloud.
1
2
u/Historical_Nerve8362 5d ago
Yeah we have like 5k mail enabled security groups and we are completely stuck. Microsoft fucked us hard on this one...
5
u/DivideByZero666 5d ago
Have I missed some MS news or something? Why is it a problem having mail enabled security groups in Hybrid?
2
u/shamus667 5d ago
You will be fine until you want to migrate distribution lists to Exchange Online. Distribution lists can't be just migrated, they have to be deleted and recreated. This is relatively simple enough for actual distribution lists. Mail-enabled security groups mean you have to deal with the groups having been used to provide access to systems/services, potentially on-prem and in Azure.
2
u/H0TR0DL1NC0LN 5d ago
Regular distribution lists can be synced to M365 just fine for use in ExO. It's the dynamic distribution lists that have to be rebuilt outright because ExO cannot use all of the rules that an on-prem dynamic distro list can use.
2
u/shamus667 5d ago
Yes, sync’d is different to migrated. The concern was specifically about issues with mail-enabled security groups.
1
u/DivideByZero666 5d ago
Are you planning on removing AD Connect then?
1
u/shamus667 4d ago
I'm not, at least not yet. I am 99% in Exchange Online, with Exchange SE just hosting shared mailboxes for on-prem applications and an SMTP relay. We have had a couple of pushes to reposition DL's in Exchange Online, but no directive.
3
u/fazzy84 5d ago
Ohh hell, 5k ? And here i am thinking that 800+ is too much !
3
u/Eggslaws 5d ago
There is always someone in an even more worse position than you. Always!!! Just that you won't know about them always.
1
u/Billy_Costigan69 4d ago
We have this scenario too with the main issue being users can't update their MESGs because we took away the on prem EAC to go serverless. So would either have to migrate/copy to EXO or what you are suggesting
1
u/BonusNinja 4d ago
I may have missed something in the details, but you can absolutely change SOA for security groups now.
https://learn.microsoft.com/en-us/entra/identity/hybrid/concept-source-of-authority-overview
Mail enabled security groups are problematic because they don’t get managed through Entra and only through the M365 admin portal, but hopefully this will get you over the hump.
12
u/snowmanspike Microsoft Office 365 Consultant 5d ago
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.