Defining E-Mail Addresses

Before we get in to the discussion of how to create mail-enabled users, groups, or contacts, we'll first discuss how these objects get their e-mail addresses. Those of you who are familiar with Exchange 2000/2003 probably remember that e-mail addresses were defined by a recipient policy. Once the recipient policy was defined, the Microsoft Exchange System Attendant's Recipient Update Service (RUS) would establish e-mail addresses for any mail-enabled recipient at some point in the future (hopefully just a minute or two).

This process is just a bit different in Exchange 2007. E-mail addresses are generated for the object at the time the mail-enabled recipient is created and they are generated by an Exchange Management Shell (EMC) task or the Exchange Management Console (EMC). Recipient policies from Exchange 2000/2003 have been broken up in to two separate concepts: the e-mail domains that your organization will accept mail for and the e-mail address policies for your users. For addresses that will be assigned to mailboxes on your Exchange 2007 servers, you define both an accepted domain and an e-mail address policy.

Accepted Domains

An accepted domain is an SMTP domain name (aka SMTP name space) that your Exchange 2007 servers will accept mail for and either deliver to Exchange 2007 mailboxes or relay on to internal or external SMTP mail servers. If you are in the middle of a migration from Exchange 2000/2003, then the accepted domains list will include the SMTP domains for your Exchange 2000/2003 mailboxes. Accepted domains must be defined for all e-mail addresses that will be routed into or by your Exchange 2007 servers.

Note 

Most small and medium-sized organizations will have only a single accepted domain.

Accepted domains are found within the Organization Configuration work center under the Hub Transport subcontainer. When you choose the Accepted Domains tab in the results pane, you will see a list of the accepted domains that have been defined for your organization, such as those shown in Figure 10.1.

Figure 10.1: List of accepted domains

When Exchange 2007 is first installed, a single accepted domain is automatically created and given a name. This is the name of the Active Directory forest root domain; for many organizations this will not be correct since the naming convention for Active Directory names and SMTP domain names are different.

Accepted domains are simple to create and require little input. To create a new accepted domain using the EMC, double-click the New Accepted Domain task in the Actions menu to see the New Accepted Domain wizard (shown in Figure 10.2). You only need to provide a descriptive name for the accepted domain, the SMTP domain name, and how the message should be treated when it is accepted by Exchange 2007.

Figure 10.2: Creating a new accepted domain

You can also manage accepted domains using the following EMS cmdlets: New-AcceptedDomain, Set-AcceptedDomain, Get-AcceptedDomain, and Remove-AcceptedDomain.

The only tricky thing about defining an accepted domain is that you must define how Exchange is to treat a message for it. There three types of domains you can choose when creating an accepted domain:

• Authoritative domains are SMTP domains for which you accept the inbound message and deliver it to an internal mailbox within your Exchange organization.

• Internal relay domains are SMTP domains for which your Exchange server will accept inbound SMTP mail. The Exchange server must have mail-enabled contacts that specify forwarding addresses for users in those domains. The Exchange server then relays the message onward to another internal mail system. Internal relay domains are used when two Exchange organizations are doing global address list synchronization.

• External relay domains are SMTP domains for which your Exchange organization will accept inbound SMTP mail but then relays that mail onward to an external SMTP mail server that is usually outside of the organization's boundaries. If Edge Transport servers are used, the Edge Transport server handles external relay domains.

E-mail Address Policies

Exchange e-mail address policies are the configuration objects that are used by Exchange management tasks when new mail objects are created. Each policy's conditions are examined to see if the policy's conditions apply to the object that is being created; if the policy's conditions apply, then the new mail-enabled object's e-mail address policies are generated based on the e-mail address generation rules.

Using the EMC, e-mail address policies are found in the Organization Configuration work center under the Hub Transport subcontainer. Once you have highlighted the Hub Transport subcontainer, select the E-mail Address Policies tab to see a list of the e-mail address policies in the organization. In Figure 10.3, we have only two e-mail address policies.

Figure 10.3: The e-mail address policies for an Exchange 2007 organization

By default, a newly created Exchange 2007 organization has only a single e-mail address policy called the default policy. The default policy is the lowest-priority policy and applies if no other policies above it apply. This is just like having multiple recipient policies in Exchange 2007.

Changing an Existing Policy

The e-mail address generation rule uses the object's Exchange alias and the domain name of the Active Directory forest root. Suppose we want to change the default SMTP domain name that is on the default policy to something else. A good example of when this is relevant is when the default domain name for the Active Directory forest root is different than the public domain name used for SMTP and you need to fix this. Further, we want all e-mail addresses to be generated using the first name, followed by a period, then the last name, and then the domain name.

