Lesson 2: Establishing Virtual Exchange 2000 Organizations | MCSE Training Kit (Exam 70-225): Microsoft Exchange 2000 Server Design and Deployment (Pro-Certification)

ASPs usually have to support independent customers who refuse to belong to a unified messaging environment. More often than not, companies that outsource their infrastructures prefer to work in environments that reflect their corporate identity. To support them, the ASP might want to implement dedicated Active Directory forests and Exchange 2000 organizations. However, this approach does not scale well if the number of users per organization is small. For example, it would not be a clever idea to implement 20 separate Active Directory forests and Exchange 2000 organizations to support 20 independent companies with 50 users. This would require a minimum of 20 servers because a particular Windows 2000 machine cannot belong to more than one Active Directory forest. To achieve cost efficiency by maximizing hardware utilization, these 20 companies should be in a single forest. The magic is in letting a distinct environment appear as 20 virtual Exchange 2000 organizations.

This lesson explains how to implement multiple virtual Exchange 2000 organizations in a single Active Directory domain. You can read about the structuring of organizational units (OUs) for distributed user account and mailbox administration and the configuration of filtered recipient policies to assign users from different virtual organizations different sets of e-mail addresses. You can also learn about the partitioning of server-based address lists and the configuration of FE servers to support large-scale hosted environments.

After this lesson, you will be able to

Identify important tasks that have to be accomplished to implement virtual Exchange 2000 organizations in a single Windows 2000 domain
Optimize FE/BE configurations to support multiple virtual organizations in a hosted environment
Design an appropriate messaging and public folder strategy to support multiple independent subscribers in one physical but separate virtual Exchange 2000 organizations

Estimated time to complete this lesson: 60 minutes

Understanding Virtual Exchange 2000 Organizations

A virtual Exchange 2000 organization is a partition or section of a physical Exchange 2000 environment that appears to its users as an individual, independent, and distinct infrastructure (see Figure 8.6). Users from a particular virtual organization are not aware that other virtual organizations exist because they do not share any resources, such as address books or public folders, with each other.

Figure 8.6 - Multiple virtual Exchange 2000 organizations on one Exchange 2000 server

To effectively separate virtual organizations from each other, you need to accomplish two things: You need to split the user account and mailbox management in Active Directory and you need to separate the Exchange 2000 resources, including mailbox stores, the MAPI-based public folder hierarchy, and server-based address lists.

To implement virtual Exchange 2000 organizations, perform the following steps:

Implement a top-level OU for each virtual organization in Active Directory and delegate administrative permissions selectively to split the user account and mailbox management.
In the Exchange System Manager snap-in, delegate the Exchange View Only Administrator role for the organization object to all administrators who are supposed to create and manage mailboxes.
Configure a separate mailbox store for each virtual organization and delegate permissions selectively to the appropriate administrators to control the creation and deletion of mailboxes per virtual organization. For large organizations, you can create multiple mailbox stores, but do not place the mailboxes of separate virtual organizations in the same database. Otherwise, you will find it difficult to manage security settings or assign partitioned offline address books (OABs).
Configure recipient policies to assign your users appropriate e-mail addresses according to the organizations to which they belong.
Delete all default address lists and then configure filtered address lists to display only the users from one virtual organization in each list. Configure security settings to prevent the users from accessing address information that does not belong to their own environments.
Delete the default OAB and then configure one OAB per virtual organization. Add the corresponding global address lists (GALs) to the OABs and then associate the OABs with the mailbox stores that belong to the same virtual organization.
Restrict the right to create top-level public folders to internal system administrators. Create a top-level public folder for each virtual organization, configure folder permissions to prevent users from different organizations from seeing each other’s top-level folders, and delegate the permission to create subfolders to the users in each virtual organization.
Configure mail exchanger (MX) records in DNS to direct incoming messages addressed to the Internet domains of your users to the SMTP hosts of your Exchange 2000 organization.
If your users access Exchange 2000 resources using Internet-based clients, configure separate protocol virtual servers for every virtual organization.

Designing the Active Directory Infrastructure

In data centers, all servers are usually deployed in a high-speed local area network (LAN). For this reason, the physical design of the Active Directory forest is very straightforward. Place all domain controllers (DCs) in the default site of Windows 2000 named Default-First-Site-Name, and promote at least two DCs to GCs to provide sufficient fault tolerance. If you service a large number of customers, consider three or more GCs. The design of Active Directory for Exchange 2000 Server is discussed in more detail in Chapter 3, "Assessing the Current Network Environment."

Windows 2000 domains can support any number of users you may want to manage in your environment. Data centers will therefore find it appropriate to deploy a single-domain forest. This approach has several advantages, including minimal resource consumption on GCs because additional domain naming contexts (domain NCs) do not exist and do not need to be replicated to the GC. However, you need to partition the domain NC to prevent users from different organizations from locating each other. Table 8.4 lists the various configuration steps required to partition a single-domain forest.

