office 365 powershell to see what distribution groups a user is part of
Bringing Former Scripts Forrard
Recently, I wrote about the New-DistributionGroup cmdlet and explained how distribution lists remain so useful, fifty-fifty when Microsoft pushes Microsoft 365 Groups as the respond for all collaboration problems. A reader promptly wrote to say that distribution groups are different in Exchange Online than they are for Commutation Server and pointed out that PowerShell scripts written for on-premises consumption oftentimes don't work in the cloud. They fifty-fifty cited a Practical 365 article from 2015 telling how to report the number of members in distribution lists as an example.
The script is to highlight large distribution lists of the blazon which might potentially cause Reply-All postal service storms. Microsoft recently updated the reply-all command settings for Exchange Online to make mail storms less probable, but at that place'south no doubt that it's a good idea to know if any very large distribution lists exist and, more than importantly, who looks after these monsters.
Let go of Get-Mailbox; it's had its fourth dimension – Read more on moving Substitution Online scripts to utilise Get-ExoMailbox
The Difference Between Get-ADGroupMember and Get-AzureADGroupMember
The original script relies on the ability of the Get-ADGroupMember cmdlet (for Agile Directory) to recursively fetch distribution list members. In other words, if a distribution list contains nested distribution lists, you need to fetch details of all members to know how many recipients will receive messages sent to the list. The Exchange transport service expands distribution lists during its fan-out process to create copies of messages for recipients, and that's when the full number of recipients is known.
The problem about taking the original script to the cloud is that the equivalent Go-AzureADGroupMember cmdlet doesn't handle recursion. The Graph API for Groups has a transitiveMembers call to return "a flat list of all nested members," just that adequacy hasn't reached the PowerShell cmdlet. To testify how transitive members piece of work, Figure 1 shows the result of a call to https://graph.microsoft.com/v1.0/groups/4f6a1e58-84cc-4365-b339-7520508c1cbc/transitiveMembers to retrieve members of a distribution listing containing nested lists using the Graph Explorer tool.
If y'all've never used the Graph Explorer, you should spend some time to get used to it because it'due south a great way to learn how to collaborate with Graph API calls.
Groups and Lists
Distribution lists are Exchange mail-enabled objects and be in both the Commutation Online directory (EXODS) and Azure Advertizing. They're chosen distribution lists in the world of Commutation and distribution groups more generally beyond Microsoft 365, or just groups within Azure AD. Microsoft 365 Groups are much easier to process when it comes to member counts. First, you lot can't nest Microsoft 365 Groups. Second, only tenant and guest accounts tin be members. Third, the Get-UnifiedGroup cmdlet returns counts for tenant members and guest members. See this article for an example of how to study the membership of Microsoft 365 Groups.
Returning to PowerShell
It is straightforward to write a script to utilise the Graph API to fetch the membership of nested distribution lists (I'll testify how in some other article), but let'southward return to basic PowerShell and consider what we tin can do to solve the same problem equally Get-ADGroupMember does on-bounds.
In this article, Vasil Michev takes an in-depth look at the bug involved in generating a listing of all members of all groups in an organization, including Microsoft 365 Groups, dynamic distribution lists, and then on. Although we could adapt Vasil's script to practice what we desire, there's no fun in that, so I spent an hour or so coming upward with a solution to the problem of identifying large distribution lists.
The first rule of a successful PowerShell hacker is never to recreate the bike. Always begin a coding project by searching to see what people accept done to solve a problem, or at least part of the trouble, that you face. In this case, a search to find how people handled the question of treatment nested Azure AD groups turned upwards several useful functions, including ane I decided to use in my script.
The Newly Coded Solution
The code is reasonably simple. First, find all distribution lists in the tenant, excluding those used for room lists.
For each list, we find its membership. In this example, I use Get-AzureADGroupMember rather than Become-DistributionGroupMember. Either will piece of work. My conclusion was driven by the fact that the function I adapted used Azure AD. Finding the membership involves figuring out which members are elementary (user accounts, guest accounts, and post contacts) and which are groups. The membership of each nested grouping is resolved and added to the overall membership. At the end, the script removes any duplicate entries from the membership.
Afterward processing a distribution list, the script extracts some statistics about the number of members, tenant accounts, guest accounts, groups, and "others" (mail contacts mostly). The script too generates a list of members. This data is stored in a PowerShell list.
One time the script has processed all the distribution lists, it outputs a CSV file and shows the results via the Out-GridView cmdlet (Figure ii).
You can download the complete script from GitHub. Feel free to improve it and make it behave the style you think it should work. The point is that it's PowerShell, so the code is very adaptable for different purposes.
Source: https://practical365.com/getting-exchange-online-distribution-list-membership-counts-with-powershell/
0 Response to "office 365 powershell to see what distribution groups a user is part of"
Post a Comment