Az állandóan kinyírt rekord esete

Telefon az ügyféltől: nem tudja, mi van, de hülyén viselkedik az Exchange. Például nem lehet postafiókot létrehozni, pedig tegnap még lehetett, ráadásul a hibaüzenet is zavaros.
A hibaüzenet tényleg elég zavaros volt. Megnéztem az eventlogot, tele volt szórva AD hibával. Oké, akkor nem is az Exchange hülye, hanem az AD. Vizsgáljuk meg.

Alapvetően egyszerű felállásról volt szó, két DC, az FSMO szerepkörök szépen elosztva, mindkettő GC. Ezek melllett pöfögött egy Exchange szerver. Tényleg nem bonyolult.

Nézzük az AD-t. Teljesen meggárgyult. A címtárreplikáció szétesett, a DC1 gyakorlatilag eltűnt a rendszerből. DNS. AD integrált. Az SRV rekordok rendben. Akkor miért nem látják? Azért, mert az A rekordja tűnt el. Azaz az SRV rekordok alapján az Exchange is, meg minden más gép is kereste volna (RIDm/PDC/IM/GC is a szerencsétlen), de az A rekord híján nem érték el. Oké, ez egyszerű eset. Az egyik irányban működött a replikáció, így felvettem az A rekordot az egyik gépen, meghúztam a replikációt, átkerült a másik gépre is, pár perc és teljesen helyrejött az AD.
De miért tűnhetett el az A rekord? Két lehetőség van, dinamikus rekord volt, és a scavenge kinyírta, vagy valaki direktben törölte. Megnéztem a beállításokat, de semmi. Azaz nem volt beállítva takarítás, hiába járt le egy bejegyzés, attól az még bent maradt a zónában. Akkor maradt a manuális törlés. Lesz egy kínos beszélgetés a helyi rendszergazdával.

Na, mindegy, nézzük, mit lépett a rendrakásra az Exchange? Új postafiók… és ugyanaz a hiba. Ne te, már. Hát meggyógyítottam a címtárat! Itt van, ni: nslookup dc1… nincs ilyen rekord. Mi van? Visszatekertem a DC-re, megnéztem a zónát: tényleg eltűnt a bejegyzésem. Izé… lehet, hogy mégsem a helyi rendszergazda törölget? De akkor ki? A scavenge ki van kapcsolva mind a két DC-n, meg egyébként is, statikusnak vettem fel a rekordot. Vegyük fel újra. Hátha most nem tűnik el. (Ez a legnagyobb marhaság, reménykedni abban, hogy csak elégszer kell próbálni, aztán egyszer jó lesz. De legalább megy vele az idő, lehet gondolkodni.) Kábé 10 perc után a rekord megint törlődött, méghozzá a DC1 törölte. Egy botor próbálkozás: DC1 netlogon service újraindít, de semmi.

Azt hiszem, valami érdekeset fedeztem fel: fekete lyuk az informatikában.

Gondolkodjunk.
AD integrált DNS zónában egy rekord törlése az valójában meglehetősen bonyolult folyamat. Egyrészt van magának a dinamikus DNS-nek a törlési folyamata (lejárat, érzékenység, scavenge időzítés), másfelől pedig a rekord maga is egy AD objektum, azaz elosztott, multimaster replikált adatbázisban lakozik. Sírkő. (Ha esetleg valaki nem lenne tisztában vele: elosztott, multimaster adatbázisban nem egyszerűen törlünk, mert az nehezen replikálódna át. Ilyenkor az objektum kap egy sírkövet, miszerint már valójában halott, és ez a sírkő feltét replikálódik. A sírkövön szerepel az is, hogy meddig tartózkodik még az objektum az adatbázisban. Utána eltűnik, sírkövestől együtt.)
Jelen esetben a dögeltakarítás (scavenge) nem működött, tehát csak a sírkövezésre kellett koncentrálnom. Mivel AD objektumról van szó, értelemszerűen elő kellett kapni az Adsiedit-et. (Vigyázat, a DNS zónákat nem ajánlja fel helyből, nekünk kell tudnunk, hogy milyen szintű integrációt állítottunk be és annak megfelelően beírni vagy a DomainDNSZones vagy a ForestDNSZones partíciók DN értékét.)
És igen, szépen ott is volt a kinyírt rekord, a dNSTombstoned tulajdonsága pedig True. Tehát akármi is nyírta ki, az az AD szintjén történt. Visszabillentettem az értéket False-ra, és hátradőlve vártam, hogy megjelenjen a DNS konzolban is. (A netes forrásom szerint meg kellett volna jelennie.) Hát, nem. Ez a rekord szégyenlősebb volt annál. Akkor most mi van? Rosszabb már úgysem lehet a helyzet, kitöröltem Adsiedit-ből is, aztán a konzolból újra létrehoztam. Erre visszajött a rekord, a változója üresen állt, ellenben létrejött mellette egy tipikusan sírkövezéskor előforduló, név+guid nevű objektum is. Na, ebből mi lesz? Vártam tíz percet. Az lett, hogy az eredeti rekord eltűnt, a guidnevűből eltűnt a guid, maradt egy bejegyzés, de a tombstone már be volt kattintva. Azaz eltűnt a törölt, az új vette át a helyét, de az is egyből töröltre jelölt lett. A nénikéd.