First, you need to define an accepted domain; if the default accepted domain is not correct for your organization, then you need to create a new accepted domain because Exchange 2007 does not allow you to change the accepted domain. Let's say that you Active Directory forest root is called fourthcoffee.com but your public SMTP domain is volcanocoffee.com. First, under the Accepted Domains tab of the Organization Configuration work center's Hub Transport subcontainer, create a new authoritative accepted domain for volcanocoffee.com.

Next you need to change the default e-mail address policy so that it uses the new domain name and generates an address using the firstname.lastname format, such as [e-mail]. Locate the Default Policy in the Organization Configuration work center (found under the Hub Transport subcontainer by clicking the E-mail Address Policies tab), highlight the default policy, and click the Edit task in the Actions pane. Click Next until you reach the E-mail Addresses page (shown in Figure 10.4).

Figure 10.4: E-mail addresses properties of an e-mail address policy

Notice in Figure 10.4, the only e-mail address that is generated is @fourthcoffee.com. Highlight @fourthcoffee.com and click the Edit button to see the SMTP E-mail Address dialog box (shown in Figure 10.5). Notice by default that the E-Mail Address Local Part check box is not checked. This means that the object's Exchange alias will be used when creating the SMTP address. You want to change that, so enable the E-Mail Address Local Part check box; once it's enabled, you will be able to select the First name.last name (john.smith) radio button.

Figure 10.5: Changing how the SMTP address is generated

Next, change the e-mail address domain found in the drop-down list at the bottom of the page. Once you have clicked OK in the SMTP E-mail Address dialog box, the e-mail address generation rules will have changed.

You have now modified the Default Policy and you need to click Next on the E-Mail Addresses page to finish the modification. Next you will see the Schedule (see Figure 10.6) page of the wizard. This might be a bit confusing at first since on the surface it doesn't seem like there is anything to schedule. However, remember that in Exchange 2000/2003, the Exchange Recipient Update Service (RUS) took care of adding SMTP addresses to mail-enabled objects. There is no such equivalence for Exchange 2007 mail-enabled recipients. Thus, some process or task has to be kicked off that will do this. If you choose Immediately, this will kick off the Update-EmailAddressPolicy cmdlet with the -Identity:'Default Policy' option and immediately update any e-mail addresses.

Figure 10.6: Scheduling an update to the e-mail address policy

If you don't choose Immediately, you have additional options:

• Do Not Apply skips the Update-EmailAddressPolicy cmdlet phase altogether. If you have just updated the default policy, you can always run the Update-EmailAddressPolicy "Default Policy" commandfrom the EMS at a later point.

• At the Following Time allows you to schedule the Update-EmailAddressPolicy cmdlet to run later. This is useful if you know that it will have to update thousands of mail-enabled objects in your Active Directory and you don't want it affecting usage during the business day. This option, when selected, allows you to specify that the task be canceled if it is still running after a certain number of hours.

One thing that we do want to point out is what happens to existing e-mail addresses once you change to a new default address. Figure 10.7 shows the E-mail Addresses property page for the mailbox of a user whose address was updated; notice that this user has two e-mail addresses now. He has the old e-mail address [e-mail] and his newly created SMTP address [e-mail]. The process of updating e-mail addresses never removes existing addresses; it creates the new address and makes it the Reply To address.

Figure 10.7: Newly created SMTP address for existing user

While our example was done entirely in the graphical user interface, you could use the EMS to perform the same steps. The EMS cmdlets you would need to use to create, delete, modify, and update e-mail address policies are shown in Table 10.1.

Table 10.1: EMS Cmdlets Used to Manipulate E-mail Address Policies
Open table as spreadsheet

EMS cmdlet	Description
New-EmailAddressPolicy	Creates a new e-mail address policy
Set-EmailAddressPolicy	Changes properties of the e-mail address policy specified
Update-EmailAddressPolicy	Updates mail-enabled objects in the Active Directory if the conditions of the policy specified apply to those objects
Get-EmailAddressPolicy	Retrieves a list of e-mail address policies and their properties
Remove-EmailAddressPolicy	Deletes the specified e-mail address policy

Finally, of course, if you want to see the e-mail addresses that have been applied to a mail-enabled object, you can also use an EMS cmdlet to retrieve that information. You would use Get-Mailbox, Get-MailContact, or Get-DistributionGroup. To retrieve the e-mail addresses for a mailbox whose alias is Julie.Samante, you could type the following command and see output similar to this:

 Get-Mailbox "julie.samante" | FL DisplayName,EmailAddresses DisplayName    : Julie Samante EmailAddresses : {smtp:[e-mail], SMTP:[e-mail], X400:c=US;a= ;p=Volcano Surfboar;o=Exchange;s=Samante;g=Julie;} 

