Hosting Email Services

Use Exchange 2000 and OWA to provide email services on a small scale

In an effort to make Exchange the platform of choice for ISPs, telephone companies, and other large organizations that derive revenue from selling or renting communications services to end users, Microsoft has given a lot of attention to Exchange Server's hosting capabilities. This goal is laudable: Many of Exchange 2000 Server's scalability and functionality gains came about in response to hosting customers' demands. But unless you work for a company such as AT&T or EarthLink, should you care about such capabilities? Actually, you should. Exchange 2000's email-hosting capabilities might be more useful to you than you think. For example, you can offer email services to business partners and key customers with whom you want to maintain high-quality communications. Or your organization might merge with one that doesn't use Exchange (small companies often use multiple, ISP-hosted POP accounts because they don't want the expense of acquiring and maintaining Exchange). Or you might want to offer limited messaging services to a spin-off, startup, or nonprofit organization that can't afford the expense of maintaining its own mail server. A simple yet secure method for providing email services under such circumstances is to use Secure Sockets Layer (SSL) with Outlook Web Access (OWA); see the sidebar "Why Host with OWA?" page 12, for a discussion of this choice. For simplicity's sake, let's examine the most common Exchange hosting configuration: one in which you provide only email services—not file, print, or Windows Terminal Services capacity—and in which users can't access your network remotely.

Topology Choices
You'll face several design challenges when you set up your hosting plan. The first, and probably foremost, is security. (Other design considerations revolve around scalability and reliability, but these aren't as important for small hosting environments as they are for large-scale hosting operations.) If you host services for another organization and accidentally expose information that the client wants kept private, at best the client will be upset. At worst, you'll be legally liable. This possibility argues in favor of careful security planning on your part. That planning will revolve around one key question: How will end users reach your Exchange servers?

The best solution is to use Exchange 2000's front-end/back-end configuration feature, which Microsoft added in large measure to provide hosting capabilities. In this type of configuration, users' mailboxes stay on a back-end server, which you can protect within your firewall. All user connections go to a front-end server, which contains no user data and needs only a few open ports to permit traffic to reach the back-end server. The front-end server essentially acts as a proxy for HTTP, POP3, Network News Transfer Protocol (NNTP), and IMAP4 traffic, as well as for these protocols' SSL-enabled equivalents. Front-end servers are essentially interchangeable: User mailbox data and Active Directory (AD) information reside elsewhere, so a failed front-end server is easy to replace. Because of these advantages and the scalability of front-end/back-end designs, Microsoft recommends using a front-end/back-end topology for hosted environments.

If you can't spare the hardware to establish this type of topology, you can set up hosted services by using an ordinary mailbox server. Make sure, however, that you open the proper ports through your firewall. When you offer only OWA with SSL, you can get by with only port 443 (HTTP Secure—HTTPS). This article discusses OWA with SSL, but Table 1 lists Exchange 2000's other key IP ports.

