Exchange 2000 Hosting: The ASP Model, Part 1

Design your Exchange organization as an ASP would

Exchange Server administrators can learn valuable lessons from application service providers (ASPs) that host Exchange 2000 Server. Because an ASP is like an IT department that must stand on its own, an ASP must put a price on its operations or services and sell them on the open market. To be successful, ASPs must offer a better product at a lower cost.

To illustrate how you can run your Exchange organization the way an ASP does, I describe the infrastructure ASPs typically use to host Exchange for multiple customers and tell you how to set up customized user logon names in Active Directory (AD). In future articles, I'll show you how to configure user email addresses and introduce some AD provisioning tools that can help improve your efficiency in managing Exchange.

ASP Priorities
First, let's look at an ASP's top priorities. When potential customers interview ASPs, they frequently have some of the same key concerns: security, availability, email clients and access methods, and account management. So ASPs make sure that they've addressed these concerns in their service offerings.

With regard to security, customers want to make sure that their mail system is protected from external intrusion and isolated from other companies' information that the ASP might host on shared resources. The ASP must protect the privacy of hosted companies so that the companies aren't aware that they're on the same system. The ASP must hire a third party to periodically perform security audits and external intrusion tests to ensure security.

Availability is often the customers'—and therefore the ASP's—second priority. ASPs use the same techniques as you do to ensure availability: fault-tolerant hardware, clustering, good design and operational procedures, and disaster-recovery plans. I describe these techniques in more detail in "The 7 Habits of Highly Available Exchange Servers," http://www.win2000mag.com, InstantDoc ID 21519. However, for ASPs, availability is an important product offering and different levels of availability have different price tags. ASPs and their customers sign service level agreements (SLAs), which set expectations for the agreed-upon availability level and establish penalties if the ASP doesn't live up to the expectations.

Another question customers ask is what type of email clients and access methods are supported. Outlook is typically the email client of choice. You might also need Outlook Web Access (OWA) for roaming users. Typically, ASPs also offer POP3 with SMTP, and IMAP with SMTP for mobile devices.

Customers also want to know the ASP's account-management policies. They wonder how open the system will be to them (e.g., can they choose to perform tasks such as creating accounts and mailboxes and resetting passwords?) and how responsive the ASP will be for simple account- or server-management requests.

Front-End/Back-End Architecture
Unless an ASP is hosting only small companies or providing only Outlook client access, the hosted Exchange architecture, which Figure 1 shows, will consist of a front end and a back end. A double-layered architecture, with a firewall protecting each layer of multiple servers, helps to address customers' security concerns.

The main entry point for client access is through a front-end network running Microsoft Network Load Balancing Service (NLBS) or using load-balancing hardware products from vendors such as Cisco, Nortel Networks, F5 Networks, and Intel. Client requests are routed to a virtual IP address for load balancing, then directed to a front-end server. The front-end servers contain two network interfaces. One NIC faces the Internet with a public IP address, and the other is on the private internal network. The back-end servers include the AD domain controllers (DCs), Global Catalog (GC) servers and DNS servers, Exchange mailbox and public folder servers, and any operations servers such as backup servers and management and monitoring servers. The back-end servers often have one NIC for the internal network and another network interface for the management and operations network.

The front-end/back-end architecture supports the Internet protocols POP3, IMAP4, SMTP (which both POP and IMAP use to send messages), and HTTP-DAV (for OWA). You must establish a separate VPN for Outlook messages, which use the Messaging API (MAPI) protocol.

ASPs use the front-end/back-end architecture for three main reasons: security, load balancing and fault tolerance, and scalability and performance. This architecture provides security because one firewall protects the front-end network, and a second firewall (e.g., Internet Security and Acceleration—ISA—Server 2000) protects the back-end network. Front-end servers act as a proxy for Internet-protocol traffic between the clients and the back-end servers. Traffic between the front end and the back end is over port 80; you can't change it to another port (say to Secure Sockets Layer—SSL—on port 443), so the only way to secure this traffic is to use IP Security (IPSec), as Figure 2 shows.

The second reason that ASPs use the front-end/back-end architecture is load balancing and fault tolerance. Clients connect to what's known as a unified namespace—that is, they connect to one domain name (e.g., mail.company.com) with no knowledge of the underlying infrastructure. The public name is mapped to any number of underlying servers, providing a measure of fault tolerance as well as the load balancing mentioned earlier. The front-end servers are considered stateless—any server can service requests for the unified namespace, unlike the familiar hard-coded mailbox server name in your Outlook profile—so you can rotate front-end servers in and out of service without affecting overall availability.

