Exchange public folders replication

Ok : http://technet.microsoft.com/en-us/library/bb123619(EXCHG.65).aspx


double check :
http://www.msexchange.org/articles/Public-Folder-Replication-Troubleshooting.html


There are two main elements regarding public folders, namely the hierarchy and the content. To put it a basic way, the public folder structure that you see in Outlook is the hierarchy, whilst what’s actually stored in those folders is the content. Well, that’s fairly straightforward, so let’s get a bit more in-depth.

The first area to check when troubleshooting any public folder replication issues is the status of the hierarchy. For example, let’s say that you’ve installed a new Exchange server into an existing Exchange organization and you suspect that this new server has not been sent a copy of the hierarchy. In this case, the first thing you need to check is whether the public information store on the new server is correctly configured with an email address. Both public folder hierarchy and content changes are sent between Exchange servers via email messages, so it therefore follows that if the public information stores email each other, they’ll need an email address as well as a working email path between them. It’s the job of the Recipient Update Service (RUS) to ensure that objects are stamped with correct email addresses, and this includes the public information store. The first thing you should therefore check is the public information store’s email address which can be performed with ADSIEdit. You’ll find that ADSIEdit is installed as part of the Windows 2003 Support Tools.

With the ADSIEdit snap-in open, right-click ADSI Edit and choose the Connect to… option. In the resulting Connection Settings window, ensure that the naming context is set to Configuration and then click OK. This will then bind to the configuration naming context allowing you to navigate your way down to the public information store. You will therefore need to work your way down the tree accordingly:

CN=Configuration, DC=domain, DC=com
CN=Services
CN=Microsoft Exchange
CN={your Exchange organization name}
CN=Administrative Groups
CN={relevant administrative group}
CN=Servers
CN={relevant Exchange server}
CN=InformationStore
CN={relevant storage group}.

In the example in Figure 1 below, you can see that I’ve navigated my way down to the First Storage Group on the server DCEXCH1.


Figure 1: Public Store Location Using ADSIEdit

Now what you do is to right-click the public folder store shown in the right-hand pane and choose Properties from the context menu. In the resulting property window, find the proxyAddresses attribute and click the Edit button. This will bring up a similar window to the one shown below in Figure 2. Here you can see an example of a public information store that has been correctly stamped with both SMTP and X.400 email addresses; if there were no values in the proxyAddresses attribute, we’d instantly know that the RUS has not run against this store and would therefore need to start troubleshooting the RUS. Note that it’s the enterprise RUS and not the domain RUS that is responsible for stamping email addresses on system objects like the public information store, so make sure you’re looking at the correct one.

During my early migrations from Exchange 5.5 to Exchange 2000, I remember that one of the most common reasons for the RUS not stamping email addresses on new Exchange 2000 servers was due to a missing proxy address generator, such as those used by fax gateways for example. Other common reasons included invalid domain controllers or Exchange servers listed in the properties of the RUS. Check out the Links section at the end of this document for some useful links for troubleshooting RUS issues. One other thing worth noting is the format of the SMTP address assigned to the public store: servername-IS@domain.com. There will be more on the significance of this later in this article.


Figure 2: Public Store Email Addresses

I mentioned earlier that as far as public information stores are concerned, they need both an email address and a valid message path in order for the replication messages to be successfully sent and received. As far as the valid message path is concerned, note that it’s a good idea to check whether you have any transport links that disallow system messages. This check process can be made really easy by using the Winroute tool. For more information on using Winroute, see the Links section at the end of this article.

Replication Messages
Increasing the diagnostics logging level of your Exchange server is always useful when troubleshooting issues. Diagnostics logging levels can be set for the MSExchangeIS Public Folder object found on the properties of an Exchange server object in Exchange System Manager. In the case of public folder issues, I’ve seen many Microsoft PSS professionals in mailing lists and newsgroups recommended to set the diagnostics logging categories shown below in Table 1 on both the source and destination servers involved in the replication process. Doing so will allow you to get a clearer picture of what is happening during the replication process. For this article, we’re going to concentrate mainly on the replication incoming and outgoing categories.


Category
Logging Level

Replication AD Updates
Maximum

Replication Incoming Messages
Maximum

Replication Outgoing Messages
Maximum

Non-Delivery Reports
Maximum

Replication Backfill
Maximum

Replication General
Maximum

Replication Errors
Medium

Table 1: Recommended Diagnostics Logging Settings

Once logging has been set, the application event logs on both source and destination servers should then begin to produce more detailed information about the replication messages as and when those messages begin to flow. There are several different types of replication message. Table 2 below shows the message type, purpose, direction of message flow and additionally the associated event ID.


Type
Purpose
Direction
Event ID

0x2
Hierarchy Replication
Outgoing
3018

Incoming
3028

0x4
Content Replication
Outgoing
3020

Incoming
3030

0x8
Backfill Request
Outgoing
3014

Incoming
3024

0x80000002

0x80000004
Backfill Response (Hierarchy)

Backfill Response (Content)
Outgoing
3019

Incoming
3029

0x10
Status Replication
Outgoing
3017

Incoming
3027

0x20
Status Request
Outgoing
3017

Incoming
3027

Table 2: Message Types

