Too many problems, not enough time.

Dynamic Distribution Groups –dynamically disturbing

If you haven’t seen or used Dynamic Distribution Groups (DDG) in Exchange before, which rock have you been hiding under? DDG has been around since Exchange 2007 and its precursor Query-based Distribution groups way back since Exchange 2000. QBDG never seemed to get too much attention. With the introduction of Exchange 2007 and PowerShell it’s become a lot easier to use and manage.

DDG works by querying Active Directory for object attributes. For example, Company Name or Department. So the foundation of fully functioning DDGs is having an actively updated and maintained AD. As everything Exchange, you can manage DDG in either the Exchange Management Console or via PowerShell. EMC is great for quick and dirty work but PowerShell is where you can do some cool stuff with DDGs.

DDG has been on my mind recently so this was a great opportunity to not only touch on how to create and manage a DDG but also around some of the issues around them.

Creating a DDG via the console wizard is very easy and self-explanatory. So I won’t go delve to deep into it.

Step to create are as follows…

Open the EMC

Navigate to Recipient Configuration -> Distribution Groups

Using the Action Pane select new Distribution Dynamic Group

The Dynamic Distribution Wizard will run. Enter a name for the new distribution group and click next.

Select mailbox types to filter by (default is all) and click next.

Create your conditions and click next.

The final screen gives you a summary detailing your options. Clicking New will create the DDG.

The console wizard has a number of limitations, namely you only have the option to query off three main attributes, State or Province, Department, and Company plus a half dozen or so custom attributes (which I’ve never used). For many organisations though this is more than sufficient in creating those generic company and department wide lists. It’s only when you start working with PowerShell that you can really take advantage of DDGs, but be mindful of how elaborate (or complicated) you get.

The PowerShell command to create a DDG is New-DynamicDistributionGroup. So as an example, say you set the Company attribute under the Organisation tab within all AD User objects. We would execute the following PowerShell script to create our new company wide Distribution List.

Fairly straight forward right? We specify in recipient filter to use the Company attribute and make sure it equals our company name. If it does, the user will be part of our new distribution list called “My Mailing List”.

The important part to make note here of is the –recipientcontainer parameter. By default when you create a DDG in PowerShell it will only run its query against the default Users container. By specifying mydomain.local we are tell the query to run from the root of our domain and include all sub OU containers.

Say you want to now modify your new DDG to query only users in a particular OU called Australia.

The command is similar to our initial one. We’re telling the script which DDG to modify but this time we only need to put the parameter we want to change.

To view who has been added to this DDG we would type the follow

$Users = Get-DynamicDistributionGroup –Identity “My Mailing List”

Get-Recipient –RecipientPreviewFilter $Users

What about something we can’t do in the EMC with Dynamic Distribution Lists? Okay, say we are setting the Managers attribute in our organisation on User objects to specify who their manager / team leader is within AD. We could create a team mailing list that would add users automatically as they move between managers / teams.

There’s two parts to this command. Firstly we query any users whose managers is called Jane Doe, and the only way to do this is to specify our manager’s full LDAP path. The second part is actually telling the script to statically add in the manager of the team -as they won’t be managing themselves and would most likely have a different manager specified.

You can even add users of security groups to a DDG. I’d only recommend this is very specific circumstances. Only because you’re basing a dynamic list of a static list. You may have good reason to do this however (e.g. You may have to add addition recipients but not want them part of the security group).

Don’t get carried away with Dynamic Distribution Groups just because you can manage to find a query to add anyone you want. The above script is a perfect example.

Things to make note of…

Don’t implement a Dynamic Distribution Group if it adds users that haven’t been requested part of a list. These situations call for tradition distribution groups. Forcing a DDG onto a team with superfluous users doesn’t achieve anything.

Be careful of users hijacking onto the back of a Dynamic Distribution Group. DDGs are based on AD attributes. Depending on your environment, users will be able to update certain attributions on their OU object. If a user is allowed to update their own Title and your DDGs are based off Titles. A user can move themselves in and out of Distribution Lists at will.

You will not be able to view DDGs through Outlook. This is by design as you don’t want to overload AD with constant queries on distribution groups. Keep this in mind when a user rings up asking why they are not part of a list.

Lastly, remember the -recipientcontainer parameter in your script. I always forget this 🙂