Lesson 2: Integrating Exchange 2000 Server with Exchange Server 5.5 | MCSE Training Kit (Exam 70-225): Microsoft Exchange 2000 Server Design and Deployment (Pro-Certification)

Following the integration and synchronization of Exchange Server 5.5 with Active Directory, Exchange 2000 can be installed in the messaging organization. For seamless integration, it is vital to implement the new platform so that earlier versions can recognize it as part of their own environment. This sounds more complicated than it really is. Most important, the Exchange designer must be aware of certain restrictions and several interoperability issues that apply to Exchange 2000 Server in mixed mode. For instance, even though Exchange 2000 servers disguise themselves as computers running an earlier version and are displayed in the Exchange Administrator program just as any other server, you should not use this program to manage Exchange 2000 resources. Similarly, Exchange System Manager displays all servers running earlier versions as read-only to prevent you from configuring these systems using this utility. Regardless of seamless integration, system administration is not unified.

This lesson explains how Exchange 2000 Server and earlier versions can coexist. You can read how to add the new version to an existing messaging organization and learn about the mechanisms utilized to replicate configuration information, such as routing tables, between the systems. You will also learn about important mixed-mode limitations and interoperability issues.

After this lesson, you will be able to

List essential information required for adding Exchange 2000 Server successfully to an Exchange organization
Explain how configuration and public folder information is replicated between Exchange 2000 and earlier versions
Design a mixed Exchange organization to optimally support Exchange 2000 and Exchange users that need access to the same resources, such as messaging connectors, public folders, Microsoft Outlook Web Access (OWA) servers, and offline address books (OABs)

Estimated time to complete this lesson: 120 minutes

Exchange 2000 Server in Mixed Mode

Exchange 2000 Server can either operate in mixed mode for backward compatibility or in native mode for full functionality. The default is mixed mode to ensure that you can integrate the system with earlier versions. As long as previous Exchange Server versions exist in your organization, moving to native mode is impossible.

The mixed mode limits Exchange 2000 Server to the rules that apply to Exchange Server 5.5, as follows:

All servers in the same Exchange site must use the same service account.
Exchange sites are mapped to administrative groups and vice versa.
It is not possible to move mailboxes to servers in different administrative groups.
Public folders in the default hierarchy are mail-enabled by default.
Routing groups cannot contain servers from other administrative groups.
You cannot switch to native mode as long as computers running previous Exchange Server versions exist in the organization.

Installation Dependencies

Your project team has to complete several preparations to successfully install Exchange 2000 Server in an existing organization. For instance, you need to identify the Exchange site at which you want to add the new server. You must determine the Site Services Account used at this site and verify that this account is part of the Windows 2000 active directory. Keep in mind that all servers in an Exchange site must use the same service account for server-to-server communication based on remote procedure calls (RPCs), including the machines running Exchange 2000 Server.

Exchange 2000 requires the Site Services Account to reside in Active Directory. For this reason, you need to ensure that the PDC of the Site Services Account is upgraded to Windows 2000. It is also possible to clone this account using the Active Directory Migration Tool (ADMT). However, you should only rely on this approach if it is impossible to upgrade the PDC. Cloning requires you to reset the password of the Site Services Account manually in the Active Directory Users and Computers console, and you must set the password to never expire.

Note

You can verify the Site Services Account information in Exchange System Manager. Display the properties of the administrative group object that corresponds to your Exchange site, and then examine the settings in the General tab.

Topology Changes for Server Consolidation

If you intend to consolidate your messaging resources on fewer, more powerful Exchange 2000 servers, you need to keep in mind that certain mixed-mode restrictions may measurably limit your flexibility. In mixed mode, for instance, it is impossible to move mailboxes between administrative groups. Administrative groups are directly mapped to Exchange sites, so you cannot consolidate resources from different sites right away (see Figure 6.10).

Figure 6.10 - Moving servers to consolidate resources

