Windows 7 vs AHCI disable

A közkedvelt notebookom múlt héten visszakerült hozzám újabb szervíz-túrája után. Időnként elpukkant a Windows 7 rajta, a minidump elemzés pedig mindig más hibával jött elő, de mind hardverhibát sejtetett. Aztán a memtest 86+ is kifagyott rajta (erről később kierült, hogy T400 típusjelenség), úgyhogy ment a szervízbe. A szervízes srác nemes egyszerűséggel AHCI BIOS állítással oldotta meg a jelenséget a munkalap szerint. Ezen jót derültünk, bár én nem tudom, hogy mi alapján döntött így, mert nem vagyok egy hardveres.

Mindenesetre tegnapelőtt jutottam oda, hogy bekapcsoljam a gépet, és azt találta mondani már bootnál, hogy KÉK. Újabb bootnál már láttam, hogy a diszkkel van baja. Futtattam egy repairt, de nem segített (de legalább 2 perc volt :), a vége a megjavíthatatlan partíciós tábla volt, úgyhogy megsirattam a Win7-et, és elkönyveltem, hogy ez volt az oka a kékhaláloknak: az egész ramatyul volt már. Elővettem a Win2008R2 vinyót, és bebootoltam azt. Kékhalál, diszkprobléma.

Na, itt elkezdtem visszaemlékezni a szervíz munkalapra… AHCI… aha… gyors netszörcs… tényleg, Vista+ oprencert ki tud nyírni a váltás, és le is volt írva csomó helyen, hogy lehet a standardról AHCI-ra váltani. De nekem kikapcsolta ez a derék ember, nem be, azt meg sehol nem írták le. Végül a Microsoft kiváló KB cikkét elolvasva megtaláltam a rejtett varázsigét. A more information szakaszban elmondták, hogy “…pl. van egy Vista vagy Win7 gép, ami a pciide.sys drivert használja, és később a SATA módot AHCI-re állítod…” Fogtam a registry hekkelős megoldást, miszerint az msahci és IastorV drivereket engedélyezzem, és ugyanazzal a módszerrel engedélyeztem a pciide drivert. Szóval gyakorlatilag a következő tartalmú .reg file-t kell letolni a gépen, és utána akár ki, akár bekapcsolod az AHCI-t, bootolni fog.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\msahci]
"Start"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\IastorV]
"Start"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\pciide]
"Start"=dword:00000000

Persze jön a kérdés, h mér ilyen láma az MS. Mert nem akartak feleslegesen vackokat betölteni (pl. IDE drivert AHCI-s gépen), amitől gyorsabb lett, viszont hagyhattak volna egy fallback hardver detection opciót, ami frakk esetén megpróbál mindent detektálni.

És az én fejemben jön a kérdés, hogy egy Vista certified logós notebookon hogy gondolja a szervízes srác, hogy kikapcsolja az AHCI-t, ami kinyírja a supported oprencert. De ez messze vezet. Meg az is, hogy miért kapcsolta vissza a touchpadot, amit gyűlölök, és a sörhasam kattogtatni szokott vele.

Windows login és az őt felruházó csoporttagságok

Klasszikus probléma, hogy van egy Windows login az SQL szerveren, aki benne van N csoportban, amik benne vannak másik M csoportban, és a répamese jegyében ez összesen nagyon sok csoport lesz. A kérdés pedig az, hogy pontosan melyik csoporttagságán keresztül milyen jogot is szerzett az SQL szerveren. Na, pont erre nyomtam egy lenyűgöző Powershell demót a SQL 2008 R2 bejelentési eseményen, aztán elhagytam a scriptet. Mivel valami dupla mákos hakkolás volt, próbáltam felhajtani, de nem sikerült. Viszont a vicc, hogy ugyanezt a fícsört megtaláltam beleépítve a SQL szerverbe.

A neve xp_logininfo, és két irányba is működik:

exec master..xp_logininfo [EMEA\EBitemo], 'all'

megmondja az összes csoportot, melyen keresztül engem beenged a SQL Server.

exec master..xp_logininfo [EMEA\#DBA_Operators], 'members'

pedig megmondja, h kiket is enged ő be azon a csoporton keresztül.

Ezzel TT felé való négyhónapos adósságomat rendezettnek tekintem :)

Új diszkek hozzáadása az SQL clusterhez

Diszket kellett bővíteni egy SQL clusterben, a lehető legkevesebb leállással, úgyhogy úgy döntöttem, hogy folytatom, amiben jó kezdek lenni: scriptelek. A cluster diszkek hozzáadása önmagában nem nagy szám (most felhördül legalább 28 ember, akinek már voltak rossz élményei a témában – nekem is, de a lekapcsolt többi node majdnem mindig dobott a dolgon), a jó rész az, hogy az SQL csak azokat a diszkeket használja, amiken dependál a service, a dependenciát pedig csak leállított helyzetben lehet állítgatni. Itt jön jól a script, hogy ne kelljen klikkelni, míg megöregszem. Ezúttal a cluster.exe volt a műtéti alany, az eredmény pedig alant látható (a sql12clus clustert megtámogatva):

