Exchange Server hosted in an application service provider (ASP) environment is similar to a corporate Exchange deployment. Smart IT departments can think of themselves as ASPs, with their own organization as their customer. This article is the second in a series about the Exchange 2000 Server lessons you can learn from ASPs.
In "Exchange 2000 Hosting: The ASP Model, Part 1," November 2001, I described the front-end/back-end architecture that ASPs use for Exchange and told you that ASPs typically establish one Active Directory (AD) forest with a separate organizational unit (OU) for each company they host. Likewise, you might set up one AD forest, with a separate OU for each of your corporate divisions. I also showed you how to define a user principal name (UPN) suffix for a division—Division A—and associate it with the logon names of the users in that division. (For an explanation of how to create a UPN suffix as an OU property, see the sidebar "Creating a UPN Suffix as an OU Property," page 12.)
The DivisionA.com UPN suffix that I created will come in handy this month, when I describe how to set up userX @DivisionA.com as a valid email address in Exchange. First, I must set the address as a property of each user, which I accomplish through recipient policies. Second, I must configure the Exchange system to accept messages for [email protected] addresses. To complete the configuration process, I secure the address list so that users see only the other users that I want them to see.
Recipient Policies
You can use an Exchange recipient policy to generate email addresses for a selected group of users—for example, to give all the users in Division A an email address with the format [email protected]. Open Exchange System Manager (ESM), expand the Recipients node, and select Recipient Policies. At this point, you might have only a Default Policy, which stamps all users with the email address for your Exchange organization (e.g., userX @Company.com). Right-click the right pane or Recipient Policies and select New, Recipient Policy. If you have Exchange 2000 Service Pack 1 (SP1), you'll see a box asking you to select the property pages that you want to include (this box includes Mailbox Manager as an option for the policy). Select the E-Mail Addresses box and click OK. Next, you'll see the Recipient Policy Properties dialog box. Give the recipient policy a name, such as All Users of Division A, and click the E-Mail Addresses (Policy) tab, which shows the generation rules for the email addresses. If you don't want users to have the first SMTP address listed for your organization, select it and click Edit. Otherwise, click New to add another STMP address. Enter the SMTP address at the SMTP Address Properties' General tab, which Figure 1 shows, and click OK.
Now go to the Recipient Policy Properties' General tab and click Modify. This step is a little tricky. You need to build a Lightweight Directory Access Protocol (LDAP) query of AD that will select the users to stamp with this new address. Ideally, you would use the OU to identify the users; unfortunately, you can't create a recipient policy based on an OU. Instead, you can use the UPN suffix I established last month for the query. If you don't want to use UPN suffixes to establish separate OU identities, you can create a group for All Users in the OU and query based on that group membership. I'll show you how to do both.
Query based on the UPN suffix. Using the UPN suffix to build the recipient policy is a bit easier, so I'll cover it first. After you click Modify, click the Advanced tab and you'll see a Find Exchange Recipients dialog box similar to the one that Figure 2 shows, except that the fields in your dialog box will be blank. Click Field and select User from the drop-down list. When you select User, a long list of names will no doubt fill your screen. Use the triangle at the bottom of that screen to scroll to Logon Name and select it by pressing the letter L (or use the keyboard to select Logon Name). You want to search for the UPN suffix, so select Ends With from the Condition field's drop-down list and type DivisionA.com in the Value field. Click Add, then click Find Now to verify that the query finds the matching users. (If the query doesn't find any users, you've mistyped the UPN suffix or the UPN suffix doesn't have any assigned users.) Click OK. When you do so, you'll see a message stating that changing the LDAP query for an existing policy doesn't automatically update the recipient policy for existing users. In other words, if users have email addresses based on a previous query and you've changed the query, you must right-click Recipient Policy and select the Apply this policy now option to update the existing addresses. However, in this example, because you're creating a new policy, you haven't changed an existing query. Note that in Figure 2, the user Yetta Nother doesn't have an email address. Unlike the other users, Yetta is a new user who hasn't been stamped with the Default Recipient Policy yet. When I apply the new Division A policy, each of these users will receive the [email protected] address.
Query based on an OU group. Associating a UPN suffix with users in an OU gives you an easy way to create a query within a recipient policy and stamp the users with a unique SMTP address. However, if you don't want to use a UPN suffix, you can create a group and place all the users in an OU into the group. Creating a group and adding the initial set of users is fairly easy in AD, but then you must maintain the group, adding and removing users in the group when you add and remove them in the OU. The advantage of this approach is that you can give users an SMTP address based on group membership alone, even if you don't use UPN suffixes.
Here's the difficult part: To associate a recipient policy with a group, you must base your LDAP query on the group's LDAP distinguished name (DN), not on the display name that you're used to working with. You can use the ADSI Edit utility to obtain this information. ADSI Edit is as powerful as a registry editor, so be careful—don't experiment with it. Launch ADSI Edit from the Windows 2000 Support Tools folder and expand the domain naming context (domain NC). Expand the domain controller (DC) for your domain name, and locate the OU that contains the group that you want to use for the recipient policy. Right-click the group and click Properties to go to the Attributes tab, which Figure 3 shows. You can select the DN, which is labeled Path, and press Ctrl+C to copy the name to the clipboard. Click Cancel (because you didn't make any changes to the attributes).
Follow the earlier instructions to open the Find Exchange Recipients dialog box. Select the User, Group Membership field. Select the Is (exactly) condition, and paste the DN you put on the clipboard in the Value field. Figure 4 shows the dialog box after you've performed these steps. Note in Figure 4 that the Recipient Update Service has changed the users' email addresses to reflect the recipient policy that I created earlier (based on the UPN suffix). Click Find Now to ensure that you've properly built the query before closing the dialog boxes and relying on the recipient policy.
Now that your users are ready to accept email at various SMTP address spaces, you must configure your Exchange system to accept email for those namespaces. As in Exchange Server 5.5, you must make sure that an MX record is set up in DNS so that DNS will route mail to your organization for the namespaces.
Securing Address Lists
After you've given your users a UPN suffix and unique email addresses, you can define custom address lists. The goal is that when users look up an address, they'll see only the addresses that you intend for them to see. The "illusion" should be complete—users shouldn't see an address list for Division A or Company A, they should see only one Global Address List (GAL) with their fellow email recipients in it.
To achieve this goal, you must set directory security on AD objects. Directory security restricts what users can see in the directory, and if done properly, restricts one company or division from viewing the information of other companies or divisions. Before you can set directory security on objects in AD, you must first select View, Advanced features in ESM so that you can view the Security tab for those objects.
Next, expand the Recipients node, right-click Default Global Address List, and select Properties. Go to the Security tab, which Figure 5 shows. The GAL currently inherits its permissions from the Exchange configuration, but you want to stop this inheritance, so you must first clear the Allow inheritable permissions from parent to propagate to this object check box. When you clear the option, Exchange asks whether you want to remove the parent permissions and start from scratch or start with a copy of the parent permissions. I usually choose the latter option. Now you can select Authenticated Users and click Remove to remove the Authenticated Users group from the default GAL; otherwise, anyone who logs on can see the default GAL. Click Apply to apply the changes. Before you create a custom address list defining who you want to see, you must restrict the default GAL. Resist the temptation to delete the default GAL, as some early Exchange 2000 white papers suggested. Without the default GAL, some system processes can't resolve internal addresses and replication breaks down.
To create a custom GAL, you must build the same type of LDAP query that you used to generate the recipient policy. As with recipient policies, you can't use OU membership to generate GALs. Instead you must use the UPN suffix of the logon name or group membership. First, right-click Global Address Lists, create a new GAL, and give it a descriptive name, such as All Users in Division A. Then, use either the UPN suffix or the group DN to build an LDAP query, as I described earlier.
The method I've outlined for multiple companies or divisions sharing a directory works well but has two minor problems with easy solutions. The first problem is that, by default, Offline Address Lists are rooted in the Store, so when I synchronize my Offline Address List and hit the road, I see all the users in the Store, not just the users in my division or custom address list. Exchange 2000 SP1 fixed this problem by letting you define custom Offline Address Lists just as you define custom recipient policies and custom address lists, so be sure that you're running SP1 or this Offline Address List problem might affect you. Right-click Offline Address Lists, create a new Offline Address List, and give it a descriptive name. As you create this Offline Address List, you'll notice that it doesn't have the same Security tab that many other objects have; it depends on the address list security settings. Figure 6 shows the dialog box you use to select an address list to associate with the Offline Address Lists.
The second problem with partitioning the directory affects Outlook Web Access (OWA) clients. When the OWA client performs a search, the address query starts at an entry point in AD that you can define. By default, no entry point value is specified, which is OK for users who need to search the entire directory but not for hosted users who should see only people in their organization. The good news is that you can control this entry point; the bad news is that you must set it per user and it isn't a user attribute that the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in exposes. Instead, you must use the ADSI Edit utility to edit the property or, better yet, use the AD provisioning tools, which I'll describe in a future article. Using ADSI Edit, you must set the msExchQueryBaseDN user attribute to the DN for the OU that you want the user to search. Here's where you can see the advantage of creating your AD hierarchy such that users are organized by OU.
Finally, here's a tip for using address lists that will benefit almost any organization—host or small business. If you need to take a server or Store offline, you usually send out an email message to all affected users. To prepare for this action in advance, you might create a distribution list (DL). But if you create a DL, you must keep it up-to-date or risk missing a user. Instead, you can create an address list on the fly, building it on the mailbox store property, as Figure 7 shows.
Valuable Lessons
By now, you can see that ASPs, with their hosted Exchange 2000 environments, can teach corporate IT departments some valuable lessons. In my next article, I'll focus on what IT departments can learn from ASPs about managing user accounts and about using AD provisioning tools to automate tasks.
