Allow addition of members to mail-enabled security groups via Graph API

[Francis_Ollivier]

That would be very useful indeed - and if would allow us to do it withing PowerAutomate as well like before.

[KatrinF]

Thanks for raising this topic, @rakhesh!
I would also appreciate enabling management of memberships for distribution lists again! I had been using Graph API for this purpose for months until it suddenly stopped working.

[jorrin1455]

Used this in multiple flows which are now broken. Would really like to get this back.

[Bill_Hanson]

This and we also need the ability to manage standard distribution lists.

Currently considering converting hundreds of distribution lists to 365 groups just to be able to manage them again.

[olavrb]

1+ for this.

I have an Automation Account PowerShell script that uses Microsoft.Graph to automate the task of adding group membership from one or multiple source groups, to one given destination group. This makes it easy to automate group membership based on a mix of group types and dynamic rules.

• Permissions is currently Run As account, with additional Microsoft.Graph permissions given to the app registration.
• Input variables is group object ids only. So for every new scenario I just add a new schedule to this one Automation Account runbook. 🙂

Latest "mission" is to automate calendar permissions using a dynamic user group as source, and a mail enabled security group as destination (for group members). Where destination group is given calendar permissions.

But would you know it, adding group members to a mail enabled security group is not possible with Microsoft Graph. Too bad. Would you be so kind, Microsoft, to add this capability to the Microsoft Graph API?

[yatishmadhav]

Hi all ... +1. This is a feature that would be great - Microsoft, Please add the functionality of managing mail enabled security groups via the MS Graph API. Thank you

[orbis_user]

Seems Microsoft is hesitant to allow the Graph API to action anything in the Exchange workload, as there are no meaningful Power Auto triggers or actions available for that service.  You have to do everything using PS via Azure Automation actions.  It's not terrible, but seems unnecessary.

Why can't we use PowerAuto to manage Exchange mailbox properties and mail enabled groups?  I really cannot justify junking up the list of M365 Groups to include one for every mail+security group in the domain.

[yatishmadhav]

Hi all. I wonder if there is an progress on this from Microsoft? Or if there is any workaround? Thank you

[StefM66]

This feature will be very helpful for our Identity Management project. Thank you.

[tresnoface]

Please bring this feature to mange distro/security groups back into the Graph API. I have tons of scripts that I am having to use really janky workarounds which are not idea. Thanks!

[AlexBadiu]

This feature is very important for setting up a clear governance and facilitate the communication. Please bring this feature back. 

[David_Montalvo]

I view this as a necessary feature. Distribution Lists and Mail Enabled Security Groups are a still valid options within Exchange. I don’t see why management of these group types through Graph or Power Automate cannot be restored; this was evidently available in the past.

Not all groups need the collaborative aspects of Modern Groups, DLs and Mail-enabled SGs still serve a function, and should be manageable using the same options. 

[Cristiano_R]

If automate is to be used to enhance the Microsoft 365 administration experience going forward then we definitely need DLs and Mail enabled Security Groups to be manageable through it too.

It is absurd that I can use an onboarding form and a flow to automate user creation, manage it's security groups and assign licenses but can't add to a simple DL, thus requiring a human intervention just the same.

What's the point of having only a semi-automated process? Should we petition to rename it to Power Semi-automate?

[DougPChandler]

With everything moving to Graph, we need a consistent way of updating Groups, not if it is this type then do Graph, otherwise do some other way...

[David_Montalvo]

I can't agree more

[Piatta]

Would be great to get this working with Power Automate! It would be good for ISMS.

[ykohler]

Bumping the idea since it is indeed a great idea and I don't understand why all other "groups" can be updated via PA but not those 

[lboonekamp]

This should work both for adding and removing users. It seems odd that this could previously be achieved.

[10BamBam01]

I wonder if anyone even monitors these pages anymore.

[CristianoGRodrigues]

Yes, in the naif faith that someone, someday, will get the system back to the wanted function.

