More Win2K interaction advice for a successful Exchange 2000 deployment

Microsoft Exchange 2000 Server is much more integrated with Windows 2000 than Exchange Server 5.5 is with Windows NT. As I explain in "Exchange 2000 and Win2K Interaction," January 2002, InstantDoc ID 23296, the success of your Exchange 2000 deployment can hinge on your understanding of this integration. In that article, I discuss Exchange 2000's reliance on Active Directory (AD) replication and File Replication Service (FRS), and I go through some of the processes involved in installing the Active Directory Connector (ADC) and your first Exchange 2000 server. You also need to understand how Exchange 2000 relies on Win2K's permissions model, the LocalSystem computer account, your AD forest organization, Global Catalog (GC) placement, DNS, and Microsoft IIS.

Role Play
Exchange 5.5's permissions model supports decentralized administration, which lets you exercise control at the site level and reflects the workgroup-centric nature of both NT and Microsoft Mail (MS Mail)—two of the primary design influences on Exchange's first generation. In essence, any user whose NT account has Administrator permission can carry out administrative Exchange 5.5 activities, such as installing new Exchange servers, for a site or the organization (depending on the level at which permission is granted).

In Exchange 2000, the focus moves from the site to the organization. This change has some significant results. Exchange 2000 and Win2K share the same permissions model, which revolves around Win2K ACLs. Both products use roles to gather sets of Win2K permissions, which you then allocate to users who need to perform different types of administrative operations. In theory, dealing with one set of permissions (as contained in a role) certainly seems simple, but in practice, the new model can complicate Exchange deployment.

Exchange 2000 lets you assign a user account or group one of three roles: Exchange Full Administrator, Exchange Administrator, or Exchange View Only Administrator. You can assign roles, and thus delegate control, at the administrative-group level (an administrative group being broadly equivalent to an Exchange 5.5 site) or at the organization level, in which case the account or group can work with objects in any administrative group in the organization. As the name implies, Exchange Full Administrator is the most powerful role. When you run /forestprep, the installation program assigns this role to your account. That account is initially the only one that holds the Exchange Full Administrator role, so you need to assign the role to the accounts of any other users when you want to act as full administrators across the Exchange organization. (For more information about running /forestprep, see "Exchange 2000 and Win2K Interaction.") An account holding the Exchange Full Administrator role at the organization level can install and remove servers, create or remove administrative groups, install the Key Management Server (KMS), and assign roles—including Exchange Full Administrator—to other accounts. In fact, the only users who can install, uninstall, or remove and reintroduce Exchange 2000 servers are users whose accounts have been allocated the Exchange Full Administrator role at the organization level. But because this role is so powerful, you should assign it—especially at that level—to as few accounts or groups as possible.

Small enterprises tend to have fewer people who set up servers and install software, so this change isn't a problem. But large companies must make a difficult choice: Assign the role to more users than is wise, restrict the number of people who can install Exchange, perform installations remotely from a central location, or grant the necessary permission on a short-term basis during installation. None of these options is entirely satisfactory.

Good Service
Exchange 5.5 uses a service account to permit Exchange services (e.g., the Information Store—IS, the Message Transfer Agent—MTA, Internet Mail Service—IMS) to log on and authenticate to the OS. A classic Exchange administrative mistake is to change the service account password through User Manager for Domains rather than through Microsoft Exchange Administrator. Doing so updates the password only in the SAM rather than in both the Exchange Directory Store and the SAM, so the services fail with a mismatched password the next time Exchange attempts to start.

By contrast, Exchange 2000 uses Win2K's built-in LocalSystem computer account to start and control Exchange services. Therefore, you don't need to worry about service account password problems, unless you run Exchange 5.5 servers in a mixed-mode organization on Win2K. In that case, the ADC and Site Replication Services (SRS) still use the Exchange 5.5 service account, so you must retain the account until you remove the last Exchange 5.5 server. You can't force Exchange 2000 to run its services under any account other than LocalSystem (e.g., you can't change the Exchange 2000 services to run under the service account used for Exchange 5.5). The Exchange services will fail to start if they detect that you've set them to run under a different account. For more information, see "Running Exchange Services from LocalSystem," http://www.exchangeadmin.com, InstantDoc ID 16371; also see the Microsoft article "XADM: Error 1069 Starting an Exchange 2000 Server Service" (http://support.microsoft.com/default.aspx?scid=kb;en-us;q271920).

Into the Forest
The link between the Exchange organization and the AD forest is yet another example of the growing integration between the email server and the OS. Installation of your first Exchange 2000 server updates the AD schema and adds an Exchange container to the schema's Configuration naming context (NC). Only one such container can exist, and it holds all the Exchange organization's details (e.g., servers, connectors). Therefore, you can have only one Exchange organization per AD forest. (By comparison, you can run as many Exchange 5.5 organizations within an NT domain or domains as you want.)

Most enterprises won't find this restriction to be a problem, but some companies might prefer to run multiple organizations within one forest. For example, application service providers (ASPs) might want to host multiple Exchange organizations within a forest, but this setup is impossible with Exchange 2000 and Win2K. If you currently support multiple Exchange 5.5 organizations, you must decide whether to run multiple AD forests (so that you can continue with multiple organizations) or to migrate all the Exchange 5.5 organizations into one Exchange 2000 organization.

