Understanding E-Mail Address Policies

[Alex]

---

E-Mail Address Policies
Recipients (which include users, resources, contacts, and groups) are any mail-enabled object in Active Directory to which Exchange can deliver or route messages. For a recipient to send or receive e-mail messages, the recipient must have an e-mail address. E-mail address policies generate the primary and secondary e-mail addresses for your recipients so they can receive and send e-mail.

Behaviors of Recipient Policies
The recipient policy functionality is divided into two features: e-mail address policies and accepted domains.
In this topic we discuss - mail address policies
For accepted domains - messagingtechs.proboards.com/index.cgi?board=exchange2010&action=display&thread=7

When you run the Update-EmailAddressPolicy cmdlet in the Exchange Management Shell, the recipient object is updated with the e-mail address policy

This example applies the e-mail address policy named EMAIL_ADDRESS_POLICY01 to all affected recipients.

Update-EmailAddressPolicy -Identity EMAIL_ADDRESS_POLICY01

When creating an e-mail address policy, you can use the following e-mail address types:

Precanned SMTP e-mail address. Precanned SMTP e-mail addresses are commonly used e-mail address types provided for you.

Custom SMTP e-mail address. If you don't want to use one of the precanned SMTP e-mail addresses, you can specify a custom SMTP e-mail address.
When creating a custom SMTP e-mail address, you can use the variables in the following table to specify alternate values for the local part of the e-mail address.

Custom SMTP e-mail address

Variable Value %g Given name (first name) %i Middle initial %s Surname (last name) %d Display name %m Exchange alias %xs Uses the first x letters of the surname. For example, if x = 2, the first two letters of the surname are used. %xg Uses the first x letters of the given name. For example, if x = 2, the first two letters of the given name are used.

Non-SMTP e-mail address.

The following types of non-SMTP e-mail addresses are supported:

EX (Legacy DN Proxy Address Prefix DisplayName)

X.500

X.400

MSMail

CcMail

Lotus Notes

Novell GroupWise

Exchange Unified Messaging proxy address (EUM proxy address)

---

Important:
In Exchange, all non-SMTP e-mail addresses are considered custom addresses. Exchange doesn't provide unique dialog boxes or property pages for X.400, GroupWise, or Lotus Notes e-mail address types. If you add a non-SMTP custom e-mail address, you must have the appropriate dynamic-link library (DLL) files. If you don't provide the appropriate DLL files, you won't be able to create a customized e-mail address policy. The following error will be logged in Event Viewer: "The e-mail address description object in the Microsoft Exchange directory for the 'SADF' address type on 'i386' machines are missing."

---

Use the Shell to create an e-mail address policy by using recipient filters



Note:
You can't use the EMC to create an e-mail address policy by using recipient filters.

To create an e-mail address policy by using recipient filters, use the following syntax.

New-EmailAddressPolicy -Name <String> -RecipientFilter <String>

This example creates an e-mail address policy that applies to all executives and for which the local part of the e-mail address consists of the first two letters of their first name and their entire last name.

New-EmailAddressPolicy -Name 'Execs' -EnabledEmailAddressTemplates 'SMTP:[e-mail]' -RecipientFilter {((RecipientType -eq 'UserMailbox') -and (Title -like 'executive'))}

[Alex]

Managing E-Mail Address Policies in Exchange Server 2010


E-mail address policies which were known as Recipient Policies back in Exchange 2000 and 2003, define the proxy addresses that are stamped onto recipient objects in the Exchange 2010/2007 organization

E-mail address policies are added on an organization level meaning they apply to the whole Exchange 2010/2007 organization. With Exchange 2010/2007, the recipient policies have been split in two: Accepted Domains and E-mail Address Policies

In Exchange 2000/2003 recipient policies also controlled which SMTP namespaces were accepted by the Exchange organization.
three primary reasons why the Exchange Product group made the split. First, if a domain was specified for an e-mail address recipient policy, but wasn’t configured as the authoritative domain, the e-mail sent to the recipients with e-mail addresses defined by the policy would not be routed within the Exchange organization for this domain. Even though this is an invalid scenario, the Exchange 2000 and 2003 System Manager allowed this type of configuration. Secondly, the authoritative domain concept was hidden under the e-mail address recipient policy GUI, which wasn’t very intuitive for administrators. Lastly, relay domains were controlled via the SMTP connector's GUI, allocated in a completely different location from where the authoritative domains (Recipient Policies) were controlled.

