Special Considerations for Mixed-Mode Topologies
This topic discusses connection agreements only in the context of public folders. For a detailed explanation of mixed-mode topologies (topologies that include both Exchange Server 2003 and Exchange Server 5.5 servers), including how to set up Active Directory Connector (ADC) and how to work with connection agreements, see "Migrating from Exchange Server 5.5" and "Upgrading Mixed Exchange 2000 Server and Exchange Server 5.5 Organizations" in the Exchange Server 2003 Deployment Guide.
The connection agreements that are maintained by Active Directory Connector synchronize user and group information, public folder information, and other configuration information between the Exchange Server 5.5 directory and Active Directory. With this information in place, replication messages pass between Exchange Server 2003 servers and Exchange Server 5.5 servers in the same way that they do among Exchange Server 2003 servers.
Note
Exchange Server 5.5 servers can host replicas of folders from the Public Folders tree. They cannot host replicas of folders from general purpose public folder trees.
Connection Agreements and Public Folder Replication
All three types of connection agreements—configuration connection agreements, user connection agreements, and public folder connection agreements—are important to public folder replication.
Important
Exchange Server 5.5 does not support general purpose public folder trees. However, you can configure Exchange Server 5.5 servers to participate in the routing of replication messages for general purpose trees. To do this, you must add entries to the Exchange Server 5.5 directory for the general purpose public folder stores, in a special container called Exchange 2003 Configuration Objects.
Configuration Connection Agreements
Configuration connection agreements (Config CAs) replicate site and administrative group configuration objects between Exchange Server 5.5 and Active Directory. Exchange Setup creates Config CAs automatically. The following tables list important attributes that the Config CAs handle. These attributes are used in the replication of the Public Folders tree between Exchange Server 2003 and Exchange Server 5.5 servers.
Attributes that ADC replicates from the Exchange Server 5.5 Site-MDB-Config object to the Administrative Group object in Active Directory
| Exchange Server 5.5 | Active Directory | Description |
|---|---|---|
Site-Folder-Guid |
siteFolderGUID |
Identification of the site folders for this site. |
Site-Folder-Server |
siteFolderServer |
Name of the server that is responsible for hosting the site folders (usually the first server in the site or administrative group). |
Folders-Container |
msExchPfCreation |
Location in which to create the public folder's directory entries in Exchange Server 5.5. If this attribute is not present, the Recipients container is used. In Exchange Server 2003, the store reads this attribute on startup to determine what LegacyExchangeDN the store must use when a folder is created in Exchange Server 2003. Using this attribute, the public folder connection agreement will replicate the new folder back to the correct container in Exchange Server 5.5. |
Attributes that ADC replicates from the Exchange Server 5.5 Microsoft Public MDB object to a Public Folder Store object in Active Directory
| Exchange Server 5.5 | Active Directory | Description |
|---|---|---|
Obj-Dist-Name |
LegacyExchangeDN |
Tracks the public folder store's Exchange Server 5.5-compatible name. |
Email Addresses |
proxyAddresses |
Identifies the e-mail addresses for the public folder store. |
Home-MTA |
HomeMTA |
Replicates the Home-MTA to Exchange Server 5.5, so that Exchange Server 5.5 can route replication messages to Exchange Server 2003. |
Exchange Server 5.5 servers can route replication messages for general purpose public folder trees. The following table lists the attributes that make this function possible. These attributes are replicated from Active Directory to the Exchange Server 2003 Configuration Objects container in the Exchange Server 5.5 directory.
Attributes that are replicated from Active Directory to the Exchange Server 2003 Configuration Objects container in Exchange Server 5.5
| Active Directory | Exchange Server 5.5 | Description |
|---|---|---|
LegacyExchangeDN |
Modified Obj-Dist-Name |
The LegacyExchangeDN attribute does not map directly to the Obj-Dist-Name attribute. (Otherwise, the general purpose public folder store object would be in the same container as public folder store objects for the Public Folders tree.) Instead, the object is placed in the Exchange 2003 Configuration Objects container. |
LegacyExchangeDN |
X.500 Pilgrim Address |
Replicates to an additional X.500, or pilgrim, address. |
HomeMTA |
Home-MTA |
Replicates a HomeMTA value to Exchange Server 5.5, so that Exchange Server 5.5 can route replication messages to Exchange Server 2003. |
proxyAddresses |
Email Addresses |
Replicates the store's e-mail addresses to the store object in Exchange Server 5.5. |
Important
If you need to be able to use an Exchange Server 5.5 Internet Mail Connector (IMC) to replicate information for a general purpose public folder tree, you must configure an additional X.500 proxy address for the general purpose store object in the Exchange Server 5.5 directory. Use the Exchange Server 5.5 Obj-Dist-Name for the new proxy address.
User Connection Agreements
The user connection agreement replicates Exchange Server 5.5 mailboxes, custom recipients, and distribution lists to Active Directory users, contacts, and groups. Because these objects are used in public folder access control lists (ACLs), it is crucial that this information be replicated correctly.
Public Folder Connection Agreements
The public folder connection agreement replicates the public folder directory objects between Exchange Server 5.5 and Active Directory. In Exchange Server 5.5, all public folders have directory objects. In Exchange Server 2003, only mail-enabled public folders have directory objects. By default, in mixed mode, folders in the Public Folders tree are mail-enabled automatically.
Setting up public folder connection agreements can prevent the following problems:
Folders that are created on Exchange Server 2003 cannot be administered from Exchange Server 5.5 if they do not have a directory entry in the Exchange Server 5.5 directory. The Exchange Server 5.5 administrative program requires directory objects for all public folders.
Folders created on Exchange Server 5.5 that do not have an object in Active Directory generate errors if you administer them using Exchange System Manager. The folder has properties stating that it is mail-enabled, so Exchange System Manager tries to find the directory object for that folder. The error can be cleared and the folder can still be administered, but you encounter the error each time you work with the folder. Also, an administrator might again attempt to mail-enable the folder and create a separate object for the folder in Active Directory. In such a case, if a public folder connection agreement is put in place, there will be two directory objects for the same folder, and e-mail messages sent to the folder will be returned as undeliverable.
If folder objects are not replicated correctly, an administrator running DS/IS consistency adjuster on Exchange Server 5.5 can create folder objects in the Exchange Server 5.5 directory that do not correspond to the folder objects in Active Directory. In such a case, if a public folder connection agreement is put in place, there will be two directory objects for the same folder, and e-mail messages sent to the folder will be returned as undeliverable.
There might be a future need to send a folder in e-mail. If all of the Exchange Server 5.5 servers are removed by the time you need this functionality, there is no longer a place to replicate the directory objects from, so the folders have to be updated manually (or mail-enabled again by using a script).
Details of how public folder objects replicate between Active Directory and the Exchange Server 5.5 directory
| Exchange Server 5.5 to Active Directory | Active Directory to Exchange Server 5.5 |
|---|---|
Search for public folder objects in the Exchange Server 5.5 directory, starting from the Site level. This means that all containers are searched for public folder objects, not just the Recipients container. |
Search for public folder objects in the Microsoft Exchange System Objects container in Active Directory. This is the only Active Directory container that holds public folder objects. |
Public folder objects replicate to the Microsoft Exchange System Objects container in Active Directory. |
Public folder objects replicate into the Exchange Server 5.5 directory container that is indicated by the LegacyExchangeDN value (set by the store when the folder is created, based on the value of msExchPfCreation). Unless another container is specified, the object will be placed in the Recipients container. |
The Home-MTA and Home-MDB attributes are not replicated because they are meaningless to Exchange Server 2003. |
The HomeMDB and targetAddress attributes are not replicated because they are meaningless to Exchange Server 5.5. |
Avoiding Common Replication Problems in Mixed Mode
Many common problems with public folder replication in mixed mode can be traced back to two issues:
Where an ACL on a public folder in Exchange Server 5.5 contains a distribution list, the ACL on a replica of the folder in Exchange Server 2003 must contain an Active Directory security group. The conversions of the Exchange Server 5.5 distribution list to an Active Directory distribution group, and then to an Active Directory security group should be automatic if your topology is configured correctly. For more information, see "Types of Groups Used in Access Control Lists" later in this topic.
Where a public folder ACL contains a user, Exchange Server 2003 must be able to locate that user in Active Directory. When an ACL that has been replicated from Exchange Server 5.5 contains a user that no longer exists (or for some other reason Exchange Server 2003 cannot identify a matching user object in Active Directory), Exchange Server 2003 cannot process the ACL. Until the problem is resolved, only the folder owner is able to access the folder. For details, see "Unknown Users in Access Control Lists" later in this topic.
This section describes how to avoid these issues. For instructions about how to identify and resolve these problems when they occur, see Problems with Problems with Permissions in a Mixed Exchange Server 2003 and Exchange Server 5.5 Environment.
Types of Groups Used in Access Control Lists
Exchange Server 5.5 uses distribution lists for both message delivery and access control, whereas Exchange Server 2003 uses them only for message delivery. Exchange Server 2003 uses Active Directory security groups for access control. ADC replicates Exchange Server 5.5 distribution lists to Active Directory universal distribution groups (UDGs). When Exchange Server 2003 processes a public folder ACL and encounters a UDG, it immediately attempts to upgrade the UDG to a universal security group. The universal security group then replaces the UDG in the ACL.
Important
The UDG must be in a Microsoft Windows Server2003 or Microsoft Windows 2000 native-mode domain to allow Exchange Server 2003 to upgrade it to a universal security group. In a mixed Exchange Server 2003 and Exchange Server 5.5 environment, ADC displays a warning if you are replicating Exchange Server 5.5 distribution lists to a non-native-mode domain.
Exchange Server 2003 is not able to convert a UDG to a universal security group under the following circumstances:
The UDG resides in a mixed-mode Windows Server 2003 or Windows 2000 domain.
A universal security group was converted manually to a UDG.
The membership of the UDG has not been replicated to Active Directory.
Important
Avoid using UDGs as members of universal security groups. Exchange Server 2003 does not check to determine whether group members are groups that need converting. As a result, if a universal security group in an ACL has members that are UDGs, the UDGs are ignored and the ACL is not enforced correctly.
Unknown Users in Access Control Lists
An unknown user (sometimes referred to as a zombie user) is a user that is listed in an ACL, but that does not have an account. The most common way that this situation arises is as follows. While the topology was purely Exchange Server 5.5, an Exchange Server 5.5 user who had been granted permissions on Exchange Server 5.5 public folders was deleted. Later, the public folder replicates to Exchange Server 2003 with references to that user still in the ACL. Exchange Server 2003 cannot process the ACL because it cannot locate the user in Active Directory. Until the problem is resolved, only the folder owner will be able to access the folder. This protects the folder from access by users that have been explicitly denied permissions on the folder. Exchange Server 2003 will also log a 9551 event when it has set folder permissions to owner only. For more information about the 9551 event, and other events that might arise when you replicate information between Exchange Server 2003 and Exchange Server 5.5, see Troubleshooting and Repairing Exchange Server 2003 Store Problems.
For detailed information about how Exchange Server 2003 converts ACLs when folders replicate from Exchange Server 5.5 to Exchange Server 2003, see "Anatomy of Object Level Access Control" in Working with Store Permissions in Microsoft Exchange 2000 and 2003. In particular, see the subsection "Special Considerations for Coexisting Exchange 2000 and Exchange 5.5 Servers." The information in this technical article applies to both Exchange Server 2003 and Exchange 2000 Server.
The best way to avoid having unknown users is to run the Exchange Server 5.5 utility DS/IS consistency adjuster before you begin replicating public folders to Exchange Server 2003. This will clean unknown users from the ACLs.
In some circumstances, Exchange Server 2003 might treat unknown users in different ways:
If the folder has replicated from Exchange Server 5.5 before without problems but an unknown user suddenly appears in the ACL, Exchange Server 2003 ignores the unknown user and processes the rest of the ACL normally. The assumption in this circumstance is that a user has been deleted in Exchange Server 5.5, or a new user was added in Exchange Server 5.5 and has not yet been replicated to Active Directory. The problem should rectify itself on the next ADC replication interval.
If you have removed all of the Exchange Server 5.5 servers and switched Exchange Server 2003 to native mode, Exchange Server 2003 assumes that the user has been deleted and removes the unknown user from the ACL.
In some cases, you can set a registry key that tells Exchange to drop unknown users from the ACL while Exchange is in mixed mode. It is recommended that you only set this registry key when it is absolutely necessary (for example, if you have a small subset of unknown users, and they can all be safely eliminated from public folder ACLs). Otherwise, if the user was temporarily unknown because of a replication delay (as described in the preceding list), you will have lost the permissions information for that user.
Warning
Dropping unknown users means that if those users have Access or Deny permissions on public folders, those permissions might be lost. It is not recommended that you drop unknown users on a long-term basis.
For detailed steps about how to temporarily ignore unknown users on an Exchange Server 2003 server that holds public folder replicas, see How to Temporarily Ignore Unknown Users on an Exchange Server 2003 Server that Holds Public Folder Replicas.