Creating a New E-mail Address Policy

If you have a small or medium-sized organization, you probably support only a single SMTP domain for your users. However, even companies with a handful of mailboxes can sometimes require two or three SMTP domain names. Let's take as an example an organization that has two divisions, each of which requires its own unique SMTP addresses.

Previously, you changed the default policy for an organization so that all users would get an SMTP address of @volcanocoffee.com. However, we will now extend that example a bit further. Let's say that this organization has another division called Volcano Surfboards and their SMTP domain is @volcanosurfboards.com. Anyone whose company attribute contains "Volcano Surfboards" in Active Directory should have an SMTP address of [e-mail]. The first thing you need to do is define this as an accepted domain, and the volcanosurfboards.com accepted domain must be authoritative. If you don't define the accepted domain, you cannot define the e-mail address policy. Next, you want to create the e-mail address policy. In the EMC, select the Hub Transport subcontainer of the Organization Configuration work center, and then select the E-mail Address Policies tab in the results pane.

To create a new e-mail address policy, click the New E-mail Address Policy task in the Actions pane. On the first page (see Figure 10.8) of the New E-mail Address Policy Wizard, you will be prompted for the name of the policy and what type of objects this policy applies to.

Figure 10.8: Naming the e-mail address policy and defining the objects to which it applies

In this example, the policy is being created for the Volcano Surfboards company users and we want the policy to apply only to mailboxes, so you will provide that information on the screen shown in Figure 10.8. When you have provided this information, click Next to move on through the wizard.

The next screen is where you define the conditions under which this policy will be applied. There are two steps to the Conditions page. First, you need to narrow the scope to a specific condition, such as the State or Province attribute, Department attribute, or Company name attribute of the object. Second, you need to provide values for the attributes you have selected.

In our example, we want this policy to apply to anyone whose company name attribute contains Volcano Surfboards. Figure 10.9 shows the Conditions page after we filled in the necessary information.

Figure 10.9: Defining conditions for an e-mail address policy

Once you select the condition Recipient Is in a Company, that option shows up in the Step 2 portion of the dialog as Users with Exchange mailboxes in the specified Company(s). The word specified appears very much like a hyperlink; it is blue and underlined. If you click on that link, the dialog box appears that allows you to edit or specify one or more company names.

When you have entered the necessary company information (in this case, just a single company called Volcano Surfboards), you can click OK to close the Specify Company dialog box. You can verify that the conditions are defined correctly by clicking the Preview button on the Conditions page of the wizard. The Preview button displays the E-mail Address Policy Preview dialog box; you should see users with mailboxes and whose company name is Volcano Surfboards. This dialog box is shown in Figure 10.10.

Figure 10.10: The E-mail Address Policy Preview dialog box helps to confirm that the policy conditions are correct.

The Preview button is also helpful in confirming that attributes are being entered correctly in Active Directory. The administrator may not recognize if everyone in a 10,000-user company exists in the Preview window, but hopefully it will give them an idea that the information is being entered correctly. In this case, if a user's company name does not contain exactly Volcano Surfboards, then the policy conditions will not be met and the user's mailbox will have the e-mail addresses from the default policy.

The next step is to define the STMP address or addresses that will be generated when the conditions of this policy apply. The default action for the Add button is to create a new SMTP address, but if you need to create a custom address, click the drop-down arrow to the left of the Add button to see a list that provides the option to create a Custom Address type.

On the E-mail Addresses page, you need to click the Add button to create a new SMTP address. You will then see the SMTP E-mail Address dialog box; select the domain (in this example, volcanosurfboards.com) from the E-mail Address Domain drop-down list and click the First name.last name (john.smith) radio button option.

If you have not yet created an accepted domain for volcanosurfboards.com, it will not show up in the drop-down list.

The next page of the New E-mail Address Policy wizard is the Schedule page; if you want the addresses to appear immediately, you must click the Immediately radio button and click Next. If there are many thousands of addresses to be created, you may want to schedule the task to run during off-hours. Once you click Next on the Schedule page, you will see the summary page. Here you can see the tasks that will be performed once you click the New button.

The final phase of e-mail address policy creation is the Completion page. While there are no actual operations or input required here (other than clicking the Finish button), this page is useful because it provides you with the cmdlets and commands that were used to perform this particular task. In the case of creating a new e-mail address policy, the task used two cmdlets (New-EmailAddressPolicy and Update-EmailAddressPolicy). The Completion page is shown in Figure 10.11.

Figure 10.11: Completion page of the New E-mail Address Policy Wizard