Setting Up
Whether you use a front-end/back-end setup or a single mailbox server, the process of setting up a hosted Exchange environment is fairly straightforward. The Microsoft Exchange 2000 Server Hosting Series (http://www.microsoft.com/technet/prodtechnol/exchange/plan/hostedexch/aspintro.asp) provides extensive documentation but includes a lot of complicated planning and design material that applies primarily to large hosting companies. To set up a hosted environment for a smaller organization, I suggest the following procedure.

First, set up your systems. You need a fully functional AD Global Catalog (GC) server and Exchange 2000 server (or servers). Make sure that basic Exchange functionality is working properly (e.g., you can send email to and receive email from internal and Internet recipients). Bring your servers up-to-date by installing the current Windows and Exchange service packs.

Next, set up AD for a hosted environment. This process limits root containers' access to accounts in your organization, thereby protecting your organization's configuration against tampering. Open the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in, and select View, Advanced Features from the snap-in's menu bar. Open the Builtin container's Properties dialog box, and go to the Security tab. Select the Authenticated Users group and clear the Read check box in the Permissions list's Allow column, then select the Everyone group and clear the Read check box. Repeat this process for the Computers, Domain Controllers, and Users containers. Click OK to close the Properties dialog box. These actions remove the Read access control entries (ACEs) for the two groups and prevent hosted users, whose accounts will belong to these groups by default, from gaining information about your top-level organization. (Don't be alarmed if you don't see these ACEs in the list on the Security tab; they might not exist for each container.)

Next, select the domain object for the domain in which you're going to host the new organizations. From the menu bar, select Action, New, Organizational Unit to create a new organizational unit (OU) to use as a top-level container for all your hosted organizations. This step is optional if you're going to host only one organization, but I recommend that you perform it regardless. Doing so gives you a place to centralize the OUs that you'll create for your hosted organization or organizations. Name this OU something like Hosting.

Create another top-level OU and name it something like Services or Master Security. Select the OU, then select Action, New, Group from the menu bar to open the New Object-Group dialog box. Name the group AllUsers, select the Global Group scope option and the Security Group type option, then click OK. Create a second global security group named AllAdmins. You need these groups to separate hosted users from native users (i.e., users from your organization). You'll put hosted users into the OUs you create and put native users in your original top-level Users container (or an equivalent OU within your organization).

Open the Hosting OU's Properties dialog box, and go to the Security tab. Clear the Allow inheritable permissions from parent to propagate to this object check box. When you receive a prompt asking whether you want to copy, remove, or cancel the existing permissions, click Copy. To prevent native users from accessing the OU, select the Authenticated Users group, then click Remove. Click Add to open the Select Users, Computers, or Groups dialog box. In that dialog box, select the AllUsers group, click Add, then click OK to close the dialog box. Click Advanced to open the Access Control Settings dialog box. Go to the Permissions tab, select AllUsers in the Permissions Entries box, then click View/Edit. Confirm that only the List Contents and Read All Properties check boxes are selected. Click OK to close the dialog box, then click OK to accept the changes.

Separating Hosted Users
In a typical hosted environment, you want to prevent users in one hosted OU from seeing information about other hosted OUs or your hosting organization. To set up these types of restrictions, use an account with Exchange Full Administrator rights to log on, then launch Exchange System Manager (ESM). Locate the All Address Lists object under the Recipients node. Open the object's Properties dialog box and go to the Security tab. Clear the Allow inheritable permissions from parent to propagate to this object check box. When ESM prompts you to choose whether to copy, remove, or cancel the existing permissions, click Copy. Select the Authenticated Users entry in the Security tab's Name list, then click Remove. Next, select and remove the Everyone entry. Click Add and add the AllUsers group, then give that group Read Properties, List Contents, and Open Address List permissions.

Next, delete the All Users, All Groups, All Contacts, and Public Folders address lists from the RecipientsAll Address Lists node in ESM. (You'll create OU-specific versions later.)

To set permissions on the default Global Address List (GAL), select the Default Global Address List object under the All Global Address Lists node. Turn off inheritance, copy the existing permissions, and remove the Everyone and Authenticated Users entries.

I suggest that you also use ESM to restrict permissions to modify top-level public folders and the Internet newsgroup hierarchy. (This restriction is a good idea whether or not you operate a hosted server because it prevents users from creating an excess of public folders at the top layers of your hierarchy.) First, locate the Public Folders container (under Administrative GroupsFolders). Open the container's Properties dialog box and go to the Security tab. (If you don't see the Security tab, see the Microsoft article "XADM: Security Tab Not Available on All Objects in System Manager" at http://support.microsoft.com/default.aspx?scid=kb;en-us;q259221 for instructions about accessing the necessary settings.) Click Add and add the All Users group to the top-level public folder hierarchy, then click Advanced to open the Access Control Settings dialog box. Click Add to add a Deny ACE for the Create Top Level Public Folders permission. Next, open the Internet Newsgroups object's Properties dialog box and go to the Permissions tab. Edit the permissions to assign the None role to the Default and Anonymous entries so that Default and Anonymous users have no permissions. Then, clear the Folder Visible check box.

Configuring OWA
By default, all users can access OWA through a standard URL (http://servername/exchange). However, you might prefer to force hosted users to go to an OU-specific virtual directory. Doing so is easy: Disable access to the default /Exchange virtual directory, then create a new, separate Microsoft IIS virtual server and add virtual directories to that virtual server.

First, open the MMC Internet Services Manager snap-in. Open the Exchange virtual directory object's Properties dialog box, go to the Virtual Directory tab, then clear the Read, Write, Script source access, and Directory browsing check boxes. Repeat this process for the Public virtual directory object.

To create the new virtual server, launch ESM, expand the HTTP object (under the target server's Protocols node), then right-click the Exchange Virtual Server object and select New Virtual Directory to create a new virtual HTTP server. Give the directory an appropriate name (e.g., the name of the OU whose mailboxes the virtual directory will serve), and select the Mailboxes for option in the Exchange Path section, as Figure 1 shows. If you permit basic authentication for your Web servers, use the Internet Services Manager (ISM) to set the directory's default authentication domain to "." To do so, open your Exchange server's Default Web Site object's Properties dialog box and go to the Directory Security tab. Click Edit in the Anonymous access and authentication control section to open the Authentication Methods dialog box. Click Edit in the Authenticated access section, then enter "" as the domain name.

When you're finished, use the same process to create a new virtual directory for each public folder. Use public somewhere in the directory name so that users will know what the directory is for.

Creating Hosted OUs
Now for the fun part: creating OUs for each of your hosted organizations. Open the Active Directory Users and Computers snap-in, and create an OU under the Hosting OU. I usually use the full domain name of the hosted organization (e.g., limestone-redcross.org) as the name for the new OU.

Create a global security group in the new OU. Give the group a name that shows that the group is for all users of that OU (e.g., [email protected]). When prompted, give the group an email address; remove the domain suffix (e.g., .org) from the address. Open the group's Properties dialog box and go to the Member Of tab. Click Add, select the AllUsers group, click Add, then click OK. This step is necessary so that the group that holds the user accounts will have permissions on the hosted organization's OU.

Open the new OU's Properties dialog box, go to the Security tab, and remove the Authenticated Users and Everyone groups. Add the new security group, then select the group and the Read check box in the Permissions list's Allow column.

Create a second global security group for the hosted organization's administrators; name this group something like [email protected]. Give the group an email address.

Right-click the new OU and select Delegate Control to launch the Delegation of Control Wizard. Use the wizard to delegate control over the OU to the new administrators' security group. Delegate the following tasks: Create, delete, and manage user accounts; Reset passwords on user accounts; Read all user information; Create, delete and manage groups; and Modify the membership of a group.

Open the MMC ADSI Edit snap-in and open the new OU's Properties dialog box. (Look for the OU object under Domain NCDC=yourDomain, dc=com, OU=hosting.) On the Attributes tab, which Figure 2, page 14, shows, select the uPNSuffixes attribute in the Select a property to view drop-down box, then add the domain name of the hosted OU in the Edit Attribute field. This action lets hosted users log on as user@domain instead of the old-style domainuser syntax. (For more information about using ADSI Edit, see Sean Daily's Windows & .NET Magazine article "The ADSI Edit Utility," http://www.winnetmag.com, InstantDoc ID 19626.)

Not Finished Yet
You've set up your Exchange server to permit access to a specified OWA virtual server, and you've created a container (i.e., the hosted OU) in which to put user accounts. But you still need to create the user accounts and configure the default address lists so that users in one hosted organization can't see the GAL of other organizations you host on the same server. I'll show you how to complete your hosting setup in my next article. In the meantime, I suggest that you review Chapter 8 of the Microsoft Exchange 2000 Server Hosting Series.