If you choose the latter option, at least Microsoft has simplified the task. Exchange 2000 Service Pack 1 (SP1) includes a refreshed Move Server Wizard. You can use this wizard to move a server from an Exchange 5.5 organization into an Exchange 2000 organization, so performing the migration isn't too difficult—providing you've accomplished all the preliminary work, such as removing connectors and public folders. (Keep in mind that whoever installs the service pack needs access to the schema master. For more information about the schema master, see "Exchange 2000 and Win2K Interaction.")

GC Placement
If you've done any research about Exchange 2000 deployment, you realize the importance of properly placing GC servers in relation to your Exchange servers. (For an extended discussion of the topic, see "Learning from Exchange 2000 Deployments," November 2001, InstantDoc ID 22553.) Be sure you discuss this subject with your company's Win2K deployment team. Also, consider deploying Exchange 2000 SP2, which includes an updated version of the DSAccess component that greatly simplifies the process of getting information about GC and domain controller (DC) access. The new DSAccess is far more robust than the earlier version and is better at failover operations, so if you operate a distributed network of Exchange 2000 servers, upgrading to SP2 is worthwhile.

Another consideration that relates to GCs has to do with distribution groups. Each GC holds a complete copy of all objects in its domain, as well as a partial copy of objects in other domains in the forest. Therefore, a GC server is the only server that can successfully resolve the membership of a Universal Distribution Group (UDG), which is the AD equivalent of an Exchange 5.5 distribution list (DL). However, the only server that can expand a global distribution group is a DC of the domain that owns the group. (AD replicates the group object, but not the group membership, to every GC.) Thus, you can run into a situation in which one Exchange 2000 server can use a global distribution group but another can't. From Exchange 2000's perspective, nothing has gone wrong: Both Exchange servers expand the distribution group and send a message to its membership. The problem is that the server that connects to a GC that's also a DC of the group's owning domain can expand and send email to all recipients in the group; the server that connects to a GC in a different domain receives a blank membership list.

The lesson: Always use UDGs. To determine a group's scope or to upgrade a group, open the Microsoft Management Console—MMC—Active Directory Users and Computers snap-in. Select the group object and open its Properties dialog box. Ensure that the Group scope option (on the General tab) is set to Universal and that the Group type option is set to Distribution. (If the group is also used for security purposes, such as restricting access to a public folder, the Group type option needs to be set to Security. Doing so makes the group a Universal Security Group—USG—but in terms of email usage, a USG is the same as a UDG.) For more information about DLs in Exchange 2000, see Jason Seim, "Distribution Lists in Exchange 2000," http://www.exchangeadmin.com, InstantDoc ID 23480.

DNS Demands
Apart from Exchange 2000's obvious reliance on DNS to ensure that AD replication is accurate and timely, Exchange 2000 depends on DNS in two primary ways. First, when GCs and DCs boot, they register DNS SRV records in AD. Exchange 2000 interrogates AD to discover the most appropriate DCs and GCs to use to access AD information. (Whenever possible, Exchange uses DCs and GCs that are in the same Win2K site, so you should be sure to place servers in the correct sites.) You can use the Microsoft Exchange 2000 Server Resource Kit's Dsadiag utility to view the DC and GC information loaded in the directory cache, or you can use the MMC Exchange System Manager (ESM) console to view a selected server's properties and determine which GC the server is using. (If you use Exchange 2000 SP2, the server's Properties dialog box will include the Directory Access tab, through which you can access the new DSAccess component.) Second, although Exchange 2000 doesn't depend on DNS lookups to send messages within a routing group or across a Routing Group Connector (RGC), Exchange 2000 does rely on DNS to route SMTP traffic to external email servers.

Additionally, if you're interested in Exchange 2000 Instant Messaging, you need to update DNS with the necessary entries to let Instant Messaging clients and servers find each other. (For the details of this process, see "Exchange 2000 Server's Instant Messaging," November 2000, InstantDoc ID 15728.)

IIS Security
Exchange 2000 depends on Win2K's built-in Microsoft IIS to provide support for the Internet protocols (i.e., SMTP, IMAP, POP, HTTP, and Network News Transfer Protocol—NNTP) that non­Microsoft Outlook clients and applications use. Because of the close and dependent relationship between Exchange 2000 and IIS, you must ensure that you understand IIS and incorporate it into your Exchange 2000 deployment plan.

Out of the box, IIS isn't as secure as it can be—a situation that has led to several recent security problems, including some of the holes exploited by the Nimda virus. Microsoft provides tools to analyze servers for vulnerability and to lock down IIS against attacks such as Nimda. (See Microsoft's Security Web site at http://www.microsoft.com/security for the most recent information.) However, the IIS Lockdown tool is a little unyielding to use as is with Exchange—the tool stops components that depend on dynamic content, such as Outlook Web Access (OWA). The Microsoft article "XCCC: IIS Lockdown and URLScan Configurations in an Exchange Environment" (http://support.microsoft.com/default.aspx?scid=kb;en-us;q309508) explains the steps to open IIS up a little and permit Exchange 2000 to work properly.

Get It Together
You can go ahead with your Exchange 2000 or Win2K deployment in blissful ignorance of the products' effect on each other, but that decision means you'll end up patching and mending your infrastructure as the deployment proceeds. Instead, confer with your Win2K deployment team—before you begin installing Exchange 2000—about the questions in the sidebar "Get the Answers."

Thinking about Win2K interaction is a good idea even when you don't intend to run Exchange 2000, which is the first Microsoft enterprise application to take advantage of many of Win2K's new features. Other applications will surely do the same in the future, so learn from Exchange and be prepared to take these features—especially those that relate to AD and the Win2K permissions model—into account when planning any new application.