Hide Individual Distribution List Members to Keep Their Identity Secret

A question in the Office 365 Technical Discussions Facebook group asked whether it is possible to hide individual distribution list members. This necessity might arise when you want to use a single distribution list to communicate information and you don’t want people to know the full set of recipients. Perhaps some recipients are external advisors or maybe you want to hide the fact that information is being shared with certain people within the organization.

The simple answer is no. Exchange Online supports the hiding of complete membership, but not an individual member of a distribution list. The same applies to hidden membership for Microsoft 365 groups. One workaround is to hide the distribution list from Exchange address lists. This stops users browsing the Global Address List (GAL), Offline Address List (OAB), or All Distribution Lists address list to find the list. Even if some discovers the SMTP address of the distribution list and sends a message, they can’t see the membership.

To hide a distribution list, edit its properties using the Exchange admin center (Figure 1). Hiding the list from the GAL is shorthand for hiding it from all address lists, including the OAB.

Alternatively, you can hide membership for a distribution list with PowerShell:

Set-DistributionList -Identity "Accounting Department" -HiddenFromAddressListsEnabled $True

Using a Nested Distribution List to Hide Members

However, hiding a distribution list that people might want to use removes a lot of its value. A better workaround exists dating back to Exchange 2000 or thereabouts, which is when I think the hidden membership feature first arrived (or maybe Exchange 2003).

The idea is simple. A distribution list can include nested distribution lists in its membership list. What we do is create a distribution list with hidden membership and include it in the membership of the public list. Here are the steps:

• Create a distribution list that includes all the users that you are happy for other users to know about.
• Create a second distribution list and set it to have hidden membership.
• Add the people you want to hide to the membership list of the second list.
• Add the second list to the membership of the first list.

You end up with a situation like that shown in Figure 2. The Public People List includes a distribution list called Secret People List in its membership.

If someone clicks on the Secret People List entry, they see the properties of the distribution list but not its membership (Figure 3). The members of the nested distribution list are invisible.

PowerShell Commands to Create the Public and Secret Lists

Here are the steps to use PowerShell to create what’s shown above. First, create the public list:

New-DistributionGroup -Name 'Public People List' -Alias Public.People.DL -Description 'People who want to be in a DL and be seen' -DisplayName 'Public People List' -IgnoreNamingPolicy

Now add the members that should be visible to the distribution list:

Add-DistributionGroupMember -Identity Public.People.DL -Member Hans.Geering
Add-DistributionGroupMember -Identity Public.People.DL -Member Otto.Flick
Add-DistributionGroupMember -Identity Public.People.DL -Member Michelle.duBois
Add-DistributionGroupMember -Identity Public.People.DL -Member James.Ryan
Add-DistributionGroupMember -Identity Public.People.DL -Member Ken.Bowers

The next step is to create the secret list. In this case, the HiddenGroupMembershipEnabled property is set to $True.

New-DistributionGroup -Name 'Secret People List' -Alias Secret.People.DL -Description 'People who want to be in a DL but not be seen' -DisplayName 'Secret People List' -HiddenGroupMembershipEnabled:$True -IgnoreNamingPolicy

Add the members of the secret list:

Add-DistributionGroupMember -Identity Secret.People.DL -Member Ann.Conroy
Add-DistributionGroupMember -Identity Secret.People.DL -Member Lotte.Vetler

Finally, add the secret list to the membership of the public list:

Add-DistributionGroupMember -Identity Public.People.DL -Member Secret.People.DL@office365itpros.com

To validate that the membership is as expected, run the Get-DistributionGroupMember cmdlet to check the membership of the public list:

Get-DistributionGroupMember -Identity Public.People.DL | Format-Table DisplayName, RecipientType

DisplayName                       RecipientType
-----------                       -------------
James Ryan                        UserMailbox
Ken Bowers                        UserMailbox
Otto Flick                        UserMailbox
Hans Geering (Project Management) UserMailbox
Michelle Dubois                   UserMailbox
Secret People List                MailUniversalDistributionGroup