Recipient Update Service (RUS) which was present in Exchange 2000/2003, is also no longer part of the Exchange 2010/2007 product. RUS was responsible for stamping E-mail addresses on AD objects, in addition to address list membership, along with a few other things, it didn’t always work as expected and was very difficult to troubleshoot when it acted up. In Exchange 2010/2007, the RUS (and thereby the asynchronous behavior used to provision objects) has been replaced by a new synchronous process (EmailAddressPolicy cmdlet), used to stamp E-mail addresses onto objects immediately! You no longer have to wait for several minutes to see email addresses on your objects as was often the case with the antiquated RUS.

Accepted Domains
Before you can begin creating a new E-mail Address Policy, you must first add the respective domain name under the Accepted Domains tab. Under the Accepted Domains tab, we specify the SMTP domains for which our Exchange 2010/2007 organization should either be authoritative, relay to an e-mail server in another Active directory Forest within the organization, or relay to an e-mail server outside the respective Exchange organization.

The difference between internal and external relayed domains is that :
Internal relaying simply sends the e-mail messages directly to the e-mail server in the organization.
Messages sent to an external relayed domain will first be delivered to the Edge Transport server in the perimeter network, and from there be routed to the respective external e-mail server on the Internet.

When the first Hub Transport server is deployed in the Exchange 2010/2007 organization, the domain name of the Active Directory Forest root domain is configured as an authoritative domain by default.
Since the Hub Transport server used as an example here has been installed into an Active Directory Forest named messagingtechs.com, this domain name is the authoritative domain for this Exchange 2010 organization by default. Since we use a split-DNS setup, where the internal and external domain names match, we don’t need to do any configuration changes after the Hub Transport server has been deployed.
Many organizations use an internal domain name that differs from the external domain name, which among other things are used for inbound mail. For example, it’s common to use a domain.local domain internally. If this is the case in your organization, you must manually create an accepted domain matching your external domain name.

---

Creating a new Accepted Domain





Or using shell

New-AcceptedDomain –Name “Global-MessagingTechs” –DomainName “global-messagingtechs.com ” –DomainType “Authoritative”

As you can see in above image, we have several E-mail Address Policies in our Exchange 2010 organization, listed in prioritized order (the lower the number, the higher the priority)
You must have at least two EAPs aside from the default in order to see the Change Priority Action pane option

---

Creating a new E-mail Address Policy



You can now be a bit more selective when defining your target group by using the filter and selecting one or more conditions. When you have configured any conditions you want applied to the policy, click Next

also check the condition. e.g. target users will be matching with company name






Now click Add and select the E-mail address local part to be used to create the username portion of the e-mail address, then choose an e-mail domain from the E-mail address domain in the drop-down box, When ready click OK and Next.











Shell command :

New-EmailAddressPolicy -Name “global-messagingtechs.com” -IncludedRecipients “MailboxUsers” -ConditionalCompany “Global Techs” -Priority “Lowest” -EnabledEmailAddressTemplates “SMTP:[e-mail]”

update-EmailAddressPolicy -Identity 'global-messagingtechs.com'

When a recipient has “Automatically update e-mail addresses based on email address policy” enabled, all primary e-mail addresses (default reply addresses) of e-mail address types will always be set from the e-mail address policy. This means that if you edit the primary address to be a different e-mail address, it will always revert back to the one specified in the e-mail address policy.

old method LDAP new OPATH
Instead of LDAP which was the recipient filter used in Exchange 2000 and 2003, Exchange now uses OPATH for filtering recipients, address lists etc. The syntax used in OPATH is much less complex that LDAP filters, which means that it’s easier to create filters in Exchange 2007 than was the case in previous versions of Exchange Server.

Managing SMTP Proxy addresses manually

In some scenarios you might want to have the SMTP proxy addresses managed via a separate provisioning tool used in the IT service desk. If this is the case, you might need to disable the Automatically update e-mail addresses based on email address policy option found on the E-Mail Addresses tab on the property page of an Exchange 2010 user mailbox
If your organization consists of several thousand user mailboxes, you do of course not want to do this via the Exchange Management Console (EMC), since the EMC doesn’t allow you to make this type of change on user mailboxes in bulk. you could use the following command:

Get-Mailbox | Set-Mailbox -EmailAddressPolicyEnabled $False

If you instead prefer to do this per mailbox server, you would use:

Get-Mailbox –Server “Mailbox Server” | Set-Mailbox -EmailAddressPolicyEnabled $False

Or perhaps you want to do so for users in a specific OU:

Get-Mailbox –OrganizationalUnit “Name of OU” | Set-Mailbox -EmailAddressPolicyEnabled $False