In Exchange Server 2007, you can use Windows PowerShell commands via Exchange Management Shell to manage standard and dynamic groups. In “Using PowerShell to Manage Groups, Part 1,” September 2007, InstantDoc ID 96699, I covered some of the basics about Windows and Exchange groups and Exchange Management Shell commands. Plus you saw how PowerShell is used to enable standard groups and work with group properties. Now I want to show you how to use PowerShell to maintain group membership and work with dynamic groups.
Maintaining Group Membership
Exchange administrators regularly maintain group memberships. Working with the shell, you use the Add-DistributionGroupMember command to add a member to a group, like this:
Add-DistributionGroupMember -id `
'Editors' -Member 'Eoin Redmond'
You must provide a pointer to the new member that Exchange can resolve. This can be a distinguished name (DN) such as “CN=Alan Kerr, OU=Exchange, DC=XYZ, DC=COM,” a user principal name (UPN) such as Joe.Jones@xyz.com, an alias, or a display name (used in the example). If you have more than a few members to add, you can do so by using a basic PowerShell trick—create a table, then pipe the table as input to the Add-DistributionGroupMember command, as follows:
"Jack Smith", "Jane Doe", `
"Molly Maguire" | `
Add-DistributionGroupMember `
-id 'Editors'
You can also scan mailboxes and apply a filter to discover members you want to add to a group. Here’s a one-line command that scans for mailboxes belonging to the “New York” office, then adds them to a group:
Get-Mailbox –Filter `
{Office -eq 'New York'} | `
Add-DistributionGroup `
-id 'New York Users'
Of course, you can also read in a list of members from a file and use the values to update a DG's membership. You can find many examples of code posted on Web sites and blogs. Try starting with
http://www.exchangeninjas.com/PSResources or http://blogs.technet.com/evand/
One of the joys of PowerShell is how easy it is to find and repurpose code for your needs, and I expect that we'll see more Web-based libraries of PowerShell examples for Exchange administrators in the next few years.
To check that your group has the right membership, use the Get-DistributionGroupMember command, as I’ve done in Listing 1. If you’ve made a mistake in adding members to the group, you can remove the incorrect entries by using the Remove-DistributionGroupMember command:
Remove-DistributionGroupMember `
-id 'Editors' -Member 'Alan Nemeth'
The shell will prompt you to confirm that you want to perform the action before it removes the object.
You can also find out the groups to which a user belongs. Doing so is a bit complicated because of the way AD uses pointers to build group membership:
$Member = (Get-User -id `
'Tony Redmond').Identity ;
Get-Group -Filter {Members -eq $Member}
There are actually two commands here. The Get-User command populates a variable called $Member with details of a user’s identity (the set of properties that lets Exchange find a user; Exchange is intelligent enough to select the most appropriate property from the set). Then the Get-Group command finds all groups that include the user. This command could be slow in large forests, but it’s a good example of how you can use PowerShell to find information that’s difficult to locate through the GUI.
Working with Dynamic Groups
Dynamic groups are different from standard distribution groups because they possess no membership until Exchange executes a query (called the recipient query) against AD to build the group membership. Exchange 2007 typically executes the query in the categorizer component of the transport service when messages addressed to dynamic groups flow through the first Hub Transport server. However, you can specify a server responsible for group expansion by updating the group’s properties, as Figure 1 shows.
You can easily create a new dynamic group by using the New-DynamicDistributionGroup command. This command puts together a dynamic DL for all mailboxes in the company, as in Listing 1. This command has two important parameters. First, the RecipientFilter parameter specifies the query Exchange executes against AD to build the group membership. For Company -eq ‘XYZ’ Exchange asks AD to find every entry that has XYZ in the company field. I also specify that I’m interested only in user mailboxes because I don’t want this list to be used to send messages to other groups or resource mailboxes. Second, the RecipientContainer parameter specifies the point in AD to start searching from, including all locations under this point. In this example, I pass the name of the domain, to include all of the mailboxes in the domain.
Exchange 2007 supports two types of recipient filters—precanned and custom. Precanned filters operate inside known boundaries, so Exchange optimizes the queries automatically when you use them. If you create or edit a query for a dynamic group through the Exchange Management Console wizard, the query will be precanned because the console limits your ability to create or edit queries to a set of known conditions presented by the wizard. Figure 2 shows how the console presents precanned conditions when you edit a dynamic group. A custom filter is one that you code yourself, as I did when I created the sample in Listing 2. Custom filters give you maximum flexibility in your Exchange-AD queries, but the syntax required to generate a precise OPath query (the standard filtering syntax used by PowerShell) can be hard to understand until you get used to it. For more information on O/PATH, go to http://www.exchangeninjas.com/OPATHSyntaxforDynamicDistributionGroups.
Exchange 2007 supports a set of special parameters—such as ConditionalCompany, ConditionalDepartment, and IncludedRecipients—that you can use to create precanned queries through Exchange Management Shell. If I want to change the custom query I used to create the dynamic group for company users to a precanned query, I’d use the command in Listing 3.
You can check the details of precanned and custom queries to see the exact syntax generated by Exchange by using the Get-DynamicDistributionGroup command, as Listing 4 shows. Exchange Management Shell returns three properties from this command. RecipientFilter is the query in OPath format, LDAPRecipientFilter is the query in LDAP format, and RecipientFilterType tells you whether the query is precanned or custom.
Why does Exchange have queries in both OPath and LDAP format? Query-based groups in Exchange Server 2003 use LDAP-format queries, so Microsoft had to ensure that dynamic-based groups created on Exchange 2007 servers could function if they were expanded by Exchange 2003 servers. Behind the scenes, Exchange 2007 automatically translates the OPath syntax into LDAP format after you update a query. However, you can’t pass an LDAP-syntax query to Exchange 2007 and have it update a dynamic group because you must either use the precanned parameters or pass a complete recipient filter in OPath syntax. Also, you can’t edit an Exchange 2007 dynamic group using Exchange 2003's Exchange System Manager because Exchange 2003 is smart enough to understand that it doesn’t know anything about OPath. Every object has an ExchangeVersion property that tells you whether Exchange 2003 can edit it. If the property is “0.1 (8.0.535.0)” it means that you can use only Exchange 2007 (or later) to edit the object. Finally, if you create a custom recipient filter, you must use Exchange Management Shell to edit it, because Exchange Management Console can only deal with precanned filters.
It’s easy to use the shell to create a dynamic group to address all users with mailboxes on a server. When you use a dynamic DL for this purpose, the advantage is that you don’t need to maintain it as mailboxes are added, deleted, or moved around. Listing 5 shows the code to create a new dynamic group that addresses all the mailboxes on a server called London-Mbx-1. When a dynamic group has outlived its usefulness, you can remove it using the Remove-DynamicDistributionGroup command:
Remove-DynamicDistributionGroup `
-id 'Mailboxes on London Server'
The Future of PowerShell and Exchange
PowerShell is undoubtedly a big part of the future for Exchange server administrators. And PowerShell’s inclusion in Windows Server 2008 indicates its growing importance in the Windows administration landscape. Microsoft has produced a complete set of commands to work with DGs in Exchange 2007, so the only question now is how and when you can take advantage of their work as you deepen your understanding of what Exchange Management Shell can do in your organization.
End of Article
Register
