A sóvárgó objektum

By JoeP 

Lassan egy éve, hogy volt ez az üde, bájos eset. Nem, nem megünnepelni akarom az évfordulóját… egyszerűen csak szeretném lezárni.
Micsoda? Hogy mit kell még egy év után lezárni?
Nos, volt egy olyan hiba, mely akkor került bele a rendszerbe, de csak most lett kijavítva.

Szó se róla, hagytunk neki időt, hogy megoldódjon magától.

Január másodikán is hívott a helyi rendszergazda. Van egy felhasználója, akinek a nagy reszelésben elveszett az accountja. Ez nem is lenne gond, legfeljebb kap egy újabbat… de nem tudja kiosztani neki a régi emailcímét, mert azt mondja a rendszer, hogy ilyen cím már van. Pedig nem is.

Megnéztem. ADUC. Tényleg nem volt ilyen cím sehol… de kiadni mégsem lehetett. Miaf?
Gondolkodósarok.
Annyiszor elmondtam, leírtam… épp ideje volt, hogy magamtól is ráébredjek: az Exchange - szemben az ADUC-cal - nem az AD hagyományos ldap adatbázisát használja. Ekkor ugyanis az Exchange szerver nem látná a távoli tartományok domain partícióit - márpedig pont ott vannak a felhasználónevek és az emailcímek. Nem, ehelyett a globális katalógus ldap adatbázisát használja. Hogyan tudunk ebbe belenézni? Ldp, a portnál pedig a 3268-ast adjuk meg. Az ldp-nek van még egy nagy elÅ‘nye az adsiedit-tel szemben: tud keresni. Rákerestem a felhasználó régi felhasználói nevére… és megtaláltam mind a két objektumot: az újat is, meg a beragadt régit is.
Ez bizony fogós probléma. Hogyan lehet a GC adatbázisból kitörölni egy bejegyzést, mely hivatalosan nincs is ott?

Mese nincs, google. Kiindulásnak pont jó volt, hogy a rossz felhasználó DN tulajdonságának értéke valami ilyesmi volt: “*CNF:GUID”. Meg is találtam, hogy ez egy vágyakozó objektum. Vágyik az elmúlásra.
Amikor kitörlünk egy objektumot, akkor az nem törlÅ‘dik egybÅ‘l. Ugye, nem kell magyaráznom, multimaster replikációs környezetben elÅ‘ször a törlés tényének kell szétreplikálódnia, majd csak utána jöhet a tényleges megsemmisítés. Ez egész konkrétan úgy néz ki, hogy az ojjektum kap egy sírkövet, rajta a dátum, hogy mikor halálozott el. InnentÅ‘l senki nem veszi komolyan… aztán pár hónap után (verziófüggÅ‘) eldÅ‘l a sírkÅ‘ is és az objektum ténylegesen is törlÅ‘dik.
Igenám, de mi van a zombikkal? Képzeljük el, hogy lekapcsoltunk egy DC-t. A lekapcsolás pillanatában volt egy sírköves objektumunk. Telt-múlt az idÅ‘, az élÅ‘ címtárból kitörlÅ‘dött az objektum… aztán valaki visszakapcsolja a korábbi DC-t. Visszajön a sírköves objektum… de az AD nem tud mit kezdeni vele. Hiszen már rég a föld alatt kellene lennie. Törölni nem meri… de replikálni a biztonság kedvéért azért replikálja.
Ezek a vágyakozó objektumok. Angolul lingering objects. A CNF pedig annyit tesz, hogy conflict.

Hogyan került bele ez az objektum abba a bizonyos címtárba az ügyfélnél? Hát… ahogy a viccben is mondják, amit ott abban a másfél napban a kollégámmal csináltunk, örülj fiam, hogy nem nyerítesz.

De mindenesetre nyomon voltam. Megvolt a név, megvolt a jelenség. Már csak azt kellett megtalálnom, hogyan is lehetne eltávolítani az objektumot.

