Azure Automation – Distribution Group

I’ve been wanting to expand my skills and abilities within the Azure platform recently, and this week a great opportunity arose for this very thing.

We provide dynamic distribution groups within Office 365 for staff, based upon AD attributes populates with DirSync. The primary example here is our “SubCompany All Staff” list, which is created with this query filter:

New-DynamicDistributionGroup -alias SubCompanyAllStaff -Name "SubCompany All Staff" -RecipientFilter { ((RecipientType -eq 'UserMailbox') -and (Company -like 'SubCompanyName*')) }

Now we have executive staff who are transitioning from this SubCompany to a parent company, which is causing an issue. Their Company attributes are no longer “SubCompanyName”, but they wish to remain on the distribution list to receive communications. However, IT does not (will not) maintain a manual membership list for this type of group. We could create an “exceptions” group, add these staff in, mail-enable the group and make sure it’s part of the query filter above, but this means every time someone changes company, we have to remember to add them into the exception group.

A better way is to filter on the ProxyAddress attribute; anyone who has an email should be part of the distribution group. Those who switch companies maintain legacy addresses as aliases. For example:

Get-Recipient -Filter {EmailAddresses -like **}

However, while the Get-Recipient command works here, this type of filtering is NOT supported within a dynamic group recipient filter; it returns no results.

This leads me to the solution: use an Azure Automation runbook to run the Get-Recipient command to populate a static group on a schedule.

The Query

First, I needed a functioning PowerShell query. I initially arrived at this here:

# Add users matching criteria to list.

$users = Get-Recipient -Filter {EmailAddresses -like "**" -and RecipientTypeDetailsValue -eq 'UserMailbox'}

foreach($user in $users) { Add-DistributionGroupMember -Identity -member $user.WindowsLiveID }

# Remove those who no longer have an alias

$users = Get-DistributionGroupMember -Identity "Company TestAll" | Get-Recipient -Filter {EmailAddresses -notlike "**"} 

foreach ($user in $users) {Remove-DistributionGroupMember -Identity "Company TestAll" -member $user.WindowsLiveID -confirm:$false}

While this did perform what I was after, it was messy. I wanted this to run on a schedule, so the first ‘addition’ command would effectively error out on the majority of the group members. When I tried to run the second command as my service account in the run book, it threw a large amount of errors about the users not being found on the domain controller.

After a lot of back-and-forth testing, I had this command that works perfectly:

Update-DistributionGroupMember "Company TestAll" -Members (Get-Recipient -Filter {EmailAddresses -like "**" -and RecipientTypeDetailsValue -eq 'UserMailbox'}|select -ExpandProperty Alias) -confirm:$false



Having never looked at Azure Automation before, I started reading. This blog post was a helpful start, and I went through quite a bit of the site reading about Runbooks, PowerShell vs. PowerShell Workflow, credential access, and so on.

I created an Automation account that is intended to be specific to Office 365 scripts, along with a corresponding Resource Group. Since this isn’t going to touch any other Azure resources, I did not create a RunAs account with it.

Next I began looking at the best way to connect to Exchange Online. I quickly found this module which looked very promising. However, after importing it as an Asset in the account, the example given of “Set-ModuleCredential” wasn’t found as a valid cmdlet, and I couldn’t see it in the .psm1 file either. Since there were many other examples of connecting to Exchange, I moved on.

The next problem I found was that when I tried to do the standard RemoteSession to connect, testing the runbook would fail without any meaningful error message; just 3 attempts and then “suspended”. Based on that behavior, I found this on the feedback portal for Azure, which is exactly what was happening. The method provided by Rune Myrhaug works great:

# Pull credential from Automation assets
$credObject = Get-AutomationPSCredential -Name "svc_auto_azure"

#Connect to Exchange Online
$ExchangeOnlineSession = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri -Credential $credObject -Authentication Basic -AllowRedirection
Import-Module (Import-PSSession -Session $ExchangeOnlineSession -AllowClobber -DisableNameChecking) -Global

I created a service account in Active Directory, synchronized it to O365 with DirSync, and then used the Exchange Admin portal to ensure it had appropriate roles to manage Distribution Groups. I added this account in as a credential asset, and created a daily schedule as well.

The final step was to publish the runbook and associate it with my schedule, and now I have an automated quasi-dynamic distribution group!

I can forsee this potentially being useful for groups that are not built along attribute filters. Perhaps something like a SharePoint list that is populated by administrative staff or department heads, which is then consumed in the runbook and applied to a distribution group.




2 thoughts to “Azure Automation – Distribution Group”

  1. Hello Jeff!

    Thank you for this. I have implemented something very similar in my environment. I event went to so far as to connect this runbook with a Microsoft Form that HR could fill out for new employees. The form would trigger a Microsoft Power Automate flow, and, after approval from IT, would trigger the runbook to create an employee. However the problem I ran into is, when we are onboarding multiple users at the same time my runbooks begin to fail. The reason is because Microsoft does not allow more than three concurrent Exchange Online sessions in Powershell at a time. I’m unable to find a way around this. Have you run into this before?

    1. Hey Jim, your workflow with a Microsoft Form sounds really cool. I haven’t worked much with Exchange Online and automation since I made this post, so I can’t say I’ve specifically run into or solved this problem.

      I’d first make sure that you’re using the “Remove-PSSession” at the end of your runbook to properly close out sessions, rather than waiting for them to time out.

      The other thing I’d suggest is maybe turning your automation into an Azure DevOps pipeline, called from a web hook. Using the free tier of DevOps, it will only allow 1 concurrent pipeline to run, and queue up all other instances behind it. This will easily allow you to implement queuing without having to write it yourself. You could have a PowerShell task in the pipeline just call your existing runbook, or convert your runbook into a script task in the pipeline.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.