You have two options: You can postpone the server consolidation until all servers in the environment run Exchange 2000 Server and then switch the organization to native mode and move the mailboxes across administrative group boundaries, or you can move the Exchange servers to the same site using the Move Server Wizard before you install the first Exchange 2000 server. Once Exchange 2000 Server is installed, the mixed-mode organization exists in Active Directory, and you should not use the Move Server Wizard any longer to move servers between sites in the same organization. It is not simple to use this wizard, so you may want to delay resource consolidation until the organization is switched into native mode. Nevertheless, if you decide to move servers between sites, give the Exchange Directory time to replicate the changes to all servers in the organization before you install Exchange 2000 Server. The Move Server Wizard is available in Service Pack 3 of Exchange Server 5.5 and later.

When adding Exchange 2000 Server to an existing Exchange organization, you need to

Log on using an account that is a member of the Domain Admins group.
Be a Permissions Admin in the Exchange site.
Know the Site Services Account name and password. The Site Services account must be part of the Windows 2000 Active Directory.
Have the right to extend the Active Directory schema (member of Enterprise Admins, Domain Admins, and Schema Admins groups) if you have not prepared the forest using Setup /ForestPrep yet.
Install Windows 2000 Server, including Simple Mail Transport Protocol (SMTP) and Network News Transport Protocol (NNTP) services and Windows 2000 Service Pack 1, on the target server. The target server must be a member of a Windows 2000 domain. Provided that you are not directly upgrading an Exchange Server machine (covered in Lesson 3), make sure that there are no databases in the \Program Files\Exchsrvr\Mdbdata directory.

Server-to-Server Communication

During the phase of coexistence, it is vital for all Exchange servers running any version to communicate with each other based on the mechanisms supported by Exchange Server 5.5. This implies that within a site, Exchange 2000 servers must use RPCs to communicate with those servers running earlier versions. The same is true for Routing Group connectors, which cause the local Exchange 2000 bridgehead to automatically switch to RPCs if messages must be transferred to a bridgehead in another site running Exchange Server 5.5 (see Figure 6.11). Message transfer between Exchange 2000 servers is not affected and always relies on the native communication mechanisms of Exchange 2000.

Figure 6.11 - Server-to-server communication between Exchange and Exchange 2000 Server

Mixed-Mode Routing Topologies

Especially in large sites, administrators may have fine-tuned the server-to-server communication to optimally use the underlying physical network. Exchange Server provides server locations for this purpose, but server locations are not available in Exchange 2000. In Exchange 2000, message transfer relies on the concept of routing groups, which in turn are unavailable to servers running previous versions of Exchange. It is important to note that in mixed mode, you cannot place servers from different administrative groups in the same routing group; nevertheless, it is possible to create multiple routing groups in a single administrative group (see Figure 6.12). You may want to implement additional routing groups in an administrative group to reflect the topology of server locations.

Figure 6.12 - Multiple routing groups in one Exchange site

Exchange servers will continue to transfer messages directly to all other servers in the site using RPCs regardless of the routing group topology. This implies that as long as your bridgehead servers run earlier versions of Exchange, message routing may not be optimal. Only the Exchange 2000 servers will strictly obey the routing group topology and be able to use link state information (LSI) for smart routing decisions. You can read more about the design of administrative and routing group topologies in Chapter 5, "Designing a Basic Messaging Infrastructure with Microsoft Exchange 2000 Server."

Directory Replication Between Exchange 2000 and Exchange Server 5.5

Both platforms must fully replicate their directory information with each other to achieve seamless coexistence, which requires a helper directory service on the Exchange 2000 server. This is the Site Replication Service (SRS), which is activated when you install the first Exchange 2000 server in a site or when you upgrade a directory replication bridgehead server. On all other Exchange 2000 servers, this service is deactivated by default.

You can think of the SRS as an Exchange Directory service for Exchange 2000 Server. In fact, the SRS contains much of the executable code of the former directory service, which ensures full compatibility. Within a site, SRS automatically replicates directory information using RPCs.