The third reason for using the front-end/back-end architecture is for scalability and performance. The white paper "Exchange 2000 for ISPs: 250,000 to 3,000,000 Subscriber Architecture Reference" (http://www .microsoft.com/exchange/techinfo/hosting/isparch.asp) describes Microsoft's use of the front-end/back-end setup to test Exchange's handling of a very large number of clients. Microsoft used 1U (1.75") rack-mount servers with one or two processors for the front-end POP3, IMAP4, SMTP, and HTTP-DAV servers and 4-way or 8-way back-end servers with high-performance fibre channel storage in a Storage Area Network (SAN) to achieve its scalability goals.

The Multitenant Directory
ASPs that use Exchange Server 5.5 for hosting several companies have no choice but to set up separate directories for each hosted company. Exchange 2000 lets you set up a separate directory (i.e., an AD forest) for each client and centrally manage these forests, but it also opens up the possibility of hosting multiple companies in the same directory, or forest. A multitenant (shared) directory is easier to manage, but can it work? And can it address ASP customers' security and availability concerns? ASPs prefer the shared model because it's more cost effective than separate directories (which require separate hardware), so the rest of this article and the other articles in this series assume this model and explain how to make it work.

Partitioning a directory can be a good idea for companies other than ASPs. Your company might buy another company, and the two merged companies might want to share a messaging system but not share all their directory information. You can set permissions on objects in AD so that when Outlook users search for an employee in the Global Address List (GAL), they see only the employees in their part of the merged company. This approach is different from Exchange 5.5's approach, in which the GAL contains everybody and you use Address Book Views (ABVs) to show portions of the GAL. In Exchange 2000, you can actually provide a separate GAL to each company and the companies have no idea that they're seeing a partitioned view.

A multitenant directory has a few disadvantages. All tenants in a forest must use the same format for displaying names in the address book—First Last or Last, First. The Microsoft article "XADM: How to Change Display Names of Active Directory Users" (http://support.microsoft.com/support/kb/articles/q250/4/55.asp) explains how to set the format.

A domain can have only one set of account policies, so for example, if two parties want different password lengths or password expiration dates, they need separate domains. Thus, you might need to set up separate domains for different divisions or an ASP might need to set up separate domains for different customers, but at least this problem is solvable.

A more difficult problem is with AD contacts. You can associate a given SMTP address with only one contact in a forest—in other words, two contacts can't have the same SMTP address. So, if one of your customers attempts to add the email address [email protected] for a contact, but another customer has already added it, the system will prevent the second entry and generate an error, leaving the customer to wonder why. You can use a scripting interface to enter two contacts with the same SMTP address, but outgoing mail addressed to those contacts will bounce. Exchange 2000 Service Pack 1 (SP1) was supposed to fix this problem, but it doesn't.

You might not run into this limitation, but you should be aware that AD allows a maximum of 800 values in a multivalued attribute, per forest. Multivalued attributes are easy to identify because Microsoft Management Console (MMC) typically presents them as drop-down lists. Two examples are user principal names (UPNs) and Offline Address Books. Thus, you can have up to 800 UPNs and up to 800 offline addresses per forest.

Setting Up Multiple Namespaces
In addition to maintaining a separate address list for each client company, an ASP must manage ID information for each user who must log on to Windows. Instead of asking users to remember a user ID, ASPs often let users type an email address to log on. The address should have the format [email protected], where userX is the user's logon name and companyX is the user's company name. The user shouldn't be aware that his or her real address is [email protected], where hoster is the name of the ASP. A company with multiple divisions might have a similar situation, in which users from each division want to be able to use the division name in their address rather than the company name.

To create customized logon names for all the users in a given organizational unit (OU), you need to create a namespace for that OU. To create a namespace, you define a UPN suffix that will be attached to the username to create the user logon name, or UPN.

To illustrate, I'll create a new logon namespace, separate from the domain name, for users in a division of a company. Let's say that you want the users in Division A to be able to log on as [email protected], even though that division has an awful legacy domain name—NTSHMINT—that's a holdover from Windows NT days. The first step is to add the DivisionA.com namespace as a UPN suffix to your AD forest. Open the MMC Active Directory Domains and Trusts console, right-click Active Directory Domains and Trusts, and select Properties. At the resulting dialog box, which Figure 3 shows, you can add one or more UPN suffixes. You must keep UPN suffixes short if you want UPNs to match users' pre-Windows 2000 logon names because pre-Win2K names are limited to 20 characters. If your logon names are 8 characters and the at symbol (@) is 1 character, you have only 11 characters for the UPN suffix, including the .com (or .edu or .org) extension. UPN suffixes are case insensitive.

(Note that Win2K supports UPN logons. Currently, Outlook 2000 doesn't support UPN logons, but Microsoft will soon have an update that adds this support. To enable UPN logon for the Exchange 2000 version of OWA, see the instructions in the sidebar "Enabling UPN Logon for OWA," page 3.)

Now, when you add a new user account, you can select the UPN suffix with which you would like the user to log on. Figure 4 shows how you manually select the UPN suffix for a user logon name. If you need to modify many existing user accounts, consider using an LDAP Data Interchange Format (LDIF) file import to replace the domain name with the UPN name in the UPN suffix. For information about how to use the Ldifde utility, see the Microsoft article "Using LDIFDE to Import/Export Directory Objects to the Active Directory" (http://support.microsoft.com/support/kb/articles/q237/6/77.asp).

Alternatively, you can use Microsoft or third-party AD provisioning tools to set the UPN suffix property. Provisioning tools is a fancy name for tools that automate the setup and management of user accounts; some of these tools also track system usage for billing purposes. I'll describe these tools in a future article.

Another option is to use the ADSI Edit utility to select each OU and eliminate UPN suffixes that don't apply to that OU. For more information about ADSI Edit, see Tony Redmond, "Introducing the ADSI Edit Utility," July 2000.

The nice thing about the UPN suffix property, aside from its independence from the underlying domain, is that you can search for it. The value of this searchability will become apparent in my next article, when I'll show you how to set up email addresses for users, but for now, you just need some background information. In AD, the OU is the container that you use to collect common users and groups under one administrative umbrella. You should use as few domains as possible—the OU, rather than the domain, is the administrative and security boundary. Thus, ASPs define OUs for each company that they host under a root OU for the ASP administrators. In fact, the Exchange 2000 and AD provisioning tools define the OU structure I just described. Unfortunately, you can't directly use OU membership to create address lists and set security on the address lists. However, you can use namespace membership for these purposes—for example, you can create an address list for all the logon names that use a given UPN suffix.

I've set up AD by defining a UPN suffix for Division A and associating it with the logon names of the users in that division, but I still need to set up [email protected] as a valid email address in Exchange. I'll show you how to do that next time.