Microsoft Exchange 2000 Server Adminstrator's Companion
Let's take a brief look at some other issues surrounding coexistence between Exchange Server 5.5 and Exchange 2000 Server.
Proxy Address
After a server joins an existing Exchange site, the proxy address settings for addresses such as SMTP, X.400, cc:Mail, and Microsoft Mail are copied to a recipient policy for users in that administrative group. This ensures that the same proxy addresses are generated for all users in the administrative group. This policy cannot be removed, and it will be the highest-priority policy in the system, meaning that any other recipient policies that conflict with it will not be enforced.
Foreign E-Mail Connection
Because SRS replicates site and configuration information between the Exchange 5.x and Exchange 2000 systems, it is possible for users in one system to use a connector in the other system to send messages. For instance, Exchange 2000 Server does not ship with a connector for Professional Office System (PROFS). If you need connectivity between Exchange 2000 Server and a PROFS system, you'll have to retain an Exchange 5.x server and use its connector to send and receive messages with your Exchange 2000 organization. Exchange 5.x will act as the transport backbone in this situation.
Messages
Messaging works between Exchange Server 5.x and Exchange 2000 Server because Exchange 2000 Server retains an instance of the MTA in its default installation. Exchange 2000 Server does have its own version of the MTA, with the main difference being that the Exchange 2000 MTA uses LDAP to perform directory lookups, rather than the Directory API (DAPI) used by the Exchange 5.5 MTA.
If two or more Exchange 2000 servers are installed into the same site, they will detect each other automatically and use SMTP as their message transport. This allows them to take advantage of such features as the advanced queuing engine, routing, and link state algorithms. In addition, remember that SMTP is asynchronous and can operate at very low bandwidth.
TIP
If two or more Exchange 5.x sites exist with low bandwidth between them, you can use the SMTP routingin Exchange 2000 Server to your advantage. First, install an Exchange 2000 server into each site, and then increase the connector cost on the current Exchange 5.x site connectors. Subdivide your Exchange 5.x site, and place each Exchange 2000 server in its own routing group. Then create a routing group connector between the two routing groups. This path will now be available to the Exchange 5.5 servers, and they will use this new, low-cost path to route messages from one to the other.
The advantage of this technique is that it allows you to use the link state information and the asynchronous nature of SMTP to route messages between your Exchange 5.5 servers. Since SMTP is more tolerant of low bandwidth and high latency, you might find this to be a good method to reduce the number of nondelivery reports (NDRs) to your users and ensure a better transfer success rate over slow or unreliable connections.
User Data
When working in a mixed-mode environment, you need to consider a few issues related to private and public user data. One deployment issue is that of delegate access to another's private mailbox. In a mixed mode environment, delegate access can be established in Exchange Server 5.5 only when users are in the same private information store on a single server or when the delegate's mailbox and the origination mailbox are on different servers. The Emsmdb32 DLL will not allow delegate access between users' mailboxes if they reside in different mailbox stores on the same physical server.
You can replicate individual public folders between Exchange 5.5 and Exchange 2000, and clients can access either replica. This is because there is very little difference between public folders in the two systems. In addition, the public folder hierarchy is replicated between all versions of Exchange Server.
Recall that Exchange 2000 supports multiple public folder trees, whereas Exchange 5.5 has one monolithic tree. The default public folder tree in Exchange 2000, Public Folders, can be seen by MAPI clients, such as Microsoft Outlook. Other public folder trees cannot be seen by these clients.
The data content of a public folder can also be replicated between public folders, but note that permissions set in Exchange 2000 Server are not represented in Exchange 5.5. If you need to house secure information in your public folder trees in Exchange 2000, migrate the users who will need access to that information to Exchange 2000 as well, and then set up an independent tree and secure it accordingly.
Outlook Web Access
In Exchange 5.5, the rendering process of Outlook Web Access (OWA) occurs inside Internet Information Services (IIS), which retrieves the data from the information store and then renders it back to the client in the form of Active Server Pages (ASP). In Exchange 2000, this rendering takes place in the Exchange 2000 Information Store process. Because of this change, it is no longer possible to customize the ASP files to change the basic user interface. However, you can use the Exchange 2000 OWA component in other applications.
If you have applications that use customized ASP files in Exchange 5.5, consider making the Exchange 5.5 OWA the "front end" of an Exchange 2000 server. Users will make their HTTP calls to the Exchange 5.5 OWA, which will check the Exchange 5.5 directory for the requested data. That request will be forwarded to the Exchange 2000 server, where the data will be retrieved and sent back to the client via the Exchange 5.5 OWA server.