The relationship between SRS, the Active Directory, and the Exchange 5.5 directory service is illustrated in Figure 6.13. The SRS replicates directory information via e-mail messages with the Exchange 5.5 Directory, and automatically disables the replication to servers and bridgeheads as soon as they are upgraded to Exchange 2000 Server. The ADC handles synchronization between the SRS directory and the Active Directory. Finally, Exchange 2000 configuration information is stored in the Active Directory, providing all Exchange 2000 servers in a forest with synchronized configurations.

The SRS maintains a separate database named SRS.EDB to hold the Exchange Server 5.5 directory information. Clearly, this is not the Active Directory database. Hence, an additional component is required to synchronize the SRS with Active Directory, which is the ADC, as shown in Figure 6.13. After you run Setup, when SRS is installed in the Exchange site, an ADC configuration CA is created automatically for you to incorporate the SRS information into Active Directory and vice versa. Active Directory or SRS will then propagate the configuration information to all domain controllers in the forest or legacy Exchange servers in the site and remote directory replication bridgehead servers. The configuration CA object is read-only in the Active Directory Connector Manager console.

The SRS has the following characteristics:

The Name Service Provider Interface (NSPI) in the SRS is disabled to prevent Messaging Application Programming Interface (MAPI)-based clients from connecting to SRS and retrieving directory information from this service.
The SRS automatically disables the directory replication to servers in the site as well as bridgeheads in other sites as soon as they are upgraded to Exchange 2000 Server.
The SRS communicates with the ADC via LDAP to synchronize configuration information with Active Directory. If you are running Exchange 2000 Server on a domain controller, SRS automatically uses TCP port 379 to avoid port conflicts with Active Directory. If you have upgraded an Exchange Server installation on a domain controller directly, SRS continues to use the customized LDAP port of the former Exchange Directory.
The SRS is not supported in a Windows 2000 cluster configuration. Therefore, the first Exchange 2000 server or upgraded directory replication bridgeheads cannot be clustered servers.

Figure 6.13 - Directory replication between SRS, Active Directory, and Exchange Directory
The SRS maintains a separate database named SRS.EDB to hold the Exchange Server 5.5 directory information.
The SRS only exists in mixed mode.
The SRS replicates directory information only with previous Exchange Directories using RPCs or e-mail messages, just as the Exchange Directory service does.

Note

You should place the Exchange 2000 server running SRS close to the domain controller running the ADC configuration CA.

SRS Permissions

When installing or enabling the SRS, all existing Exchange 2000 administrators inherit the permissions to manage the SRS environment. Administrators who are granted permissions to the Exchange 2000 organization at a later time will not receive any permission in the SRS. These administrators will therefore not be able to manage the SRS unless you grant them permissions explicitly using the Exchange Administrator program. Connect to the Exchange 2000 server and grant the desired user accounts the appropriate rights at the organization, site, and configuration levels. You need the rights of a Permissions Admin to accomplish this step.

Exchange Server Interoperability Issues

Replication of configuration information between Exchange Server 5.5, SRS, and Active Directory is the basis for seamless system integration. Legacy Exchange servers will be able to locate and use resources on Exchange 2000 servers, and vice versa. However, several interoperability issues exist due to differences in system architectures. For instance, Exchange 2000 Server uses LSI from a link state table (LST) to make routing decisions, whereas Exchange Server 5.5 relies on a Gateway Address Routing Table (GWART). Moreover, Exchange Server 5.5 maintains security information in the Information Store to grant or deny users access to the resources, whereas Exchange 2000 Server uses Windows 2000 security mechanisms. Awareness of the differences can help to avoid interoperability problems during the production rollout.

Note

Test your system integration and upgrade plans carefully in a test lab and during the pilot phase before launching the production rollout. This allows your project team to locate and address interoperability issues.

Link State Table vs. Gateway Address Routing Table

