Years ago I used a third-party application for creating, managing, and updating automated DLs in Exchange. When I moved to another company that didn’t have that application, nor would spend the money to buy it, I wrote a script as a poor-man’s version of that application. Since then, it has been updated with more features, and I recently updated it again for a customer who wanted features I had never needed.
You might wonder why not use dynamic distribution groups? There are a number of limitations when using DDGs that automated DGs (née DLs) overcome:
- Use the group as a security principal
- Allow static members (those that should be members even though they don’t match the filter)
- Use any LDAP attribute in the schema in the search filter, not just those exposed via OPATH
- View the group membership (when an end user)
The way the module works is it marks an existing DG as automated and updates the Note property stating that it is an automated group; you enter an LDAP filter to use for membership, optionally specifying any static members and domains to restrict membership to, and save it; and the membership criteria are saved as a binary value in the extensionData attribute. Then you can run Update-AutoDL to update the membership of that one group or all (or all in a specified domain), or schedule a task to run that cmdlet to update membership, say, daily. If you want to download it without reading all of the details:
AutoDLManagement.zip (9.2 KiB)
- Permission to manage the group objects in Active Directory
The module uses ADSI to manage the groups, search for members, and to update membership.
- A shell with Exchange cmdlets loaded
A few of the Exchange cmdlets are used to validate that a group exists, and to enable it for automation.
- Put the module in an appropriate directory
If you want the module to be implicitly loaded, or explicitly loaded without specifying a path, put the module inside a directory of the same name inside the Modules directory of your profile, e.g.,
C:\Users\<username>\Documents\Windows PowerShell\Modules\AutoDLManagement\AutoDLManagement.psm1. You can put it anywhere if you want to load it manually and specify the full path to it.
- For interactive or scheduled execution, load the Exchange cmdlets
Whether using implicit remoting or a shell loading the Exchange snap-in locally, you’ll want to have the Exchange cmdlets loaded in the session before running any of the AutoDL cmdlets.
Features of the AutoDLManagement module:
- Uses an LDAP filter as membership criterion
Note: There is no syntax checking for the filter, so be sure you enter a valid one.
- Membership criteria are stored in the group itself
There is no external dependency except for the module to update the group membership.
- Group can contain static members
Include recipients that do not match the search filter. The attribute used to match static members can be customized. (The default is sAMAccountName.)
- Restrict membership to specified domains
The default configuration is to include all matching recipients in the forest, but you can specify one or more domains in the forest that membership is restricted to.
- Global filter that applies to all groups
This is a filter that is applied in addition to a group’s filter, such as not including terminated users.
- Customize which custom attribute (extensionAttributeN) and what text string are used to indicate a group is automated
- Email notification when a group update fails or membership is zero when it wasn’t previously
If the module is unable to add members after clearing membership, resulting in no members, you are notified so you don’t end up with a group that people are emailing and no one gets the message.
- Supports all versions of Exchange, including Exchange Online
Note: Exchange Online support requires groups to be authoritative on-premises, syncing to Exchange Online via AAD Connect.
- Display membership criteria in both “raw” and “pretty” formats
When you run
Get-AutoDLFilter, the result is an IE window that displays the LDAP filter, the static members, and domains for membership. The filter is displayed as both a raw string that you can copy and paste for editing, and as a formatted filter (based on my LDAP-formatting script described here) that can be easier to read and is useful when sending a filter to a user.
- Mirror membership from other groups
Sometimes a group owner wants the membership to mirror a security group because it isn’t mail-enabled. You can mirror membership of one or more groups by setting the LDAP filter to be “guid:<GUID of group>”. Separate multiple GUIDs with a semicolon.
- Logging of each group that is updated, including old and new count
- Ability to update the membership of one group, all groups, or groups in a specified domain
Update-AutoDL, you can provide the identity of a group, use the
UpdateDomainparameter to specify a single domain’s groups to update, or no arguments to update all groups in the forest. (If you update all groups interactively, it will ask for confirmation. If updated via a scheduled task, the confirmation is suppressed.)
- Set/Update a group’s criteria via command line or GUI
Set-AutoDLFilter(alias sadl) with the identity of a group. If the group is not already managed/automated, it will ask if you want to enable it:
After entering ‘y’, the GUI will display so you can enter membership criteria:
The form performs basic checks in order to enable the OK button: if static members is checked, then the text box has to be populated; if domain restrictions is checked, then at least one domain must be checked.When you run the cmdlet with a group that already has membership criteria, the form will be populated with the appropriate values, so you only have to modify what is to be changed about the criteria.For command-line updating, use the appropriate parameters for the filter, static members, and domain restrictions. (The parameters are documented in the cmdlet’s help.) If you update from the command-line, you need to include all values even if it isn’t changing. For example, if you are modifying the LDAP filter for a group that has static members, you need to specify those members even if they aren’t changing. Otherwise, the static members (or domain restrictions) will be lost.
- Pipeline support
For bulk-enabling and -changing groups, you can pipe groups to the
Set-AutoDLFiltercmdlet. This allows you to bulk-enable groups for automation and set their membership criteria if you already have that information in, say, a CSV. You can use a switch parameter with the cmdlet to suppress the confirmation prompt to enable automation for a group.
Functionality that I am considering adding in the future:
- Static exclusions
If there are recipients you don’t want to be in the group even though they match the criteria, you can specify them. (You can do this now by adding the username to the filter with a NOT operator, e.g.,
- Add object picker for selecting groups for mirrored membership
Currently, you need to manually enter the source group’s GUID in the LDAP filter field (preceded by
guid:). The object picker would let you browse the forest and select a group to have its GUID automatically entered.
- Perform syntax checking of an LDAP filter
- Preview the pending membership of a group
In the criteria editor, you could click a button to preview the membership based on the criteria currently specified (and without having to save it).
- Add/remove only changed members
Currently, group membership is cleared and then updated with all objects returned in the search. This has an element of risk because if a failure occurs between clearing and adding membership, the group is left with no members. This feature would compare the current and pending memberships and only add/remove the necessary objects.
If these or other features would be of interest to you, let me know in the comments. Download the module:
AutoDLManagement.zip (9.2 KiB)