Table 8.4 Steps to Partition a Single-Domain Forest

Configuration Step	Comments
Use the Active Directory Users and Computers console to create an OU for each company that you plan to support in your single-domain forest.	If possible, name the OU according to the company, such as Litware, Inc. for a company called Litware, Inc., to clearly identify the resources (see Figure 8.7). You can then create child OUs according to the requirements of your customer, such as an individual child OU for each department or business unit within the company.
Create separate security groups for the administrators and users of the company. If you are working on a computer with Exchange System Manager installed, do not create Exchange e-mail addresses.	These groups have a similar purpose to the Domain Admins and Domain Users groups. For example, Litware Admins and Litware Users are appropriate names for Litware, Inc.
Create an Administrator account in the new OU and add it to both security groups of the company. Do not create an Exchange mail-box for this account.	For example, you can use the logon name AdminLit for the administrator of Litware, Inc. Add this account to both the administrator and user groups, such as Litware Admins and Litware Users.
Block permission inheritance for the company’s OU and remove the Authenticated Users account from the list of accounts with permissions. After that, grant the company’s user group Read permission.	In the Active Directory Users and Computers console, open the View menu and select Advanced Features. After that, right-click the OU of the company, such as Litware, Inc., and select Properties. Click the Security tab, and then clear the Allow Inheritable Permissions From Parent To Propagate To This Object check box. In the Security dialog box, click Copy to retain the current security settings. Remove Authenticated Users and then add the company’s users group, such as Litware Users. Make sure Read permission is granted.
Grant the company’s administrator group the rights to manage user accounts, reset passwords, and so forth.	Right-click the OU, select Delegate Control, and then use the Delegation Of Control Wizard to grant the desired permissions to the administrator group, such as Litware Admins.
Configure further permissions for the Windows 2000 and Active Directory resources to give all of the users and administrators the desired level of access to the single-domain forest.	For example, you may want to adjust the security settings on all existing OUs to block access to them for all authenticated users who do not have explicit permissions. Stop the permission inheritance and remove the Authenticated Users account from the list of accounts with permissions. For some containers, such as Builtin, you might need to remove the Everyone account.

Note

You should block permissions only by removing accounts. Do not remove any special accounts and do not deny access to the OUs explicitly.

Specifying security settings manually is a burdensome and error-prone undertaking, especially if the number of OUs or companies is large. As always, you should test the configuration. Log on to a workstation as the Administrator of your customer (such as AdminLit). In the Active Directory Users and Computers console, you should only be able to see the company’s OU—and the LostAndFound container if Advanced Features are enabled (see Figure 8.7). Create a test user account, such as Litware Guest. Do not create a mailbox, but add the account to the company’s user group, such as Litware Users. Verify that you are able to manage user settings.

Note

Do not forget to tell the account administrators (for example, members of Litware Admins) to add their users to the user group (for example, Litware Users) to grant them appropriate permissions in the Active Directory and Exchange 2000 environment.

Figure 8.7 - A partitioned Windows 2000 domain

Choosing a Group Type

One design question revolves around the administrator and user groups that you need to configure for each company. Should you create domain local, global, or universal security groups? If the domain is in native mode, you may want to create universal security groups because they are more flexible than others. In mixed mode, where universal security groups are not supported, choose domain local or global security groups. Keep in mind, however, that these groups are not replicated to the GC, which restricts their functionality. However, these restrictions (such as unavailability of membership lists) only apply to multidomain forests.

Windows 2000 security groups have the following characteristics:

Domain local groups Can contain members from any domain, including any type of groups, but are only available in the local domain.
Global groups Can contain members from only the local domain but are available across domain boundaries. Global groups cannot contain domain local or universal security groups.
Universal groups Can contain members from any domain and are available across domain boundaries. Universal groups are the most flexible groups in Windows 2000.

Note

If you plan to create large universal groups, consider the creation of nested groups to keep the number of users per universal group small. Universal groups are replicated to the GC, and whenever the group membership changes, the full list of members must be replicated again. Nested groups allow you to minimize the amount of data replicated.

User Principal Names

Another important question is how to build the logon names of the users. Every user requires a unique logon name in the domain. One option is to use an abbreviated combination of user and company name, such as AdminLIT for the administrator of Litware, Inc. Another is to use User Principal Name (UPN) suffixes. The UPN consists of logon name and a UPN suffix in the form of User@UPN.suffix, similar to an SMTP address, such as Admin@Litware.com. It is a good idea to use the same name for the users’ UPNs and e-mail addresses. UPNs are independent of the domain, are replicated to the GC, and must be unique across the entire Active Directory forest.

To add UPN suffixes for your companies to the forest, use the Active Directory Domains and Trusts console. In this console, right-click the root object called Active Directory Domains And Trusts and select Properties. In the UPN Suffixes tab, under Alternative UPN Suffixes, type the SMTP domain names of the company and click Add. Repeat this step for all of your customers, then click OK to close Active Directory Domains and Trusts.