For backward compatibility, Exchange 2000 Server generates a GWART and replicates it to the Exchange servers, so all users in the organization will be able to take advantage of Exchange 2000-specific connectors, such as an SMTP Connector linking the messaging organization to the Internet (see Figure 6.14). Among other things, this gives you the ability to decommission all instances of the Internet Mail Service (IMS) running on legacy Exchange servers. Perhaps even more important, Exchange 2000 Server will also read the routing information from the legacy Exchange servers and place this data in the LST. This allows Exchange 2000 to use any existing connectors, such as those not available in the product, including the Professional Office System (PROFS) Connector, the System Network Architecture Distribution Services (SNADS) Connector, or any third-party gateways.

All users in the organization can theoretically send messages via any existing connector. However, some connectors may be restricted in scope, which can present an interoperability issue.

Figure 6.14 - Connector coexistence in a mixed-mode Exchange organization

In Exchange Server 5.5, you can specify connector availability at three different levels: organization, site, and server location. Connectors with an organization-wide scope are available everywhere in the organization. Site-level connectors are restricted to the local Exchange site and Exchange 2000 routing group in which they exist. However, locally scoped connectors do not have a counterpart in Exchange 2000. Connectors with a local scope are available to all Exchange 2000 users in the routing group, which by default refers to the entire site. Perhaps the best way to address this issue is to create an additional routing group that corresponds to the Exchange 5.5 server location.

Note

Exchange 2000 Server supports connector scopes at the organization and routing group levels, but for locally scoped connectors no counterpart exists. Message routing may be inefficient as long as locally scoped connectors are in use on Exchange Server 5.5.

Synchronizing Public Folder Resources

In a mixed-mode organization, public folders can reside on Exchange Server, Exchange 2000 Server, or both, and all users can access them no matter where they are located. To provide all users with the same level of access to all public folders, you need to synchronize the complete set of public folder information.

In Exchange Server 5.5, public folders are always mail-enabled, meaning they have associated directory objects, although these are hidden from the address book by default. The legacy Exchange Administrator program, for instance, expects to find a directory object for every public folder in the organization. The directory objects allow you to send messages to public folders as to any other recipient in the organization. Exchange 2000 Server, operating in mixed mode, likewise mail-enables public folders for backward compatibility reasons.

If you create a public folder on an Exchange server, the associated public folder directory object exists in the Exchange Directory. If you create a public folder on an Exchange 2000 server, the directory object will exist in Active Directory instead. This means that without further measures, directory information will be inconsistent across both directories. Hence, for public folders to function properly in a mixed-mode organization, you need to synchronize the directory objects of all public folders between Exchange and Active Directory.

The Exchange 2000 ADC supports the synchronization of public folder directory objects based on public folder CAs. When you create a public folder CA, the ADC will automatically select the Windows 2000 OU and Exchange recipients’ container for you. You cannot change these settings. In Active Directory, public folder directory objects reside in an OU called Microsoft Exchange Systems Objects. In Exchange, these objects are in the recipients’ container. Public Folder CAs are always two-way CAs, and they are always primary for the connected Exchange organization. You need to create a separate public folder CA for each Exchange site, but only one CA should be configured as a primary CA for each connected Windows 2000 domain. It is not possible to configure public folder CAs between Exchange organizations. You can read more about the configuration of primary and nonprimary CAs in Lesson 1.

Note

Public folder CAs will synchronize public folder directory objects, but not the actual public folder hierarchy or the public folder contents.

Public Folder Coexistence

In the Information Store, public folders consist of two separate entities: a public folder hierarchy and the contents. Each of these is replicated differently across the organization. The hierarchy information (that is, the folder list) is propagated to all servers that hold a database associated with the hierarchy. The content, in contrast, is replicated only to those servers specified in the folder configuration. You can read more about public folder hierarchies and contents in Chapter 5, "Designing a Basic Messaging Infrastructure with Microsoft Exchange 2000 Server."

The MAPI-based hierarchy is associated with the public information store on every Exchange server and with the default public folder store on all Exchange 2000 servers. The MAPI-based hierarchy is therefore propagated across the entire organization. The contents, in turn, do not have to reside on the user’s public server for Outlook 2000 to access the information. If the user’s public server does not hold the data, it returns a referral list to the client to redirect it to a location that has the information available. The client may connect to an Exchange server or an Exchange 2000 server to access the contents, but both systems manage access to public folder resources differently (see Table 6.1).