When users send a message to the public list, the Exchange Online transport service resolves the membership, including the nested secret list. Figure 4 shows the recipients for a message sent to the public list as viewed through OWA. The secret list is in the recipients, and we know that this copy was delivered to Ann Conroy, a member of the secret list, because her name is in the window title bar.

You can run a message trace to confirm that the Exchange transport service expanded the message recipients to include members of the list:

Get-MessageTrace -MessageId DB7PR04MB441021BCEDA43033408C417C8B7B2@DB7PR04MB4410.eurprd04.prod.outlook.com | ft received, 'recipientaddress', subject

Received            RecipientAddress                     Subject
--------            ----------------                     -------
24/01/2024 22:37:16 ken.bowers@office365itpros.com       Interesting Information to Read
24/01/2024 22:37:16 public.people.dl@office365itpros.com Interesting Information to Read
24/01/2024 22:37:16 hans.flick@office365itpros.com       Interesting Information to Read
24/01/2024 22:37:16 secret.people.dl@office365itpros.com Interesting Information to Read
24/01/2024 22:37:16 michelle.dubois@office365itpros.com  Interesting Information to Read
24/01/2024 22:37:16 lotte.vetler@office365itpros.com     Interesting Information to Read
24/01/2024 22:37:16 james.ryan@office365itpros.com       Interesting Information to Read
24/01/2024 22:37:16 ann.conroy@office365itpros.com       Interesting Information to Read
24/01/2024 22:37:16 hans.geering@office365itpros.com     Interesting Information to Read

Note that the name of the secret list does not feature in the set of recipients reported by the message trace, but the public list does. This is because the event reported by the message trace for the list is the expansion of the recipient list while the other events are deliveries.

Old Secrets Can Be the Best

Sometimes the old tricks are the best. In this instance, using a nested distribution list to cloak the identities of some recipients is a nice workaround and solves the question asked in the group.

Learn about maximizing your usage of Exchange Online and the rest of Office 365 by subscribing to the Office 365 for IT Pros eBook. Use our experience to understand what’s important and how best to protect your tenant.

Dynamic Group Membership is the Obvious But Not the Only Option

A member of the Microsoft Technical Community asks if it’s possible to automatically add newly-created accounts to an existing group. The initial response offered by the community focused on dynamic groups – either dynamic distribution lists or dynamic Azure AD groups.

It’s a reasonable suggestion. Dynamic distribution groups are part of base Exchange Online functionality and don’t require any additional licenses. Dynamic Azure AD groups require Azure AD Premium P1 licenses for every account covered by dynamic membership. In both cases, the trick is to make sure that the query used by Exchange Online or Azure AD to determine group membership finds the new account.

Dynamic Group Membership for Exchange Online Mailboxes

It’s possible to create a dynamic distribution group based on a simple query like “all mailboxes” that will automatically include new accounts (if they have mailboxes). Figure 1 shows the UX in the Exchange admin center (EAC) to define the membership of a new dynamic distribution list.

The list works and email sent to it arrives in the inbox of every mailbox in the tenant, including shared mailboxes. This is because the recipient filter generated by Exchange Online for the dynamic distribution group selects all mail-enabled objects with a recipient type of ‘UserMailbox’ and only filters out some system mailboxes.

A dynamic distribution list like this is said to use a “canned” recipient filter because Exchange Online generates the filter based on the choices the administrator makes when they create the new list. You can only edit canned filters through the EAC. Exchange Online gives greater flexibility through the support of custom recipient filters. These filters can only be created using PowerShell, but they’re much more flexible in terms of selecting the set of mail-enabled objects to address through the list. A simple custom recipient filter to find just user mailboxes is shown below together with a test with the Get-Recipient cmdlet to prove that the filter works.

$Filter = "{RecipientTypeDetails -eq 'UserMailbox'}"
Get-Recipient -RecipientPreviewFilter $Filter

Dynamic Group Membership for Azure AD User Accounts

Dynamic Azure AD groups can be used with Microsoft 365 groups and Teams. These groups use different membership filters (query rules) to find the set of target objects. Instead of mail-enabled objects like mailboxes, the query against Azure AD focuses on user accounts rather than mailboxes. However, the same capability exists in that it’s possible to create a dynamic Azure AD group that includes all user accounts, including those newly created.

