Όπως έχω πει και σε προηγούμενο post μου τα προβλήματα που συναντάμε κατά την διάρκεια migration ή replication public folders είναι πολλά και ποικίλα.Σε αυτό το post δεν θα δώσουμε λύσεις για κάθε πιθανό πρόβλημα. Απλά θα δώσουμε κάποιες γενικές οδηγίες για το πώς μπορούμε να εντοπίσουμε πιο γρήγορα το πρόβλημα.

Ο καλύτερος σύμμαχος μας σε αυτή την προσπάθεια είναι το application log. Ανοίγοντας το Diagnostic Logging στο Replication Incoming / Replication Outgoing λαμβάνουμε διάφορες πληροφορίες με την μορφή διαφόρων Event IDs.

Δυστυχώς όμως τα Event IDs αλλάζουν μεταξύ των εκδόσεων του Exchange ( πχ. Στον Exchange 5.5 το outbound backfill request εμφανίζεται ως 3014 ενώ στον Exchange 2000 και 2003 ως 3016). Το ίδιο ισχύει και για τους άλλους τύπους Event όπως το outgoing hierarchy,incoming hierarchy,Status requests και status messages,κλπ.

Η λύση σε αυτό το πρόβλημα που δημιουργείται είναι να συνδυάσουμε το Event ID με την παράμετρο Type. Υπάρχουν μόνο 7 types:

Hierarchy - 0x2

Content - 0x4

Backfill Request - 0x8

Backfill Response - 0x80000002 (για hierarchy) ή 0x80000004 (για content)

Status - 0x10

Status Request - 0x20

Ακόμα όμως κι έτσι πολλές φορές υπάρχει παραπλάνηση όπως για παράδειγμα το event ID 3093 που δείχνει ότι υπάρχει κάποιο error σε ένα property ( πράγμα που μπορεί να αγνοηθεί με ασφάλεια).

Ας δούμε κάποιους τύπους replication:

Hierarchy Replication

To replication αυτό λαμβάνει χώρα όταν ένας folder δημιουργείται ή σβήνεται ε’ιτε συμβαίνει κάποια αλλαγή σε properties του public folder ( replica list, client permissions, description, administrative note, storage limits).

Κάθε 15 λεπτά (by default), το store κάνει broadcast τις αλλαγές που έχουν συμβεί στο μεσοδιάστημα αυτό. Με ενεργοποιημένο το logging για μια αλλαγή στο hierarchy θα δούμε κάτι της μορφής:

Event Type: Information

Event Source: MSExchangeIS Public Store

Event Category: Replication Outgoing Messages

Event ID: 3018

Description:

An outgoing replication message was issued.

Type: 0x2

Message ID: <[email protected]>

Database "First Storage Group\Public Folder Store (ITPRODEVEXCH1)"

CN min: 1-72CF, CN max: 1-72D3

RFIs: 1

1) FID: 1-6994, PFID: 1-1, Offset: 28

IPM_SUBTREE\NewFolder

Προσέξτε το "Type: 0x2" που δηλώνει ότι πρόκειται για hierarchy replication message.

Content Replication

Το Content replication συμβαίνει όταν ένα message δημιουργείται,σβήνεται ή αλλάζουν τα properties του. Ο χρόνος στον οποίο γίνονται broadcast οι αλλαγές είναι και εδώ ο ίδιος. Ένα content replication message έχει Type 0x4 και όπως και το hierarchy replication δεν ακολουθεί κάποιο topology.Τα πιο πιθανά σενάρια λάθους λοιπόν όπως καταλαβαίνετε σε replication αφορούν είτε content είτε hierarchy replication.

1. Ο server έστειλε replication message?

Αυτό μπορεί να διαπιστωθεί με αρκετούς τρόπους: Στον ESM, με δεξί κλικ στους Public Folders και διαλέγοντας "Connect To" στο συγκεκριμένο store. Προσοχή στα Client Permissions δεν αλλάζουν από τον ESM. Προ Exchange 2003 Sp2, όταν αλλάζαμε Client Permissions από τον ESM αυτός θα προσπαθήσει να κάνει την αλλαγή στο store που έχει την replica παρόλο που τα permissions είναι property του folder στο hierarchy. Με το 2003 Sp2 αυτό διορθώθηκε και πλέον η αλλαγή γίνεται στο hierarchy. Εάν χρησιμοποιούμε Outlook μπορούμε να χρησιμοποιήσουμε το MFCMAPI για να δούμε το PR_REPLICA_SERVER property του folder.Αυτό σε συνδυασμό με την εμφάνιση ή μη type

0x2 ή 0x4 στο default χρονικό όριο μας οδηγεί στο ασφαλές συμπέρασμα ότι το πρόβλημα είναι στο server που κάνουμε την αλλαγή. Αυτά αναλυτικά περιγράφονται στο KB272999. Ιδιαίτερης προσοχής χρήζει το 3079 event:

Event ID: 3079

Source: MSExchangeIS Public

Type: Error

Category: Replication Errors

Description:

Unexpected replication thread error 0x3f0.

EcGetReplMsg

EcReplStartup

FReplAgent

Αν το 3079 έχει και το "EcReplStartup" τότε ο replication agent δεν έτρεξε για κάποιο λόγο.

Αν στο organization υπάρχει ακόμα Exchange 5.5 τότε ο Exchange 2000,2003 όταν στέλνει replication message πρέπει να έχει και το ptagACLData property (ταe 5.5-style permissions βασισμένα σε legacyExchangeDN) από το ptagNTSD property (το 2000-style permissions βασισμένο σε SID). Αυτό σημαίνει ότι κάθε SID πρέπει να γίνει legacyExchangeDN. Αυτό μπορεί να αποτύχει για πολλούς λόγους: Πχ. Αν το SID αντιστοιχεί σε περισσότερους από έναν χρήστες:

Event ID: 9528

Category: General

Source: MSExchangeIS

Type: Error

Description:

The SID S-1-5-21-408248388-469072634-37170099-1391 was found on 2 users in the DS, so the store cannot map this SID to a unique user.

The users involved are:

/DC=com/DC=company/CN=Users/CN=User1

/DC=com/DC=company/CN=Users/CN=User2

2. Ο παραλαμβάνων server πήρε το μήνυμα?

Σε αυτή την περίπττωση την απάντηση θα μας την δώσει το message tracking και συγκεκριμένα το πεδίο To: αν το target store δεν υπάρχει εκεί τότε οι αλλαγές δεν έχουν πάει εκεί για κάποιο λόγο.

3. Έφτασε το message στον destination server?

Εφόσον έχουμε βεβαιωθεί ότι το μήνυμα έφυγε από τον server τότε πρέπει να δούμε γιατί δεν έφτασε ποτέ. Εκέι την λύση δίνουν τα incoming replication events που server-στόχου.

Τα παραπάνω αποτελούν απλώς κάποιες γενικές οδηγίες – κατευθύνσεις για την επίλυση των πιο συχνών προβλημάτω που μπορεί να παρουσιαστούν.Τα πράγματα περιπλέκονται λόγω μη ύπαρξης topology στο replication αλλά με απλές ερωτήσεις σαν αυτές που παρέθεσα παραπάνω η λύση είναι πάντα θέμα χρόνου.