Table 6.1 Public Folder Interoperability Issues

Interoper- ability Issue	Differences	Comments
Public folder permissions	Exchange Server 5.5 controls access to public folder resources based on distinguished names (DNs) of Exchange directory objects. Security information is stored in separate database tables in the public information store database. Exchange 2000 Server uses Windows 2000 ACLs to control access to public folders. ACLs are properties of the public folders in the hierarchy. No extra database tables are maintained.	Exchange 2000 Server must incorporate the legacy public folder permissions into Windows 2000 ACLs. If this process is not accom- plished or fails, the folder will not be visible to Outlook users connecting to the Exchange 2000 Server, as illustrated in Figure 6.15.
Public folder affinities	Exchange Server 5.5 stores affinities at the site level in a separate table (the affinity table) of the Exchange directory database. Public folder affinities are not transitive. Exchange 2000 Server uses the routing table to calculate public folder affinities. Every routing group connector (RGC) allows you to block access to public folders in other routing groups via the Do Not Allow Public Folder Referrals setting, and the connector cost value determines the affinity level. Public folder affinities are transitive.	Public folder affinities are not upgraded by default. You must reconfigure them manually after upgrading to Exchange 2000 Server. You can read more about the design of routing group topologies and public folder access strategies in Chapter 5, "Designing a Basic Messaging Infrastructure with Microsoft Exchange 2000 Server."

To give Exchange 2000 users access to public folders, the public folder hierarchy must be available on the users’ public Exchange 2000 server. This is the case because every public folder server will receive the complete list of all public folders from the other servers. The hierarchy replication is automatic and does not require anything extra, as long as RPC communication and e-mail transfer work. However, users connecting to an Exchange 2000 server will not be able to see Exchange Server 5.5 public folders, which may lead to confusion in the user community (see Figure 6.15).

The problem is not that the hierarchy was unavailable. The problem is that access permissions are not specified in Windows 2000 ACLs. Folder permissions are replicated as part of the hierarchy, but Exchange 2000 does not use them to grant or deny access to the resources. Exchange 2000 Server must convert this information into Windows 2000 ACLs to provide Exchange 2000 users with access to the contents. Unfortunately, this conversion can fail for several reasons. When this happens, an error is written to the server’s application event log and the folder remains invisible to Exchange 2000 users (see Figure 6.15). It is advisable to examine the event log after the installation of Exchange 2000 Server and correct the client permissions in the Exchange System Manager snap-in to ensure that the security information was upgraded successfully.

Security-related access problems may also arise at later times when users create new public folders on the Exchange server. For this reason, it is a good idea to relocate all public folders to an Exchange 2000 server early in the migration process. The Information Store of Exchange 2000 maintains the public folder ACLs, which gives all Exchange 2000 users access to the resources. Exchange 2000 also calculates public folder permissions and replicates this information as part of the public folder hierarchy to legacy Exchange servers.

Figure 6.15 - Accessing the public folder contents on an Exchange server

Note

The Exchange System Manager snap-in will always give you access to the complete list of public folders in the hierarchy, even though the folders may be invisible in Outlook 2000.

The upgrade of public folder permissions might fail in the following situations:

Accounts specified in public folder permissions do not exist in Active Directory.
Accounts specified in public folder permissions exist in Active Directory, but have no msExchMailboxSecurityDescriptor or msExchMasterAccountSID attribute. This can happen, for instance, if the ADC created disabled user accounts for resource mailboxes when these mailboxes have been specified in folder permissions. Enabling all user accounts with mailbox information in the Active Directory Users and Computers console avoids this problem.
Distribution lists specified in public folder permissions have been synchronized with universal distribution groups, but the automatic conversion into universal security groups fails (for instance, because the domain does not operate in native mode, as explained in Lesson 1). Exchange 2000 Server attempts to convert only those universal distribution groups that have been specified in public folder permissions.

