Nem léphetsz kétszer ugyanabba a folyóba?

Egyébként pont úgy hozta a sorsom, hogy a munkahelyemen is virtuálkodom. (Egy fejlesztés teszteléséhez kell létrehoznom egy virtuális környezetet.)
A virtuális gépek egyik előnye pont az lenne, hogy gyakorlatilag hardverfüggetlenek. (Bár Tamás felvilágosított a múltkor, hogy a processzort teljes egészében érzékelik – és nyilván egy bad sectoros vinyó is meg tudja hatni őket.) Nos, a várt egyformasághoz képest váratlanul érdekes dolgok történtek.
Az első gépnél szépen fel is ment az oprencer. Dcpromo, hiba nélkül lefutott. DNS check, minden oké. Másik virtuális gép is feltelepült, beléptetném a tartományba, nem találta a DC-t. Ott voltak egy hoston, network beállítások atombiztosak voltak, ping, nslookup oda-vissza ment. Dcdiag, iszonyú mennyiségű hiba. Hogy nincs GC. Hát hogy ne lenne? Megnéztem, be volt kattintva. Az srv rekordoknál be volt jegyezve, hogy ő, saját maga a GC. A dcdiag mégsem látta. Nem részletezem a teljes nyomozást, egy fél napom ment el rá. Aztán amikor kiderült, hogy nem jöttek létre a rendszermegosztások (sysvol, netlogon) és amikor én manuálisan akartam létrehozni, akkor meg hibaüzenettel elhajtott… na, ekkor újrahúztam a virtuális gépet. Következőre csont nélkül DC lett belőle, szép, tiszta dcdiag kimenettel.
Aztán itt van a mai eset. Szerver feltelepült, dcpromo. Látszólag oké minden. Átfésültem a beállításokat, végül jöhetett a dcdiag. Minden rendben volt, eltekintve a következő bejegyzéstől:
Server failed test systemlog. (Hibakód 0xC0001067; event string nem volt hozzá.)
Most az egyszer Gugli sem segített, meglepően sok helyen vágtak be komplett dcdiag kimeneteket ahhoz, hogy értelmes infót lehetett volna kibányászni belőlük. Viszont volt az eventlogban egy látszólag érdektelen MSDTC hiba, 53258-as kóddal. Elmentem az EventID-re… és egyből megcsapott a vajákolás szaga. Ott van az üzenet… és ott van ötfajta javítási mód. Még csak véletlenül sincs látszólag semmi közük egymáshoz. Már csak szofisztikáltsága miatt is az ötödikre szavaztam, mely nagyon durván összefoglalva így nézett ki: nyiss meg egy ablakot, nyiss meg még egyet, jobbklatty egy ikonon, properties, nyiss meg egy ablakot, nyiss meg még egyet, vessél rá egy bűvös pillantást, zárd be, állítsd le az MSDTC-t, indítsd el az MSDTC-t, zárj be minden ablakot végül indítsd újra a gépet. Jelentem, végigcsináltam – és ez volt a megoldás. A következő dcdiag már hibamentes lett.

Összefoglalva:
Ugyanaz a Virtual Server program lett telepítve a host gépekre.
Ugyanaz a Windows 2003 Server Sp1 oprencer lett telepítve a virtuális gépekre. (Ugyanaz a telepítő cédé.)
Network, DNS, minden teljesen ugyanúgy volt beállítva, mielőtt jött volna a dcpromo.
Ennek ellenére a háromból egyszer reménytelenül rossz lett a tartomány, egyszer csont nélkül jó lett és egyszer megörvendeztetett egy rejtélyes hibával, melynek rejtélyes volt a javítása is.
Ha a virtuális gép hardverfüggetlen, akkor mi okozhatta ezeket a nagyfokú eltéréseket?
Még a végén tényleg igaz lesz a poénként emlegetett függés a napfolt tevékenység intenzitásától…

Eseutil XP alatt?

Bármilyen furcsa, de van. És időnként szükség is lehet rá.

A mostani hétvégét arra szántam, hogy kiépítsek otthon egy tesztkörnyezetet – elvégre nem élet az élet házi Exchange szerver nélkül. Virtual PC, Virtual Server van, idő szintén, akkor hajrá.
Az első meglepetést a Virtual PC okozta, ugyanis nem tudta bebootolni a virtuális gépet a telepítő cédéről. A cédé jó volt, a host gép be tudott róla indulni, a virtuális gép beállításai jók voltak – mégse. Mindegy, vacak 2004-es termék, lássuk a nagytesót.
Csakhogy ehhez előtte IIS-t kell telepíteni az XP-re. És rögtön az elején belefutottam egy dilemmába. Ez ugyanis még egy olyan oprendszer, mely sp1-ként települt és később lett rárakva az sp2. Milyen cédét adjak neki, amikor IIS-t akar telepíteni: sp1 vagy sp2?
Végül sp2-t adtam neki, de nem fogadta el. Gondoltam, mielőtt kipróbálnám az sp1-et, megpróbálom megetetni vele az önálló sp2 csomagot. Ez meg is volt valahol. Alig háromszor-négyszer kellett lefuttatnom, mire beugrott a varázslatos -x kapcsoló, amely csak kitömörít. (Korrektek voltak a fiúk, a /?, -? kapcsolókra simán elindult a telepítés. Ennyit a felhasználóbarátságról.) De ez a könyvtár sem tetszett az IIS telepítőnek. Végső elkeseredésemben beadtam az sp1 telepítőlemezt, de az sem volt elég jó.
Itt kezdtem el nagyon nem érteni a dolgot. Aztán a fejemre csaptam: az a hülye a staxmem.dll-t keresi, az összes telepítőszetben meg staxmem.dl_ van. Lehetséges, hogy ezen hasalna el a mutatvány? Ahogy visszaemlékszem, ez nem szokott problémát okozni – de tegye a szívét a kezére az, aki negyed másodpercnél tovább szokta figyelemmel kísérni az ilyen üzeneteket. Lehet, hogy most, pont most csúszott porszem a gépezetbe? És ha igen, mi a teendő? Átnevezhetem simán a dl_ fájlt dll-re? Vagy igyak inkább előtte egy fröccsöt?
Végül az lett a megoldás, hogy ittam egy fröccsöt és közben eszembe jutott, hogy még meg sem kérdeztem az esetről Gugli barátunk véleményét. Hiba volt. A korrekt esetleírás, a megoldási javaslattal, itt található.
Azért röviden összefoglalom.
Van egy secedit.sdb adatbázis valahol a %windir% valamelyik bugyrában. Ha ez megsérül, akkor az IIS telepítő nem fogad el bizonyos dll-eket. Hogy miért nem? Nincs hozzá gusztusa. Mittudomén. Azt se tudom, mitől sérülhet meg. Én egész biztosan nem szoktam kötekedni vele.
Imhol a gyógyítása:
esentutl /p %windir%\security\database\secedit.sdb
És ennél a sornál kezd el jojózni egy Exchange adminisztrátor szeme. Mi van? Eseutil? Az XP-ben?
Bizonyhogy. A név egy picit mutálódott, de a paraméterezés már ugyanaz. És az adatbázis kiterjesztése is beindíthatja a szabad asszociációs folyamot: mdb, edb… sdb… ez bizony JET típusú adatbázis lesz. Aztán amikor az enter lenyomása után megjelenik az a bizonyos rettegve utált karakteres bitkolbász, akkor már egész biztosan tudhatjuk, hogy a deja vu érzésünk helyénvaló volt.
Mellesleg a módszer működik.