In hosted environments, UPNs have the following advantages:

UPNs can be used to provide a unique namespace for each hosted organization. The users’ logon names do not need to be unique as long as the UPNs are distinctive and used for logon and user identification. For example, you can create two special Guest accounts and name them Guest@Litware.com and Guest@Fabrikam.com.
Security-related events, written to the server’s event log, allow you to identify the user and his or her company from the UserID.

Unfortunately, UPNs have several limitations that reduce their usefulness. For instance, UPNs are unavailable to Microsoft Windows NT users and users who work with Outlook 2000 in a nontrusted Windows 2000 environment. Outlook prompts for logon information, and here, the down-level logon name (such as VIP\AdminLIT) must be used. The down-level logon name has to be unique in the forest and for simplicity reasons should match the user’s logon name. In this scenario, you should ensure that all logon name portions of the UPNs are unique.

While it doesn’t generally apply to ASP environments, UPNs are very useful if users work with a client solution that supports direct logons to your Windows 2000 domain, such as a Terminal Services client (see Figure 8.8). OWA can also be configured to use UPNs with basic authentication. Simply change the authentication settings in the properties of the HTTP virtual directory, such as /Exchange. Set the default domain to "\" to enable UPN logons.

Figure 8.8 - Logons with down-level user name or UPN

More Info: Caching the Last UPN in the Terminal Services Client

By default, the Terminal Services client displays the last logged-on user name in the Log On dialog box, yet only the logon name is cached even if you use a UPN. For instance, if you logged on as AdminLIT@Litware.com, only AdminLIT is displayed the next time you log on.

To support the caching of complete UPNs, add a REG_SZ value called TSForceUPN to the Registry of your Terminal Server and set it to 1. Add this value on the server to the following Registry key:

 HKEY_LOCAL_MACHINE \Software  \Microsoft  \WindowsNT  \CurrentVersion  \WinLogon

Customizing Administrative Utilities

Microsoft did not explicitly design Exchange 2000 Server for hosted environments. Therefore, standard utilities for user and mailbox management do not take into account the requirements of virtual organizations. For example, an administrator might forget to manually add a user to the company’s user group, such as Litware Users. Consequently, this person is unable to access his or her mailbox right away because access to Active Directory is not granted unless you adjust the group membership manually. By default, all new domain users are members of only the Domain Users group. To compensate for this, you might want to develop custom administration tools that handle all the dependencies.

In the simplest case, you can use Microsoft Management Console (MMC) to build customized tools. To create a company-specific management tool, for instance, open the Active Directory Users and Computers console, right-click a company’s OU, and then select New Window From Here. Close all other child windows and then save the console in User Mode – Limited Access, Single Window. You can use Group Policy to assign the console to the appropriate administrators.

The following three options are available to save custom MMC consoles:

User Mode – Full Access It is not possible to add or remove snap-ins or save changes to the console.
User Mode – Limited Access, Multiple Windows The same restrictions as User Mode – Full Access. In addition, it is not possible to close those windows that were open when you saved the console. The administrator has the ability to open additional child windows.
User Mode – Limited Access, Single Window Same as User Mode – Limited Access, Multiple Windows, with the exception that additional child windows cannot be opened. The administrator can work with only those windows that were open when you saved the console.

You can also use a variety of powerful programming interfaces, such as Active Directory Services Interface (ADSI) or Collaboration Data Objects for Exchange Management (CDOEXM) to build management solutions. Another option is Microsoft Exchange 2000 Hosting Pack v1.1, which is an extensible, transactional framework that allows you to automate provisioning and delegated administration of hosted services. For detailed product information see Microsoft’s Web site (www.microsoft.com ) and search for the phrase "Hosting Pack."

Configuring Trust Relationships

It is seldom possible for ASPs to configure trust relationships to the domains of their customers, but internal data centers may be in a different position. If you can establish a trust from the data center’s domain to the domains of your subscribers, access permissions to mailboxes can be granted to the user’s original Windows NT or Windows 2000 accounts. You only need to add the user accounts to the appropriate user groups, such as Litware Users, to grant the required permissions in Active Directory. You also need to specify the accounts as associated external accounts in the mailbox rights of the mailbox-enabled user accounts, as explained in Chapter 3, "Assessing the Current Network Environment." Users do not need to work with different user information to access their mailboxes, resulting in a better integration of messaging services with the users’ work environment. The disadvantages are that the system administration is more complicated and that the customer is required to allow an external trust to access account information in the customer’s internal domain.

Partitioning the Information Store

The Enterprise Edition of Exchange 2000 Server allows you to partition the information store into 4 storage groups with up to 5 stores each, which allows you to configure a total of 20 stores. This gives sufficient room for dedicated mailbox stores for your customers. For large companies, consider spreading the mailboxes across multiple mailbox stores. Among other things, this helps to reduce the database size per mailbox store, which in turn allows quicker restores from backups if a database is ever destroyed. The features of storage groups and information stores are discussed in more detail in Chapter 10, "Designing Fault Tolerance and System Resilience for Microsoft Exchange 2000 Server."

