| CATEGORII DOCUMENTE |
| Asp | Autocad | C | Dot net | Excel | Fox pro | Html | Java |
| Linux | Mathcad | Photoshop | Php | Sql | Visual studio | Windows | Xml |
This appendix presents an overview of how Microsoft Exchange public folder replication works, how you can configure replicas, and how you can tune the replication process. Understanding the basic replication processes will help you to troubleshoot replication issues that are specific to your Exchange topology. (For information about common problems that may arise during public folder replication, see Appendix G, 'Troubleshooting and Repairing Store Problems.')
This appendix also provides recommendations for configuring public folder replication when you have a mixed-mode topology (a topology that includes servers running Microsoft Exchange Server 5.5), and describes how to use the Inter-Organizational Replication Tool to replicate information between two Exchange organizations.
When multiple public folder stores-each located on a separate server-support a single public folder tree, Exchange uses public folder replication to keep the stores synchronized.
Public folder content exists only in stores that are configured to have a replica of a specific folder. Content and hierarchy information are replicated separately. Each store keeps a copy of the hierarchy, which includes lists of which other stores hold content replicas of each folder. Content replicas exist only on the stores that you specify.
For each content replica in a public folder store, the store maintains a Replication State Table. A replica's Replication State Table stores the following information:
Basic information that is required to construct updates to the replica.
Information about the last update to the replica that originated in the local store, including the change number of the update.
Groups of updates that have been applied to all other known replicas of the folder. The updates in each group are identified by change numbers; the set of change numbers of all of the updates in a group is called a CNSet. Update information is passed from one store to another as part of the replication process.
By combining the lists of stores that hold content replicas and the information in the Replication State Tables, each public folder store can determine how up-to-date it is compared to the other stores that support the public folder tree. For information about how public folder stores use this information, see 'Status and Backfill Messages' later in this section.
When a folder or its contents are modified, the store that is hosting the replica that was changed e-mails the change to the other stores in the form of a replication message. Exchange routes the replication message the same way that it routes normal e-mail messages. For replication to work properly:
The Recipient Update Service must be able to stamp e-mail attributes on the store objects in the Microsoft Active Directory directory service (mail, proxyAddresses, and so on). Normally, Exchange automatically creates the recipient policies that the Recipient Update Service follows to update the store objects.
Exchange must be able to route e-mail between the replicating servers. Replication messages can be routed through different types of e-mail links (routing group connectors, X.400 connectors, and so on).
Note
The replication process uses the Active Directory attributes
of the public folder stores, not of individual public folders. The
Active Directory entries for individual public folders are only used to
send regular e-mail to or from the folders. Figure E.1 shows a public
folder store object in Active Directory. A public folder store object is configured
and maintained automatically, and resides in the Configuration
container in Active Directory.
Figure E.1 Public folder store objects in Active Directory
However, replication messages differ from normal e-mail messages in that Exchange treats replication messages as system messages. This means that replication messages are not bound by the normal restrictions that are applied to user e-mail messages, such as size and delivery restrictions. In the Exchange 5.5 Directory, replication messages were also system messages.
Table E.1 lists the different types of replication messages that Exchange uses.
Table E.1 Types of public folder replication messages and when they are used
|
Message type* |
When used |
|
Hierarchy (0x2) |
Replicates hierarchy changes from the local public folder store to all other public folder stores that support the same hierarchy. |
|
Content (0x4) |
Replicates content changes from one replica to all other content replicas of that folder. |
|
Backfill request (0x8) |
Requests missing data (in CNSets) from another store (both hierarchy and content change numbers). |
|
Backfill response (0x80000002 or 0x80000004) |
Sends missing data (in CNSets) to a store that requested missed updates. |
|
Status (0x10) |
Sends the current CNSets of a folder to one or more replicas of that folder (both hierarchy and content change numbers). |
|
Status request (0x20) |
Requests CNSets to be replicated, or status messages to be returned (both hierarchy and content change numbers). |
* The value in parentheses is the hexadecimal notation of the message type, which is used in events and logs. Use the hexadecimal value when you are troubleshooting replication issues. For more information about troubleshooting replication issues, see Appendix G, 'Troubleshooting and Repairing Store Problems.'
When a user modifies a public folder, the following process occurs on the server that holds the replica of the folder to which the user is connected:
The public folder store records the change, and checks the folder properties to determine which other servers hold a replica of that folder. If other replicas exist, the store determines what information needs to be replicated to them. This information becomes the 'update' to the replicas.
Public folder replication is object-based: if one property of an object is modified, the entire object must be replicated. The store that is replicating the change cannot assume that all of the receiving replicas are up-to-date, so it must send the whole object. The implications for the different types of replication are as follows:
Hierarchy replication If a new folder is created or if a folder property (such as its display name) is changed, the update includes all of the folder's properties.
Content replication If a new message is posted or an existing message is modified, the update includes the entire message and its properties.
The public folder store assigns a change number to the update.
When a folder replicates an update to another server, the change number is included with the update. The change number is then used by the receiving server to determine whether the update represents a new change, and also whether it is missing any data.
Change numbers are similar to the Update Sequence Numbers (USNs) used in Active Directory replication. However, in most other aspects, public folder replication is very different from Active Directory replication.
The public folder store 'packs' updates into a replication message. As indicated earlier, the change numbers of all of the updates in the message are referred to as a CNSet.
Along with the updates, the public folder store packs information from the Replication State Table of each folder, including the CNSets that were applied to the replica previously.
To reduce mail traffic, multiple hierarchy updates can be packed into a single replication message. Likewise, multiple content updates for the same folder can be packed into a single replication message. However, hierarchy updates cannot be packed into the same replication message as content updates.
The public folder store addresses the replication message to the other public folder stores that host replicas that are affected by the updates.
At the next scheduled replication cycle (which is determined by the replication interval set for the public folder store), the public folder store sends the message, along with any other messages that have been packed since the previous replication cycle.
The public folder store relies on Exchange's internal routing components to deliver replication messages. The store makes no attempt to split replication messages based on topology details. If the content of a folder is modified and it has five other replicas, a single replication message is generated and addressed to all five other stores. It is up to the routing components within Exchange to determine how to route and deliver the message.
When a public folder store receives a replication message, the following process occurs:
The public folder store 'unpacks' the updates from the replication message.
The store compares the change numbers to the list of change numbers that it already has and identifies the updates that have not been received previously.
The store applies the new updates to the appropriate folder replicas.
For each updated replica, the store updates the replica's Replication State Table with the change numbers of the current updates.
If the replication message indicates that other CNSets have been applied to other replicas of the folder but not to this store's replica, the store records that information as well and prepares to send a backfill request (as described in the next section).
A store sends a status message to another store to indicate the current state of a particular folder on the sending store. 'Backfilling' occurs when a public folder store determines that it has not received all of the updates for a replicated folder and must retrieve the missing updates from another store.
If a public folder store receives a status message regarding a folder that indicates that the sending store has more recent information about the folder, the receiving store creates a backfill request. If the change numbers are shown to be equal (or the change numbers on the receiving server are more recent), no action is taken.
A store sends a status request under the following circumstances:
It receives a hierarchy update that includes a change to the list of stores that hold replicas of a folder. For example, you used Exchange System Manager to add a store to the list or remove a store from the list.
A new store has started for the first time. This status request requires every known replica of the folder to respond. When all of the stores hosting these replicas have responded, the new store sends a backfill request to the 'best' of the known stores.
A store sends a status message under two circumstances:
In response to a status request sent by another store, as described previously. The status message is sent only to the requesting store.
Twenty-four hours after the most recent update to a folder was received, if there have been no subsequent updates. Each time the store receives an update for a specific folder, the timer is reset to 24 hours. This status message goes to the other public folder stores that have replicas of the updated folder.
The store follows a set schedule for checking whether status messages need to be sent. By default, this check runs at 00:15 and 12:15 Coordinated Universal Time (Greenwich Mean Time). As a result, after a folder has been updated, a status message may be sent as many as 36 hours later.
Figure E.2 depicts the basic sequence of events that is triggered when you add a content replica to a public folder store (adding the public folder store to the folder's replica list) in a simplified two-server scenario. Note that the sequence of steps depends on factors such as the timing of the replication intervals and the routing topology.
Figure E.2 The sequence of events when you add a replica to a public folder store
The details of the process are as follows:
Working on ExServ01, an Administrator adds ExServ01 to a folder's replica list.
ExServ01 sends out a hierarchy message.
ExServ01 sends a status request to ExServ02.
ExServ02 adds ExServ01 to the local copy of the folder's replica list.
ExServ02 sends a status message to ExServ01 that includes the full CNSet of the folder.
ExServ01 determines that all of the folder content is missing and creates a backfill request.
If the content is still missing when the backfill time-out elapses, ExServ01 sends a backfill request to ExServ02.
ExServ02 compiles the content messages and sends them to ExServ01.
ExServ01 uses the incoming content messages to update the folder content and related tracking information.
If change numbers still appear to be missing, ExServ01 waits 24 hours and then sends an updated backfill request. If a server other than ExServ02 is available, ExServ01 may send the request to that server.
Figure E.3 shows the sequence of events that is triggered when you remove a replica from a public folder store (removing the public folder store from the folder's replica list) in a simplified two-server scenario. Note that the sequence of steps would become more complex in topologies with more than two servers, and depending on how the delete command originates.
Figure E.3 The sequence of events when you remove a replica from a public folder store
The details of the process are as follows:
Working on ExServ01, an Administrator removes ExServ01 from a folder's replica list.
ExServ01 marks its replica (the copy of the folder on ExServ01) as 'delete pending'.
Clients can no longer access the folder using this store.
ExServ01 sends out a hierarchy message.
ExServ02 updates its copy of the folder's replica list to show that the folder is in the 'delete pending' state on ExServ01.
ExServ02 will no longer refer clients that are looking for this folder to ExServ01.
ExServ01 sends a status request to ExServ02.
ExServ02 sends a status message to ExServ01.
ExServ01 checks that the folder replica on ExServ02 contains all of the information that the 'delete pending' replica does. If it does not, ExServ01 returns to Step 5. Otherwise, ExServ01 continues with Step 8.
ExServ01 marks its replica as 'delete now'. The next maintenance cycle will remove the replica from ExServ01.
ExServ01 sends out a hierarchy message.
ExServ02 removes ExServ01 from its copy of the folder's replica list.
The following events may alert a public folder store to missing updates that need to be backfilled:
An incoming replication message contains CNSets for a specific folder, and the incoming CNSets are out of sequence with the CNSets that are listed in that folder's Replication State Table. The public folder store identifies the missing change numbers and packs them into a backfill request.
A public folder store starts for the first time. As described above, the new store sends out status requests to get information about the other stores in the hierarchy, and then prepares a backfill request.
An incoming hierarchy message indicates that a new content replica is to be placed in the public folder store. The store prepares a backfill request to get the content for the new replica.
To select a server (or servers) to use as a backfill source, Exchange first creates a list of all of the servers that have some portion of the necessary content, and then it sorts the list as follows:
According to the lowest transport cost. Servers in the same site have priority over servers in remote sites.
For servers with the same transport cost, sorts again according to newest Exchange version.
In Microsoft Exchange Server 2003, transport cost has greater importance in the selection criteria. This is a change from earlier versions of Exchange. In Microsoft Exchange 2000 Server and Exchange 5.5, servers running newer Exchange versions are selected over servers running older versions, regardless of the transport cost. For example, a server in a remote site running Exchange 2000 would be selected over a local server running Exchange 5.5.
For servers with the same transport cost and Exchange version, sort again according to the largest number of necessary changes that are available on the server. The backfill request will go to this server.
In previous versions of Exchange, a server that holds all of the necessary updates is chosen over a server that holds only some of the updates, regardless of transport cost. In Exchange 2003, this preference has been changed so that if some updates are available on a server with a lower transport cost, that server is selected to backfill those updates, even if the rest of the updates must be obtained from other (higher-cost) servers.
If one server does not have all of the needed changes, Exchange runs through this process again to select the server with the next largest number of changes. This process is repeated until all of the changes have been requested.
In previous versions of Exchange, if no single server could satisfy a backfill request, each separate backfill request would be held 24 to 48 hours before being sent. Using the new process, requests can be sent simultaneously to different servers after the initial 6-hour time-out (12 hours for sending requests to servers in remote sites). For more information about backfill time-outs, see Table E.2.
This process is faster and more efficient than that used by all versions of Exchange 2000 Server. Consider an Exchange 5.5 deployment of several sites (with multiple servers per site, all replicating public folders) that must be upgraded to Exchange 2003. Add one Exchange 2003 server to each site. In each site, the Exchange 2003 server backfills its public folders from the local Exchange 5.5 servers, rather than searching for a newer server in one of the remote sites.
After the store has created a backfill request, it holds the request for a specified length of time before sending it. If, in the meantime, the store receives an update that fills in the missing information, the request is discarded without being sent. Table E.2 lists the default backfill time-out values, which depend on where the request is to be sent and whether the request has been sent before.
Table E.2 Default time-outs used for backfill requests
|
Type of request |
Addressed to a store in the local site |
Addressed to a store in a remote site |
|
Initial backfill |
6 hours |
12 hours |
|
First backfill retry |
12 hours |
24 hours |
|
Subsequent backfill retries |
24 hours |
48 hours |
If the majority of folders in a specific public folder store contain information that rarely changes, you can schedule less frequent replication for all of the folders in the public folder store. However, if one folder contains time-critical information that is updated more often, you can set up more frequent replication intervals for that folder to ensure that all replicas remain current. You can also schedule replication during non-peak hours to reduce message traffic.
If all public folders are used with the same frequency, you can create one replication schedule for all of the folders by setting the schedule on the public folder store. After you set the store's schedule, all folders that are set to Default Schedule replicate according to the store's schedule.
To set a default replication schedule for a public folder store, use the Replication tab of the public folder store's Properties dialog box, as shown in Figure E.4.
Figure E.4 The Replication tab for a public folder store
Use the following options to set the replication schedule:
Replication interval Select a replication interval, or click Customize to display the Schedule dialog box, in which you can define the desired replication interval.
Replication interval for always (minutes) Use this setting if you use the Always Run setting for Replication interval. This interval is the number of minutes between replication cycles.
Replication message size limit (KB) Specify a size limit for the messages that Exchange uses to pass replication information from one server to another.
Important
Before you configure replication settings, you must first create
public folder stores on the servers to which you want to replicate. Associate
those stores with the public folder tree that contains the folder that you want
to replicate.
After you create multiple public folder stores for a public folder tree, you need to identify the folders to replicate to the stores. Folders are not replicated automatically. Use a public folder's Replication property tab (shown in Figure E.5) to configure which stores will have replicas of the folder, and how often replication will occur.
Figure E.5 The Replication tab for a public folder
In the Replicate content to these public stores section of the Replication tab, use the Add or Remove buttons to specify the public folder stores that should hold content replicas for this folder. The group of public folder stores that you specify is the folder's replica list.
By default, folders in a specific public folder store replicate according to the store's schedule. If you have a few folders that should replicate more often or less often than others, you can set a specific replication schedule for those folders. On the folder's Replication tab, you can use the Public folder replication interval drop-down list to set a replication interval of 2 hours or 4 hours, or you can click Customize to create a different schedule.
The Replication message priority setting determines the order in which replication messages for the specific folder are delivered to the target store (relative to replication messages that the target store receives from other sources). See Table E.3 for explanations of the settings that are available.
Table E.3 Priority settings for replication messages
|
Option |
Description |
|
Not urgent |
Messages with this priority are delivered last. |
|
|
Messages with this priority are sent before non-urgent messages; however, all urgent messages are delivered first. |
|
Urgent |
Messages with this priority are sent before messages with a priority of normal or not urgent. |
For actively updated information about a specific public folder's replication status, use the Replication tab in the left pane of Exchange System Manager (shown in Figure E.6). The Replication tab lists the servers that hold content replicas of the specific public folder, the replication status of each server, the last time a replication message was received, and the average transmission time. Use this information for performance monitoring.
Figure E.6 Replication tab of a public folder
You can also view this information by clicking Details on the Replication tab of the folder's Properties dialog box.
Table E.4 lists a number of additional time-outs and settings that control public folder replication. Values that you can modify are noted in the table; other values are for reference only. This information is provided to help you troubleshoot replication issues, especially if replication seems to take an unusual length of time.
Table E.4 Default time-outs and intervals that Exchange uses during replication
|
Replication event |
Default time-out |
Description |
|
Replication Expiry |
24 hours |
The frequency with which the store checks folders for expired information. |
|
Replication Send Always |
15 minutes |
The default 'Replicate Always' value, indicating how often the store checks to see whether it needs to replicate content. Can be adjusted using Exchange System Manager. |
|
Replication Send Folder Tree |
5 minutes |
The frequency with which the store checks to determine whether a hierarchy replication message needs to be sent. |
|
Replication Send Status Timeout |
24 hours |
The frequency with which the store checks to determine whether a status message for a folder should be sent. |
|
Replication Timeout |
5 minutes |
The frequency with which the store checks to determine whether any backfill time-outs have expired. |
|
Replication New Replica Backfill Request Delay |
15 minutes |
The length of time that the store delays before sending a backfill request for a new folder replica when the data is available in the same Exchange site. |
|
Replication Short Backfill Request Delay |
6 hours |
The length of time that a store delays before sending a backfill request when the data is available in the same Exchange site. |
|
Replication Long Backfill Request Delay |
12 hours |
The length of time that a store delays before sending a backfill request when the data is not available in the same Exchange site. |
|
Replication Short Backfill Request Timeout |
12 hours |
The time-out value that is used when trying to send a backfill request when the data is available in the same Exchange site. |
|
Replication Long Backfill Request Timeout |
24 hours |
The time-out value that is used when trying to send a backfill request when the data is not available in the same Exchange site. |
|
Replication event |
Default time-out |
Description |
|
|
Replication Short Backfill Request Timeout Retry |
24 hours |
The time-out value that is used when sending a backfill request when the data is available in the same Exchange site, and this request is a retry of a previous backfill request. |
|
|
Replication Long Backfill Request Timeout Retry |
48 hours |
The time-out value that is used when sending a backfill request when the data is not available in the same Exchange site, and this request is a retry of a previous backfill request. |
|
If you want to ensure that changes to public folders replicate without having to wait for the normal replication interval, you can start replication manually.
Important
Manual replication only affects changes that should already have
replicated at least once. Changes made after the last replication message was
sent are not included.
Exchange provides two commands for this purpose:
Send Hierarchy
This command is available on the Action menu in Exchange System Manager for public folder trees, for individual public folders that have subfolders, or for public folder stores. This command replicates hierarchy changes (including changes in the tree structure or changes in folder properties).
Send Contents
This command is available on the Action menu in Exchange System Manager for individual public folders.
When you use these commands, Exchange prompts you to select one or more source and target servers, and to specify a range of changes to replicate. The range of changes to replicate starts the number of days in the past that you specify and ends at the last replication cycle. For example, you can replicate all changes made over the past two days, except for any changes made since the last replication cycle.
This section discusses connection agreements only in the context of public folders. For a detailed explanation of mixed-mode topologies (topologies that include both Exchange 2003 and Exchange 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 book Exchange Server 2003 Deployment Guide ( www.microsoft.com/exchange/library
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 5.5 Directory and Active Directory. With this information in place, replication messages pass between Exchange 2003 servers and Exchange 5.5 servers in the same way that they do among Exchange 2003 servers.
Note
Exchange 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.
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 5.5 does not support general-purpose public folder
trees. However, you can configure Exchange 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 5.5 Directory for the
general-purpose public folder stores, in a special container called Exchange 2003 Configuration Objects.
Configuration connection agreements (Config CAs) replicate site and administrative group configuration objects between Exchange 5.5 and Active Directory. They are created automatically by Exchange Setup. Tables E.5 and E.6 list important attributes that are handled by the Config CAs. These attributes play a part in replication of the Public Folders tree between Exchange 5.5 and Exchange 2003 servers.
Table E.5 Attributes that ADC replicates from the Exchange 5.5 Site-MDB-Config object to the Administrative Group object in Active Directory
|
Exchange 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 (normally 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 5.5. If this attribute is not present, the Recipients container is used. In Exchange 2003, this attribute is read by the store on startup to determine what LegacyExchangeDN must be used by the store when a folder is created in Exchange 2003. Using this attribute, the public folder connection agreement will replicate the new folder back to the correct container in Exchange 5.5. |
Table E.6 Attributes that ADC replicates from the Exchange 5.5 Microsoft Public MDB object to a Public Folder Store object in Active Directory
|
Exchange 5.5 |
Active Directory |
Description |
|
Obj-Dist-Name |
LegacyExchangeDN |
Tracks the public folder store's Exchange 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 5.5, so that Exchange 5.5 can route replication messages to Exchange 2003. |
As stated previously, Exchange 5.5 servers can route replication messages for general-purpose public folder trees. Table E.7 lists the attributes that make this function possible. These attributes are replicated from Active Directory to the Exchange 2003 Configuration Objects container in the Exchange 5.5 Directory.
Table E.7 Attributes that are replicated from Active Directory to the Exchange 2003 Configuration Objects container in Exchange 5.5
|
Active Directory |
Exchange 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 5.5, so that Exchange 5.5 can route replication messages to Exchange 2003. |
|
proxyAddresses |
Email Addresses |
Replicates the store's e-mail addresses to the store object in Exchange 5.5. |
Important
If you need to be able to use an Exchange 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 5.5 Directory. Use the
Exchange 5.5 Obj-Dist-Name for the new proxy address.
The user connection agreement replicates Exchange 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.
The public folder connection agreement replicates the public folder directory objects between Exchange 5.5 and Active Directory. In Exchange 5.5, all public folders have directory objects. In Exchange 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 future problems in the following ways:
Folders that are created on Exchange 2003 cannot be administered from Exchange 5.5 if they do not have a directory entry in the Exchange 5.5 Directory. The Exchange 5.5 administrative program requires directory objects for all public folders.
Folders created on Exchange 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 must deal with the error each time you work with the folder. Worse, an administrator may attempt again 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 ever put in place, there will then be two directory objects for the same folder and e-mail 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 5.5 can create folder objects in the Exchange 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 ever put in place, there will then be two directory objects for the same folder and e-mail that is sent to the folder will be returned as undeliverable.
There may be a future need to e-mail a folder. If all of the Exchange 5.5 servers are removed by the time you need this functionality, there is nowhere to replicate the directory objects from anymore, so the folders have to be updated manually (or mail-enabled again by using a script).
Table E.8 Details of how public folder objects replicate between Active Directory and the Exchange 5.5 Directory
|
Exchange 5.5 to Active Directory |
Active Directory to Exchange 5.5 |
|
Search for public folder objects in the Exchange 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 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 (they are meaningless to Exchange 2003). |
The HomeMDB and targetAddress attributes are not replicated (they are meaningless to Exchange 5.5). |
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 5.5 contains a distribution list, the ACL on a replica of the folder in Exchange 2003 must contain an Active Directory security group. The conversions of the Exchange 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. See 'Types of Groups Used in Access Control Lists' later in this appendix.
Where a public folder ACL contains a user, Exchange 2003 must be able to locate that user in Active Directory. When an ACL that has been replicated from Exchange 5.5 contains a user that no longer exists (or for some other reason Exchange 2003 cannot identify a matching user object in Active Directory), Exchange 2003 cannot process the ACL. Until the problem is resolved, only the folder owner is able to access the folder. See 'Unknown Users in Access Control Lists' later in this appendix.
The rest of this section describes how to avoid these issues. For instructions about how to identify and resolve these problems when they occur, see 'Problems with Permissions in a Mixed Exchange 5.5-Exchange 2003 Environment' in Appendix G, 'Troubleshooting and Repairing Store Problems.'
Exchange 5.5 uses distribution lists for both message delivery and access control, whereas Exchange 2003 uses them only for message delivery. Exchange 2003 uses Active Directory security groups for access control. ADC replicates Exchange 5.5 distribution lists to Active Directory universal distribution groups (UDGs). When Exchange 2003 processes a public folder ACL and encounters a UDG, it immediately attempts to upgrade the UDG to a universal security group (USG). The USG then replaces the UDG in the ACL.
Important
The UDG must be in a Microsoft Windows 2000 or Windows
ServerT 2003 native mode domain to allow Exchange 2003 to upgrade it
to a USG. In a mixed Exchange 2003/Exchange 5.5 environment, ADC
displays a warning if you are replicating Exchange 5.5 distribution lists
to a non-native-mode domain.
Exchange is not able to convert a UDG to a USG under the following circumstances:
The UDG resides in a mixed-mode Microsoft Windows 2000 or Windows Server 2003 domain.
A USG 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 USGs. Exchange does not check to
determine whether group members are groups that need converting. As a result,
if a USG in an ACL has members that are UDGs, the UDGs are ignored and the ACL
is not enforced correctly.
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 if, sometime while the topology was pure Exchange 5.5, an Exchange 5.5 user was deleted, but the user had been granted permissions on Exchange 5.5 public folders. At some later time, if the public folder replicates to Exchange 2003 with references to that user still in the ACL, Exchange 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 may have been explicitly denied permissions on the folder. Exchange 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 may arise when you replicate information between Exchange 5.5 and Exchange 2003, see Appendix G, 'Troubleshooting and Repairing Store Problems.'
For detailed information about how Exchange converts ACLs when folders replicate from Exchange 5.5 to Exchange 2003, see 'Anatomy of Object Level Access Control' in the Exchange technical article ' Working with Store Permissions in Microsoft Exchange 2000 and 2003' ( https://go.microsoft.com/fwlink/?LinkId=18612 ). 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 2000 and Exchange 2003.
The best way to avoid having unknown users is to run the Exchange 5.5 utility DS/IS Consistency Adjuster before you begin replicating public folders to Exchange 2003. This will clean unknown users from the ACLs.
In some circumstances, Exchange 2003 may deal with unknown users in different ways:
If the folder has replicated from Exchange 5.5 before without problems but suddenly has an unknown user in the ACL, Exchange 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 5.5, or a new user was added in Exchange 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 5.5 servers and switched Exchange 2003 to native mode, Exchange 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 first bullet point 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 may be lost. It is not
recommended that you drop unknown users on a long-term basis.
Warning
Incorrectly editing the registry can cause serious problems that
may require you to reinstall your operating system. Problems resulting from
editing the registry incorrectly may not be able to be resolved. Before editing
the registry, back up any valuable data.
To temporarily ignore unknown users, on an Exchange 2003 server that holds public folder replicas, set the following registry key and then restart the Microsoft Exchange Information Store service:
HKLMSystemCurrentControlSetServicesMSExchangeISParametersSystemIgnore zombie users = <nonzero value>
This is a DWORD value. If the value is zero or if the key is not present, Exchange 2003 handles unknown users normally.
You can share public folder and free and busy information between two or more organizations in different Active Directory forests using the Inter-Organization Replication Tool. You can download the Inter-Organization Replication Tool from the Exchange Server 2003 Tools and Update Web site ( https://www.microsoft.com/exchange/2003/updates ). The utility package contains two applications:
Microsoft Exchange Server Replication Configuration utility (exscfg.exe)
Microsoft Exchange Server Replication Service (exssrv.exe)
This package also contains documentation that describes how to set up inter-organizational replication. For more information about inter-organizational replication, see the book Exchange Server 2003 Deployment Guide ( www.microsoft.com/exchange/library
After you have configured the Exchange organizations, you can use this utility to coordinate meetings, appointments, and contact information between the members of the two organizations. As shown in Figure E.7, the inter-organizational replication process involves one Exchange server in each forest. One server acts as a publisher and sends information to the second server (the subscriber).
Figure E.7 Using publisher and subscriber servers to replicate information between forests
To configure the Inter-Organization Replication Tool, follow the instructions provided in the readme file that accompanies the tool. When you've finished the configuration process, you will have the following:
At the first level of both the publishing public folder tree and the subscribing public folder tree, a public folder named ExchsyncSecurityFolder
For each first-level public folder in the publishing tree that you want to replicate, a corresponding target folder in the subscribing tree (subfolders in the subscribing tree will be created automatically).
A mailbox-enabled account that has the following:
Local administrator rights on both the publisher server and the subscriber server.
Owner permission on both copies of ExchsyncSecurityFolder
Owner permission on the folders to be replicated and the corresponding target folders.
Session configuration settings for one Free and Busy replication session.
Session configuration settings for one or more public folder replication sessions. If you need to tune your replication traffic, you can create public folder sessions that replicate at different times and at different intervals.
|
Politica de confidentialitate | Termeni si conditii de utilizare |
Vizualizari: 1360
Importanta: 
Termeni si conditii de utilizare | Contact
© SCRIGROUP 2024 . All rights reserved
