Category: windows server

Csak dinamikusan

Felteszem, sokan használunk dinamikusan frissített DNS zónákat. Valószínűleg legalább annyian dühöngünk is miatta, mert az istenért sem működik a döglött rekordok eltávolítása.

Ahhoz, hogy megértsük, miért nem, célszerű megismerkedni részletesebben is a folyamattal.

DHCP oldalon:
Itt tudjuk beállítani, hogy mindazon host, amely DHCP kliens, milyen időszakonként frissítse meg az IP cím bérleti idejét.

DNS oldalon:

  • Stale record: Döglött rekord. Eredeti gazdája már régen nem létezik vagy már más IP címet birtokol – de a bejegyzés még nem tűnt el.
  • Scavenging process: Magyarul dögevés. Ennek a folyamatnak során tűnnek el a döglött rekordok a zónafájlokból.
    A folyamat beállítási lehetőségei elég gyérek: gyakorlatilag nulla a beavatkozási lehetőségünk. Hét naponta fut le, nem tudjuk befolyásoni, hogy a nap melyik órájában induljon el.
  • Aging: Annak eldöntése, hogy egy rekord döglött-e vagy sem. Két fontos paramétert kell hozzá beállítani:
    – No-refresh interval
    – Refresh interval

Ez utóbbi folyamat külön megér egy misét. Nézzük csak, mi van a beállítópanelra írva:

No-refresh interval: The time between the most recent refresh of a record timestamp and the moment when the timestamp may be refreshed again.
Refresh interval: The time between the earliest moment when a record timestamp can be refreshed and the earliest moment when the record can be scavenged.

Bevallom őszintén, nagyon sokáig nem értettem, mit jelentenek ezek a mondatok. Nem is mertem hozzányúlni, hagytam mindkettőt a default 7 napos értéken. Nemrégiben viszont piszkálgatnom kellett, és így most már sokkal világosabb a helyzet:

  • No-refresh interval: Az az időszak, amikor a DNS szerver nem foglalkozik a rekorddal. Tekintve, hogy a takarítás erőforrásigényes folyamat, nem mindegy, mennyi rekordot kell folyamatosan csekkelni.
  • Refresh interval: Az az időszak, amelyen belül a DHCP szervernek meg kell újítani a bejegyzést. Amennyiben ezt nem teszi meg, akkor lesz a rekord stale.

Nézzünk végig egy folyamatot:

  1. Beóvakodik a hálózatba egy kliens, a DHCP IP címet ad neki.
  2. A DHCP beregisztrálja a kliens nevét, IP címét a megfelelő AD integrált zónába.
  3. Amíg le nem telik a No-refresh érték, addig a DNS szerver nem bántja a rekordot. Célszerű ezt ugyanannyira választani, mint amennyi a DHCP-ben a bérlet lejáratának ideje.
  4. Letelt a No-refresh idő, mostantól már figyel rá a DNS szerver.
  5. Amennyiben a Refresh időtartam alatt nem történik meg a rekord frissítése a DHCP által, akkor a rekord stale lesz.
  6. Hét naponta megjelenik a Scavenging és elviszi a stale rekordokat.

Így már nem is bonyolult.
Most nézzük, meg, miért nem működik?

Leginkább azért, mert ez a dögevő meglehetősen szégyenlős. Tudja, hogy a munka, melyet végez erőforrásigényes, így amikor kidugja az orrát a barlangból és azt látja, hogy a DNS szerver éppen nagyon dolgozik, vissza is bújik. Majd legközelebb.
Ebben ugye az a különösen szép, hogy nem tudjuk beállítani, mikor dugja ki az orrát. Hiába tudjuk, hogy éjfélkor már alszik a széken a kabát, szunnyadozik a szakadás – nem adhatjuk meg neki ezt aktiválódási időpontnak.

Kétféleképpen kerülhetjük meg:

  • Elindítjuk manuálisan, grafikus felületről. Jobbklatty a szerver nevén, ‘Scavenge Stale Resource Records’.
  • Elindítjuk manuálisan, parancssorból. A Support Tools része a dnscmd segédprogram, ehhez kell hozzácsapni a /startscavenging paramétert.

Az utóbbi különösen azért figyelemre méltó, mert parancssor lévén ütemezhető is – azaz megkerültük a Scavenge bizonytalan indulásának problematikáját. Innentől kezdve gyakorlatilag nincs is rá szükségünk, bátran kapcsoljuk ki. (Az ‘Aging’ panelen vegyük ki az ikszet a ‘Scavenge Stale Resource Record’ checkbox-ból.) Figyelem, minden DNS szerveren ki kell kapcsolni, melyen az illető zóna megtalálható.

Ez utóbbi gondolatot érdemes egy kicsit továbbvinni. Ez az egész dinamikus regisztrációs folyamat csak AD integrált DNS zónákon működik – ezek ‘zónafájljai’ viszont a tartomány mindegyik tartományvezérlőjén megtalálhatók. (Ez mondjuk nem teljesen igaz, itt nézhetsz utána részletesebben.) Na most, teljesen felesleges mindegyik DC-n beindítani ezt az erőforrásigényes takarítási folyamatot, amikor a jelölgetések, törlések úgyis replikálódnak: vagy beállítod egy DC-n, a többin pedig letiltod, vagy leállítod mindegyiken és enyhébb forgalmú időszakra beállítva beidőzíted a fenti parancsot valamelyik DC-n.

Végül egy jópofa trükk: hogyan takarítsuk ki gyorsan a zónánkat?
Például úgy, hogy a DHCP lejárati idejéhez képest vegyük jóval alacsonyabbra a No-refresh/Refresh értékeket. Ezt annál is könnyebb megtenni, mert a paraméterek igen messze találhatók egymástól a grafikus felületen.
Menjünk végig a korábban részletezett folyamaton. A DHCP 2 naponta frissít, a frissítési értékek legyenek mondjuk 2 óra.

  1. Beóvakodik a hálózatba egy kliens, a DHCP IP címet ad neki.
  2. A DHCP beregisztrálja a kliens nevét, IP címét a megfelelő AD integrált zónába.
  3. A No-refresh érték viszonylag hamar letelik, két óra múlva a DNS már figyeli a rekordot.
  4. Eltelik újabb két óra, a DHCP természetesen nem regisztrál újra, mivel ő csak kétnaponta újítja meg a bérletet. A rekord stale állapotú lesz.
  5. Hét naponta megjelenik a Scavenging és elviszi a stale rekordokat – azaz a jelen esetben a zóna nagy részét. (Nyilván maradnak kivételek, akik még éppen nem váltak döglötté. Ne felejtsük el, a döglött rekord is újra aktivizálódhat, ha a DHCP ugyanazt az IP címet adja vissza a kliensnek két nap múlva.)
[Update]
Kollégám hívta fel a figyelmemet, hogy Windows2003 tartományban már lehet szabályozni a Scavenge periodicitását is. A DNS konzolon belül kijelöljük a szervert, properties, advanced, ablak alja, csodálkoz.

Majdnem-Herkules

Igen, ő a Muszáj-Herkules testvére.

Felteszem, mindenki tudásában vannak fehér foltok. Olyan területekre gondolok, melyeket ha máskor nem is, de vizsgára megtanultunk – aztán utána el is felejtettük, mert soha nem volt rá szükségünk. Nekem ilyen terület a biztonsági sablonok molesztálása.

Adott volt a következő feladat: telepítsünk egy egyszerű failover clustert multi ügyfél magyar leányvállalatához. A vasak egyszerű pengeszerverek, oprendszer, IIS (erőforrás lesz belőle az ügyfél alkalmazásában). A gép tartományba beléptetve, lokál admin jogunk van, tartományi admin jog nincs. Jól is néznénk ki.
Mielőtt még felhajigálnánk a clustert (pontosabban beizzítanánk, hiszen a WIndows2003 Enterprise változatban helyből települ), még le kell futtatnunk egy helyi specifikus alkalmazást: ez bekeményíti az operációs rendszert, bekonfigurál egy csomó mindent, felrak ezt-azt. Céges standard, kötelező.
Jöhet végre a cluster. Gyönyörűen fel is települ, majd amikor leokézom az utolsó ablakot, jön egy kövér error. Hogy access denied.
Első alkalommal ijedtemben eltávolítottam a node-ot. (Ami persze nem igazán egyszerű dolog, hiszen grafikus felületről nem látszik semmi. A megoldás: ‘cluster node <nodename> /forcecleanup’) De az újabb, alaposabb konfigurálásnál ugyanezt kaptam. Ráadásul a kollégák szóltak, hogy a cluster tulajdonképpen működik, kívülről elérhető. Csak éppen nem menedzselhető. Zorró, a fantomklászter. Jöttek a szokásos ráolvasások éjfélkor keresztútnál (filemon, regmon, user jogosultságok, gpresult), de nem sok sikerrel. Aztán az ügyfél ötletére ráhúztuk a rendszerre a ’setup security’ biztonsági sablont – és onnantól már a cluster szolgáltatás sem indult el. Viszont amint visszaállítottuk a cluster service account user jogosultságait a setup security sablonban, egyből menedzselhetővé vált a cluster.
Azaz a hardening csinált valamit, amitől elérhetetlenné vált a cluster management GUI – amint visszatettem egy gyengébb sablont, minden ment simán.
Azt hihetnéd, hogy örültünk ennek a megoldásnak. Óriási tévedés. A leánycégnek az égegyadtavilágon semmi ráhatása sincs arra, hogy a magasságos multi anyacégnél a biztonsági részlegen milyen hardening eljárást dolgoznak ki. Sőt, még tájékoztatást sem kapnak, hogy tkp. mi is történik a folyamat során. A maximum, amit ki tudtunk csikarni, az egy mérsékelt érdeklődés volt, és egy igéret, hogy ha kiderítjük, melyik beállítás okozza a hibát, akkor az eredményt felveszik a céges knowledge base-be.