Dedicated mailbox stores also allow you to configure permissions so that only the administrators from a particular company can create mailboxes in a particular mailbox store using the Exchange Task Wizard. Because OABs are associated with mailbox stores, this ensures that users are able to obtain correct address information.

Granting Account Administrators Access to the Information Store Partitions

An account administrator who is supposed to create and manage mailbox resources requires the permissions of an Exchange View Only Administrator to the Exchange 2000 organization. As mentioned in Chapter 5, "Designing a Basic Messaging Infrastructure with Microsoft Exchange 2000 Server," you should delegate this role to all account administrators at the organization level.

By default, Exchange View Only Administrators have the ability to create mailbox resources in all mailbox stores in the organization. If you have implemented a single administrative group for centralized system administration, it is not feasible to narrow administrative permissions at this level. You have to configure each existing mailbox store individually (see Figure 8.9).

Figure 8.9 - Partitioning the mailbox store

It is a good idea to test the permission assignments. Log on to the domain as an Account Administrator and attempt to mailbox-enable a test account, such as Litware Guest. You should be able to select only the stores that belong to the company, such as the mailbox store of Litware, Inc. Table 8.5 summarizes the configuration options at the mailbox-store level.

Table 8.5 Configuration Options at the Mailbox Store Level

Configuration Option	Comments
Block the inheritance of security settings and remove all administrators who are not supposed to create mailboxes in the mailbox store from this list.	This is a reliable way of configuring permissions. If you add further account administrators at the organization level, they do not inherit any permission to the mailbox stores. Do not remove the Exchange Domain Servers and other special accounts not available to the customer.
Do not block the inheritance of security settings but deny the administrators access to the mailbox stores.	Explicitly denied permissions take precedence over inherited permissions, but any new administrators at the organization level can create mailboxes in all mail-box stores by default. This configuration option is less secure because with every new account administrator, you have to adjust the security settings on all mailbox stores in the organization.

Partitioning the Address Book

At this point, you have streamlined user account and mailbox administration. Now you need to partition the server-based address book to implement partial address book views for each company. In fact, splitting the address book information is the key element in configuring virtual organizations. Partial address books deliver the impression that only the users from one particular company belong to the same messaging organization.

To partition the server-based address book, perform the following steps:

Create recipient policies to assign the recipients from each company an appropriate SMTP address, such as AdminLit@Litware.com or AdminFab@Fabrikam.com.
Delete the default address lists and GAL and configure partitioned address lists and GALs for each company.
Configure an OAB for each company and assign it to the corresponding mailbox stores.

Configuring Recipient Policies

To configure a recipient policy, in the Exchange System Manager snap-in, open the Recipients container, then right-click on Recipient Policies, point to New, and select Recipient Policy. Specify a name that corresponds to your customer’s company, such as Litware, Inc., and then click Modify. You now must set up an appropriate LDAP filter. Based on LDAP filters, you can selectively assign SMTP addresses to your users and mark them as inbound. For example, a user of Litware, Inc. might require an SMTP address of <user>@Litware.com, but not an address of <user>@Fabrikam.com, and so on.

The challenge is to configure an optimal LDAP filter. Unfortunately, it is not possible to check for the parent OU of the users because OU information is not part of the user or group accounts. To circumvent this problem, Microsoft recommends filtering for UPN suffixes (such as Litware.com) or group memberships (such as Litware Users), but this information is available for user accounts only, not groups. You should therefore set up separate recipient policies for groups and filter for the group name, which then would have to begin or end with a company-specific identifier for the filter to work. The string representation of LDAP search filters is defined in Request for Comments (RFC) 2254.

A more straightforward approach uses a common attribute to specify the company-specific filter information. For example, user accounts, groups, and contacts all have a Description attribute in common, which account administrators can use to specify the company name. This is no more or less error-prone than the previous approach, but it allows you to create a single filter that applies to all possible recipient objects of a virtual organization. Remember to inform the account administrators about the configuration requirements. It would be useful to provide a customized administrator tool that takes care of the configuration issues programmatically. To verify the correctness of the filter you have created, click Find Now from the Find Exchange Recipients dialog. Figure 8.10 shows an example of a query for the Description attribute.

Note

LDAP filtering cannot address incorrect or missing company information. For example, if an administrator specifies an incorrect UPN suffix, forgets to add a new account to the corresponding user group, or does not specify company information in a dedicated account attribute, incorrect addresses of the default recipient policy might be assigned to the object. It is then necessary to correct the user, group, or contact address information manually.

To complete the configuration, click the E-Mail Addresses tab, double-click an SMTP Address entry, and modify the address according to the SMTP domain name of the company, such as @Litware.com. Make sure the This Exchange Organization Is Responsible For All Mail Delivery To This Address check box is selected to identify the domain name as inbound, and then click OK. Marking an SMTP domain as inbound lets Exchange 2000 Server deliver Internet messages, for recipients with a corresponding SMTP address, to the mailboxes. Remember to configure appropriate MX records for each domain in DNS, as explained later.

