Allow addition of members to mail-enabled security groups via Graph API
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?
48 Comments
- lboonekampCopper Contributor
Why are we still waiting for this? I've seen MS involvement in the conversation thread but we're still here 3 years later voicing our desire to have this added to the Graph API.
- jf_cwCopper Contributor
First comment of 2024!
I just want to add my voice to the crowd- We want this. We need this. Thank you. - Oliver_olstCopper Contributor
+1 Would love to have this in Graph. Can manage M365 groups, but too much baggage for auto-updated distributions. DLs and MESGs are what we need to manage new joins, moves and terminations!
- zvyezdanCopper Contributor
Yes, please add the feature! Onboarding solution is almost uniform with graph, except for mail enabled sec groups and distro lists. What even!? Now I have to resort to some roundabout ways to implement it (azure fn-s?). Maintenance will have me nailed to the cross when they find out eventually.
- bradbamford1Copper Contributor
@Darrel Miller Yes, would like to see it added back to the Graph. It is stupid that you can GET a list of members in a mail enabled security group, but you can't add or remove.
- Neil HoffCopper Contributor
I also agree with @lboonekamp . It should be part of the Graph API.
- chad512Copper Contributor
DarrelMiller It sure would be nice if somebody at Microsoft would make a final decision on whether or not Graph is going to be the unified API framework. It's complete crap to have Microsoft telling developers that X, Y and Z are going away, and we should use Graph, but--wait for it--what you are doing right now in X, Y and Z isn't supported in Graph.
- Joerg_JuengerCopper Contributor
Hi, I agree to lboonekamp . It should be part of the Graph API because nearly all other groups , rights and user manipulations can be done there in an automated way.
So manipulation of all these instances in Graph is the only way that makes sense.
Regards, JJ - DarrelMiller
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.
- lboonekampCopper Contributor
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?