E2K7: Creating Custom SMTP E-mail Address Policies Utilizing Various Replacement String Combinations

Thursday, April 30, 2009 2:56 PM by Eric Norberg

 I have recently received a number of questions surrounding the generation of e-mail addresses in Exchange 2007. Particularly, whether or not custom email addresses can be generated via “legacy” replacement strings to meet specific organizational naming conventions.This post will present a brief overview of the process as well as offer numerous examples which should assist you when tasked with creating your own custom proxy address templates in Exchange 2007.

Legacy Behavior:

In previous versions of Exchange, administrators would commonly use variables and replacement strings within SMTP Recipient Policies to generate specific email addresses for their mail enabled users. Specifically they would use these strings and variables to generate the local part of a user’s SMTP address. Once the Recipient Policies were created and applied, the Recipient Update Service would “stamp” the proper email addresses on the objects based upon an LDAP Recipient Filter.

The most common variables and replacement strings are documented in MSKB 822447 (http://support.microsoft.com/kb/822447).

Exchange System Manager (ESM) itself did not provide a GUI to assist with the creation of the various combinations which could potentially be generated. As such, the Administrator(s) had to have detailed knowledge of the replacement strings as well as their possible uses in order to successfully generate the SMTP addresses for mail enabled objects. Once the replacement strings were added to the policy, the Recipient Update Service was then responsible for “stamping” the objects with the custom addresses based upon an LDAP filtering syntax (stored on the purportedSearch attribute of the Recipient Policy).

Exchange 2007 Behavior:

Today, Exchange 2007 offers a Graphical Interface within the Exchange Management Console (EMC) to help an administrator generate email addresses based upon the most common variable combinations. To create an E-Mail Address Policy via the EMC an Administrator performs the following:

?         Opens the EMC.

?         Navigates to the Organization Configuration, Hub Transport Node.

?         Switches to the E-Mail Address Policy Tab.

?         Provides a Name for the Policy and selects what type of Recipient Objects the policy will be responsible for as well as the conditions for how the policy will be applied.

?         Once these basic pieces of information have been provided, the Administrator eventually arrives at the E-Mail Addresses option page.

On this page, an Administrator needs to define how the local part of the address will appear. As noted above, there are a number of pre-canned options to use for the alias. These options are provided in the following screen shot:

What should immediately stand out as a primary difference with that of legacy Exchange Recipient Policies is that there is no way to actually edit the alias generation portion of the address in the GUI. In short you can only select one of the pre-canned options and lack the ability to further modify the local part of the address.

In the example above, I have elected to generate based upon first initial of First Name (Given Name) and the full Last Name or Surname (e.g. for a user named “Test User” the user portion of the address would be “tuser”). Once I specify the FQDN for the address (or select a valid Accepted Domain) and select OK, the replacement variables become visible on the E-Mail Addresses portion of the policy (although I can’t further edit them, if you select “Edit” you will simply be returned to the pre-canned options page):

This presents a problem if as an Administrator I had been tasked with generating the user portion of the addresses in the form of:

?         First 3 letters of the First Name (e.g. the Given Name)

?         .

?         Full Last Name (e.g. the Surname)@en164420.lab.

In this instance, I would want a replacement string in the form of:

    %3g.%s.@en164420.lab

This string once successfully applied would render a mail enabled object named Test User with an SMTP address in the form of: Tes.User@en164420.lab (which would accomplish precisely what I had been tasked with).

However as evident from above, there is no pre-canned option for the generation of this type of address nor do I have any ability to directly modify it within the Exchange Management Console (e.g. via a Custom Address, etc.).

To accomplish the goal I essentially have 2 options:

?         Keep an Exchange 2003 Server around so that custom Recipient Policies can be created, modified and applied by the Recipient Update Service (not a very attractive option).

?         Build or modify my policies via the Exchange Management Shell.

Using SMTP Replacement Strings in Exchange Management Shell:

The Exchange Management Shell can be utilized to define more sophisticated address templates. Once created the syntax is fully visible in the Management Console (it’s just not editable).

Administrators new to Exchange 2007 also need to understand that E-mail Address Policies natively created in Exchange 2007 (or legacy polices that have had their filter syntax upgraded) utilize the new OPATH filtering syntax as opposed to LDAP. Although there is a bit of a learning curve the primary benefit is that the filters themselves are far easier to create and interpret than those created with LDAP. Legacy Recipient Filters that were created in previous versions of Exchange still function it is just not possible to edit those policies from within the EMC until they have been upgraded to OPATH.

To create a new E-mail Address Policy the New-EmailAddressPolicy cmdlet is utilized within the shell: http://technet.microsoft.com/en-us/library/aa996800.aspx

To modify an existing E-mail Address Policy the Set-EmailAddressPolicy is utilized within the shell: http://technet.microsoft.com/en-us/library/bb124517.aspx

In my previous example, I wanted to generate the user portion of the SMTP utilizing the following naming convention :

First 3 Letters of First name.Full Last Name@domain.com (the name of my lab domain is en164420.lab)

Example: Tes.User@en164420.lab

To create a new policy with this alias convention involves the following steps:

1.       Deciding on a Name for the new E-mail Address Policy.

2.       Deciding on the Recipient Types I want the policy to apply to (e.g. Users with Exchange Mailboxes, Resource Mailboxes, etc.).

3.       Filtering Syntax (e.g. who do I want the policy to apply to)?

4.       The format of the alias (e.g. what SMTP Replacement Strings to utilize).

5.       Whether the address will apply to an Accepted Domain or an FQDN.

6.       Actually creating the E-mail Addressing Policy via Exchange Management Shell.

For the purpose of this example, I’m going to create a new policy named “Test” that applies to all Recipient Types via an OPATH filter utilizing the %g and %s replacement variables.

?         Open Exchange Management Shell.

?         Issue following command:

New-EmailAddressPolicy -Name “Test” –IncludeRecipients AllRecipients –EnabledPrimarySMTPAddressTemplate “SMTP: %3g.%s.@en164420.lab”

?         ENTER

Note: In this specific example, I used the “-IncludeRecipients” parameter as opposed to creating a conditional filter via the –RecipientFilter parameter. The –RecipientFilter parameter is very useful for creating Policies that filter on specific properties such as Company, Country Code, a Custom Attribute, a Database, Department, etc). I will provide some examples at the end of the post using conditional clauses with the –RecipientFilter parameter.

