I am running a hybrid configuration, so my Dynamic Distribution Groups (DDG) are on-prem, which I believe is the only time you'll see this problem.
I have had some users, that for years have not been getting emails that are sent to our All Users DDG or their location DDG. Finally I heard about this one user that did not get the All User email regarding a company event that required an RSVP. Many days later, I have it fixed, and this was affecting more than just one user.
This all comes down to mailNickname in the Attributes of the user account. If that is <not set> the user will never be included in any DDG. If you get into the Properties for the user's account, while in the OU where that accounts resides, you will see the tab for Attribute Editor. You can edit mailNickname using the Attribute Editor. If you're not in the actual OU, this tab does not appear (IE: don't open from search results).
The mailNickname normally matches the SAMAccountName, but even when it doesn't match (like where somebody got married and changed their name), the user will receive emails sent to any DDG they are in.
The command below will show you which accounts have blank (<not set>) mailNicknames. Well, it will show you all users if you point high enough in your OU structure. For example, we have an OU called Mail, under that are several OUs which align with our various locations. To see all my users, I point to Mail. To check out just a sub OU, I would change the distinguished name to point to that OU.
Anyway, when the list scrolls up the screen, just scroll back and forth looking for blank mailNicknames. Any account that doesn't have an email account, or is not used in any DDGs, can be ignored. This will be in PowerShell, not Exchange PowerShell.
Get-ADUser -Filter * -SearchBase "<distinguished name> -Properties mailNickname, sAMAccountName | Select-Object sAMAccountName, mailNickname
You still have to change the filters on your DDG's because some user's have a different recipient type than what O365 will have. O365 sets all users to mail-enabled. Your on-prem AD can have UserMailbox, MailUser, and MailContact.
The following command will fix your filters. I got errors sometimes when I used the name of the DDG, while other times it worked. Using the email address for the DDG worked every time. This will be in Exchange PowerShell on your on-prem Exchange server.
Set-DynamicDistributionGroup -Identity <DDG's email address> -RecipientFilter {(RecipientType -eq 'UserMailbox') -or (RecipientType -eq 'MailUser') -or (RecipientType -eq 'MailContact')}
Not sure if somebody is being left out? If the mailNickname is blank, they are being left out. But you can list the members with the commands below. This will be in the Exchange PowerShell on your on-prem Exchange server:
- create a variable that contains the name of any DDG. I have a DDG for All Users, and one for each location. You have to re-run at least the last two commands to see if you have fixed a user. And of course if you re-run the first command you'll need to re-run that last two.
$dl2 = Get-DynamicDistributionGroup <DDG email address>
* Build a 2nd variable for the last command to use.
$allr2 = Get-Recipient -RecipientPreviewFilter $dl2.RecipientFilter -OrganizationalUnit $dl2.RecipientContainer –ResultSize Unlimited
* List all the members with whatever info you want, name, primary email, etc.
$allr2 | Select-Object Name,PrimarySmtpAddress,Title,Department,city
I came into this with very little experience. This community helped a lot, but at the end of the day I found the problem by opening two users in the same OU. One gets the emails and the other user doesn't. I compared every attribute side by side, and something as innocuous as mailNickname was causing this problem (@ Jake Zhang - thank you for suggesting I look in detail at the specific properties and filters). Microsoft uses this field when creating the list of users for the email you are sending with a DDG. There is a filter in Exchange Online that says this field can't be blank. Why? Who knows, but it cannot be blank. By default is it supposed to match the SAMAccountName, but this clearly does not always happen (again, I don't know why).