Kezdőoldal > Exchange > Exchange DAG szívások

Exchange DAG szívások


Adott projekt kapcsán belefutottam egy olyan hibába, hogy az Exch DAG nem akart összejönni – az adatbázis replikációja folyamatosan hibára futott, azzal az üzenettel, hogy az elsődleges kiszolgálón hiányolt egy log-állományt (ami viszont ott volt). Sebaj, ezt a múltkor (bár nem írtam le) egy új adatbázis létrehozásával kerültük ki, amibe átmozgattuk a postafiókokat, most pedig úgy, hogy ideiglenesen áttettük körkörös logolásra, ekkor már simán létrehozta a másolatot (utána természetesen illik visszaállítani a logolást).

Következett (volna) a PF replikációja. Nos, itt látszólag minden szép és jó volt – csak épp replikáció nem történt… Tekintettel arra, hogy 2003-asról migráltak, a múltkoriak alapján manuálisan kellett létrehozni a szükséges mappákat (amennyiben nem akarunk manuálisan belenyúlni, akkor setup.com /prepareAD ismételt futtatásával is illik létrejönnie), valamint a megfelelő nyilvános mappa adatbázisokon módosítani az msExchOwningPFTree értékét, hogy a most létrehozott PF mappa DN-jére mutasson. Viszont az IS újraindítása után (mindkét szerveren) továbbra sem változott a helyzet – így ismét közösen folytattuk a nyomozást.

Egy eddig nem említett lehetőséget vetettünk be: a loggolás szintjét megemeltük (Server configuration, kiszolgálón jobb klikk, Manage Diagnostic Logging Properties) az alábbiak szerint:

  • MSExchangeIS
    • 9001 Public
      • Replication Backfill – High
      • Replication Errors – Medium
      • Replication General – High
      • Replication Incoming Messages – High
      • Replication NDRs – High
      • Replication Outgoing Messages – High

Az Application eseménynaplóban ezután a MSExchangeIS Public Store által generált alábbi bejegyzéseket kell figyeljük (teljes lista itt):

  • 3030
  • 3038
  • 3018
  • 3027

Ennek alapján tisztán látszott, hogy az eseménynaplóban szerepelt a kiküldött levél, de az is kiderült, hogy kiküldésre sem kerülnek a szinkronizációs levelek. Az ok: a kollégák a leírásból az utolsó lépést kihagyták: a Servers konténer törlését. Tartalmilag üres volt, de a konténer még létezett – ennek eltávolítása után máris helyreállt a replikáció.

Igen ám, de az előző tesztelések eredményeképpen az Exch2-n látszólag két PF lett felcsatolva. Ezt nem lehetett látni a PF-management konzolból (ott ráadásul a szerver kiválasztása ablakban hiba is fogadott), egyedül adott PF-mappa replikációjának beállításánál látszott ez a rossz állapot.

Lefuttattuk a

Get-MailboxServer | Get-PublicFolderDatabase

parancsot, ahol egy hibaüzenet segített a megoldás felé vezető úton:

WARNING: The object EXCH2-PFDB02 has been corrupted, and it’s in an inconsistent state. The following validation errors happened:

ADSI Edittel ellenőrizve/javítva a PF objektum msExchOwningPFTree tulajdonságát (ez magával vonja a visszacsatolás – BackLink – értékének módosulását is az msExchOwningPFTreeBL mezőben), majd az IS szolgáltatást újraindítva helyrebillent a lelki béke 🙂

Mielőtt még hátradőltünk volna, a végén, miután megvolt az új CAS Array is, a felhasználók panaszkodtak az ActiveSync működésképtelen voltára. Erre szerencsére „gyors” (értsd: Exchange-tempós 🙂 ) megoldást jelentett a Server config/Client Access varázslójának újrafuttatása (haladóbbak vehetik sorra az alól található fülek: OWA, ECP, stb. beállításait), hogy biztosan mindenhol jól legyen beállítva a külső csatlakozási elérhetőség (external name).

Advertisements
Kategóriák:Exchange Címke: , ,
  1. Még nincs hozzászólás.
  1. No trackbacks yet.

Vélemény, hozzászólás?

Adatok megadása vagy bejelentkezés valamelyik ikonnal:

WordPress.com Logo

Hozzászólhat a WordPress.com felhasználói fiók használatával. Kilépés / Módosítás )

Twitter kép

Hozzászólhat a Twitter felhasználói fiók használatával. Kilépés / Módosítás )

Facebook kép

Hozzászólhat a Facebook felhasználói fiók használatával. Kilépés / Módosítás )

Google+ kép

Hozzászólhat a Google+ felhasználói fiók használatával. Kilépés / Módosítás )

Kapcsolódás: %s

%d blogger ezt kedveli: