Copilot for Microsoft 365 Tech Accelerator
Feb 28 2024 07:00 AM - Feb 29 2024 10:30 AM (PST)
Microsoft Tech Community

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

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

Upvotes

Upvote

 Nov 18 2021
38 Comments (38 New)
New

Previously one could add members to mail-enabled security groups via Graph API. But turns out that was a bug, and it was fixed some weeks ago removing this functionality. Would it be possible to allow add-remove of members in mail-enabled security groups via Graph API?

Comments
Copper Contributor

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

Copper Contributor

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.

Copper Contributor

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

Copper Contributor

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.

Brass Contributor

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?

Copper Contributor

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

Copper Contributor

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.

Copper Contributor

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

Copper Contributor

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

Copper Contributor

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!

Copper Contributor

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

Copper Contributor

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. 

Copper Contributor

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?

Copper Contributor

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...

Copper Contributor

I can't agree more

Copper Contributor

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

Copper Contributor

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 

Copper Contributor

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

Copper Contributor

I wonder if anyone even monitors these pages anymore.

Copper Contributor

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

Brass Contributor

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

Copper Contributor

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.

Copper Contributor

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

Copper Contributor

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!

Copper Contributor

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, MicrosoftLet's get it together and help your user base!

 

Copper Contributor

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?

Microsoft

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.

Copper Contributor

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!

 

Copper Contributor

@Darrel Miller 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?

Microsoft

@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.