Azaz identifikálni kell, ezerrel.

És itt jön be a képbe a Security Configuration & Analysis segédprogram. A Majdnem-Herkules.

Mielőtt tovább haladnánk a megoldási folyamatban, nézzük át részeletesen, hogyan is működik ez az eszköz.

Először is, az eszköz grafikus felülete csak MMC konzolból érhető el – azaz megfuttatjuk az mmc.exe progit, majd a snap-in-ek közé felvesszük a Security Configuration & Analysis konzolt. És ha már ott járunk, kapjuk fel a Security Templates konzolt is.

Nagyítás

Ha magunktól próbálunk rájönni az eszköz működésére, akkor gondban leszünk. Ugyanis ha nem ismerjük a logikáját, magunktól soha nem fogjuk kitalálni.
Az elv az, hogy van egy működő rendszer. Ez az, amely éppen dübörög a gépen, amelyen vizsgálódunk. És van egy munkaterület, ahová boncolási célzattal betölthetünk biztonsági sablonokat. Egyszerre mindig csak egyet. Ezt a munkaterületet adatbázisnak nevezték el. Az összes műveletnek ez a két terület az alanya.

  • Össze lehet hasonlítani a munkaterületen lévő sablont a jelenlegi beállításokkal. (Analysis.)
  • Tetszőlegesen módosíthatjuk a munkaterületen lévő sablont, majd elmenthetjük.
  • A munkaterületen lévő sablont ráhúzhatjuk a működő gépre. (Configuration.)

Nézzük részletesen.

Mielőtt bármit csinálnánk, munkaasztalt – adatbázist – kell definiálnunk. Jobbklatty, open database.

Nagyítás

Itt beírjuk a létrehozandó adatbázis (.sdb) nevét. Ezzel létre is jön. De mielőtt még kiérnénk a kuruzslóból, megkérdezi, hogy vajh melyik sablont szeretnénk betölteni? Válasszuk ki valamelyiket.

Nagyítás

Amivel egész biztosan nem okozunk galibát, az az összehasonlítás. Csapjunk bele.

Nagyítás

Rögtön az elején megkérdezi, hová mentse az összehasonlítás során keletkező log fájlt. Ezt jegyezzük fel, mert később szükségünk lehet rá. (Persze ha konzolból nyomjuk, az meg fogja jeleníteni a jobb oldali ablakban.)

Nagyítás

Aztán dolgozik az analízis. (Menj analízisbe, Ofélia.)

Nagyítás

Imhol a végeredmény. Látható, hogy a security fa melyik ágán vizsgálódunk és mely tulajdonság egyezik, mely pedig nem. Az eltérést a mismatch jelzi.

Nagyítás

A konkrét ábrán például láthatjuk, hogy a User Rights ágon belül a System Time állítgatási jog beállításai eltérnek az adatbázisban és az éles rendszeren. Nézzük meg, hogy hogy is néz ez ki a grafikus felületen:

Nagyítás

Igen, láthatjuk, hogy a munkaasztalon lévő sablonban a megfelelő beállítás előtt egy ikon jelzi, hogy ott valami nem stimmel.
Egész pontosan az ikon a következőket jelezheti:

  • Piros körben fehér iksz: a beállítás eltér a valós rendszer és a vizsgált sablon között.
  • Fehér körben zöld pipa: a beállítás megegyezik a valós rendszerben és a sablonban.
  • Kérdőjel: A beállítás nem létezik az adatbázisban, ergo nem is került kiértékelésre.
  • Felkiáltójel: Pont fordítva: a beállítás nem létezik a valós rendszerben.
  • Nincs semmilyen jel: A beállítás egyik helyen sincs definiálva.

Például a korábban a szövegfájlban látott mismatch így jelenik meg a grafikus felületen.

Nagyítás

Természetesen a munkaterületre betöltött sablont nem csak boncolhatjuk, hanem műthetjük is. Bármelyik beállítást módosíthatjuk, majd az így létrejövő sablont exportáljuk valamilyen új néven.
Értelemszerűen ahhoz, hogy ez a menüpont megjelenjen, előtte be kell tölteni egy sablont a munkaterületre, majd összahasonlítani az aktuális beállításokkal. Utána lehet menteni.

Nagyítás

Új sablont nem csak létezőből kiindulva hozhatunk létre – igaz, ehhez már egy másik konzolra lesz szükségünk. A Security Templates snap-in-ben jobbkattintás, majd New Template…

Nagyítás

Látható, hogy ez egy teljesen üres sablont hoz létre. Miénk a terep, tetszőlegesen perverz kombinációk létrehozása előtt nyilik meg a lehetőség. Csak arra vigyázzunk, hogy magunkat ne zárjuk ki a módosítási engedéllyel rendelkező személyek közül. Onnantól ugyanis unalmas hétköznapunk egy kicsit pörgősebbre fog változni.

Nagyítás

Itt pedig azt láthatjuk, hogy a Security Templates konzolban létrehozott MacskaRugjaMeg sablont mentés után már a Security Configuration and Analysis konzol munkaterületére is betölthetjük, további fazonírozás céljából.

Nagyítás

Amennyiben a megfelelően módosított sablont rá akarjuk húzni, akkor az Analysis menüpont helyett a Configuration menüpontot válasszuk – ekkor a munkaterületen lévő beállítások rámásolódnak az aktuális számítógépre.

Nos, nagyjából ennyi. Egész jó kis segédprogram.
Lenne.
Ha a program tervezése során figyelembe vettek volna egy átkozottul reális igényt: azt, hogy a meglévő gép biztonsági beállításaiból sablont gyárthassunk. De nincs. Tessék ilyen szemmel végigolvasni az eszköz működését: mindenhol a munkaterületet exportálhatjuk, oda meg már létező sablont tudunk csak betölteni. Ez egy akkora öngól, hogy még ma sem tudom igazán elhinni. Programozástechnikailag semmibe nem került volna összedobni, a sablongyártásban pedig óriási segítség lett volna.

Érted már, hogy miért Majdnem-Herkules?

Térjünk vissza a megoldandó problémához. Van egy gép, induláskor a setup security sablonnal. Ezen begerjesztem a cluster szolgáltatást, felkonfigurálom a clustert. Innentől már eltértünk a sablontól, tekintve, hogy a telepítés/konfigurálás belerondít rendesen. Aztán jön a multi cég hardening folyamata, mely aztán végképp összezavarja a szálakat.
Nekem arra lenne szükségem, hogy mielőtt ráengedném a hardeninget, le tudjam menteni sablon formában az épp aktuális beállításokat, majd a bekeményítés után visszatölthessem a munkaterületre és ki tudjam analizálni közöttük a különbséget. Nyilván még ez sem lenne túl egyszerű, kicsit ‘tű a szénakazalban’ jellegű a munka… de valahogy így lehetne nekiállni.
Ehelyett… kinlódunk. Nem tudom lementeni a sablont, tehát maximum a setup security kiindulási pont és a hardening végső pont között tudok különbséget képezni – azaz a feladat jellege megmaradt, csak a szénakazal lett jóval nagyobb.
Illetve… trükközhetek. Felkonfigurálom a clustert, majd összehasonlítom a valós rendszert a setup security sablonnal. Ekkor megkapom azokat a beállításokat, melyeket a cluster telepítés érintett. Gyújtok egy gyertyát Szent Antalnál és reménykedek, hogy ez a halmaz nem lesz nagy – és tartalmazni fogja azt a beállítást, melynek átállítása okozza a galibát.
Most jöhet a hardening, majd ezt összehasonlítom a setup security sablonnal – de csak a korábban manuálisan kiszűrt beállításokkal fogok foglalkozni.

A megoldás kicsit olyan ’szarva között a tőgyét’ jellegű – de akár működhet is. Talán.
Ha nem, akkor kénytelen leszek felvenni a csempetépkedő kesztyűt.

