Exchange 2000's Win2K Connections

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).

   Previous  [1]  2  3  Next