It is a good idea to test the effectiveness of the recipient policies by creating a mailbox-enabled test account. Verify that the Recipient Update service assigns the user the correct SMTP address.

You can use the following placeholders in your SMTP address spaces:

% d —Display name
%g —First name
%i —Middle initial
%m —Alias
%s —Last name

You can specify the number of characters to use in the form of %<number><identifier>, such as %1g.%s@Litware.com, which would result in L.Administrator@Litware.com, for example.

Figure 8.10 - Configuring an LDAP filter based on the Description attribute

Configuring Server-Based Address Lists

The configuration of address lists and GALs is similar to the creation of recipient policies. The good news is that the configuration of LDAP filters for address lists is easier than the configuration of recipient policies because, at this point, all recipients possess a well-known and company-specific SMTP address. Right-click All Address Lists or All Global Address Lists, point to New, and then select Address List or Global Address List. Specify a name and then click Filter Rules. Make sure Exchange Recipients is selected under Find. Click the Advanced tab, click Field, point to Users, and then select E-Mail Address. Under Condition, select Ends With, and under Value, type the SMTP domain name of the company you are creating the address list for, such as Litware.com. Click OK and then click Finish to create the new address list object.

Do not forget to assign the new address list to the company’s user group via security settings. Right-click the address list object and select Properties. Click the Security tab and block the permission inheritance by clearing the Allow Inheritable Permissions From Parent To Propagate To This Object check box, and then click Copy. Remove Authenticated Users and all other accounts that are not allowed to access the address information, leave the system accounts in place, and add the company’s user group. This group requires the following permissions: Read, Execute, Read Permissions, List Content, Read Properties, Open Address List, and List Object. Additional rights are granted automatically.

Note

Remove the default address lists and GAL objects in the Exchange System Manager snap-in; otherwise, your users will continue to see complete address information in their messaging clients instead of your partial address lists.

Configuring OABs

The OAB is a client-based replica of the server-based address lists. It is created on the server and downloaded to the user’s local computer to provide recipient information when no connection to the server exists and the client operates in offline mode. On the server, the offline address information resides in a hidden public folder; on the client, the offline address information is in up to five files with an .oab extension (ANRDEX.OAB, RDNDEX.OAB, TMPLTS.OAB, DETAILS.OAB, and BROWSE.OAB).

To avoid the download of full address information, delete the default OAB and create a customized, partial OAB for each company. In the Exchange System Manager snap-in, under Recipient Policies, right-click Offline Address List, point to New, and then select Offline Address List again. Provide a name for the OAB (such as OAB Litware), specify an appropriate server on which to store the offline address information, and ensure that only the address lists that belong to the company are included in the OAB. Remove all other address lists. Click OK and then assign the OAB to the mailbox store of the company. In the Exchange System Manager snap-in, display the properties of the mailbox store. Click the General tab, and specify the desired OAB. If you have configured a separate mailbox store for each company, the assignment of OABs is very straightforward.

You should also configure security settings for the OABs to prevent the accidental download of incorrect offline address information to the wrong clients. Security settings are quickly configured in the OAB’s Security tab. As usual, block the permission inheritance, copy the accounts into the permissions list, and then remove Authenticated Users from this list. Add the company’s user group and grant it the following rights: Read, Execute, Read Permissions, List Content, Read Properties, and List Object. Click OK and test the download of the offline address information the next day.

Note

Offline address lists must be generated on the server before clients can download them. They correspond to system public folders created on the server during public store maintenance intervals.

Partitioning the Public Folder Store

For the MAPI-based public folder tree, only one public folder store is supported per Exchange 2000 server. In other words, all virtual organizations will work with the same set of public folders, and by default, all public folders are accessible by all users (see Figure 8.11). To avoid the disclosure of potentially confidential information, you must assign each virtual organization a dedicated top-level folder and set access permissions on it so that the folder is only visible and accessible to members of that virtual organization. Remember to restrict the right to create top-level folders to the system administrators of the data center. Otherwise, account administrators or users might create further root folders, which would then be visible to all virtual organizations by default. Restricting the rights to create top-level folders is explained in Chapter 5, "Designing a Basic Messaging Infrastructure with Microsoft Exchange 2000 Server."

Figure 8.11 - Partitioning the public folder store

To create a pseudo-root folder for a virtual organization, use the Exchange System Manager snap-in to create the top-level folder. In the Permissions tab, click Client Permissions. Clear all rights, including the Folder Visible check box, for the Default and Anonymous accounts. After that, add the virtual organization’s user group, such as Litware Users, and grant it the Folder Visible and Read Items permissions at minimum. You might also want to give the users or at least the account administrators the Create Subfolders permission. Within their pseudo-root folder, the users are then free to develop a public folder structure according to their business needs.

