Essünk túl rögtön a nehezén: farok voltam. Nem is kicsit. De megint mákom volt, nem ez okozta a szopást.
Mint írtam korábban, egy nagyobb lélegzetű projekt részeként fel kellett húznom egy távoli tartományban, egy távoli szájtban egy tartományvezérlőt. Anélkül, hogy túl sokat gondolkodtam volna, felhúztam rá egy w2k3 szervert. Aztán amikor jött a dcpromo, kerregett egy kicsit, majd indignáltan közölte, hogy “legalább egy adprep kellene, fiú“. Basszus – csaptam a fejemre – ez még csak natív w2k tartomány. Oké, tudomásul vettem, hogy nem történt meg az előléptetés – a biztonság kedvéért átnéztem az AD-t, de sehol semmi nyoma nem volt, hogy keletkezett volna egy DC.
Újrahúztam a gépet, immáron w2k-val, megint dcpromo, remekül sikerült. Elég késő este volt, gondoltam reggelre lemegy minden replikációs szutyok.
Hát, nem. Semmi replikáció nem történt, semmi srv rekord nem jött létre – a DC bizony elég döglöttnek tűnt. Egy kollégával nekifogtunk a feltámasztásnak, de nem bírtuk kirángatni a klinikai halál állapotából. A hibaüzenetek mélyén mindig beleütköztünk egy gyanús objektumba, mely egy guid névre hallgatott. Úgy tűnt, hogy ez a bazi hosszú karaktersorozat akadt keresztbe az AD torkán.
Ha nem, hát nem. Dcpromo vissza. Azt mondta, hogy nem lehet, mert nem működik a replikáció. Itt kezdett el jojózni a szemem – hát pont azért akarom demotálni, mert nem működik a replikáció! Aznapra elég is volt ennyi.
Hétvégén egyrészt aludtam egyet-kettőt, másrészt gondolkodtam. Igen, szoktam. Néha.
Találtam is valami magyarázatot. Igaz, légből kapott – ún. identifikált – magyarázat volt, de logikusnak tűnt. Kicsi is, savanyú is, de a miénk. Valószínűleg az első dcpromo már megágyazott a szervernek a konfigurációs névtérben – és csak utána vette észre, hogy nem megfelelő a séma. Persze ezt már nem takaritotta ki. Mocskos Microsoft. Trehány banda.
Jöttem két nap múlva és megpróbáltam létrehozni egy ugyanolyan nevű DC-t. Naná, hogy ennek – legbelül – csak ronda guid-os neve lehetett, hiszen az előző ágy még ott illatozott. Hogy aztán miért okozott helyrehozhatatlan replikációs hibát ez az elnevezés, azt már nem tudom.
A megoldás adta magát: valamilyen módon ki kell takaritani a döglött DC-t, helyét felszántani, sóval bevetni, aztán másik néven kreálni egy újabb tartományvezérlőt. A takarításhoz meg is találtam a megfelelő KB cikkeket (egyik, másik), innentől kezdve már csak a diplomácia maradt hátra. Mennyire lesz ez kockázatos? Ha fejreállítom a regionális vezető szerepre törő ügyfél éles tartományát egy Europe-wide projektben, akkor én az EMEA régióban sem találok új munkahelyet. De az idő is erősen sürget, és bár kicsi a kockázat, de ha megemlítem, akkor beindul a change management, kockázatelemzés, független tesztelés, annyakínja…
Volt min agyalnom.
Végül megoldódott a helyzet. Beavattam a főnökömet, írtam az ügyfélnek, fél napig vártam, nem válaszoltak, hallgatás – beleegyezés. Mehettem dózerolni. Az első döbbenet akkor ért, amikor a dcpromo /forceremoval sem működött. Azt mondta, nem tudja leállítani a netlogont. Nofene.
Itt már azért sejtettem, hogy megint mehetek a jó öreg zajos, szélviharos szerverhelyiségbe.
Egyelőre beléptem az ILO porton, letiltottam az összes hálókártyát, majd nekiálltam megműteni az éles AD szívét. Nem mondom, hogy nem remegett a kezem.
Itt érdemes megemlékezni egy fordítási bakiról.
10. Perform a metadata cleanup for the demoted domain controller on a surviving domain controller in the forest.
…
10. Végezze el a metaadatok törlését a lefokozott tartományvezérlőn az erdő egy még meglévő tartományvezérlőjéről.
Uraim, ez nem ugyanaz, nagyon nem…
A műtét sikerült, az ügyfél nem vett észre semmit, én meg tekerhettem a Dataplexbe. Ilyen flott telepítésem még nem volt blade-del: 2 óra alatt tiptop fent volt az oprencer, mindenestől. Hát, igen… a rutin.
És jött megint a félelmetes dcpromo. Látszólag minden sikerült. Jó, akkor most menjünk büfébe, mert szégyenlős a kicsi – ha nézik, akkor nem replikál. De ez a büdös dög akkor sem replikált, ha nem nézték. Ugyanaz a jelenség. Semmi replikáció, szájton belül RPC error, szájton kívül semmitmondó ‘majd replikálok, ha ráérek‘ üzenet, az eventlogban meg egy teljesen értelmezhetetlen hibaüzenet: nem tud bejegyezni egy bazinagyguid nevű aliast az msdcs.forestroot dns zónába. Megnéztem és ez egy igen idétlen zóna: tele van ilyen ökörhugyozás bejegyzésekkel és az új DC-nek tényleg nyoma sincs.
Nos, a szituáció megérett egy funkcionális eszkalációra. (ITIL vagyunk, vagy miaf@sz.) Először mozgósítottam a tűzfalas emberünket, majd ezzel egy időben becsörögtem a Microsoft PSS-hez. Tuti örültek nekem, délután fél ötkor, egy ‘A’ kategóriás bejelentéssel. Az első embernek egyből el is romlott a postafiókja, így kénytelen volt rögtön eszkalálni a problémát.
Amíg ők odabent békésen eszkalálgattak, visszahívott az – egyébként igen jónevű – tűzfalas emberünk.
– Hát, van néhány drop, DNS kéréseknél – mondta.
– Mennyi?
– Tulajdonképpen kurva sok.
– Áááááá! – kezdtem el sikoltozni. (Még rögtön az elején nyomatékosan kértem, hogy az új DC és a többi között any-any szabály legyen.)
– Elég érdekes a dolog – folytatta a srác, mintha érezte volna, mi bántja a szívemet – ugyanis protocolfilter fogja meg; azt mondja, hogy valótlan a kérés szintakszisa.
Kezdett összeállni a dolog.
– Nem lehet, hogy ez egy olyan DNS kérés, amelyikben valaki egy kibaszott hosszú nevű aliast akar beregisztrálni? – érdeklődtem.
– De, lehet.
– Nem-e lehetne-e ezt a protokolszűrést kikapcsolni-e?
– De, lehet. (Medve a halállistával.)
Vártam pár percet, újraindítottam a DC-t és… pár perc múlva begerjedt a replikáció. Én így még nem örültem replmon képernyőnek.
Tehát összeállt a kép: a dcpromo lefutott, de egy DNS regisztráció nem történt meg: az új DC GUID-ja nem került be aliasként a forest root tartomány msdcs.forest.root zónájába. És azért nem került bele, mert a bejegyzési kérelmet a tűzfal BOF támadásnak érzékelte.
Oké. De miért vágta ez haza a replikációt?
Ekkor hívtak vissza a Microsofttól. Örömmel közöltem, hogy megoldódott a probléma. Rakjuk össze, amink van – javasolta a srác. Erre elmondtam, mire jöttünk rá – ő pedig elmagyarázta, hogy hogyan is történik igazából a replikáció. Így:
The domain controller initiating the replication (DC1) queries the Active Directory in searching for its configured replication partners. These replication partners are typically defined by the Knowledge Consistency Checker (KCC), but can also be defined manually.
DC1 knows only the name of the domain controller that it wants to replicate with (DC2). It finds a GUID in the Active Directory that matches the target domain controller’s name (DC2). Note that each domain controller in the forest should have its own unique GUID.
Now that DC1 knows DC2’s GUID, it must find DC2’s IP address so that it can connect to it across the network. To do this, DC1 uses DNS. DC1 sends a recursive DNS query to its locally configured DNS server for a CNAME record. The format of this record always matches the following
guid._msdcs.root of Active Directory forest
Where guid is the GUID that DC1 found in the Active Directory, and root of Active Directory forest is the root of the Active Directory forest. For example 91f9b084-4876-4b59-be17-59e74c340221._msdcs.reskit.com where 91f9b084-4876-4b59-be17-59e74c340221 is a GUID and reskit.com is the root of the Active Directory forest.
DC1’s locally configured DNS server should respond to the query for the CNAME with an alias. The alias is another name for the GUID. For example, the GUID 91f9b084-4876-4b59-be17-59e74c340221 is resolved to dc-02.reskit.com.
Now that DC1 knows the alias for the GUID, it must resolve the alias to an IP address so that it can connect to DC2 across the network. DC1 sends a recursive DNS query to its locally configured DNS server for a Host (A) record that matches the name of the alias. The DNS server should respond with the IP address that has been mapped to the alias — for example, 169.254.66.7
Now that DC1 knows DC2’s IP address, it can connect to DC2 over the network and replicate Active Directory data.
Röviden összefoglalva, itt kőkemény névfeloldás folyik. A replikációs partnerek csak egymás nevét ismerik. Ez alapján kikeresik az AD-ból a partner GUID-ját. Most már csak a GUID-hoz tartozó IP cím kellene – ezt tartalmazza az a bizonyos zóna a forest rootban. Ha ebben nincs meg az új DC GUID-IP összerendelése, a replikáció csonkára fut.
Szép, mi? Jól mellétrafáltam az ujjamból szopott magyarázattal. Szó sem volt megágyazásról, beragadásról meg trehány Microsoftról. Minden tiszta, logikus és érthető. Csak az kicsit gáz, hogy ezt az infót a PSS-től kellett megtudnom. Lehet, hogy valahol le van írva… lehet… de én még nem találkoztam vele.
Szóval most működünk.
Milyen fából faragják a jó tűzfalast? Úgy van. Pár perc múlva visszahívott, hogy oké, JoeP, szóljál mikor kapcsolhatom vissza a filtert, mert anélkül szarul érzem magam. Itt kezdtem el másodjára sikoltozni – de aztán rájöttem, hogy nem beszél hülyeségeket. Ha vigyázunk arra a szájbanyomott rekordra, akkor többször nem kell bejegyezni. Kiolvasni meg csak ki tudják. Talán. Holnap teszteljük.
Szeretünk a penge élén.
2009-02-20 at 03:29
Ez egy nagyon regi cikk, es nem is remelem, hogy megtalalod az itteni kommentemet, mindenesetre a nagyvilagnak vazolnam, mirol is van itt szo:
Szoval, az AD-hez ketto DNS domain szuksegeltetik, mondjuk a mittudomain.com meg a _msdcs.mittudomain.com zona. Nomarmost, a gond a masodikkal van, megpedig annak az elso szamu tagjaval, ugyanis a rendes DNS szabvany szerint az alahuzas (underscore) karakter DNS nev resze nem lehet, kezdokaraktere meg plane (szabvany szerint csak alfanumerikus karakterrel kezdodhet DNS nev). Amely protokollfilter a kimondott RFC szabvanyhoz ellenoriz, ott bizony-bizony az osszes olyan domain keres fenn fog akadni, amely ebbe a zonaba probal meg bejegyezni barmit is.
Hogy a tuloldalon miert nem volt ez gond? Nagyon egyszeru: a Microsoft valamennyire azert ismeri latszik a sajat termeket, es a sajat DNS szerveren engedi az alahuzast tartalmazo nevek letrehozasat . Ellenben ha barhol elofordul, hogy 3rdparty cucc probal meg ellenorizni ilyen DNS-re iranyulo irast, az bizony meg lesz fogva.