Again, the key is to construct a query rule that finds all user accounts – of the right type. When Azure AD is used for a Microsoft 365 tenant, there are many non-interactive user accounts created to give identities to objects such as shared mailboxes and room mailboxes. These are all considered “member” accounts and it’s easy to build a rule to find all member accounts. However, you probably want a more refined version that finds just the accounts used by humans.

Azure AD doesn’t have a human filter, so we need to construct something that Azure AD can use to find matching accounts in its directory. One approach is to use licenses for the check. You could look for accounts assigned Office 365 E3 licenses but would have to check for accounts with F1 or E5 licenses too. An easy change is to look for accounts that have any license that has at least one enabled service. For instance, accounts with Office 365 E3 or E5 licenses with the Exchange Online, Teams, Planner, or SharePoint Online service would all match. Figure 2 shows a test of the rule against a “real” user account and some other user accounts belonging to room and shared mailboxes. You can see that the real account passes the validation test while the others do not.

Azure AD accounts used by shared mailboxes must be assigned licenses when they need more than 50 GB of mailbox storage or an online archive. These accounts satisfy the membership rule, but that’s perhaps not important. If it is, some tweaking of the membership rule is necessary to remove the shared mailbox accounts.

Dynamic Group Membership of Org-Wide Teams

If your organization is smaller than 10,000 accounts, new Azure AD accounts automatically join the org-wide teams in the tenant (a tenant can support up to five org-wide teams). Org-wide teams are a special form of dynamic Microsoft 365 group whose membership is controlled by Teams rather than Azure AD, so Azure AD Premium P1 license are not required.

The PowerShell Alternative to Manage Dynamic Group Membership

If you don’t want to use a dynamic object, it’s certainly possible to use standard distribution lists or Microsoft 35 groups. In this scenario, the tenant takes the responsibility for maintaining group membership. Usually, PowerShell is used to add new accounts to group membership. You don’t have to worry about removing deleted accounts from the group as this happens automatically following an account deletion.

To add a new user to a distribution list, use the Add-DistributionGroupMember cmdlet:

Add-DistributionGroupMember -Identity "All Tenant Mailboxes" -Member Lotte.Vetler@office365itpros.com

To add a new user account to a Microsoft 365 group, either run the Add-UnifiedGroupLinks cmdlet (from the Exchange Online management module) or the New-MgGroupMember cmdlet (from the Microsoft Graph PowerShell SDK):

Add-UnifiedGroupLinks -Identity "All Tenant Accounts" -LinkType Member -Links Lotte.Vetler@office365itpros.com

New-MgGroupMember -GroupId "107fe4dd-809c-4ec9-a3a1-ab88c96e0a5e" -DirectoryObjectId (Get-MgUser -UserId Lotte.Vetler@office365itpros.com).Id

If the tenant creates user accounts programmatically with PowerShell, these commands can be added to that script. If not, a background scheduled job could find accounts that don’t exist in group membership and add them. See this article for more information about group management with the Microsoft Graph PowerShell SDK.

Many Possibilities to Ponder

A simple question required a long answer. That’s because the questioner didn’t specify what type of group that they wanted to add new accounts to. In any case, it’s nice to be able to debate the possibilities and then settle on the best course of action to take.

Insight about the various options to manage dynamic group membership for new accounts doesn’t come easily. You’ve got to know the technology and understand how to look behind the scenes. Benefit from the knowledge and experience of the Office 365 for IT Pros team by subscribing to the best eBook covering Office 365 and the wider Microsoft 365 ecosystem.

A reader asks what’s the best way to transfer the membership of distribution lists from one user account to another? If this is a one-off operation involving just a few DLs, the right answer is to add the new account to the DLs using your preferred administrative interface (Microsoft 365 admin center, Exchange admin center, or PowerShell).

Automating Distribution List Updates

Handling a few adjustments to distribution list membership through a GUI is acceptable. But if the membership of 30 or 40 distribution lists must be adjusted, which sometimes happens when people change jobs, it’s better to automate the process (if only to avoid boredom).