ps.
Amikor az ember először morog, utána gondolkodik. A ‘secedit /export /mergedpolicy /db /cfg’ mintha pont ezt csinálná.

Kleine szívás, gute szívás

Tulajdonképpen ez az írás valamennyire kapcsolódik Al hozzászólásához. Az ember ugyanis nem úgy utál meg egy terméket vagy egy gyártót, hogy egyszer belefut egy kellemetlen hibába – az általánosabb utálathoz sokkal inkább tömérdek apró bosszúságon keresztül vezet az út.
Olyanon, mint amilyenbe pl. ma este is belefutottunk.
Egy ügyfelünk meglehetősen cifra címtárának forest root tartományát állítottuk át Windows2000-ről Windows2003-ra. (Már céloztam erre a melóra.) A tartományvezérlők HP blade szerverek.
Nyilván a munka oroszlánrésze (büdös vagy és ordítasz) az előkészítő munka volt. Összeszedtünk mindent, kezdve a megfelelő Support Pack-tól a legapróbb információig. Többek között tudtuk, hogy amennyiben a hálókártyák teamingben vannak, akkor inplace upgrade előtt szét kell őket szedni. És még számtalan apró trükköt tudtunk – de tényleg nem akarok túl sokáig ezzel macsózni.
Kezdtük a jó öreg forestprep-pel.

Megjegyzés:
Isten áldja, aki kitalálta a ‘repadmin /options +DISABLE_OUTBOUND_REPL’ parancsot. Eszméletlen mennyiségű munkától kímélt meg bennünket. Ha lesz időm, akkor majd a Technet blogba meg is írom, mi a hálálkodás lényege.

Mint a mesében, minden simán lement. Replikáció – mint kés a vajban. Alig telt el másfél óra és az ország legeldugottabb sarkában is ott vigyorgott az új séma. Jöhetett az upgrade. Távoli gépre rámásolva az i386 könyvtár, ILO porton keresztül belépve a winnt32 elindítva. Elméletileg ennek a kezdeti érdeklődés után minden interakció nélkül le kellett volna futnia. Elméletileg.
Éppen amikor kezdett gyanús lenni, hogy minden túl szépen megy, beütött a ménkű.
Feljött egy ablak, hogy a program hiányol egy francseemlékszikanevére.sys állományt egy Compaq Network Teaming Disc nevű médiáról. Alul egy browse jellegű menü, felette a lehetőségek: OK vagy Cancel.
Zavartan néztünk egymásra a kollégámmal.
– Istenbizony nem voltak teamingben a kártyák – mentegetőztem.
– De a teaming fel van telepítve… – szögezte le.
– Igen. De ki volt kapcsolva.
Vakaróztunk rendesen. A kérdéses DC nagyjából a legfontosabb DC volt az erdőben. (Azzal illik kezdeni.) Schema Master, Domain Naming Master… meg fontos replikációs csomópont.
Értelemszerűen ilyen telepítő médiánk nem volt. Lévén este kilenc után, az se volt valószínű, hogy be tudunk szerezni egyet. Azaz az OK gomb kiesik – marad a Cancel gomb. Belegondoltál? Egy marha bonyolult erdő legfontosabb tartományvezérlője behal inplace upgrade közben.
Nyilván megvoltak a rollback stratégiáink. Innen tudtuk, hogy ha ezt a DC-t – pontosabban a funkcióit – elő akarjuk varázsolni a semmiből, akkor kényelmesen megtekinthetjük majd az ablakból azokat a hajnali kukafosztogató egyetemistákat, akik még éppen megelőzik a hajléktalanokat.
Főnökünk volt olyan balszerencsés, hogy pont ekkor telefonált ránk, hogyan állunk. Nem adhattunk mást, csak mi a lényegünk. Még a telefonon keresztül is érzékelni lehetett, hogyan nyúlt meg az orra.
Természetesen nekiálltunk felszántani az Internetet. Én megpróbáltam a HP oldaláról közelíteni, kollégám pedig guglizott. Mondanom sem kell, hogy én egy abszolút érdektelen oldalra jutottam, ő viszont talált egy érdekes doksit.
Idézek belőle:

If you have Compaq Network Teaming installed, see the informations below:

  • During the Installing Network phase, the installation stops (approximately with 32 minutes left of the install to complete) and a dialog pops up specifying Insert Disk (see actual message below.)
    Please insert the compact Disk labeled ‘Compaq Network Teaming Disk’ into your CD-ROM and then click ‘OK’.
  • When dialog pops up, click Cancel for the installation to proceed. After this point, the installation proceeds uninterrupted until it is complete.

Gondolj bele azoknak az embereknek a lelkivilágába, akik szerint ez így korrekt megoldás. Nem, nem teszünk ki az ablakba egy ’skip’ gombot. Nehogymár. Szarjon csak be az a rendszergazda, hogy ha nyom egy Cancel-t, akkor lesz egy installálás közben ábrándosan félbehagyott, használhatatlan szervere. Hogy esetleg ki is írhatnánk valami információt az ablakba? Ugyan már… nyomd meg öcsém a gombot, ha bátornak érzed magad!
Természetesen ez volt a megoldás. Megnyomtuk a Cancel gombot, a telepítés pedig – a félbeszakítási szándékunkon jót derülve – simán lefutott.

Ez messze nem volt hetedhét határra szóló szívás. Olyan aprókára sikerült. De mögötte ott van egy olyan mentalitás, melyet nem tudok elfogadni. Hiába jók általában a HP vasak, hiába dicsekedhetsz szép nagy uptime értékekkel – az ilyen pofonok jobban megmaradnak az emberben. Különösen, ha nem csak egy termékcsaládnál találkozik ezzel a felelőtlen trehánysággal.

A velünk élő történelem

Szükség van WINS szolgáltatásra az Exchange 2000/2003 működéséhez?
Igen.
Fog ezen változtatni az Exchange 2007?
Igen.
Szükség lesz WINS szolgáltatásra az Exchange2007 működéséhez?
Igen.

Azért ez már valami. Mit tudhat ez a masztodon, hogy ennyi évvel kitalálása után is még ilyen szívósan tartja magát?
Nos, azt tudja, hogy ismeri az emberi természetet. Tudja, hogy lusták vagyunk. Ha nem is mindannyian, de valaki valahol biztos lusta lesz begépelni azt, hogy ‘envagyok.a.falurossza.egyedul’, inkább megpróbálkozik az ‘envagyok’ címmel.
Emellett azt is tudja, hogy egy ekkora kódtömegben biztosan lesz valahol olyan eljárás, mely rövid név alapján fog keresni.
Ennyi már elég is a túléléshez.

Nézzük meg, milyen viszonyban is voltak egymással: WINS és Exchange 2000/2003 rendszerek.
A link szekcióban található egy KB cikk, abban bizony feketén-fehéren ott áll, hogy Exchange rendszerekben igen-igen erősen ajánlott WINS névfeloldás használata.
Miért is?
Például azért, mert

  • Az Exchange2003 kódjában több helyen is előfordul rövid név alapú DNS névfeloldási próbálkozás. Természetesen, ha jól vannak konfigurálva a DNS kliensek, akkor ez nem jelent gondot. De általában nem mindenki DHCP-s, különösen a szerverek nem – márpedig ha nincs jól beállítva a DNS suffix az Exchange szerveren, akkor bizony problémák lesznek.
  • Ennél sokkal csúnyább, hogy a kódban bizonyos helyeken – pl. setup – olyan esetek is előfordulnak, hogy szó sincs DNS névfeloldásról, a rutin egyből Netbios API-t használ névfeloldásra.
  • Végül a legszebb. Tudjuk, az Exchange az egyes szerverek konfigurációs adatait a címtár konfigurációs névterében tárolja. Ezt úgy kell elképzelni, mintha minden szervernek lenne egy foldere, amely alatt gyülekeznének az adatai. Mi is a folder neve? Bizony, az Exchange szerver gép Netbios, azaz rövid neve.
    Értelemszerűen következik, hogy óvakodni kell attól, hogy ne legyen két azonos Netbios nevű Exchange szerver az organizációban – hiszen akkor bizarr módon keverednének össze a konfigurációs beállításaik.
    Hogyan tudnám ezt garantálni? Azt tudjuk, hogy a konfigurációs névtér erdő szintű. Ebben az erdőben elméletileg számtalan site, számtalan subnet található, tetszőleges mennyiségű Exchange szerverrel. Viszont ha nem használok WINS-t, akkor az egyediség csak Netbios broadcast segítségével ellenőrizhető. Meddig terjed a Netbios broadcast határa? Amíg egy router azt nem mondja, hogy coki, eddig és ne tovább. Ergo kell az a fránya WINS, mert az egyből kiszűri, hogyha már létező Netbios nevet akarok még egyszer kiadni, abban a körben, ahol össze vannak löve a WINS szerverek.