Ehhez sem kellett sokat keresgélnem: itt van a cikk. Javaslom, fusd át, mielőtt tovább olvasnál.
Durva.
ElsÅ‘ olvasás után zsongott is rendesen a fejem: mikor, melyik GC-rÅ‘l kell becélozni melyik GC-t? És mi ez a tömérdek GUID? Micsoda… mindegyik GC-t meg kell műteni? És mindezt egy nyomorult emailcímért?
Szóltunk az ügyfélnek, hogy ez egy kicsit durvább műtét, mint gondoltuk. Meg kellene várni egy csendesebb időszakot, amikor éppen nem heggesztjük ezerrel a címtárat. Rábólintottak.
Az más kérdés, hogy azóta folyamatosan rajta lógtunk a címtáron.

Végül eljött az az időszak, amikor már nem lehetett tovább várni. Hamarosan megszűnik az a bizonyos tartomány, márpedig a megszűnés után szinte reménytelen lenne eltávolítani a sóvárgó zombit.
Nekiugrottam a manuális eltávolításnak. Kövér error. Na jó, erre most nincs idÅ‘m, ment a bejelentés a PSS-nek. A német sráccal lefutottuk a kötelezÅ‘ köröket, majd kipróbáltuk a meglehetÅ‘sen beszédes nevű ‘repadmin /removelingeringobjects’ parancsot. Kiiírta, hogy minden fasza, eltávolította az összes lingeringet, nézzük meg az eventlogban, hogy mennyit. Egész konkrétan nullát.
- Ejha - füttyentett a mérnök. Ez mégsem lesz egy hétköznapi történet.

Nekiálltunk mi is a manuális eltávolításoknak. Kaptuk is az errorokat. De a hapi nem csüggedt.
Neki volt igaza… az egyik kombinációnál siker koronázta az erÅ‘feszítésünket: az ldp kiírta, hogy eltávolította az objektumot.
- Oké - dőlt hátra székében a fazon - Megvan a módszer. Most már csak ezt kellene végigcsinálni mindegyik DC-nél.
A helyzet ugyanis az, hogy a zombi valamiért mégsem replikálódik szét mindegyik DC-re. Csak úgy, sztochasztikusan.
Javasolta, hogy próbálkozzak inkább a cikkben található szkripttel.
Nem mondtam neki, de eszem ágában sem volt. Ilyen kritikus műtétet rábízni egy ismeretlen szkriptre… egy ekkora címtárban… hiszen le se tudom menteni. Inkább kattogtatok.
Szóval azt mondja… az ldp-bÅ‘l konnektálok egy DC-re. Aztán a command string megadásakor beírom egy másik GC GUID-ját, illetve a lingering objektum GUID-ját. Majd a commandnál végigmegyek az összes DC-n. Huszonegy DC, az annyi mint… 441 futtatás.

Izé… hol is van az a script?

Ez sem volt egy matyóhímzés. Egész konkrétan 5 darab fájlt kellett legyártani, GUID-hegyek torlaszoltak el másik GUID-hegyeket… de végül összeállt. Ráküldtem az éles címtárra, végiggondoltam, hogy hol is tárolom a munkakönyvemet, elolvastam egy gazdasági cikket… aztán egyszer csak lefutott a szkript. Dobáltam még egy kis dartsot, majd nagy levegÅ‘, teszt: felvettem a felhasználónál a korábban kiadott emailcímét.
És működött.

Nagy sóhaj.

By JoeP november 21, 2008 at 00:57  Tags:   Posted in: active directory

One Response

  1. SzCsaba - március 23, 2009 at 20:57

    USN rollback is okozhat lingering (hátramaradt) objektumokat. E két jelenségről és még sok más AD-val kapcsolatos dologról bővebben:
    http://blogs.technet.com/glennl/default.aspx

Leave a Reply