The capabilities of Exchange Online PowerShell make this task very straightforward. The basic approach is:

• Find the source mailbox (check it exists, etc.).
• Find the target mailbox.
• Find the set of distribution lists the source mailbox is a member of. If the mailbox doesn’t belong to any distribution lists, say so and exit.
• Display the set of distribution lists to be transferred and prompt for approval to proceed.
• If yes, go ahead and add the target mailbox to the membership of each of the distribution lists in the set. Optionally, remove the source mailbox from the same distribution lists.

Here’s some code to illustrate the principle.

$SM = Read-Host "Enter name of source mailbox"
$SourceMailbox = (Get-ExoMailbox -Identity $SM -ErrorAction SilentlyContinue -RecipientTypeDetails UserMailbox)
If (!($SourceMailbox)) { Write-Host "Unable to find mailbox for" $SM " - exiting"; break }
$TM = Read-Host "Enter name of target mailbox"
$TargetMailbox = (Get-ExoMailbox -Identity $TM -ErrorAction SilentlyContinue -RecipientTypeDetails UserMailbox)
If (!($TargetMailbox)) { Write-Host "Unable to find mailbox for" $TM " - exiting"; break }
$DN = $SourceMailbox.DistinguishedName
$NewDN = $TargetMailbox.DistinguishedName
[array]$DLs = (Get-DistributionGroup -ResultSize Unlimited -Filter "Members -eq '$DN'" | Select DisplayName, Notes, ExternalDirectoryObjectId, ManagedBy, PrimarySmtpAddress)

If ($DLs.Count -eq 0) { Write-Host "Sorry, but" $SourceMailbox.DisplayName "isn't a member of any distribution groups - exiting" ; break }

CLS
$DLs | Format-Table DisplayName, PrimarySMTPaddress -AutoSize
$PromptTitle = 'Transfer membership of Distribution Lists'

$PromptMessage = 'Please confirm whether to go ahead and transfer membership of ' + $DLS.Count + ' distribution lists from ' + $SM  + ' to ' + $TM
$yes = New-Object System.Management.Automation.Host.ChoiceDescription "&yes", 'yes?'
$no = New-Object System.Management.Automation.Host.ChoiceDescription "&no", 'no?'
$cancel = New-Object System.Management.Automation.Host.ChoiceDescription "&cancel", 'Exit'
$PromptOptions = [System.Management.Automation.Host.ChoiceDescription[]]($yes, $no, $cancel)
$PromptDecision = $host.ui.PromptForChoice($PromptTitle, $PromptMessage, $PromptOptions, 0) 

If ($PromptDecision -eq 0) { # Yes
  ForEach ($DL in $DLs) {
     Write-Host "Adding user" $TargetMailbox.DisplayName "to DL" $DL.DisplayName "and removing" $SourceMailbox.DisplayName
     Add-DistributionGroupMember -Identity $DL.ExternalDirectoryObjectID -BypassSecurityGroupManagerCheck -Member $TargetMailbox.PrimarySmtpAddress -ErrorAction SilentlyContinue
     Remove-DistributionGroupMember -Identity $DL.ExternalDirectoryObjectId -Confirm:$False -Member $SourceMailbox.PrimarySmtpAddress -BypassSecurityGroupManagerCheck -ErrorAction SilentlyContinue
  } # End Foreach
} # End if

[array]$NewDLs = (Get-DistributionGroup -ResultSize Unlimited -Filter "Members -eq '$NewDN'" | Select DisplayName, Notes, ExternalDirectoryObjectId, ManagedBy, PrimarySmtpAddress)
Write-Host " "
Write-Host ("All done. {0} is now a member of {1} distribution lists." -f $TargetMailbox.DisplayName, $NewDLs.Count)
$NewDLs | Format-Table DisplayName, PrimarySmtpAddress

There are many enhancements you could make to the code, including checking if the source mailbox is the owner of any of the distribution lists and if their removal leaves the distribution list in an ownerless state (this isn’t good). The code is written for Exchange Online but should work on-premises with a few adjustments (like switching Get-Mailbox for Get-ExoMailbox and using a different property for the distribution list identity).