Let’s take the first message type, the hierarchy replication message, as an example. If you create or delete a public folder, or perhaps change that folder’s permissions, a hierarchy replication message will be generated from the source server to the destination server. As you might expect, the sending of the hierarchy replication message maps to the Replication Outgoing Messages diagnostics logging category in Table 1 above, whilst the receiving of the hierarchy replication message maps to the Replication Incoming Messages category. It therefore follows that for each outgoing message from the source server, there should be a corresponding incoming message on the destination server.

Consider the example replication message shown below in Figure 3. Here you can see that the event category is shown as Replication Outgoing Message. The reason for this message is clear when you examine the event details. The Type is set to 0x2 (hierarchy) and the affected folder is called New Test Folder; this was a new public folder that I had created.


Figure 3: Outgoing Replication Message Event

As I just mentioned, it is normal to expect to see a corresponding incoming replication message on the destination server. Therefore, if you were troubleshooting a situation where Outlook clients connected to the destination server were not displaying the New Test Folder public folder, the next step would be to examine the event log on the destination server for the corresponding incoming message event to make sure it had been received. This event would have a category of Replication Incoming Message and an event ID of 3028. You would expect the event description to again list a message type of 0x2, since this would be a hierarchy message, and also to contain the folder name of New Test Folder.

Naturally the same process applies to the other types of replication message. For example, if a user posts a new message to a pubic folder, or perhaps modifies an existing post in some way and saves it back to the public folder, the entire post is replicated and will be seen in the event viewer as a content replication message (type 0x4) with event IDs 3020 or 3030 depending on whether you are examining the source or destination server.

Backfill request and response messages are part of the backfill process which itself is the process whereby public stores that detect they are missing some replication updates re-request these updates from other public stores. The backfill request is sent as message type 0x8, whilst the response message will be type 0x80000002 for hierarchy messages and 0x80000004 for content messages. Figure 4 below shows an example of a content backfill response message. In this example, server DCEXCH1 is responding to server EXCH3’s backfill request for the public folder called Items For Sale.


Figure 4: Content Backfill Response Replication Message Event

The final replication message types are status replication, type 0x10, and status request, type 0x20. These are used by the public information stores to allow the receiving store to ascertain as to whether it is synchronized with the sending store.

Tracking Replication Messages
Continuing with our example scenario above, it may be the case that the destination server did not contain the corresponding incoming replication message event. If this proved to be the situation, the next logical step would be to examine the message transport. Probably the first thing to do would be to use the Message Tracking Center in Exchange System Manager in an attempt to see what is happening.

You can see from Figure 5 below that I’ve tracked messages sent from the public folder store on server DCEXCH1. To do this, I simply typed in dcexch1-is@hobsonlabs.com as the sender of the message. You’ll recall from earlier in this article that this is the SMTP address of the sending public information store; you can see that this has been resolved to the friendly display name of Public Folder Store (DCEXCH1).


Figure 5: Tracking Public Folder Replication Messages

I personally find it very useful to ensure that subject logging is enabled within message tracking. You can enable this on the General tab of the properties of your Exchange server object in Exchange System Manager. You can see from Figure 5 above that enabling subject logging makes finding your messages much easier, since all messages after 22:33 have the subject field populated after subject logging was enabled. For example, it can clearly be seen that the message sent at 22:45 is a hierarchy replication message.

To drill deeper into the events associated with each tracked message, it is simply a case of double-clicking the relevant tracked message. For example, double-clicking the hierarchy message sent at 23:00 reveals the Message History screen as shown below in Figure 6. Here we can see that the last entry shows us that the message has been successfully delivered to the destination server EXCH3. Had the last two entries on this screen not been present, we would have seen that the last line would have stated SMTP: Message Routed and Queued for Remote Delivery. In this case, we would have known that the message had likely queued on our source server and hence had not been delivered. It would have then been time to check the message queues using the Queue Viewer utility in Exchange System Manager on the source server.


Figure 6: Message Tracking History

One last thing to note here is that a single replication message is created even if there are multiple replicas of that public folder. For example, if a public folder is modified on server DCEXCH1 and a replica of that folder exists on both the servers EXCH2 and EXCH3, you will find that only a single replication message is generated and is addressed to both public folder stores at the same time. Naturally when tracking such a message, expect the Message History window to show this as shown below in Figure 7.


Figure 7: Message Tracking History – Multiple Replicas

Summary
The most important thing to remember about public folder replication is that it’s message-based replication. Knowing this means that, once you’re confident that the public stores have correct email addresses, you can use standard tools in the form of Exchange System Manager and the Event Viewer to start troubleshooting your replication issues. Of course, there are always more complex issues that could arise that are way beyond the scope of this article, but hopefully this article has given you a starting point.

Links

Troubleshooting the Recipient Update Service
http://support.microsoft.com/?id=288807

Troubleshooting the RUS Using Event Logs Parts 1-4
http://blogs.technet.com/exchange/archive/2004/07/07/175444.aspx
http://blogs.technet.com/exchange/archive/2004/07/15/184356.aspx
http://blogs.technet.com/exchange/archive/2004/07/22/191513.aspx
http://blogs.technet.com/exchange/archive/0001/01/01/198662.aspx

Using Winroute to Determine The Routing Status of Your Exchange Organization
http://www.msexchange.org/tutorials/WinRoute-Routing-status-Exchange-organization.html