Akkor workaround. Villámkezű Joe. Felvettem újra az A rekordot, meghúztam a replikációt, AD helyreállt, gyorsan átmozgattam az FSMO-kat a DC2-re, GC a DC1-en lekapcsol, újból meghúztam a replikációt, az Exchange szerveren a DNS kliens beállítást átírtam a DC2-re, magán az Exchange-n is mindenhol beállítottam, hogy a DC2-t használja. AD Topology (és vele még 7 egyéb) service újraindít, IISreset. Gyors ellenőrzés, még megvolt a DC1 rekordja. Oké, teszt. Új postafiók. Ugyanaza a hiba.

Vicces. Mindez péntek délután.

Ekkor vettem a fáradtságot, hogy értelmezzem az Exchange egyébként borzasztóan nem odaillő hibaüzenetét. Vazzeg. Azt írja, hogy az Address List service hülyült be. Az viszont valójában a System Attendant, mely kimaradt a nagy újraindítási hullámból. Restart. Postafiókteszt. Működött. Hurrá. DC1 bejegyzés? Már eltűnt. Most ez is hurrá, mert ez azt jelenti, hogy az Exchange már megy, a DC1-től függetlenül, azaz innentől ráérek az állandóan kinyírt A rekorddal foglalkozni.

A gond csak az, hogy semmi ötletem nem volt. Áttúrtam a netet, remek írásokat találtam arról, hogyan lehet auditálni a DNS-t, ahhoz, hogy elkapjuk a rekordtörlő rendszergazdákat. De itt magát a rendszert kellett volna elkapni, arra meg nem vonatkozik az audit. Végül úgy döntöttem, hogy marad az atombomba. Életre rángatom megint az AD-t, aztán DC1 demote (és bízom benne, hogy lemegy 10 perc alatt), az immár member szervert átnevezem, aztán DC3 promote.
Előtte feltettem a teavizet. Míg a konyhában kortyolgattam a teát, eszembe jutott, hogy adjunk egy esélyt a mágikus újraindításnak. Veszíteni nem veszítek vele semmit. A tea után meg is történt a restart – és csodák csodája, egyből létrejött a DC1 A rekordja! Igaz, dinamikus bejegyzés lett belőle, ezt gyorsan átírtam statikusra… és vártam. Elég sokat. 25 perc után kezdtem csak elhinni, hogy meggyógyult az AD, hiszen továbbra is élt az A rekord. Romeltakarítás.

Case solved. (Azt most ne firtassuk, hogy hétórányi szopást tudtam volna megúszni, ha egyből a restartot választom.)

Hogy mi volt az a rejtélyes krokodil, mely tíz percenként előbújt és leharapta az AD-ból a DC1 A rekordját, azt nem tudom és valószínűleg nem is fogom megtudni. Annyit sikerült kiderítenem, hogy két héttel ezelőtt volt egy áramszünet, mely levágta a Hyper-V hostgépet és nyilván mentek vele a virtuálisak is. (Pl. a DC1.) Utána minden visszaindult és látszólag rendben is volt. Látszólag. A mai napig.

ps.
Mondjuk, nekem még igen büdös volt az el-eltűnő A rekord objektum dSCorePropagationData tulajdonságának az értéke is. A DC2 esetében a tulajdonság értéke 0x0 volt, amikor a DC1 megjavult, akkor az övé is, de amíg rossz volt, addig az aznapi dátum volt benne. Sajnos nem találtam semmi infót, hogy konkrétan ennél az AD objektumnál ez a tulajdonság mire szolgál (úgy egyébként az öröklődés szabályozásához van köze, de ennyi a konkrétum: “This attribute is for internal use only”). Ráadásul még csak nem is módosítható.

9 Comments

  1. Nagyon élveztem, írj még!

  2. @Oldman: Ilyet se mondtak még. Általában azt szokták inkább mondani, hogy ne írjál már olyan sokat, mert nem tudjuk követni. 🙂
    Az viszont tény, hogy ennek a blognak is voltak szebb napjai, amikor sokkal több cikk jelent meg rajta. Az utóbbi időkben már nincs sok kedvem hozzá. (Inkább a privát blog pörög.)

    ps.
    Egy intim kérdés: R.T. a valamikori hardverfórumból?

  3. dSCorePropagationData: Active Directory használja, pontosabban a Security Descriptor Propagator. Ez ‘csak’ egy belső állapotjelző (StateOf), azt jelzi hogy mikor kerültek át a szülő objektumtól a gyerek objektumra a tulajdonságok.
    Ténylegesen rendszer tulajdonság, nem kell vele foglalkozni (nem is lehet állitani), az NTFS, AD és az SDProp magányügye mi van benne. 😀

  4. Ja, és lemaradt az előbb: dede, írjál még ilyet! Sokat! 😀

  5. Igenigen, soksok ilyen szakmai cikket kérünk még! 😀

  6. +1 az érdekes tényfeltáró cikkekre!

  7. Pontosan ugyanez tortenik eppen nalunk ( http://serverfault.com/questions/482974/windows-dns-server-deletes-its-own-a-record-on-reload ), kiprobaljuk a magikus rebootot este, remeljuk mukodik.

  8. Es a reboot tenyleg megoldotta. koszi!

  9. Szívesen. 🙂

Leave a Reply to Oldman Cancel reply