Configuring the External Domain Name System

Apart from Active Directory and the Exchange 2000 organization, you also need to configure the external DNS servers with MX records for each virtual organization to ensure proper routing of inbound messages from the Internet. Point all MX records to the IP addresses of the SMTP hosts of your Exchange 2000 organization that communicate with the Internet (see Figure 8.12). Within the Exchange 2000 organization, messages are transferred according to the internal routing topology. Message routing based on link state information (LSI) and routing groups are discussed in Chapter 5, "Designing a Basic Messaging Infrastructure with Microsoft Exchange 2000 Server."

Figure 8.12 - Routing inbound SMTP traffic to the Exchange 2000 organization

To configure DNS, do the following:

Create a standard (primary) zone for each virtual organization’s Internet domain.
Add address (A) host records for the SMTP hosts that accept incoming message traffic from the Internet.
Create MX records for the SMTP hosts and assign priorities to them. Load balancing is performed if the MX records have the same priority.

Note

MX records should point to A records—not to CNAME records—to avoid misrouting of inbound mail. It is common to have multiple SMTP servers within an organization, so more than one MX record may exist per Internet domain.

Configuring Protocol Virtual Servers

By default, only one virtual server exists per Internet protocol, but this is not sufficient for ASPs that are hosting numerous independent virtual organizations for their customers on a small number of powerful servers. In this situation, you should configure dedicated virtual servers for each virtual organization to gain more control over client communication. To create additional protocol virtual servers on your Exchange 2000 machine, use the Exchange System Manager snap-in. Open the Protocols container underneath the server object, right-click the desired protocol container (HTTP, IMAP4, or POP3), point to New, and then select the <Protocol Type> Virtual Server command. You need to define a name for the new virtual server and assign it an IP address and port number.

For each virtual server you can restrict the number of users who can access messaging resources concurrently and specify a period of time after which idle connections are terminated. In the Access tab, you can configure authentication settings. You can allow Anonymous Access, Basic Authentication, or Integrated Windows Authentication, and specify a Default Domain if Basic Authentication is activated for resource access. Remember to specify "\" to support UPN logons, as mentioned earlier. You can also encrypt the communication channel between server and client based on SSL by installing a server certificate that belongs to the virtual organization. It might also be useful to specify IP addresses or ranges of IP addresses that should be granted or denied access to the Exchange 2000 server.

Protocol Virtual Servers in FE/BE Configurations

You must assign each virtual server either a separate IP address or customized TCP port numbers for nonencrypted and SSL-encrypted communication. An FE/BE environment, however, does not support customized TCP port numbers. In this situation, it is important to provide an individual IP address for each virtual server. In Windows 2000 Server you can assign a single network card multiple IP addresses or install multiple network adapters and configure each with a separate IP address.

Keep in mind that the configuration of FE and BE servers must match. For instance, if you configure an HTTP virtual server with an /Exchange and /Public virtual directory for a virtual organization on an FE server, you need to do the same on all of the BE servers that the users of the virtual organization should access (see Figure 8.13). Make sure that the correct Internet domain of the virtual organization is specified as the SMTP domain in the General tab of the virtual directory used for mailbox access (for example, /Exchange). Otherwise, users cannot open their mailboxes using OWA, as explained in Lesson 1.

Microsoft recommends the following strategy to create and configure HTTP virtual servers for BE servers:

Use a name that easily identifies the purpose of the virtual server. A name in the form of <Exchange FE VS (front-end – hostname)> is recommended, but for clarification you might want to add the name of the virtual organization to which the virtual server belongs.
From the Internet Services Manager, right-click on your Web virtual server and select Properties. Select the Web Site tab and click Advanced beside the IP Address field. Within the Multiple Identities For This Web Site section of the dialog box, click Add. Under Host Header Name, type the FE namespace to allow the FE server to communicate correctly with the BE machine.
Make sure TCP Port is set to 80, because customized ports cannot be used in an FE/BE communication.
Accept the default IP address setting, All Unassigned, or specify a particular IP address assigned to the server. Click OK to add the identity.
If the users have several ways to access the FE server, such as through internal and external host names, repeat this process to add several corresponding identities to the virtual server. When all identities have been added, click OK twice to return to the Internet Services Manager.
Add virtual directories to the virtual server to match those configured on the FE server, such as /Exchange and /Public. For /Exchange or any other virtual directories that point to mailboxes, make sure the SMTP domain matches the SMTP domain specified on the FE server, as mentioned earlier.

Figure 8.13 - FE/BE servers for virtual organizations

Operability Issues

Compared to Microsoft Exchange Server 5.5, Exchange 2000 Server provides ASPs with far more opportunities to provide a reliable, high-performance messaging organization. Nevertheless, there are a few issues specifically related to hosted environments and virtual organizations that you must address in your implementation plan to achieve the desired level of security and functionality. Table 8.6 summarizes the most important issues.