Ezzel az első ‘igen’-t ki is tárgyaltuk.

Nézzük, milyen változások várhatóak az Exchange2007-ben. Jó hír, hogy a problémák kétharmad részét megszüntették. A kódból kivették mind a közvetlen Netbios API hívásokat, mind a rövid név alapján történő DNS névfeloldási kérelmeket.
De a harmadik esettel nem tudtak mit kezdeni. Ha kompatibilisek akartak maradni a korábbi Exchange2000/2003 rendszerekkel, akkor meg kellett hagyni a konfigurációs névtér Exchange alterének szervezeti felépítését. Innentől viszont szükség volt a rövid nevek egyediségére, organizáció szinten. Pont.
Ergo, igen, dolgoztak a problémán, nagy részét eliminálták. Ez volt a második ‘igen’.

A harmadik ‘igen’-t már gondolom, nem kell részleteznem. Ha bízom magamban és biztos vagyok benne, hogy nem adok azonos Netbios neveket az Exchange szervereimnek – sem én, sem a worldwide cég 235 másik adminisztrátora -, akkor szemétre a WINS szerverrel.
De ha megpróbálok racionálisan gondolkozni – néha érdemes, megéri -, akkor mondhatom azt, hogy a WINS szerver alkalmazás alig kér enni, békésen megfér bármelyik tartományvezérlőn: miért ne hagynám meg? Különösen, ha nem csak azt garantálja, hogy nem lesz két azonos nevű Exchange szerverem, hanem azt is, hogy egyáltalán nem lesz két azonos rövid nevű gépem az erdőben.

Link szekció:

  1. Windows 2000 Server Windows Internet Naming Service (WINS) Overview
  2. Windows Server 2003 Windows Internet Name Service (WINS)
  3. DNS, DHCP, WINS – WINS
  4. Exchange Server 2003 and Exchange 2000 Server require NetBIOS name resolution for full functionality
  5. David Lemson írása a blogjában

Itt sincs, ott sincs

Megőrjít.
Van egy kliens gépem. Ezen akarok futtatni egy szkriptet, mely távoli AD szájtok felhasználóinál módosítana display nevet. (Vbscript + ADSI.) Az adatok Excel táblában vannak.
Lefuttattam az egyik szájtra, a nevek átíródtak. Megnéztem ADUC-ból, tényleg.
Lefuttattam ugyanazt a szkriptet a másikra, nevek látszólag átíródtak. ADUC – mégsem íródtak át. Átfutottam az összes DC-t, sehol sem íródtak át. Picit átírtam a szkriptet, hogy most csak lekérdezze az értékeket – és tényleg nem íródtak át. Beleraktam még vagy ötször a setinfo-t, biztos, ami kurvafix – és kiegészítettem azzal, hogy írás után olvassa is vissza ADSI-n keresztül az értékeket és írja ki fájlba. Szkript lefutott, és a megváltozott értékeket írta ki. Gyorsan ADUC – sehol sem volt változás. Site-site replikáció megrángatása, újból körbenézés, semmi. Lefuttattam a szkriptet csak olvasó módban – a régi értékek jöttek vissza.
Hihetetlen.
A kliens gépről egy gyors próba, ldp-vel megváltoztattam a távoli szájt felhasználójának az adatát – és így működött, tehát se jogosultsági, se tűzfal probléma nincs. Ha ugyanezt egy nyomorult háromsoros vbscript-ből csináltam, akkor bezzeg nem ment.
Bele fogok dilizni. Ez az egy lépés van hátra abból a holland projektből, melynek már a nevétől is feláll a szőr a hátamon. És itt, az utolsó lépésnél jön be egy ilyen X akta, amikor már nem vágyom másra, mint hogy lezárjam ezt a szutykot.

Miután jól kisírtam magam, nekiálltam gondolkozni. Mi lenne például, ha kitörölném a bűvös ‘on error resume next’ sort?
Hoppá. Rögtön az elején befigyelt egy hiba:

Run-time error ‘-2147016693 (8007200b)
Automation Error
The attribute syntax specified to the directory service is invalid

Na, vajon mi lehet ez? Erős a gyanú, hogy adathiba, hiszen a szkript más szájtra lefutott. Kezdjünk játszani. Első körben csak a displayname értékét írtam ki – nem volt hiba. Jött a keresztnév, nem volt hiba. Jött a vezetéknév – és vele együtt a hiba. Hmm… ennyire kényes lenne az az sn attribútum?
Ránéztem az excel táblára – és letéptem az első sor csempét. Az adott szájton nem mi adminisztrálunk és a fiúk nem vacakoltak, a teljes nevet a keresztnévhez írták – azaz az sn attribútumba üres mezőt kellett volna betölteni. Ettől borult meg a szkript futás közben – de az onerrorresumenext továbblökte, mintha mi sem történt volna. Nem is történt semmi. Kiírás sem.
Oké. Akkor tegyünk bele egy vizsgálatot és ha üres a mező, akkor a kérdéses mezővel ne történjen semmi, de a sor többi mezőjét írja ki. Jó lesz ez? Nem biztos. Lehet, hogy az ügyfél törölt egy értéket és szeretné, ha az el is tűnne az AD-ból. Jó, akkor írjunk ki egy “”-t.
Nos, aki azt hiszi, hogy az oChild.attributum = “” lesz a jó megoldás, az még menjen vissza egy kicsit a homokozóba. Ugyanis pont ez a forma adta a fenti runtime error-t.
Igenám, de akkor hogyan lehet törölni egy attribútum értékét? Gugli.
És végül itt van a megoldás. Annyira szép, hogy alig hiszem el.
Tudni kell, hogy az AD-ba lehet cseppeként is írni. Ilyenkor csak a megváltozott attribútum értéke utazik a dróton, azaz spóroltunk egy csomó sávszélességet. Cserébe kicsit bonyolultabb a szintakszis.
Ilyen: oChild.putex X, “attributum”, valtozo,
ahol az X a helyzet kulcsa. Ugyanis ha X=2, akkor kiírás következik, ha X=1, akkor törlés.
Tehát a kérdéses kódrészlet:

If Trim(Cstr(Cells(sor,1).value)) = “” then
oChild.putex 1, “displayname”, “”
else
oChild.putex 2, “displayname”, Trim(Cstr(Cells(sor,1).value))
EndIf

Dögi. Futtassuk meg.
Megint ugyanazt a runtime error-t kapjuk. WTF?
Nos, ismét jött egy kis Gugli – majd megint lekerült a falról egy sor csempe.
A putex-es verzió ugyanis tömböt kér paraméternek. Miért? Csak. Akkor, amikor törlök, akkor nem is igazán kell neki érték, a “” bőven megteszi. De akkor, amikor módosítok, akkor bizony tömbbe kell rakni a változót.
Így fog kinézni a sor:
oChild.putex 2, “displayname”, Array(Trim(Cstr(Cells(sor,1).value)))
És ez már tényleg működik.

Illetve…
Boldogan engedtem rá a felturbózott szkriptet a böszme nagy excel táblára – és pár perc múlva megint runtime error-t kaptam. Egy kicsit megrugdostam az asztallábat majd nekiálltam nyomozni. Hiába. Minden teljesen rendben volt. Kínomban kimásoltam a táblázatból a dn értéket, benyomtam az ldp-be – és megfeküdt az is tőle. Nocsak. Nézzünk be az ADUC-ba.
Basszus. Amíg szarakodtam a szkripttel, addig törölték a felhasználót.
‘On error resume next’ visszakapcsol. Anyátok.

Mentális erő

A napokban kihelyezett okítás van nálunk, cluster témakörben. Nyilván az egészet nem fogom beírni, de a tegnapi napból egy levezetés megragadta a fantáziámat.
Előre jelzem, hogy erősen egyszerűsíteni fogok. Most egy konkrét erőforrásról lesz szó. Feltételezem, hogy ez egy fontos erőforrás, melynek ledőlése átmozgatja az erőforrás csoportot a másik node-ra – azaz failover következik be. Az erőforrás tulajdonságlapjának Advanced fülén lehet beállítani az advanced paramétereket. Ilyeneket:

  • Threshold / Period [sec]: a period időtartam alatt az erőforrás hányszor halhat meg, ahhoz, hogy kikényszerítsen egy node váltást.
  • Pending time out [sec]: mennyi ideig várjunk az erőforrásra ahhoz, hogy döglöttnek nyilvánítsuk.