If your command completed successfully, you can now verify it by running Get-EmailAddressPolicy “Test” in Shell or going into the EMC and verifying that exists within the Organizational Configuration Node for Hub Transport.

Shell:

Exchange Management Console:

The actual replacement string is now available in both the EMC and EMS:

Exchange Management Console:

Exchange Management Shell:

Now to actually test that the policy applies an SMTP address in the proper format we are going to create a user called Test User and then Mailbox-Enable the object.

In Active Directory Users and Computers (ADUC), I created a user account with a First Name of “Test” and a last name of “User” (the user object itself has no mailbox):

I then Mailbox Enable “Test User”:

Enable-Mailbox –Identity “Test User” -Alias “tuser” -Database “MyServerFirst Storage GroupMailbox Database”

Next verify that the user portion of the address is accurate:

Exchange Management Console:

Exchange Management Shell:

Conclusion:

SMTP Replacement Strings can be utilized in Exchange 2007 just as in previous versions of Exchange. However, there is no editable GUI interface for them in Exchange 2007. Thus, to successfully generate aliases based upon replacement strings an administrator needs to utilize the Exchange Management Shell.

Additional Examples:

Example 1:

This example will create an email-address policy where the user portion of the SMTP address is in the form of FirstName.LastName(e.g. Eric.Norberg) where the domain is en164420.lab. It will also only apply the address to users who are on an Exchange server named “Executives” that have a title of “Executive”:

New-EmailAddressPolicy -Name “Executives” -RecipientFilter { ServerName -eq “Executives” -and Title -eq “Executive” } -EnabledPrimarySMTPAddressTemplate “SMTP:%g.%s.@en164420.lab”

Example 2:

This example will create an E-mail Address policy where the user portion of the SMTP Address is in the form of first 3 letters of First Name.Last Name (e.g. eri.norberg@en164420).   It will also force that all characters in the user portion of the address be in lower case (Example:  If you had a user named “John Doe”, the address would not be Joh.Doe but joh.doe@en16442.lab).  The policy would also only apply to objects that had an associated mailbox and had the Company value set to “Microsoft”:

New-EmailAddressPolicy -Name “Global” -EnabledEmailAddressTemplate `SMTP: %rAa%rBb%rCc%rDd%rEe%rFf%rGg%rHh%rIi%rJj%rKk%rLl%rMm%rNn%rOo%rPp%rQq%rRr%rSs%rTt%rUu%rVv%rWw%rXx%rYy%rZz%3g.%s.@en164420.lab’ -RecipientFilter {((RecipientType -eq ‘UserMailbox’) -and (Company -eq ‘Microsoft’))}

Example 3

This example modifies the SMTP Template on a policy named “Test”.  It simply adjusts the SMTP user portion of the address template to display name by utilizing the %d replacment string:

Set-EmailAddressPolicy -Name “Test” -EnabledPrimarySMTPTemplate ‘SMTP: %d.@en164420.lab’

Example 4:

This example creates a new policy titled “Redmond Users”.  The policy applies to user objects with mailboxes that exist in the state of Washington “WA” who additionally have the otherTelephone attribute set to an area code beginning with 425.  The user portion of the address is simply being stamped as alias.

New-EmailAddressPolicy -Name “Redmond Users” -EnabledPrimarySMTPAddressTemplate ‘SMTP: @en164420.lab’ -RecipientFilter { RecipientType -eq ‘UserMailbox’ -and StateorProvince -eq “WA” -and OtherTelephone -like ‘425*’ }

Additional Reading:

• Understanding E-Mail Address Policies:  http://technet.microsoft.com/en-us/library/bb232171.aspx
• New-Email Address Policy Wizard / Custom Address:  http://technet.microsoft.com/en-us/library/aa996030.aspx
• Managing E-Mail Address Policies: http://technet.microsoft.com/en-us/library/aa998940.aspx
• Filterable Properties for the -RecipientFilter Parameter:  http://technet.microsoft.com/en-us/library/bb430771.aspx 
•  New-EmailAddressPolicy: http://technet.microsoft.com/en-us/library/aa996800.aspx
• Set-EmailAddressPolicy: http://technet.microsoft.com/en-us/library/bb124517.aspx
• Update-EmailAddressPolicy: http://technet.microsoft.com/en-us/library/aa996869.aspx
• Upgrading Custom LDAP Filters to OPATH:  http://technet.microsoft.com/en-us/library/cc164375.aspx