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).
Prev. page
[1]
2
next page 