Ránézésre semmi különös. De ha jobban belegondolunk, mégis van itt egy kis rafinéria.
Mondjuk legyen az erőforrás egy service. A küszöbérték legyen 3, a period 900 sec, a timeout 180 sec. (Ezek a default értékek.) A szerencsétlen szolgáltatás beragad – azaz az ‘Is alive’ hibásnak jelzi. Kivárják a 180 másodpercet, küszöbérték számláló 1-re áll. Megpróbálják újraindítani a szolgáltatást, de az ostoba vigyorral a képén továbbra is csak áll, újabb 180 sec múlva lép a küszöbérték kettőre és még 3 perc kell ahhoz, hogy az erőforráscsoport áttegye a seggét a másik node-ra. Átteszi? Igen, mert összesen 3*180 sec telt el, azaz benne vagyunk a 900 sec perióduson belül.
Igenám, de mi van akkor, ha az adminisztrátor azt mondja, hogy ez egy Exchange szolgáltatás, itt a timeout érték igen magas: vegyük fel 350 másodpercre. Tessék végiggondolni.
Pusztán szellemi erővel sikerült hazavágnunk a clustert, legalábbis a szolgáltatásra nézve. A hiba biztos megállapítása 1050 sec lesz, miközben az erőforráscsoport csak akkor fog vándorolni, ha a hibára jellemző mintázat 900 másodpercen belül történik meg. Ez a cluster a büdös életben nem fog clusztogni. (Mellékes folyomány, hogy emiatt nem lehet Exchange szerveren kiemelkedően magas rendelkezésre állást bevállalni – hiszen egy beragadt IS service biztos detektálása 15-20 percet is igénybe vehet.)
És a minta nem egyedi. Van egy másik beállító panel. Ez arra vonatkozik, hogy ha egy bizonyos intervallumon belül (period) volt x darab failover, akkor hagyja abba, mert ez az erőforráscsoport már a boldog vadászmezőkön nyargal és nem illik rugdosni a döglött oroszlánt. Namost, minden failovernek van egy jellemző ideje: ki kell nyírni a döglött erőforrásokat (szolgáltatás, egyebek) és el kell indítani a másik node-on. Exchange esetén ez megint nem kis idő. Ugyanaz a hibalehetőség: ha az x, megszorozva a failover idejével, több, mint a period érték, akkor ez a cluster még a harmadik világháború után is failoverezni fog az embernélküli sártekén.
Szép, mi? Ismerek egy csomó Microsoft terméket, de egyiknél sem emlékszem olyan GUI beállítási lehetőségre, amelyikkel ki lehet nyírni magát a terméket. (Uninstall nem játszik.)
Megint valami, amihez kevés a next-next-finish admin hozzáállás.

Ezt ne próbáljátok ki otthon

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.

Penge III.

Aludtam rá egyet és lenne néhány megjegyzésem. (Valahogy úgy érzem, ekkorát azért nem kellett volna szívnom.)

1. A hp mérnökei ennyire nem lehetnek idióták. A rendszert nem ilyen felhasználásra tervezték – hivatalosan smartstart cédéről kellett volna telepítenem az oprendszert és akkor a problémák 89 százalékát elkerültem volna.
Más kérdés, hogy a kollégák szerint az a telepítés létrehoz egy plusz partíciót, mely később zavarokat okoz az üzemeltetésben. Ehhez viszont nem tudok hozzászólni.

2. De ha már így kell telepíteni – és fel is lett nyomva közel harminc szerver -, akkor már igazán ki lehetett volna jelölni egy terminál szervert, ahová felkerülnek a preparált image-k (floppy a raid kontrollerrel, cédé a megfelelő driverekkel) és ahonnan lehet a hálózati ILO porton keresztül telepíteni. Telepítési doksiról nem is beszélve.

Penge II.

És amikor már azt hinném, hogy vége, a történet váratlanul folytatódik.

Ma délután kiderült, hogy elböktem, nem windows 2003 server kell rá, hanem Windows 2000. Gond egy szál sem, már mindent tudok a cuccról, kiszaladok, felhajítom és uzsonnára már otthon is vagyok – gondoltam én, a naív.
Kimentem, rákapcsolódtam az ILO portra, virtual media (telepitő cédé) felkonnektál, gép restart a remote konzolból. Ugyan mondták, hogy az ILO piszok lassú, de azért ennyire… másfél órán keresztül másolta a fájlokat… majd bizalmasan közölte, hogy ‘édes öregem, ez lódobogás, nem vincseszter – telepítés befejezve‘. Hogy ne érezzem úgy, hogy mindent ő csinál helyettem, megnyomhattam az F3 gombot.
Pusztán csak az mentette meg a blade-t a kipusztulástól, hogy véletlenül jelen volt az ügyfél egyik informatikusa is.
Persze, tudom, akkor van ilyen, amikor nincs driver a scsi kontrollerhez. De nem lehetne ezt esetleg az elején, másfél órával a kiírás előtt lecsekkolni?
No, mindegy, driver keresés. Szerencsére kiismertem már a hp oldalát, ez tényleg sitty-sutty volt. Floppy is volt nálam, rámásoltam a kitömörített cuccot. Indulhatott az újabb install. Ez ugye a gyorskezűek sportja, mivel gyorsan meg kell nyomni az anykey-t amikor cédéről akar bootolni, majd egyből az F6-ot, lehetőleg tizennégyszer és közben bedugni a floppyt, mert sohasem lehet tudni.
Megtörtént. A setup tervező ergonómiai zseni nyilván nem érezte fontosnak, hogy adjon is valami visszajelzést arról, hogy tudomásul vette a külön driver beadagolási szándékomat. Jó 25 percig rághattam a körmömet, mire a sok fájlmásolas közben nagy kegyesen odavetette, hogy ‘mondjad, paraszt, hol is az a driver‘. ‘A floppyn, instállom‘ – esedeztem. Felismerte, kijelöltem, nekiállt másolni – majd pár perc múlva közölte, hogy ez biza korrupt. Szerencsére volt nálam másik floppy, arra is kimásoltam, az már jó volt neki. Újabb rohadt hosszú másolás és végre megjelent a partícióformázós menü. Megkapta a magáét, folytatta a másolást, én pedig indultam volna pezsgőt bontani. Botor ötlet volt.
A virtual media nagy percei (órái?) következtek. Úgy kezdődött, hogy a telepítő kiírta, hogy bizonyos fájlok korruptak. Egész addig nem volt gond, ment a másolás. Választhattam, hogy átlépem-e őket. Mivel mindegyik fájl úgy kezdődött, hogy tcp*, inkább kilőttem a faszba a telepítést. Erről a cédéről sokszor szoktam telepíteni, biztos voltam benne, hogy a cédé nem korrupt. (Átmágneseződött a villamoson, hehe.)
Van az a hülye unicode bug a w2k-nál, de az csak akkor jön elő, ha magyar nyelvet választunk – erről itt még szó sem volt.
Már a floppynál is büdös volt nekem a virtual media, de itt már igen sanda szemmel néztem rá. Megpróbáltam megsasolni, erre egyből lefagyott a mimóza. Csak a host gép teljes újraindításával jöttem egyenesbe. A telepítésnek persze megint lőttek.
Taktikát váltottam. A virtual médiával csináltam egy image-t a host gép vinyójára és azt mountoltam be cédéként. Új telepítés, újból másfél óra várakozás a másolásnál.
Látszólag megette, eljutottunk a grafikus setuphoz. Mentem volna a pezsgőért, de megint rámküldött egy hibaüzenetet. Azt mondta, nem találja a netmon fájljait a cédén. Mutatnám neki a cédét, de nincs. Nadehát… eddig volt!? Onnan dolgozott. De most már nincs.
Na, mindegy, kell a francnak netmon, úgyis packetyzert fogok használni, escape. Az igényvisszafogás egyoldalú volt – a telepítő egyre több fájlt követelt, a cédé meg beintett. A sokadik escape után bátran lemountoltam mindent, aztán vissza és újból volt cédém, ment vidáman tovább a telepítés.
Olyan is lett. Amikor elindult a rendszer, egyből el is dobott kapát, kaszát – mondván igen fontos dll-ek hiányoznak, szervízek kaput.
Jó. Repair install. Erre a netmonnál ugyanúgy elment a cédé málnázni. Körülbelül tíz-tizenötször le- és felmountoltam az image-t, de nem hatotta meg. Dühösen nyomtam egy escape-t, de rögtön utána nem talált meg még egy állományt. Ugyanaz. Ekkor lemountoltam a floppy-t is – és rögtön megtalálta a cédét! Hoppá. Itt a kutya sírja. Ez akár jó telepítés is lehet, hiszen egyedül a netmon dll-jeit hagytam ki, azt meg legfeljebb újratelepítem. Izgatottan nyomtam meg a finish gombot, és… kékhalál. A franc se gondolta volna, hogy a netmon ilyen fontos ember.
Oké, szórakozzon a fene a repairrel, most már tudom a trükköt, mikor kell bedugni a floppyt és mikor kell kihúzni (kamaszkoromban ezt kirántott húsnak hívtuk), szóval full install, előlröl.
Igaz, közben telefonált a lányom, hogy az orvos azonnal szemészet ügyeletre küldte, ő viszont nem megy sötétben egyedül a nyolckerbe – de a szemem sem rebbent. Van annak a gyereknek anyja is. Igaz, pánikközeli állapotban szakdolgozatát írja otthon, de tuti, hogy jól fog esni neki egy szellőztető séta.
Még az sem zavart, hogy a brutális Dataplex klíma miatt éles pengékkel lett tele a torkom. Most már a vadászszenvedély hajtott.
Eldúdoltam, hogy