[EricLegault]

FYI, this lack of functionality is documented in a GitHub issue here, and the official response is to upvote the feature request.

[tonydileonardo]

The fact this doesn't work is making many companies stay in a hybrid environment.  We can automate this functionality in PowerShell On-premise easily.  This needs to be fixed as it is giving everyone the reason not use this product.  Even copilot believes it should work and it does not, the examples I have been testing all came from copilot.

[Joerg_Juenger]

We do need this feature to keep all groups in synch in our identity management. Would be really helpful to get this feature.

[feelie75]

Just adding another Upvote! This is definitely the definition of anti-automation and forces human intervention. Makes no sense why they left the API just half-done. Please finish it!

[jbaechtel]

Not only would this be helpful, it would be even more helpful to have Graph API support for Exchange Online in general.

Why do we have to have two different ways to manage things in the cloud?  Just the overhead of loading two different management modules and having to remember what gets done in this one and what has to be done in the other is burdensome.

Found an AzureAD commandlet (AzureAD module) that didn't work with either Certificate Based or ApplicationID authentication but did work with other Auth methods.  What is the deal there?

Found that the New-MgGroupMember commandlet just comes back with an error message like "We failed to update the group.  Try again later" message when trying to add a member to a group using the GroupId and the MemberId as parameters and yet the New-MgGroupMemberByRef commandlet works just fine.  I don't know how much time was wasted trying to figure that one out.  Inconsistencies like this are just wrong!

Microsoft keeps deprecating older modules and Auth methods and then doesn't provide the tools to easily use the newest standards/tools that they are forcing everybody to switch over to.

Come On, Microsoft!  Let's get it together and help your user base!

[jbaechtel]

This thread has been open for one month shy of two years and not even a peep from Microsoft.

Are you even listening Microsoft?  Is this on a roadmap somewhere?

[DarrelMiller]

Yes we are listening. I have been trying to make the case for this for longer than this thread has been around.  The conversation is happening once again, right now, but there remain some people that are not convinced that bringing the API functionality to Microsoft Graph is the right approach.

It would be useful feedback to understand whether you care if the API in on Microsoft Graph, and so would be part of the Graph docs and Graph SDKs, bound by Graph breaking change policies.  Or, if you don't care as long as there is an HTTP API you can call.

[feelie75]

Thanks for the feedback Darrel Miller! Personally, I don't care if it's part of the MS Graph API or just a ny API. Any 'ol HTTP API call to remove and add. personally, my code only deals with employee Terminations, so I just remove people from O365 groups.

The Graph API seems like it was a good idea, but then it kinda died; or at least issues like this make it seem like it died and got left behind, half-implemented.

But yeah, if there's ANOTHER way to add or remove people from an O365/Azure mail-enabled security group (or distribution list), that would be great so it doesn't have to be done manually!

AUTOMATE All the things! 🙂 Thanks!

[lboonekamp]

@DarrelMiller thanks for your input. I'm struggling to understand the reasons why there are people who believe it shouldn't be part of Graph? It's a standard operation, whether that's against a standard group or a mail-enabled security group shouldn't come into it.
To move this operation outside of Graph wouldn't make much sense, as you'd have almost all other operations being performed here and then for this operation you'd need to go over there. Also, what does that entail in terms of authentication; will we now need to authenticate against the new API and get a different token first or will our Graph token cover the new API?

[DarrelMiller]

@feelie75 We are actively working with many teams to bring admin scenarios such as SharePoint settings, Service Announcements, Edge management to Graph.  It would be disappointing if customers end up having to a different API and get a different token for certain M365 admin operations.  Having said that, I understand that you just want the capability to be made available.

@lboonekamp It is not really a case of someone thinking it should not be on Graph.  It is more a case of the effort to bring it to Graph could be spent working on other customer requests.   Yes, if it was a different API then it would require a different token.

Thank you both for your feedback.