Sign up for the ITPro Today newsletter
Stay on top of the IT universe with commentary, news analysis, how-to's, and tips delivered to your inbox daily.
Hosting Email Services, Part 2
Create a recipient policy and build an address list for a hosted organization
Paul Robichaux
July 30, 2002
10 Min Read
Create a recipient policy and build an address list for a hosted organization
In "Hosting Email Services," August 2002, InstantDoc ID 25469, I discussed the fundamentals of getting Outlook Web Access (OWA) 2000 ready for small-scale hosted environments. You must perform a fairly long list of steps to make hosting work, but none of them are particularly difficult. This month, I complete the process by creating a recipient policy and building and securing an address list for the hosted organization. Then, it's time to create some users and test whether things work correctly.
Creating a Recipient Policy
Each hosted organization needs its own recipient policy, which tells the Recipient Update Service (RUS) how to build the proxy addresses (such as SMTP addresses) for objects that match the policy. You probably want a recipient policy that gives all mailboxes, security or distribution groups, and public folders that belong in the hosted organization the same SMTP domain address. "Microsoft Exchange 2000 Server Hosting Series" (http://www.microsoft.com/technet/prodtechnol/exchange/plan/hostedexch/aspintro.asp) tells hosting providers to turn off RUS, but that's only because when you create a new object, the object isn't mail-enabled until the next time RUS runs. Unless you can't live with a delay of up to 15 minutes while you wait for RUS, leave the service turned on. If you turn off RUS, you must manually add all the mailbox-specific attributes when you create a new object.
Like address lists, recipient policies depend on building Lightweight Directory Access Protocol (LDAP) queries that select only the objects you want. For each hosted organization on your servers, you need a separate recipient policy, which you can create as follows:
Open Exchange System Manager (ESM), expand the Recipients node, and right-click Recipient Policies. Select New, Recipient Policy. (If you have Mailbox Manager installed, a dialog box appears and asks you to select E-mail Addresses or Mailbox Manager Settings. Select E-mail Addresses.)
Give the new policy a name that associates it with the organization to which it applies. In the policy's Properties dialog box, click Modify to open the Find Exchange Recipients dialog box. From the Find drop-down list, select Custom Search, then click the Advanced tab.
Enter the LDAP query that forms the recipient policy. LDAP query syntax is important but convoluted. (For information about the LDAP syntax, see http://msdn.microsoft.com/library/default.asp?url=/library/en-us/netdir/ad/creating_a_query_filter.asp.) You can use the query (&(|(&(objectCategory=person)(userPrincipalName=*orgName)(mailnickname=*)(objectclass=user))(&(objectCategory=group)(displayName=*orgName)(mailnickname=*))(&(objectClass=publicfolder)(mailnickname=*)(company=orgName)))) if you substitute orgName with the name of the organization that you want to host. Figure 1 shows a query for the organization 3sharp.com. The parentheses and ampersands group operands. If you were reading this policy, you'd probably say, "Find all objects that are mail-enabled users in 3sharp.com, mail-enabled groups in 3sharp.com, or mail-enabled public folders in 3sharp.com." Remember that you'll need to use the same organization and company name that you used here when you create the objects.
Return to the E-mail Addresses tab of the recipient policy's Properties dialog box. Click New and enter an SMTP address for the organization; Exchange will apply this new address to newly created objects. (Of course, be sure that you've specified the correct DNS name for your organization, including its top-level domain, before you create the SMTP address.)
After you specify the new SMTP address, the E-mail Addresses tab reappears. Select the check box for your new SMTP address, then choose Set as Primary. This action enables the new SMTP address and makes it the default. You can then clear the check box for the default SMTP address for your domain (i.e., the domain you use for your users, not hosted users) to prevent hosted users from getting an address in your domain.
Click OK to finalize the new policy. After the next time RUS runs, it will know how to stamp the hosted organization's SMTP address on objects that "belong" to the organization.
Creating an Address List
By design and by default, Exchange 2000 has one Global Address List (GAL). This setup is great when you have only one organization; however, if you want to host other organizations, you want the users in each organization to see the objects in only their organization. The easiest way to limit users' views is to set up a separate GAL for each organization. Creating a GAL object in ESM is easy, but setting up the necessary LDAP filter in the Microsoft Management Console (MMC) ADSI Edit snap-in is more difficult. For each organization that you host, follow these steps:
Launch ESM and navigate to Recipients, All Global Address Lists. Right-click and select New, Global Address List.
Give the new GAL an organization-specific name (e.g., 3sharp GAL), then click Finish.
Click Start, Run, and type
adsiedit.mscto launch the ADSI Edit snap-in. Connect to a domain controller (DC). Open the Configuration Container object, then navigate to the newly created GAL. (If you don't see the Configuration Container object, click Action, Connect To to connect to a Global Catalog—GC.) The GAL you're looking for will be at CN=Services, CN=MicrosoftExchange, CN=orgName, CN=Address Lists Container, CN=All Global Address Lists under your organization's CN=Configuration object, as Figure 2, page 8, shows.
Right-click the new GAL and select Properties, then select the purportedSearch attribute from the Select a property to view drop-down list.
Type the following LDAP filter (replacing orgName with the hosted organization's name) into the Edit Attribute text box: (&(|(&(objectCategory=person)(userPrincipalName=*orgName)(mailnickname=*)(objectclass=user))(&(objectCategory=group)(displayName=*orgName)(mailnickname=*))(&(objectClass=publicfolder)(mailnickname=*)(company=orgName)(msExchHideFromAddressLists=FALSE)))). You must enter the filter manually instead of using ESM to enter it automatically because the filter is too long for ESM's UI to accept. Like the recipient policy filter, this unwieldy mass tells Exchange to find all the users, groups, and public folders that belong in the hosted organization and consolidate them in the new GAL. The msExchHideFromAddressList=FALSE statement is important because without it, public folders or other objects that you want to hide from the GAL will appear in the address list. After you enter the filter, click Set, then click Apply.
After you've created a GAL for an organization, you need to follow a similar set of steps to create an organization-specific, "regular" address list. You can tweak the LDAP filter you entered in Step 5 to let the hosted organization's GAL include objects from other organizations, but having a real, nonglobal address list for each hosted organization is also useful. By separating the GAL and the organization-specific address list, you let users download a shorter address list to use offline, which is important for users on slow dial-up connections. To set up an organization-specific address list, follow these steps:
Launch ESM and navigate to Recipients, All Address Lists. Right-click and select New, Address List.
Give the new address list an organization-specific name that's different from the GAL name, then click Finish.
Right-click Offline Address Lists and select New, Offline Address List. In the New Object - Offline Address List dialog box, give the list a name, then click Browse to pick an Exchange server to be the list generator. When prompted for address lists to include, choose only your new address list.
Launch the ADSI Edit snap-in. Open the Configuration Container, then navigate to the newly created address list. It will be at CN=Services, CN=Microsoft Exchange, CN=orgName, CN=Address Lists Container, CN=All Address Lists under your organization's CN=Configuration object.
Right-click the new address list and select Properties. Select the purportedSearch attribute from the Select a property to view drop-down list.
As with the GAL, provide a custom LDAP filter that will catch all the objects of interest to this organization's users. Type the following filter (replacing orgName with the hosted organization's name) into the Edit Attribute text box: (&(|(&(objectCategory=person)(userPrincipalName=*orgName)(mailnickname=*)(objectclass=user))(&(objectCategory=group)(displayName=*orgName)(mailnickname=*))(&(objectClass=publicfolder)(mailnickname=*)(company=orgName)(msExchHideFromAddressLists=FALSE)))).
Repeat the steps to create a GAL and offline address list for each organization that you want to host. Next, you need to apply correct permissions to the lists to keep different organizations' lists separate from one another.
Securing the Address Lists
You must perform two separate sets of steps to secure a hosted organization's address lists—one for the GAL and one for the offline version. Let's start with the GAL.
Open ESM and find the GAL whose permissions you want to set. Right-click the GAL and select Properties.
Go to the Security tab and clear the Allow inheritable permissions check box. When ESM prompts you, choose to copy the existing permissions from the parent object to the current object.
Remove the Everyone and Authenticated Users items from the ACL. Add the allusers@orgname and admins@orgname groups that you created for the organization (as I described in "Hosting Email Services").
For each of the two groups that you added, clear all the permissions except for Read, Execute, Read permissions, List contents, Read properties, List object, and Open address list. Click OK to apply the new permissions.
The offline address list requires a slightly different set of steps.
Open ESM and navigate to the offline address list whose permissions you want to set. Right-click the list and select Properties.
Go to the Security tab and clear the Allow inheritable permissions check box. When prompted, choose to copy the existing permissions from the parent object to the current object.
Remove the Everyone and Authenticated Users entries from the ACL. In their place, add the allusers@orgname and admins@orgname groups that you created for the organization.
For each of the two added groups, clear all the permissions except for Read.
Click OK to close the security dialog box. (Click Yes on the warning about Deny ACEs taking priority.)
Find the offline address list you just modified. Right-click it, then select Rebuild to force RUS to recreate the list with the new permissions.
Adding Users
Now for the best part—adding new user accounts and testing them. As I mentioned earlier, if you follow Microsoft's recommendation to hosting providers to turn off RUS, you must manually add all the mailbox-specific attributes when you create a new object. If you're using your own provisioning scripts to create hosted users, adding the attributes yourself is fine; if not, leave RUS enabled to make adding new user accounts much easier. To create accounts in the hosted organizational unit (OU), use the standard MMC Active Directory Users and Computers snap-in process, but right-click the hosted organization's OU instead of the default Users container.
Before you can test your new user configuration, you must add for the hosted OU a DNS MX record that points to your server. Until that mail exchanger (MX) record is in place and propagated, no one can send mail to your users.
Creating Public Folders
You can use Outlook or ESM to create public folders that only one organization can access. No matter which tool you use, you need to set permissions by copying the inherited folder permissions, removing the Everyone and Authenticated Users entries, and adding the allusers@orgname group (with Author permissions) and the admins@orgname group (with Publishing Editor and Folder Contact rights). You also need to use ADSI Edit to add the company attribute to the folder—the LDAP filters we created earlier use this attribute to decide which folders to include. Of course, end users in the hosted organization can't change permissions on the public folders. If you want to give them the ability to set custom permissions, create a top-level public folder with permissions for the group of that organization. New folders created inside that folder will inherit those permissions.
After you've configured users and public folders, you're ready to test the whole setup. First, add a test user to the new organization. Then, use Microsoft Internet Explorer (IE) to go to http://serverName/orgName/userName, log on to OWA, and compose a new message to a known-good Internet address (such as your own). Make sure that the logon process correctly uses user principal names (UPNs) and that outbound messages have the correct return address. Then, reply to the message and verify that your reply goes where it's supposed to go. For bonus points, turn on Secure Sockets Layer (SSL) on the hosted organization's virtual directories to protect their back-and-forth traffic.
Add the users to the new organization, then ensure that mail sent to the new users arrives where it should (if it doesn't, double-check the DNS MX record and make sure that the organization's recipient policy is correct). Verify that users can log on to OWA and through POP3 or IMAP4, if you're using them. Use Outlook to log on as a hosted user and ensure that the To button in the message composition window shows you recipients from only the user's organization.
About the Author
You May Also Like
.png?width=700&auto=webp&quality=80&disable=upscale)