Este van már, nyolc óra
Lesz hó végén túlóra.

Majd újabb telepítés. Ekkor már nem kértem netmontot. És vigyorogva vártam, hogy egyből megtaláljon mindent, hiszen időben lemountoltam a floppyt. De megint elvesztette a cédét. Jeges kéz markolta össze a szívemet. Kínomban visszamountoltam a floppyt, lebontottam a virtuális cédét, majd visszacsináltam mindent: floppy le, cédé fel. Leokéztam és innen kezdve megtalált minden fájlt.
Ennek a dögnek lelke van. Feneketlenül sötét.
De végre eljutottunk a finish gombhoz. Megnyomtam. Kékhalál. Mint az előbb.
Nyüszítettem egy kicsit, majd reseteltem a gépet, reménykedve a csodában. Megjött. A gép csodálatosan felállt.
Az a kékhalál csak olyan búcsúüzenet lehetett: köszönjük szíves érdeklődését, kitartását, Ön egy velejéig makacs ember, igazán megérdemel egy kis extra bónuszt a végén.

Azok is emberek voltak, akik kitalálták, megcsinálták, legfőképpen eladták ezt. Azoknak is kellett legyen anyjuk. Én meg legszívesebben összehoznék egy randevút a kedves mama és egy talicska aprómajom között – aztán le a prüdériával.

Nos, azért még innen is beletellett pár órába, mire ebből a gépből jóképességű (virnyákölő, foltok) DC lett egy távoli szájton. Szokás szerint elvoltam a windowsupdate-tel, bár most csak kicsit szívtam: időnként belassult, aztán a 26 foltból 12 failed lett, lehetett újrakezdeni… nem egy nagy szopás, de éjjel fél tizenegykor, amikor már ezerrel akarok hazamenni, felettébb bosszantó.
Kellett még egy kicsit küszködni a tűzfalakkal is, de végül taknyos angolnaként csúsztam át köztük.
Holnaptol jöhetnek a hollandok.

Tanulság:
Ha legközelebb valaki megkérdezi, hogy hány órát tervezzen egy egyszerű windows szerver telepitésére, vasvillával fogom kikergetni a határba.

Happy end:
De már jó, minden nagyon jó. Kiléptem a Dataplexből és felsikítottam: sűrű pelyhekben esett a hó. Gyors döntés: taxi rendel, otthon laptop ajtóból repült a fotelbe, a konyhában 2 cent unikum, szintén repült, és irány havat fényképezni.
Hajnal egykor. Ahogy kell.

Penge I.

Ügyfélt berángatták a málnásba. Van egy saját Active Directoryja, benne saját Exchange organizáció. És van egy másik, worldwide Exchange 5.5 organizáció, ezen keresztül tartják a kapcsolatot a multi anya-, illetve leánycégekkel. Ebből a kettőből kell egyet gyúrni.
A projektnek lassan vége, de ez csak annyiból nyilvánul meg, hogy egyre idegesebb vagyok. A munka, az inkább szenved, mint halad.
Most például baromi hamar kellett volna egy blade szerver, de a tartalékhoz nem lehet hozzányúlni, mert… nna, ez egy külön történet. Nem lesz megíratlan.
Ügyfél valahonnan – szószerint a föld alól – beszerzett egy szervert. Hurrá. Kicsit zavaró, mondjuk, hogy mindkét emberünk, aki már csinált ilyen blade installálást, világvégi ügyfélnél szívja a nagy teszi dolgát. Ló nincs, menjél te, Joep.
Dataplex. (Az utóbbi időben kissé fel van túrva, csak nem a Google költözik ilyen nagy erőkkel?)
Őrök. Megálltam a fémdetektor előtt, kabátomban egy mozgó iroda. A táskámat átküldtem mellette, aztán némi gondolkodás után a kabátomat is le akartam venni.
– Azt ne vegye le – figyelmeztetett az őr.
– De tele van revolverrel meg bicskával! – reklamáltam.
– Akkor pakoljon ki mindent! – komorodott el.
Nem valami vicces fiúk. De megérdemlem, anno az első pár alkalommal rendszeresen megittam a kávéjukat. Úgy figyelmeztettek a kollégáim, hogy nem, az nem az ügyfeleknek szóló ingyen kávé. Szerintem meg megérdemelték, milyen marhaság már, hogy egy ilyen helyen, ahol az állandó neonfényben infomunkások robotolnak éjjel-nappal, nincs kávéautomata?
No, becsekkolás megvolt, a pengeszervert is megtaláltam. Kicsomagoltam. Azannya. Jól néz ki. Bedugtam, bekapcsoltam, jé, működik. Találtam ILO fütyit is, rácsatlakoztam. Usernév, jelszó,… hibás. Biztos elgépeltem, nézzük meg jobban azt a cetlit. (Minden bladen van egy azonosító cetli, a legfontosabb adatokkal.) Újabb próbák. Az ötödik sikertelen kísérlet után – amikor a jelszókérő ablak már jó félóra után resetelt – elkezdtem gondolkodni. Nézzük, más szerverekkel mi a helyzet. Pepita. Valamelyikkel ment a csatlakozás, valamelyikkel meg nem. Aztán kábelcsere után mindegyikkel ment, csak az újjal nem. (Basszus, hogy mindig szertehagyom a saját bejáratott ethernet kábeleimet.)
Sok-sok telefon, kiderült, hogy az ügyfél valami bemutató példányt talált – nyilván szénné volt konfigurálva. Kezdtem érezni a hisztéria kaparását ábrándos lelkemen. Önmagában a blade konfigurálás is mocsáros ismeretlen terület számomra, de egy szanaszét állított blade egyenesbehozása… durva. A jelszót sajnos senki nem tudta, de kolléga szerint ha hozzáférek a boot képernyőhöz, akkor átállíthatom. Ez jó hír, mert ez újabb tipusú blade, az ILO fütyin nemcsak RJ45 és soros port van, hanem monitorcsati és két USB port is. Apró szépséghiba, hogy USB billentyűzet harminc kilométeres körzetben szál se, egérrel meg nem tudom megnyomni az F9-et.
Ekkor jött egy leírás a hp-tól, hogy hogyan kell egy ilyen masinát széthekkelni. Komoly darab. A lényeg, hogy darabokra kell szedni a vasat és DIP kapcsolókkal matyizni. Utoljára 386-os alaplapon játszottam ilyet – viszont hatásos. A fizikai erő mindig győz.
De végre elértem az első ILO portját. Notebook ráment, virtual media bekonnektálódna – ha a volna ott nem volna. Error. Így viszont nem tudtam neki cédét tolni a pofájába. Véres hibakeresés, gépemen java 1.4.2, az elég, 128bit ssl engedélyezve, tűzfal kikapcs… miazapjakasza kellhet még neki? Nézzük, ha nem teszik neki szemből, mit szól, ha hátulról? Nemcsak fütyis ILO létezik, van ennek DHCP-s network ILO portja is. Ehhez csak meg kell találni a DHCP adatbázisban. Ami nem nagy ügy, a gép neve rajta van a névjegyen. Csakhogy ilyen nevű gép nincs az adatbázisban. Nyilván a fiúk a gépnevet is átállították. Elméletileg rá is lehetne hibázni, de ezeriksz bejegyzés közül kellene egyet eltalálni…
Újból hívtam a kollégát – és átváltottunk advanced üzemmódba. Azt mondta, hogy húzogassam ki-be a blade-t (amíg el nem sül?), kapcsolgassam ki-be, cseréljek újból hálókábelt, áldozzak kecskét keresztútnál. És a modern technika bevált, egyszercsak megjelent a virtual media, az első ILO portos csatlakozásnál.
Hurrá. Telepítő CD gyorsan bemountol, Windows2003 szerver felugrott, jöhettek a beállítások. Itt kell megemlékeznem a remote console java felületét megalkotó team tagjainak anyjáról. Mindkettőről. Rémes. Két egérkurzor van: egyik a virtuális gép konzolján, a másik a host gépen. Elméletileg a határvonalon kellene váltani. Gyakorlatban nemritkán a virtuális kép közepén átvált külső kurzorra, elérhetetlenné téve a fél képernyőt. Ideges egérrángatás után lehet csak rendbetenni a kurzorokat – pár percre. Még jó, hogy az ideges rángatás ekkor már nagyon ment.
Mint kollégától később megtudtam, ezt úgy hívják, hogy valami double cursor. Az a trükkje, hogy akkor is ilyen módban indul a konzol, ha nem ezt választom ki.
De legalább már van windows. Apró szépséghiba, hogy hálókártya driver, az nincs. Ha lenne a gépen floppy v. cédé meghajtó, ha lenne telepítő médiám, ha lenne USB kulcsom… ha-ha. Állítólag a két kollégának van valahol egy image fájlja, amelyiket bemountolva van egy könyvtár, amelyikben… a kulcsszó sajnos az, hogy valahol – tehát nem itt.
Viszont kolléga szerint el kell menni a hp oldalára, sitty-sutty két kattintás és már lent is van a driver. Átdugtam a gépem, hp.com, gépnév beír, windows2003 network driver kategória kiválaszt, 1.1 MB, le is tekert egyből. De hogyan fog ez átkerülni a blade-re? Ha lenne floppy lemezem… izé… És győzelem, a táskám egyik eldugott zsebébe valamikor beszorulhatott egy. Bedugtam a hős floppyt a notebookba, elég nehezen ment be, de a rendszergazda vagy okos vagy erős. Itt az utóbbi játszott, mert nem néztem meg és a floppy írásvédett volt. Megpróbáltam kiszedni, de beszorult. Megrántottam, remekül kijött – csak a vaslemez maradt bent a drive-ban. Volt egy floppy meghajtóm. Túrtam még a táskámban és megtaláltam a hős csipeszt is. Kihalásztam a fémcsúszkát, de aznap ennyi maradt az összes sikerélményem.
Majd holnap, lemezekkel, írható cédékkel. Kipihenten.
Jó. Új nap. Délutánra jön a kolléga bekötni, addigra már hálókepesnek kellett lennie. Ez már nem lehet nagy ügy, csak felrakok addig egy tetves drivert. Cuccot kimásoltam floppyra, floppyt bemountoltam, ql. Program elindult… és mi ez? Feltelepített egy virus throttle progit… és ennyi.
Visszamentem a hp oldalra, és tényleg, virus throttle a neve a driver szekcióban lévő cuccnak. Azt hittem, hogy csak egy hülye név, de nem, ez tényleg egy vírusgyötrő valami. Driver? Az, nincs.
Itt jutottam olyan hisztis állapotba, hogy elfelejtettem gondolkodni. Egy kicsit rugdostam Döncit, a páncélszekrényt, majd felhívtam kollégát, hogy miafrancért mondta, hogy ne hozzak smartsmartot és honnan a francból szerezte be anno a drivert. Nem tudta, de adott egy jó tippet – az egyik blade pont ilyen, nézzem meg rajta a hálókártya típusát, aztán irány a net.
Google. Kidobott egy találatot, driverguide. Hülye fejjel belementem a regisztrációs folyamatba (tizennéhány szájbanyomott form egymásután, mindenhol kötelező mezőkkel), amikor eszembe jutott, hogy itt már jártam egyszer. Kétszer. Szóval a nagy titok: a usernév _mindig_ driver2, a jelszó pedig all. Ne szopjatok a formmal, inkább hasítsatok be. Sajnálom driverguide srácok, értem én, hogy az ingyenes adatbázis üzemeltetéshez kell egy kis mellékes – de ez már túlmegy minden határon.
No, mindegy, a google adta linken ott fityegett a driver. Lejött, mint a vakolat. Kábel vissza a blade fütyijébe, a cucc floppyn keresztül átsuhant – aztán kiderült, hogy w2k driver a szentem, a telepítő elküldött a búsba.
Legszivesebben mentem is volna. Mindenesetre Alvint dúdolgattam, különösen az a sor ment nagyon, hogy ‘basszameg, basszameg‘.
Visszatéptem a netre, driverguide, keresés, vazze… semmilyen w2k3 driver nincs ehhez a kártyacsaládhoz.
Még egyszer benéztem a hp-hoz és véletlenul nem jól gépeltem be a blade nevét: ‘hp bl20p g3′ helyett azt írtam, hogy ‘hp bl20 g3′ – és egyből jött egy csomó driver link. Igaz, hálókártya nem volt köztük, de vérszemet, azt kaptam: rákerestem direktben a hálókártya típusára, ugyanazon az oldalon. És ott volt: w2k3 driver. Igaz, a vasak között nem volt felsorolva ez a konkrét blade, de kicsire nem adunk. A szokásos módon átjátszottam a virtuális floppyra, felment és győzelem. Délután fél kettő. Kettőre jött a kolléga és jópofizott, hogy mióta vakarhatom itt a hasamat. Vagy lentebb. Hiszen ma csak egy drivert kellett felraknom.
Nem akartam mondani neki, hogy pont csak annyi szabadidőm volt az érkezéséig, hogy lemossam a habot a szám széléről.