More Info: To Ensure a Smooth Upgrade of Public Folder Security Settings

Microsoft recommends the following steps to upgrade public folders to Exchange 2000 Server:

Use the Exchange Administrator program to display the client permissions for existing public folders and document them carefully.
Use the Exchange Administrator program on the legacy Exchange server to check the Information Store/Directory consistency. Enable the option to remove unknown user accounts from public folders. Removing unknown accounts helps to prevent permission-related upgrade problems.
Install Exchange 2000 Server and configure public folder CAs to create public folder objects in Active Directory that correspond to the public folder objects in the Exchange Directory.
Use the Exchange System Manager snap-in to verify that the Exchange 2000 server has a complete list of all public folders in its MAPI-based hierarchy. Hierarchy replication is an automatic process, so you only need to make sure that the transfer of e-mail messages works, because hierarchy and public folder replication use e-mail as their transport mechanism.
Use the Event Viewer to check that the folder permissions were mapped correctly to Windows 2000 ACLs during the upgrade process. Check the application event log to find any errors logged for public folders.
Use the Exchange System Manager snap-in to check the public folder ACLs. Display the Permissions property sheet of the desired folder in the MAPI-based hierarchy, press Ctrl, and then click Client Permissions. This displays the Exchange 2000 ACLs in Windows 2000 format. If only the Anonymous Logon account is listed, you need to correct the configuration. Close the dialog box and click Client Permissions again, this time without pressing Ctrl. This launches the Client Permissions dialog box, which provides a consistent user interface with the Exchange Administrator program and Outlook 2000.
Use the Exchange System Manager snap-in to examine the directory rights and also check the administrative rights for users and groups who administer the public folders.
Use the Exchange System Manager snap-in to relocate the public folders to an Exchange 2000 public folder store. Click the Replication tab, add the Exchange 2000 server to the list of servers that hold a replica, and then remove the legacy Exchange servers. To assign configuration changes to all folders in a tree, you can propagate replication settings from parent containers to child folders.
For the MAPI-based hierarchy, in the Exchange System Manager snap-in, check the Client Permissions settings in the folder’s Permissions tab. Verify that your users have the correct access permissions.

Outlook Web Access Interoperability

Both Exchange Server 5.5 and Exchange 2000 Server provide an OWA client, but seamless interoperability is only achieved when public folders reside in Exchange 2000 Server. The Exchange Server 5.5 version of OWA relies on Collaboration Data Objects (CDO) version 1.2.1, whereas the new version of Exchange 2000 uses a completely different approach based on the Web Storage System (WSS). Because WSS is not available in previous versions, you cannot access public folder resources in Exchange Server 5.5 using the Exchange 2000 version of OWA. You can, of course, replicate Exchange Server 5.5 public folders to an Exchange 2000 server for access from the Exchange 2000 version of OWA. OWA 5.5, on the other hand, is able to access computers running both Exchange Server 5.5 and Exchange 2000 Server. Only alternate public folder hierarchies are unavailable to OWA 5.5 because CDO 1.2.1 is based on MAPI (see Table 6.2). Alternate public folder hierarchies are discussed in Chapter 5, "Designing a Basic Messaging Infrastructure with Microsoft Exchange 2000 Server."

Note

If your users need to work with OWA in a mixed-mode organization, deploy the legacy version included in Exchange Server 5.5. To support Exchange 2000 OWA, you must move your users’ mailboxes and all public folder resources to an Exchange 2000 server.

Table 6.2 Outlook Web Access Interoperability

	OWA of Exchange Server 5.5	OWA of Exchange 2000 Server
Alternate public folders	No	Yes
Mailbox on Exchange 2000 Server	Yes	Yes
Mailbox on Exchange Server 5.5	Yes	No
MAPI-based public folders on Exchange 2000 Server	Yes	Yes
MAPI-based public folders on Exchange Server 5.5	Yes	No

Note

You can use the PFADMIN.EXE utility from the Exchange 2000 Resource Kit to generate a list of public folder permissions. Make sure all users with access permissions exist in Active Directory before installing the first Exchange 2000 server.