Handling Dynamic Distribution List Membership

Transferring membership of dynamic distribution lists is more difficult. Dynamic distribution lists depend on a query (filter) executed against the Exchange Directory to resolve the set of recipients. Filters can be precanned, meaning that they execute against a set of well-known object properties like the department or city. Alternatively, the list owner or maintainer can create a custom filter with PowerShell to query against any property available for mail-enabled objects. Custom filters can be an excellent way to find the

Both precanned and custom filters depend on directory data. It therefore follows that to transfer membership from one mailbox to another, you need to understand the properties used by the filter and then adjust the properties of the target mailbox in the directory so that the filter includes the target mailbox in its result set when it runs. It’s possible to update directory properties with PowerShell to make sure that mailboxes are found by precanned or simple custom filters, but this becomes more difficult for complex custom filters. Given the number of dynamic distribution lists which are probably involved in moving membership from one mailbox to another, it’s probably best to make the changes manually.

And the Graph?

It would also be possible to transfer membership of distribution lists using the Microsoft Graph Groups API. However, this is an example of a situation where plain and simple PowerShell is all that’s needed. You won’t speed up the updates to any significant degree and will spend longer writing the code. That’s not a good trade-off, so stick with PowerShell and contemplate how easy it is to automate operations like this with just a few commands.

Learn more about how Office 365 really works on an ongoing basis by subscribing to the Office 365 for IT Pros eBook. Our monthly updates keep subscribers informed about what’s important across the Office 365 ecosystem.

A recent request asked how to add a single user (mailbox) to multiple distribution lists. The easy answer is to say that although it might be tedious, the simplest approach is to use the Exchange Admin Center or Microsoft 365 Admin Center to update the membership of the target groups.

This is an acceptable response when you have a small number of lists to update. It’s a little different when you need to add a mailbox to hundreds of lists, which was apparently the situation behind the plea. PowerShell is the obvious way to approach the problem.

Use an Array as Input

The first run at the code uses an array to hold the target distribution lists. After reading in the name of the mailbox to add and checking that it is a real mailbox, we call the Add-DistributionGroupMember cmdlet to update each target list.

$CheckName = Read-Host "Enter Name of mailbox to add"
  Try {
   $Mbx = Get-Mailbox -Identity $CheckName -ErrorAction Stop | Select -ExpandProperty PrimarySmtpAddress}
  Catch {
Write-Host "No mailbox can be found called" $CheckName; break }
$DLs = @("Company Sales", "Trading Partners Team","Planner Gurus")
ForEach ($DL in $DLs) {
   Add-DistributionGroupMember -Identity $DL -Member $Mbx } 

Use a CSV File as Input

Populating an array can be error-prone. Here’s some updated code that reads the distribution lists in from a CSV file. The file is very simple (Figure 1) and contains the alias of each list under a heading called “Dl Alias.” If you don’t want to use the alias, you could use any of the value identifiers for a list like a display name, distinguished name, or primary SMTP address.

With the CSV file prepared, we can read it in with the Import-CSV cmdlet and use the alias in each line to identify the target distribution list. Here’s the code:

$CheckName = Read-Host "Enter Name of mailbox to add"
Try {
    $Mbx = Get-Mailbox -Identity $CheckName -ErrorAction Stop | Select -ExpandProperty PrimarySmtpAddress}
Catch {
    Write-Host "No mailbox can be found called" $CheckName; break }

$DLs = Import-CSV "C:\Temp\InputDLs.csv"

ForEach ($DL in $DLs) {
     Try {
       Add-DistributionGroupMember -Identity $DL."DL Alias" -Member $Mbx -ErrorAction Continue }
      Catch {
        Write-Host "Couldn't add" $Mbx "to DL" (Get-DistributionGroup -Identity $DL."DL Alias").DisplayName }
}

I’ve already answered the questioner in the Facebook group where the issue arose and document it here for anyone else who might be interested.

If our questioner only had a copy of the Office 365 for IT Pros eBook they would have found the answer themselves. The book contains hundreds of PowerShell examples. Subscribe and support the only book that constantly evolves to keep pace with Office 365.