Lucky search

Ma éppen fejtágításon ültem. (Hogyan implementálta holland-francia anyacégünk az ITIL-t és mi változott legutóbb a folyamatkezelő programunkban…) Aztán csörgött a telefon, hogy leállt egy szerver az általunk támogatott egyik kórházban.
– Legalább a lélegeztetőgépek vannak rajta? – kérdeztem vissza.
– Majdnem – jött a tömör válasz – Gyerekosztály, diagnosztikai adatok.
Tartalékszerver, install cédék, irány a kórház. A helyszínen egy elgyötört Oracle szakértő fogadott. Hogy ilyet még nem látott és csak félnapos mentés van. És tényleg, ilyet még én sem láttam. A szerver látszólag működött, de ha bármilyen szervízt álltam neki piszkálni MMC konzolból, hosszas tökölődés után kiírt egy nem túl információgazdag szöveget (’Letelt az idő, kötsög!’) és ennyi. Eventlogban semmi üzenet. Annyit megtudtam,hogy tegnap volt egy áramszünet, a szünetmentes lekapcsolta a gépet, visszakapcsolták és azóta ez van. A szervízként futó Oracle alkalmazás elérhetetlen. Az összes többi szervízzel egyetemben.

Az első körben víruskereső megállít, a registry RUN kulcsa alatt megnéztem, milyen processzek indulnak, ezeket leállítottam, de semmi hatása sem volt. Átfutottam, vannak-e egyáltalán patchek a gépen – voltak. Na jó. Akkor még futok egy kört a neten, ha nincs semmi, akkor SP4 újrarakás, ha az sem segít, akkor gép újrahúzás. (Az ITIL egyik fontos momentuma, hogy incidens esetén amilyen gyorsan csak lehet, vissza kell állítani a szolgáltatást. Ha kell, workaround bedobásával. A probléma okának megkeresése már egy másik, hosszabb folyamat része. Nem is beszélve a kiküszöbölésről.) A dokkerek beletörődtek a fél napos adatvesztésbe, bár nem voltak boldogok.
Szerencsére volt egy event ID-m. Na nem az eventlogban, csak egy üzenőablakban. Irány az eventid.net – és már megint nem érhető el. Gyakorlatilag 1 hónapja áll. Van valakinek infója, mi történhetett a fiúkkal?
Oké, jöhet a Microsoft – pedig nem igazán kedvelem a support oldalt. Szvsz elég béna. Egy értékelhető találatot kaptam, de az is elég indifferensnek tűnt. Azt mondta, hogy ha .net alatt fejlesztettem egy szolgáltatást és rosszul használtam bizonyos függvényeket, akkor annak lehet ilyen üzenet a következménye – de csak annál a szolgáltatásnál. Megoldás: telepítsük a .net sp1-et. Isten látja lelkemet, nem szokásom dotnet alatt szolgáltatásokat fejleszteni. A szerveren sem volt fent még a runtime sem.
Maradt a google. Itt már több találatot kaptam – de ezek is falsnak tűntek. Egy csomó oldal MS programok hibáira utalt. (Úgy látszik, a fiúk is kedvelték rosszul használni azt a függvényt.:) Egyre kedvetlenebbül futottam át a találatokat, a harmadik lap után már ritkán szokott értékelhető infó akadni.
De nem most. Belefutottam egy fórumba, onnan pedig ebbe a linkbe. Bingó – legalábbis annak látszik.
Azt mondja, hogy amennyiben van fent egy APC 6.x verziójú UPC managerprogram, akkor az hajlamos arra, hogy áramkimaradás utáni újraindításkor megbolonduljon és rejtélyes hibákkal szórakoztassa a rendszergazdát. És tényleg – a gépen van egy APC progi és tényleg volt áramkimaradás okozta újraindítás. Sajnos a program verzióját nem tudtam megnézni, mert nevet és jelszót kért – az az ember, meg aki telepítette, már rég elment, meghalt, nemet változtatott és egyáltalán nem is létezett. (Ezt a kórházat nem túl régóta kezeljük, egy csomó gépet – köztük ezt is – igazából még át se vettünk.) De a hozzáállásból sejthető volt, hogy erre egyszer felraktak egy őskori változatot és a kutya sem foglalkozott azzal, hogy azóta az APC kiadott egy kritikus foltot. Azaz jó eséllyel 6.x lehet rajta.
Nosza, safe módban elindít, APC szolgáltatások disabled – és megette. Ez mindenképpen jó jel. Gép újraindít, oracle szolgáltatás megpöcköl – és indul, mint a versenymalac. Oracle szakértő rávetődik, tíz perc múlva boldogan közli, hogy van mentés, el lehet indítani az adatbázist. És tényleg. Minden működik rendesen.
Sikertörténet. József sír.