Table 8.6 Configuration Issues Related to Exchange 2000 Server in Hosted Environments

Configuration Issue	Comments
Account administrators and users are able to see a list of all OUs in the Active Directory Users and Computers console.	Even without any access permissions, all top-level OUs are listed in the details pane when selecting the domain object in the Active Directory Users And Computers contents pane. If you followed the recommendations and used company names for your OUs, sensitive information might be disclosed. For this reason, avoid the creation of company-specific OUs at the top level. Use arbitrary names and place the company-specific OUs beneath. In this way, users might be able to see arbitrary OUs, but they cannot determine the other organizations that belong to the same environment.
Improperly configured user accounts might receive incorrect address information and appear in the wrong address lists.	An account administrator might forget to include company-specific information required to properly assign your recipient policies or might fail to add new users to the company’s user group, such as Litware Users. In this scenario, the users cannot find their recipient objects in the server-based address lists and consequently cannot log on to their mailboxes. To address this issue, you might want to develop custom administration tools that take care of all configuration tasks.
Independent of permissions assigned for OUs, OWA users can see all recipients in address book searches by default.	Per-user rights do not affect directory queries in OWA, which effectively represents a security breach because it can disclose a complete list of all recipients in the Exchange 2000 organization regardless of the security settings assigned to the OUs. To eliminate this problem, define a search scope for each individual user who uses Exchange 2000 OWA. Launch ADSI Edit, or use a similar low-level LDAP utility, and set the msExchQueryBaseDN attribute for each individual user to the OU that represents the user’s virtual organization, such as OU=customer1, DC=VIP,DC=COM. (To determine the distinguished name [DN] that you have to specify for the user, display the properties of the user’s parent OU in ADSI Edit. At the top of the Properties dialog box, under Path, you can find the fully qualified name, which contains the DN.) Unfortunately, the msExchQueryBaseDN attribute is not exposed in any standard administrative tools, such as the Active Directory Users and Computers console. If pos- sible, develop a custom utility based on Microsoft Visual Basic Scripting Edition (VBScript) and ADSI to control this attribute.
Internal information may be exposed to the ASP or to other virtual organizations.	The ASP can always access their customers’ information in all mailboxes and public folders, and improperly configured security settings can expose internal data to other organizations. To prevent the disclosure of sensitive information, install the Key Management Service (KMS) and integrate the entire Exchange 2000 organization into a public-key infrastructure (PKI). Enable all of your users with advanced security for message signing and sealing. A sealed (encrypted) message is only readable by intended recipients, and a digitally signed message allows you to verify that the displayed originator was indeed the source of the message and that the message text was not tampered with during message transmission.
It is not possible to create mail-enabled contacts for users in other virtual organizations. It is not possible to separate public folder resources on a single server.	You might want to add mail-enabled contacts (formerly known as custom recipients) to your server-based address lists, but these users cannot reside in any of the virtual organizations. In the same forest, only one directory object can be assigned a particular e-mail address. If you need to provide custom address information for users or user groups in other virtual organizations, create a public folder for contact objects and display the contents of this folder in the users’ address book via the Outlook Address Book provider. If you need to keep the public folders of each virtual organization in a different public folder database, place each pseudo-root on a dedicated public folder server. Unfortunately, this may force you to implement as many public servers as virtual organizations exist.
Users cannot obtain originator addresses in messages received from users in other virtual organizations.	If you receive a message from a user in another virtual organization, and you double-click on the originator name to obtain detailed address information, Outlook 2000 displays an empty dialog box. Due to missing access rights to the originator’s OU, you cannot read the user attributes. OWA users see the originator’s reply address if the recipient replies to the message. To address this problem, you might want to include the users’ SMTP address in the display name, such as Administrator (AdminLit@Litware.com).

Designing a Hosted Environment for the Baldwin Museum of Science

The Baldwin Museum of Science, introduced in Chapter 7, has successfully migrated to Exchange 2000 Server. "We find the option to configure virtual organizations very attractive," says Shelly Szymanski, Head of Information Technology. "In this way, we finally can support the Graphic Design Institute and the School of Fine Art in the Museum’s centralized messaging environment. This will help us to reduce the number of organizations as well as the number of systems that we have to support. The Graphic Design Institute, the School of Fine Art, and the Baldwin Museum of Science all actually belong to the same network sponsored by the local government. We don’t need to implement a highly secured environment, but we want to provide virtual organizations to give the users the impression that they work in their own hemispheres. For this reason, the global address lists should contain only addresses from the local organization, but detailed address lists should also be provided to show the recipients from all other organizations as well. For us, to separate the resources does not mean to refuse to work together."

Szymanski designed the following environment:

The Graphic Design Institute, the School of Fine Art, and the Baldwin Museum of Science are supposed to manage their own user accounts and groups. Therefore, we will implement a structure of three top-level OUs (one for each organization), create a user and administrator group, and delegate the required rights for the OUs to these groups.
In our environment, it is not necessary to prevent the users from seeing each other across the boundaries of the virtual organizations. It is not necessary to tighten security to prevent the authenticated users from accessing OUs. We will leave the security settings at their defaults.
Our production environment operates in native mode. Hence, we can and will create universal security groups for the administrators and users in each virtual organization.
We intend to provide a partial OAB to the users in each virtual organization, and we also want to prevent account administrators from creating mailboxes in the repositories of other virtual organizations. Correspondingly, we will split the information store and create three mailbox stores. After granting the account administrators the Exchange View Only Administrator permissions at the organization object in the Exchange System Manager snap-in, we need to restrict access to the mailbox stores at the mailbox-store level.
Because of our limited resources, we cannot create any customized utilities for user account and mailbox administration. The administrators have to take care of the requirements themselves. We will configure three recipient policies to assign all users appropriate e-mail addresses based on the Description attribute, but the account administrators must specify organization-specific information in this field manually. Based on the SMTP address information assigned via the recipient policies, we will create partial GALs and detailed address lists for the users. We will delete any default GALs and address lists and then assign the appropriate GAL to each virtual organization. Detailed address lists will be available to all users in the environment.
We will configure a separate OAB for each virtual organization. The OABs, assigned to the corresponding mailbox stores, will contain only information from the partial GALs.
Our users need to be able to work closely together. For this reason, we will not split the public folder tree. It is not necessary to create pseudo-public folder roots.
The users in all three virtual organizations work with Microsoft Outlook 98, Outlook 2000, or Outlook XP. It is therefore not necessary to configure virtual servers for Internet-based client access.

Activity: Designing Hosted Environments

In this activity, you will design virtual organizations for Northwind Traders, a fictitious company that plans to implement Exchange 2000 Server.

Tip

You can use Figure B.23 in Appendix B as a guideline to accomplish this activity.

Scenario: Northwind Traders

Northwind Traders, a national corporation specializing in motorcycles, automobiles, trucks, heavy equipment, boats, and aircraft, with headquarters in Los Angeles, California, and offices all over the United States, is considering an implementation of Exchange 2000 Server to support its numerous trading centers and distribution points. "We are in a strange situation," says Mark Harrington, Head of Information Technology at the company. "Our company consists of more than 150 major trading centers that operate independently of each other. Their markets sometimes overlap and, therefore, our trading centers indeed compete with each other directly. You may think of each trading center as an independent company. In the past, we had to implement a separate messaging environment in each of our 150 locations. We used the same platform, which was Exchange Server 5.5, but now, with Exchange 2000 Server, we finally see an opportunity to centralize all of our messaging resources. We believe that this will help us dramatically reduce our maintenance costs. Of course, our trading centers must remain separate entities with separate messaging environments, but we intend to achieve centralization by means of virtual organizations."

It is your task to outline an appropriate environment of virtual organizations for Northwind Traders:

How should Northwind Traders configure its Active Directory environment, provided that the organization operates in native mode?
Northwind Traders intends to provide a partial OAB to each virtual organization and structure the mailbox administration so that the account administrators can only create mailboxes in the mailbox store of their own virtual organizations. How many servers does Northwind Traders need, at minimum, to support all 150 trading centers?
Would you recommend the development of custom administration tools? Why?
How can Northwind Traders split recipient information so that users can obtain address information from only their local virtual organizations?
You have created 150 OABs and configured the security settings correctly. What do you have to accomplish next to allow users to download the correct OAB to their clients?
Northwind Traders must prevent public folder access across the boundaries of virtual organizations. How can you accomplish this?
The trading centers of Northwind Traders will use OWA for messaging. What do you have to accomplish to properly support the clients in an FE/BE scenario?

Lesson Summary

ASPs can use Exchange 2000 Server to support independent customers in a unified messaging environment by means of virtual organizations. To effectively separate virtual organizations from each other, you need to split the user account and mailbox management in Active Directory and separate the Exchange 2000 resources, including mailbox stores, the MAPI-based public folder hierarchy, and server-based address lists.

To split the user account and mailbox management in Active Directory, create a top-level OU for each virtual organization and delegate administrative permissions selectively. It is a good idea to create an account administrators group and a users group for each virtual organization. This facilitates the assignment of permissions to OUs, address lists, and public folders. The configuration of numerous security settings is especially challenging. You can streamline this task by developing custom administration utilities. Consider the configuration of UPNs to provide a unique namespace for each virtual organization.

To separate the Exchange 2000 resources, configure separate mailbox stores for the virtual organizations and delegate permissions to the appropriate administrators. You also need to configure recipient policies to assign the users the required e-mail addresses. As recipient objects, they appear in the server-based address lists and OAB, which you also need to adjust or re-create. You should not leave the default address lists in place. Further tasks include the implementation of pseudo-public folder roots, the configuration of DNS MX records for each virtual organization, and the creation of separate protocol virtual servers for every virtual organization.