cluster.exe sql12clus resource "SQL Server" /Offline 
cluster.exe sql12clus resource "SQL Server" /AddDependency:"K: BillingData"
cluster.exe sql12clus resource "SQL Server" /AddDependency:"L: BillingLog"
cluster.exe sql12clus resource "SQL Server" /Online

Azaz leállít, dependenciát hozzáad, elindít. Egy öröm volt.

Windows klónozás és SID duplikáció – monkeys and bananas

Az egyszeri történet szerint a céges szabályzatok a következőképpen készülnek: egyszer egy csoport majmot bezártak egy ketrecbe, ahol felakasztottak egy banánt. Akárhányszor az egyik majom hozzányúlt a banánhoz, mindegyik állat hidegzuhanyt kapott. Hamar leszokott mindenki a banán piszkálásáról. Egy idő után megszűnt a víz, a majmok már nem is próbálkoztak. Aztán kicserélték az egyik majmot, és az új fiú rögtön rápróbált a banánra, de alig ért a közelébe, a többiek elverték. Lassan rájött, hogy a banán tabu. Aztán kicserélték az összes majmot, és mindet megtanította az aktuális csoport, hogy ne próbálkozzon a banánnal. Végül nem volt egy majom sem a ketrecben, aki látta volna a zuhanyt, de a banánhoz senki sem nyúlt.

Az informatikában így születnek a csontvázak, amikről senki sem tudja, hogy miért vannak ott és úgy, de senki nem meri megmozdítani. Hogy ezt miért mesélem most el? Mert a múltkor tesztkörnyezetet építettem, és miközben a SID-eket ütögettem át a Sysinternals NewSID.exe programjával, azon gondolkoztam, hogy miért is kell pontosan átütni őket… Valami rémlett ,hogy amikor belépnek a domainbe, akkor jön a gubanc, meg amikor egymással beszélgetnek, de hogy pontosan mi, azt nem tudtam. Úgyhogy elkezdtem túrni a netet, és belefutottam Mark Russinovich friss blogbejegyzésébe: a NewSID.exe megszűnik. Mark a Windows lelkivilágának nagy ismerője, a Sysinternalsos progik (többek között a newsid.exe) fő szerzője. De miért szűnik meg ez a kütyü?

Az úgy kezdődött, hogy Mark kapott pár visszajelzést, amikor a newsid.exe gubancot okozott. Ezeket próbálta kibogozni, és arra gondolt, hogy jó lenne tudni, milyen gubancot előz meg a progi. Elment tehát a Windows fejlesztőkhöz, hogy pontosan milyen problémák fakadnak a duplikált SID-ből. És a fejlesztők némi töprengés meg kód átnézés után azt mondták: Semmilyen.

Apró öröm, hogy Mark pont előttem egy héttel gondolkozott el ezen a témán, de az eredmény így is mellbevágó. Remélem most már mindenki érti a majmokat.

Windows 7 RC

Még fut mellettem az install, de annyira jó, hogy le kell írnom (update: már Windows 7-en vagyok). A dizájnerek biztos nem vetették meg a sci-fit, remélem ez marad a bootloader a végleges változatban is :)

Első és legfontosabb: Windows 98 óta nem lehetett ennyi idő alatt Windowst telepíteni. 30 perc onnantól, hogy berakom az install DVD-t odáig, hogy kattinthatok először szabadon a start menün. Kérdez az elején hármat, a végén hármat, és ennyi. Feltoltam rá az Office-t meg néhány egyéb apróságot.

Vannak persze furcsa élményeim, mert kliensoldalon az XP az utolsó emlékem (a Vistát kipróbáltam pont amikor kijött, de két hét alatt nem jöttem rá, hogy miért szeretném jobban, mint az XP-t). Meg persze notebookra telepítem, és már előre a hekkeléshez van idomítva a rendszer – például KELL a 32 GB-nál nagyobb FAT32 partíció, hogy lássa az Ubuntu is a virtuális gépeimet, mert néha az fog kelleni (a company policy nagy úr). Viszont 64 bites a gép, 64 bites a W7, és minden működik. Még a beépített Bluetooth adaptert is simán felismerte magától.
Így egy (fél) nap után az élmény pozitív, az IE8 teljesen élvezhető, csak még nincs hozzá 5000 plugin, mint a Firefoxhoz, de remélem, hogy lesz. Emberek, vegyenek Windows 7-et! A fiamnak már adtam egy install DVD-t…