Offline Address Book Interoperability

There are also significant differences in the implementation of OABs, which users can download to their Outlook clients to compose messages while disconnected from the server. Exchange Server 5.5 generates site-specific OABs from recipient information in the Exchange Directory; Exchange 2000 Server generates organization-specific OABs from Active Directory objects. There is no upgrade or synchronization of OABs between Exchange Server 5.5 and Exchange 2000.

Users with mailboxes on a server running an earlier version of Exchange can only download OABs generated by an Exchange 5.5 server. For this reason, as long as legacy Exchange servers exist in the administrative group, OABs cannot reside on an Exchange 2000 server. If you want to upgrade the server that holds the OABs, you need to move them to another Exchange server. To do so, open the Exchange Administrator program, display the properties of the DS Site Configuration object from the Configuration container of your site, click the Offline Address Book tab, and then specify another Exchange server in the Offline Address Book Server list box.

Directory Attributes Interoperability

Interoperability issues also exist in the attributes of recipient objects. The schema of the Exchange 5.5 Directory was not flexible enough to support customization. To address this issue, previous versions of Exchange Server support 15 custom attributes, which you can rename in the Exchange Administrator program (DS Site Configuration object, Custom Attributes tab). You can assign your recipients, such as mailboxes, additional information relevant to your organization, such as an employee ID.

Exchange 2000 Server supports legacy custom attributes via 15 extension attributes. The ADC can populate these attributes and you can change their values in the Active Directory Users and Computers console. Recipient objects, such as mailbox-enabled users, provide a Custom Attributes button in the Exchange Advanced tab. By design, you cannot rename the extension attributes because extension attributes exist for backward compatibility reasons only.

Active Directory provides a flexible database schema. If you find that the extension attributes do not meet your requirements for custom information, you can modify the schema to implement your own attributes. However, your attributes are not mapped to any Exchange Directory attributes by default. To synchronize the information correctly, you need to change the ADC matching rules, as explained in Lesson 1.

Note

Plan your custom attributes carefully. You need to modify the Active Directory schema to implement your attributes, which will cause a complete rebuild of all GCs. Remember that it is not possible to delete schema extensions. You can only deactivate them once they are implemented.

Developing a Coexistence Strategy for Wide World Importers

In preparation for the installation of Exchange 2000 Server, Wide World Importers has updated its Active Directory environment. Peter Waxman, Head of Communications Technology, deployed the Exchange 2000 ADC to synchronize Exchange recipient information with Active Directory. Distribution groups are created in a native-mode Windows 2000 domain.

Waxman set the following goals for the implementation of Exchange 2000 Server:

Wide World Importers plans to consolidate messaging resources on fewer, more powerful Exchange 2000 servers. However, resource consolidation across site boundaries will be postponed to focus on the actual integration of Exchange 2000 Server. Our concern is that moving Exchange servers between sites using the Move Server Wizard is a complex undertaking that will result in substantial directory replication traffic in our global backbone, which we intend to avoid. Consolidating servers from different sites is not a critical priority and can be accomplished after the last Exchange server is decommissioned and the organization is switched into native mode.
All our Site Services Accounts are Windows 2000 security principals because we have fully deployed Active Directory.
Wide World Importers will implement new and powerful computers for Exchange 2000 Server. We do not expect any problems with OABs, which can remain on the current servers until we decommission our Exchange 5.5 systems.
Initially, we will not place any connectors or mailboxes on the first Exchange 2000 server. However, we will replicate all public folders to the new machine to ensure that folder permissions are upgraded correctly. We need to configure a public folder CA for each of our Exchange sites.
We do not intend to replace our OWA servers yet; all users will continue to use OWA 5.5. For Exchange 2000 users, we will also deploy Exchange 2000 OWA. All public folders will be accessible on the first Exchange 2000 Server and are therefore available to the new OWA version. In case of problems, users can always switch back to OWA 5.5.
Currently, we use custom attribute 1 in Exchange Server 5.5 to specify cost center information for our employees. The custom attribute was renamed Cost Center. We are not familiar with Active Directory schema extensions yet, but Stuart Munson, System Administrator, Messaging, will be responsible for the development of an appropriate schema extension strategy. For the time being, we will synchronize our Cost Center attribute with the extensions attribute 1 in Active Directory.

