Focusing on certain recipients by using filters
The most basic form of a recipient filter used with email address policies is that used for the default policy, which sets a scope that tells Exchange to apply the policy to every mail-enabled object in the organization. However, like dynamic distribution groups, you can create sophisticated recipient filters to focus the scope of an email address policy as tightly as you would like.
If you use the Get-EmailAddressPolicy cmdlet to examine the recipient filter for the default policy, you see that it contains this filter:
Alias -ne $null
However, the recipient filter for the email address policy for the members of the IT department is:
((Department -eq 'IT') -and (RecipientType -eq 'UserMailbox'))
In other words, “Select any recipient that is a user mailbox and has IT as its department.”
EAC offers a little less flexibility in terms of creating recipient filters for email address policies than did EMC. The benefit here is that EAC focuses on the common criteria used for recipient filters and excludes some of the more complicated and less used criteria that EMC allowed administrators to manipulate (and possibly get wrong). As always, if you need to create a more complex recipient filter, you can do so through EMS.
For now, concentrate on using EAC to create a recipient filter. This approach is similar to creating a recipient filter for a dynamic group and offers the same selection of preformatted properties from which to choose. You can:
- Specify the kind of mail-enabled objects to which Exchange should apply the policy. Every mail-enabled object needs an email address, which is why the default email address policy applies to all kinds of mail-enabled objects. However, you might decide that rooms and resource mailboxes should have different forms of email addresses than user mailboxes. EAC enables you to select the different types of mailboxes to which a policy can apply.
- Specify a particular Active Directory container to locate the objects for the policy to process. Each email address policy has a RecipientContainer property that tells Exchange which objects to process. By default, the property is left blank, so Exchange should process every object in the organization that matches the recipient filter. In Figure 4, a particular OU in Active Directory has been selected as a rule for the recipient container to instruct Exchange that this policy only applies to objects in that part of Active Directory.
Figure 4. Adding rules to an email address policy
- Specify other rules to focus the policy even more tightly. These rules are those available for dynamic distribution groups and include the 15 custom attributes.
If you view the recipient policy in the email address policy created in Figure 4 by using the Get-EmailAddressPolicy cmdlet, you see:
RecipientFilter : ((((Department -eq 'Sales') -or (Department -eq 'Marketing'))) -and (((StateOrProvince -eq 'France') -or (StateOrProvince -eq 'Ireland'))) -and (CustomAttribute2 -eq 'Account Executive') -and (RecipientType -eq 'UserMailbox'))
As stated before, it’s best to restrict the number of email address policies that are used across the organization to avoid confusion and the proliferation of multiple email addresses for objects. However, if you need to create a focused email address policy, it’s probable that you can do this with EAC, and if the recipient filters generated by EAC are insufficient, you can then explore custom filters for email address policies.
Creating email address policies with custom filters
Why would you need to use EMS to create a recipient filter for an email address policy? The need to use EMS probably will not arise very often. The most common reason is that you want to filter based on a property that is not exposed in the EAC user interface (UI).
This requirement can be handled by creating an email address policy with a custom filter using the New-EmailAddressPolicy cmdlet. In this situation, the syntax rules are the same as those used to specify recipient filters for dynamic distribution groups, so the filters you can create are very flexible. For example, assume that you want to create an email address policy that applies to mailbox users in the Dublin office only. You could use New-EmailAddressPolicy to create the new policy and then immediately apply it to the matching recipients with Update-EmailAddressPolicy. Note that before Exchange will accept the value used here for the primary SMTP address template (@dublin.contoso.com), this domain must be created as an accepted domain for the organization.
New-EmailAddressPolicy –Name 'Dublin Office Users' –RecipientFilter {City –eq 'Dublin' –and RecipientTypeDetails –eq 'UserMailbox'}
–EnabledPrimarySMTPAddressTemplate 'SMTP:%g.%[email protected]' –Priority 2 Update-EmailAddressPolicy –id 'Dublin Office Users'
Two big issues come into focus here. First, it’s easy to create an email address policy that contains a recipient filter that never applies to any object. This happens if you specify a property Exchange cannot use to filter recipients or if you just create an incorrect filter. One way around this problem is to test the filter you propose to use by inputting it to the Get-Recipient cmdlet on the basis that if the filter returns the correct object set when used with Get-Recipient, it will generate similar results for an email address policy. For example:
Get-Recipient –RecipientPreviewFilter "City –eq 'Dublin' –and RecipientType –eq 'UserMailbox'"
Second, unlike the email address policies so far considered, policies created in this manner have a custom recipient filter. You cannot edit these policies with EAC afterward, so if you need to update the recipient filter subsequently, you will have to do it by writing a new recipient filter with the Set-EmailAddressPolicy command. Figure 5 shows how EAC recognizes that an email address policy has a custom filter that it cannot edit and the very useful preview facility that enables you to see exactly which objects Exchange will update with new email addresses when the filter is applied.
Figure 5. Previewing the effect of the filter contained in an email address policy
The ability of Exchange to send messages was originally based on X.400, but it now has a firm preference for SMTP, and this preference is reflected in the fact that the primary and sometimes only email address assigned to mail-enabled objects is an SMTP address. However, over its lifetime, Exchange has supported many types of email addresses to permit interoperability with foreign email systems such as Novell GroupWise.
Each email address format is defined to Exchange in its configuration data. The entry for an address format stores details of the dynamic link library (DLL) that Exchange calls to create addresses in the format. Out of the box, Exchange 2013 provides DLLs for SMTP, Lotus Notes, and X.400 format addresses. Figure 6 shows details of the Notes address format as viewed through ADSIEdit. The DLL Exchange calls to generate email addresses of this type is ntspxgen.dll (highlighted), which must be available to Exchange in the \v15\mailbox\address\ directory.
Figure 6. Viewing the details of the Notes email address format
Software vendors that provide solutions that integrate with Exchange and require a specific email address format must include their own custom DLL to enable Exchange to incorporate email addresses of the format into email address policies and generate the appropriate proxy addresses for the objects that fall under the scope of the policies. Sometimes this detail is omitted, and you’re then forced to consider how to create and maintain the required addresses without using email address policies.
One approach that has been successfully used is to generate and apply the set of required proxy addresses to objects though EMS scripts. This approach works but, because it is manual, not integrated into the Exchange management framework, and prone to error, it is an approach that should be used only when it is impossible to manage proxy addresses through email address policies for some reason.