Ja, és hogy miért lucky? Mert egy farok voltam. Ha nem találom meg a cikket, nyomtam volna rá az SP4-et ész nélkül. Pedig egy safe módban történt újraindítás egyből megmutatta volna, hogy vagy driver vagy service a bűnös.

[Update]
GT szólt, hogy nála megy az eventid.net. Otthonról megnéztem, és tényleg, nekem is ment. Ma délután javult volna meg? És lám, a kisgonosz: a hibaüzenetnél a második találat rögtön meg is mondta a frankót.
Azért ilyenkor derül ki, mennyire megváltozott ez a szakma. Megakadsz, irány az eventid.net, a KB, a Google. Ha azok valamiért nincsenek, csak a szerencse ment meg a nagy szopástól.

AdminSDHolder, a keménytökű

Lehet, hogy találkoztál már olyannal, hogy belefutsz egy problémába, hosszas nyomozás után kideríted, hogy emögött az áll, hogy néhány erős felhasználónál elvesztek bizonyos jogosultságok. Beállítod, probléma eltűnik, hátradőlsz, ajnározod magad. Egészen 61,5 percig, amikor a probléma újból előjön.

Tavaly tavasszal találkoztam ezzel először Exchange telepítés közben. Forestprep, domainprep megvolt valamikor, de az install ellszállt. A domainprep újbóli lefuttatása után végigment a telepítés, de amikor később újra elindítottam, hogy megnézzek valamit, megint kardjába dőlt.
A bűnös az AdminSDHolder. Ennek az agyába be van égetve néhány kulcsszereplő jogosultsága és rendszeresen csekkolja az Active Directoryt. Ha a neki megadottól eltérő jogosultságokat talál, akkor felsikít, előrántja a baltát és visszafaragja az eredeti jogosultságokat.

Hogyan lehet ezt a mániákus parkőrt meggyőzni?
Úgy van, az nyert, aki arra tippelt, hogy registry buherával.
Indulásnak itt egy másik KB cikk, a többi nyomozást rátok bízom.

Üdén, frissen

Egy nyers szervert kellett átadnunk péntek reggelre. Kollégák felhúzták, de csütörtökön jelezték, hogy nem megy a windows update. Elindítás után feljött egy nyomógombos oldal és bármelyik gombra nyomtak, a 0×80244021 kódú hibát kapták. Böngészés, knowledge base, a KB842773 cikk pont erről szól. Oké, ISA2004 szerveren beállítottam, hogy a konkrét gép IP alapján is kimehessen. De a windowsupdate megint elszállt hibaüzenettel. Nekiálltam kuruzsolni (IE6 Sp1 telepítés, ActiveX engedélyezések, trusted site-ok feltöltése, automatic update beállítása, szervízek automatára állítása, egy csomó újraindítás, stb…) – és egyszer csak észrevettem, hogy megváltozott a hibakód: 0×8024402F. (Ha agyonüttök sem tudom, melyik lépés után változott meg.)

Újabb guglizás, de semmi értelmeset nem találtam. Aztán valahonnan a régmúltból előjött, hogy egyszer már szívtam ilyennel és akkor a BITS2.0 telepítése oldotta meg a problémát. Nosza, töltsük le: KB842773. (Genuine check, offkórsz.) Ez egyben letölti a Winhttp5.1-et is, így egyet kér, kettőt kap a tisztelt admin. Természetesen telepítés után újraindítás – és a gép elment kávézni. Pingre válaszolt, de máshogy nem lehetett elérni. Jó egy órába került, mire találtunk embert a Dataplex környékén, aki távvezérléssel (telefon) belerúgott a gépbe.

Akkor windowsupdate megint. Azt mondta, most még telepíteni szeretné a legújabb windows installert is. Oké, tedd azt. De nem tette, hibaüzenettel elszállt. Hát vécére is én vigyelek ki? – morogtam, és letöltöttem a windows installert is. (KB893803; genuine, naná.) És már el is jutottam odáig, hogy válogathatok a foltok közül. Király.
Csak éppen nem jött le semmi, az összes letöltés failed-re futott. (Hibakód:0×8024401B.) Elmegy ez egyáltalán a proxy felé? Az ősködből előjött egy proxycfg.exe segédprogram emléke. A Winhttp ugyanis egy karakán egyéniség, szarik az IE beállításaira – neki külön beállítások kellenek; a BITS pedig ezekből dolgozik. Command prompt, proxycfg, ismeretlen parancs. Mi is az oprencer? Windows 2000 szerver sp4. Hát… Na, mindegy, töltsük le. Nem lehet; kérheted és majd odaadják. De már fél nyolc van és nekem holnap reggelre át kell adnom ezt a cuccot. Végülis… ez egy registry érték, be lehet ezt gépelni direktben is. HKLM / Software / Microsoft / Windows / Currentversion /Internet Settings / Connections, itt van egy kulcs: Winhttpsettings. Sajnos bináris típusú, a fene tudja, mi a jó értéke.
Utánaolvastam, egy helyen azt írták, hogy a Winhttp5.1-hez másik proxycfg.exe kell, az amelyik az XP Sp2-ben jelent meg. Nosza, kerestem egy sp2-es XP-t majd felmásoltam a szerverre a segédprogramot. És működött. Proxycfg -u; ezzel lehet elérni azt, hogy Winhttp uraság ugyanazokat a proxybeállításokat használja, mint az IE. Csakhogy így sem működött az update. Proxycfg -d; visszaállás.

Legyünk tudományosak, vegyük elő a netmont. Röpke kukucska – és továbbra is sűrű sötét a homály. A windowsupdate teljesen jó irányba forgalmazott teljesen jónak tűnő http forgalmat. Nézzük az ISA szervert, az mit rögzített. Hoppá, itt van egy HEAD http kérés, mely deny-re futott. Lehet, hogy nincs engedélyezve a metódus a HTTP proxyban? Engedélyezzük. De… nincs filter menüpont a jobbklattyban és szürke a gomb a panelen… miafene…?! Oké, tudom, hogy az add-in-ok között van egy http filter ki/bekapcsolási lehetőség; és ha kikapcsolom, akkor ezt a jelenséget kapom. Csakhogy most nincs kikapcsolva. A legtudományosabb windows módszert választottam, néhányszor ki/bekapcsoltam a filtert, majd újraindítottam a tűzfalat. Semmi hatás. (Mental note: ezzel az ISÁval még foglalkozni kell a közeljövőben.)

Nos, ez az ügy egyre cifrább. Elmormogtam néhány ősmagyar siralmat a fogaim között és engedélyeztem minden protokollt az IP-s szabályban. Újabb windowsupdate kísérlet, megint ugyanaz a hiba. Viszont az ISA logban látszott, hogy minden forgalom átment, semmi deny. Csak hogy csináljak valamit, felraktam egy firewall klienst is, de azzal sem működött.
Itt rúgtam bele az asztalba és mentem haza.

Aztán új nap, új remények. Először is szóltam egy kollégának, hogy indítsa el a windowsupdate-t a gépen, írja fel egy cetlire a patch azonosítókat és kezdje el egyenként letölteni, fellapátolni. Eközben összedobtunk egy tiszta szervert, hogy azzal kísérletezzek. Elindítottam a windowsupdate-et, mely első lépésben nekiállt letölteni(!) a Bits2.0-át és a Winhttp5.1-et. Anyád. Az a hernyótalpas. Ezt tegnap este miért nem tudtad megcsinálni?? Restart,az újbóli próbálkozásra leszedte az új windows installt. Itt már csak csóváltam a fejem. A következő lépésben a tesztgép úgy lekapta mind a 27 foltot, mint a huzat.
Nézzük az éles rendszert. Szerencsére a kolléga még csak töltögetett (21 a 27-ből), nem installált. Próbaképp ráböktem egy kicsi patch-re – és lejött. Egyből vérszemet kaptam és ráindítottam mind a maradék 26-ot. Mind lejött. Meg a csempe is a falról.

Mivel racionális ember vagyok, számbavettem, mi történhetett valójában:

  • Valamelyik kolléga kecskét áldozhatott éjfélkor, keresztútnál.
  • Az a Compaq Management utility volt a bűnös, melyet reggel leszedett a gépről egy kolléga.
  • A Microsoftnál volt valami üzemzavar.

Mindhárom nagyjából azonos esélyű. Rátok bízom a választást.

Megjegyzés:
TankoP írkál itt valami apt-get-ről. Szerintem csak azért, hogy bosszantson.