Activity: Developing an Exchange/Exchange 2000 Server Coexistence Strategy

In this activity, you will develop a coexistence strategy for Adventure Works. Adventure Works has globally deployed Exchange Server 5.5 and is synchronizing Exchange recipient information with Active Directory.

Tip

You can use Figure B.18 in Appendix B as a guideline to accomplish this activity.

Scenario: Adventure Works

Adventure Works has globally deployed the Exchange 2000 ADC to synchronize Exchange Server 5.5 with Active Directory. Adventure Works’ current Windows 2000 and Exchange Server 5.5 environment is shown in Figure 6.9.

It is your task to develop an appropriate system integration strategy.

Adventure Works has not yet installed Exchange 2000 Server. For political reasons, the company intends to delegate the management of mailboxes to individual administrators in each domain. Would you recommend moving all Exchange servers into the same Exchange site to consolidate the server resources?
Adventure Works intends to install Exchange 2000 Server in the site of North America first. How many public folder CAs do you need to configure to fully synchronize public folder directory objects with Active Directory?
Adventure Works intends to upgrade the server VAC-02-EX. This server currently runs an IMS, which will be upgraded to an SMTP Connector. What else do you need to configure to allow the users in the Exchange organization to send and receive messages to and from the Internet?
VAC-02-EX holds OABs for the site of North America. DMZ-01-SMTP is an OWA server. What do you have to configure on both systems before you can install Exchange 2000 Server on VAC-02-EX?
Adventure Works does not utilize public folders very heavily. Only a few public folders exist on VAC-01-EX. You want to verify that public folder permissions are upgraded correctly. What do you have to accomplish after you install Exchange 2000 Server?

Lesson Summary

Your project team must clarify several important issues before implementing the first Exchange 2000 Server in the organization. For instance, the Site Services Account of the site where you plan to add the server must be part of the Windows 2000 Active Directory, and you must know its password. The project team should also clarify which servers to consolidate in the Exchange 2000 organization. In mixed mode, it is not possible to move resources from different sites or administrative groups to the same server. You may have to move servers using the Move Server Wizard before installing the first Exchange 2000 server. This is required if you want to merge separate Exchange organizations. It’s optional if you plan to consolidate servers from different sites in the same organization. Resources in the same organization can also be consolidated after the upgrade project, when the last Exchange server is decommissioned and the organization is switched into native mode.

On the first Exchange 2000 server installed at a site, the Setup program activates the SRS. This is also the case when upgrading directory replication bridgehead servers that replicate directory information with servers at other sites. The SRS is basically an Exchange 2000 implementation of the Exchange Directory service. It maintains Exchange 5.5 configuration information in its own database. An explicit configuration CA is required to replicate this information with Active Directory. The Setup program will create the ADC configuration CA automatically for you. A fast and reliable network connection should exist between the ADC and the SRS.

Besides configuration CAs, recipient and public folder CAs are also vital. Recipient CAs integrate Exchange Server 5.5 recipient information with Active Directory. Following the installation of Exchange 2000 Server, public folder CAs must be created to synchronize public folder directory objects. A public folder that has an associated public folder directory object is known as a mail-enabled public folder. In a mixed-mode Exchange 2000 organization, public folders must be mail-enabled for backward compatibility reasons.

Following the server installation, your project team must address several interoperability issues. Generally, all connectors are available to all users, but locally scoped connectors have no counterpart in Exchange 2000 and may require adjustments in the routing group topology. You also need to ensure that existing public folders are upgraded without problems. The conversion of folder permissions is an especially critical factor. Public folders are upgraded automatically when you install Exchange 2000 Server on an existing server. If you add a fresh server to the organization, permissions are upgraded when the public folder hierarchy is replicated to this server.