Category: windows kliens

Agysebészet kőbaltával

Nem, most nem Matolcsyról fogok beszélni. Bár vad dolgok ebben az írásban is lesznek.

Habár az előzményekről már esett szó a privát blogomban (itt és itt és itt) – leginkább dühöngés és káromkodás formájában – de itt, ebben az írásban valamelyest újra felelevenítem ezeket, immár higgadtabban és szakmai szemmel.

Tehát a jelenség az volt, hogy 9-én este, amikor le akartam játszani egy videót a médiailag felturbózott Windows 2008 R2 szerveren, elment a hang, illetve beszaggatott a kép, minden lejátszóprogramban. Már amelyik egyáltalán elindult. Bementem a Control Panel / Programs panelbe, kiszórtam az összes Creative programot és drivert, emellett kiszórtam mindent, amit felesleges hulladéknak, telepítési szemétnek tartottam. A videólejátszás rögtön megjavult, a hang nyilván nem, de egyfelől írtam Jánosnak – akitől a hangkártyát kaptam kipróbálásra – hogy mi is ennek a szutyoknak a pontos neve, másfelől megrendeltem egy párezer forintos USB hangkártyát, mert több helyen is írták, hogy a HP ML110 PCI csatija nem annyira szereti a hangkártyákat.
Reggel, még az ágyban, átfutottam az éjszakai leveleket, ott volt benne a hangkártya pontos neve. Gut. Úgy pizsamásan lementem, lekaptam a Creative oldaláról a Microsoft(!) által írt drivert, feltettem, kért egy újraindítást, leokéztam… aztán kék halál.

From Segédlet
From Segédlet

Oké, láttam már ilyet, hibás drivertől nem ijedünk meg. Last good configuration. Megint kék halál. Nofene. Safe mode. Ugyanaz. Ekkor felejtettem a konyhában a kávémat. A safe módban látható volt, hogy a classpnp.sys betöltésével van a baj. Jobb híján rákerestem a neten… és rámdőlt a világ. Mint földrengéskor a tízemelet. Vajákolások, kinlódások, jószándékú, de fogalmatlan topicok, hosszan elnyúlva, aztán egy-két értelmes bejegyzés, melyek azért adtak némi támpontot és ötleteket a továbbhaladáshoz. A továbbhaladást értsd úgy, hogy egyre beljebb a mocsárba. Az első nap végén eljutottam oda, hogy realizáljam, őrült nagy baj van, de még azt se tudom, hogy a Windowsban, a hardverben, vagy a Biosban. János szerint a Creative programozóinál csak az Adobe programozói idiótábbak, szóval ő a maga részéről arra tippelt, hogy a hangkártya driver vágta haza a rendszert. Nekem meg kiesett a fejemből, hogy ez MS driver volt, és hát azért az MS csak nem öli meg a saját rendszerét. Viszont a rossz driver mellett szólt, hogy a Startup Repair is azt üzente, hogy BadDriver. Attól meg végleg kikattantam, hogy egy driver hogyan tud megölni egy szerver operációs rendszert.
Az egész napot pizsamában nyomtam végig, kaja nélkül. Hajnalban hullafáradtan dőltem bele az ágyba.
Reggel folytköv. Pizsama, a dohányzóasztal, mint szék. Éjjel még támadt néhány ötletem, azokat ki akartam próbálni, illetve előkészíteni az újratelepítést. Az ötletek közül egy sem működött, a telepítéshez összeraktam mindent (ez sem volt egyszerű, de most ne részletezzük)… aztán fellázadtam. Hagytam a francba az egészet, reggeliztem, zuhanyoztam, melegítőt cseréltem, főztem egy kávét… szóval megpróbáltam kultúrembert faragni a két napja széjjelfrusztrált gnómból.

Ez a szünet mentette meg a gépemet.

Közben ugyanis a blogbejegyzésben megjelent egy komment, melyben újabb ötletek voltak, illetve nem sokkal később egy másik, amelyikben volt egy link. Egy olyan írásra mutatott, melyet olvasván tátva maradt a szám. Bakker, ez pont az én történetem! Fura volt látni, mert az a több száz bejegyzés, melyet az utóbbi másfél napban olvastam, mind úgy nézett ki, mintha az én esetem lett volna, de aztán mégsem. Ez viszont pontosan az volt.

Amikor telepítettem a segédprogramokat, valamelyik (VLC? K-Lite? DaemonTools? Egyéb?) felajánlotta, hogy felrak egy McAfee Scan nevű cuccot. Habár az MSE már fent volt, de tapasztalataim szerint az eléggé harmatos, ezt a gépet pedig négyen fogjuk gyötörni, köztük két húszéves padaván, szóval úgy gondoltam, inkább több védelem legyen, mint kevesebb. Aztán amikor 9-én este szétesett a gép, nemcsak a hangkártya drivert és segédprogramokat szedtem le, hanem sok egyéb mellett ezt a McAfee cuccot is. Ezzel helyeztem el a pokolgépet a rendszerben. Aktiválni pedig a restarttal lehetett, melyre másnap reggel, a driver telepítésekor került sor. Jó, mi? Azt hinnéd, hogy a driver ölte meg a gépet. A fene sem gondolná, hogy a McAfee Uninstall a háttérben már szétkeffentette a lemezen az oprendszert és az egész gyakorlatilag a memóriából megy.

A KB cikk a McAfee oldalára mutatott, a kettőből szépen össze lehetett rakni a történetet. Létezik egy könyvtár, a %systemroot%\system32\catroot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\, ahol úgynevezett .cat katalógusfájlokban található minden szolgáltatásról, driverről és hotfixről minden azonosító adat. (Pontosabban a katalógusfájlok az egyes csomagok fájljairól készített hash-ek gyűjteménye, természetesen szintén aláírva.) Ezekből az adatokból a rendszer kiszed bizonyos információkat és eltárolja azokat a %systemroot%\system32\CodeIntegrity könyvtárban egy bootcat.cache nevű fájlban. Ezt a fájlt próbálja felolvasni a classpnp.sys driver. Ha nem sikerül neki, akkor megpróbálja legenerálni azt a catroot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE} könyvtár tartalmából. És itt jön a balhé: ha az innen felszedett információk nem egyeznek meg a gép konfigurációjával (értsd driver, service, hotfix szinten), akkor a classpnp.sys eldobja az agyát: kék halál.

Ezek után lássuk, mit csinált McAfee.

Amikor azt mondtam, hogy uninstall, akkor fogta és azt a bizonyos guidnevű könyvtárat átnevezte(!?) temp????.tmp névre, létrehozott helyette egy üres újat… majd a fene tudja, mit tervezett vele, mert ebben a pillanatban tökönszúrta magát és elhalálozott. A gép pedig a következő újraindításkor szembesült vele, hogy a catroot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE} könyvtár üres. Persze, hogy a classpnp.sys eldobta az agyát. Arra kérlek, hogy ha van előtted akár egy Windows 7, vagy akár egy Windows 2008 szerver, akkor nézzél bele ebbe a könyvtárba. Több ezer .cat fájl. Na, az ott látott szolgáltatások és driverek, illetve pecselt komponensek mind kipurcantak, mert nem volt meg hozzájuk a bootoláskor szükséges információ.
Csoda-e ezek után, hogy McAfee-t le akarják lőni Belizében?
Mondjuk, az is egyfajta understatement, hogy a Windows csak annyit mondott, hogy BadDriver. Bakker, az összes driver és az összes szolgáltatás Bad lett.

A workaround nyilván az, hogy Emergency Repair módban visszamásoljuk a temp????.tmp könyvtárból a .cat fájlokat a guidnevű könyvtárba, a bootcat.cache fájlt pedig töröljük.

Csakhogy. Nálam valahogyan a McAfee Uninstall valamelyik gonoszabb változata garázdálkodott, ez nem hozott létre temp könyvtárat, viszont a guidnevű tartalmát törölte. Ott álltam egy tök pucér katalóguskönyvtárral, úgy, hogy nem volt meg az előző állapot. Nézz bele légyszíves megint abba a könyvtárba! Hogy érzékeld a helyzetet: itt mindennek pontosan klappolnia kell: a drivereknek, a szolgáltatásoknak, méghozzá verziószámra azonosan, és persze jelen kellett lennie az összes patch katalógusfájljának, amelyik a gépen volt. Az a nyomorult classpnp.sys csak akkor indult el, ha minden egyezett.
Jópofa vadászat kezdődött. Először átmásoltam a Windows RE változatból – mely gyk. a Repair Tools opcióval indul el – a .cat fájlokat. Nem indult el. Kaptam egy bootcat.cache fájlt, bemásoltam. Kiröhögött. Újabb ötlet: ott van a szerveren egy csomó virtuális 2008 R2 szerver, szedjük ki azokból a .cat fájlokat. Windows RE alól a diskpart segédprogrammal fel lehet mountolni a vhd fájlokat, kimásoltam a {F750E6C3-38EE-11D1-85E5-00C04FC295EE} könyvtár tartalmát. Nagy levegő. Megint nem indult el. Pedig úgy emlékeztem, a host és a guest gépek azonos pecseltségi szinten vannak. Újabb ötlet: a %systemroot%\servicing\packages könyvtárban ott van az összes hotfix katalógusfájlja, küldjük még rá azt is. Le van szarva, ha több lesz. És igen, ezzel nyertünk: a három helyről összemásolt katalógusfájlokban már megvolt minden, pontosan olyan verziókkal, ahogy az a fránya kényes ízlésű classpnp.sys elvárta. Habár malmozott pár percig, de aztán kék képernyő helyett a Windows logon képernyő jött be.

Ha meglett volna a forgószékem, akkor elégedetten dőltem volna hátra.

Nyilván jött még egy nagytakarítás, a lakás gyk. tele volt romokkal, aztán rendezni kellett a kártyákat, drivereket (a találgatások során szanaszét állítgattam a registry-t), de ez már egyszerű hamupipőke munka volt, szerencsére mindent logoltam egy noteszbe.

Végezetül a Köszönet rovat. Ez az írás nem jöhetett volna létre a Microsoft nélkül. Ez kivételesen nem irónia akart lenni. Onnantól kezdve, hogy délben üdén és tisztán kijöttem a fürdőszobából és megtaláltam azt a bizonyos linket, István vezette a kezemet. Tőle kaptam az ötleteket, az én dolgom csak annyi volt, hogy utánaolvassak, megértsem, mit csinálok, majd végre is hajtsam az újabb és újabb feladatokat. A magam részéről teljesen le vagyok nyűgözve, mert egyrészt ez nem volt hivatalos bejelentés, másfelől, mint kiderült, nem is az MS sara volt az oprendszer halála – mégis teljes vehemenciával dolgoztak a hiba megszüntetésén.
És köszönettel tartozom Jánosnak is, aki a hardver irányában tett kisérletezéseimben segített.
Köszönet mindkettőjüknek.

IE9 + Windows Update

Telepítettem egy új Windows Server 2008 R2-t (a régi megdeglett, fátylat rá, hogy miért). Felraktam az összes szükséges update-et, de folyton közni, hogy márpedig ő IE9-et akar telepíteni (pedig már fenn van).

Elkövettem egy Windows Update reset-et (SoftwareDistribution, catroot2 mappa töröl). A Windows Update friss meleg ropogósnak tűnik. Mint amit még sosem futtattak. Lefuttatom. Még mindíg közli, hogy kéne neki egy IE9.

Gugli a mi barátunk:

http://social.technet.microsoft.com/Forums/en-US/winservergen/thread/2c252dbe-c833-424d-9b75-4948bb8fb816

Jó hosszú. Összefoglalva:

1. Szedd le az IE9-et (a Programs and Features alatt, ha megjeleníted az update-eket akkor látod és le is tudod szedni)

2. Rebbot

3. Töltsd le a standalone telepítőt innen: http://windows.microsoft.com/en-US/internet-explorer/downloads/ie-9/worldwide-languages

4. Telepítsd fel /update-no kapcsolóval

5. A Windows Update-ből rakd fel a felkínált cumulative fix-et.

Újbeszél

A UNIX sokkal komplikáltabb – az átlagos UNIX buherátornak sose jut eszébe, hogy is hívják ezen a héten a PRINT parancsot

Az Igazi Programozó

Valamikor jókat röhögtünk a fenti íráson… és meg sem fordult a fejünkben, hogy egyszer a Windows operációs rendszerben is – egyáltalán, az se fordult meg a fejünkben, hogy a Windowsból operációs rendszer lesz – hasonló káosz alakul ki a nevek és szintaktikák körül.

Összelapátoltam ebbe az írásba, pusztán csak úgy magamnak, néhány fontosabb változást. Olyan egyszerű – legalábbis régebben egyszerű – fogásokról lesz szó, melyek ma már némileg megbonyolódtak.

Winhttp

Ha proxy mögül neteztünk, és olyan programot kellett indítanunk, amelyik képtelen volt kiolvasni az Internet Explorerből a proxy beállításokat (pl. Windows Update), akkor volt szükség a winhttp proxy beállítására. Ezt nagyon egyszerűen lehetett megoldani, a proxycfg paranccsal:

proxycfg -p proxyservername:portnumber -> beállította a proxyszerver értékét a winhttp-ben,
proxycfg -d -> lenullázta a proxyszerver értékét a winhttp-ben.

A Windows 2008 szerverben kinyírták a proxycfg-t, a tudását pedig átadták a netsh-nak. Itt így néz ki a parancs:

From Segédlet

Server Manager

A Windows Server 2008-ban kapott végre értelmet a Server Manager konzol. Most nem részletezem, mi mindent lehet vele kavarni, hiszen nem a dedóban vagyunk. Gondolom, azzal sem mondok újat, hogy volt neki parancssoros verziója is, mellyel pontosan ugyanannyi csodát lehetett varázsolni, mint a grafikus konzollal. Ezt a programot hívták úgy, hogy servermanagercmd.
A Windows Server 2008 R2-ben viszont megszűnt ez a parancs. Pontosabban, beleolvadt a Powershell-be. Elindítjuk, betöltjük a ServerManager modult

import-module ServerManager

és tulajdonképpen megint megtehetünk mindent, amit korábban is, csak teljesen más szintakszissal. Life long learning.

Időszinkron

Ez az ősidőkben (NT4) még elég cifrán működött, de aztán finoman becsiszolódott. Tartományi környezetben a PDC emulátor FSMO szereppel ellátott tartományvezérlőt kell hozzászinkronizálni egy külső forráshoz, tőle pedig – a szolgálati út betartásával – megkapja a többi tartományvezérlő, még akkor is, ha az erdő több tartományból áll. A tartományi kliensek pedig értelemszerűen a tartományvezérlőhöz szinkronizálnak.
A PDC emulátor beállítása pofonegyszerű volt:

net time /querysntp -> Lekérdezte az ntp szerver nevét
net time /setsntp:time.kfki.hu -> Beállította az ntp szerver nevét

A Windows Server 2008 R2 ezt is nyugdíjba küldte. Bejött helyette a w32tm parancs, a szintakszis pedig finoman szólva is durván bonyolult lett:

w32tm /config /manualpeerlist:time.kfki.hu,0×8 /syncfromflags:MANUAL /reliable:yes
w32tm /config /update
net stop w32time
net start w32time
w32tm /resync

A szkript – mert ez már az – önmagában is megérne egy elemzést. Mivel még mindig nem dedó, ezt rátok bízom: a parancs létezik a korábbi Windows változatokban, mind kliens-, mind szerveroldalon, a w32tm /? parancsra elég részletes help jön fel. Egy dolgot nem ír a help: mi a búbánat az a 0x8 függelék az ntp szerver neve mögött? Erre egy KB cikk ad választ: ezzel a kapcsolóval állítjuk be, hogy az ntp kérést kliens módban küldje a gépünk.

Autoarchive

Alapvetően egy pimfli dolog, de megdolgoztatta az agysejtjeimet.

Mint tudjuk, suszternek a cipője lyukas, nálunk a levelezés szenved diszktelenségben. Olyan alacsony postafióklimitünk van, mely még az Exchange 2003-as időszakban is szűknek számított volna. Ebből kifolyólag a 3 hónapnál régebbi leveleket keményen törli a házirend. Ebből kifolyólag a két hónapnál régebbieket autoarchívval rakom ki pst-be. (Tudom. Pontosan tudom, hogy Personal Archive. De hiába.)

Hogy konkrét legyek, két pst-m is van. Az egyikbe rakom ki a már lezárt ügyekkel kapcsolatos leveleket, az a manuális archív. A másik pedig az, ahová az Outlook archivál. Az az auto.

Aztán egyszer kellett volna valami régi anyag és nem találtam sehol. Helyette lyukat találtam: egy konkrét időintervallumban eltűntek a leveleim. Hogy miért döglött meg az autoarchív, azt már nem tudtam megállapítani. De innentől alaposan figyeltem, miket is csinál.

Első körben ott hidaltam le, amikor olyan könyvtárat – és értelemszerűen olyan leveleket – archivált le, melyek nem léteztek a postafiókomban. Hát, izé. Nem mondom, ez jobb, mint ha meglévő levelek tünnének el a csillagkapu mögött, de azért fura.

Nem szeretem a fura dolgokat.

Fogtam a könyvtár tartalmát és átdobtam a manuális archívba, ahol már volt egy ilyen nevű folder. A biztonság kedvéért gyártottam egy új pst-t, 1 napra állítottam az autoarchívot – és vártam.
Másnap megint ott volt a nemlétező folder, immár a szűz új pst-ben. Miamanó? A rendszergazdának finoman jeleztem, hogy esetleg, lehet, hogy van valami gubanc az adatbázisban a postafiókommal, de azért még futok pár kört. Már kezdtem izzítani az mfcmapi-t, amikor eszembe jutott, hogy előtte el kellene takarítani a törmeléket. Fogtam az odaszülető könyvtár tartalmát és beledobtam újra a manuális archívon lévő folderbe. És csak utána ütöttem a fejemre. Megnéztem a foldert és nem volt email duplikáció. Tehát ez az eszetlen autoarchív a manuális archív pst-ből archiválta le a leveleket az autoarchív pst-be! Én meg szorgalmasan húzogattam vissza a manuálisba, melyet az autoarchív minden este visszarángatott.
Remek.

De miért csinál ekkora marhaságot az autoarchív? Miből gondolja, hogy neki a pst-ből is archiválnia kell?

Azért, mert azt mondták neki. Az autorchív ugyanis nem csak egy beállítóablak a Tools/Options/Other fül alatt. Sőt, igazából ez csak olyan általános tinglitangli. A lényeg, ami ténylegesen is befolyásolja az automatikus archiválást, az az, hogy mi van a folderen beállítva. (Properties / autoarchive fül.)

From Segédlet

Itt három beállítási lehetőségünk van:

  • Semmilyen autoarchiválás ne történjen a folderen.
  • Vegye át a központilag beállított paramétereket.
  • Beállíthatunk egyedi értékeket a folderre.

Az alapértelmezés az első.
Hoppá. Meg is van, hogyan tűnhettek el a leveleim. Akkoriban strukturálhattam át a folderszerkezetet, az új folderekre az alapértelmezett ‘no autoarchive’ beállítás esett, a mailbox folder policy meg nem kegyelmezett.

De miért archivál ez a gyökérkefe a pst-ből? Egyszerű. Mert anno a foldert drag&drop technikával húztam át az éles postafiókból a manuális archívba. Azaz nem létrehoztam neki egy új foldert és a tartalmat másoltam át, hanem jött a teljes folder, az összes paraméterével együtt. Köztük az autoarchív beállításokkal is.

From Segédlet

Mi a tanulság?

  • Ha ennyire kritikus az automatikus archiválás, akkor minden olyan átszervezésnél, mely érinti a folderszerkezetet – konkrétan új foldert hoztunk létre – központilag rá kell erőltetni az autoarchív beállításokat az összes folderre. Nyomogassuk sűrűn az ablak közepén lévő ‘Apply these settings to all folders now’ gombot.
  • Ha foldert húztunk át pst-be, akkor szedjük le róla az autoarchív beállításokat – hacsak nem akarjuk, hogy a levelek ész nélkül vándorolgassanak a pst-k között.

Kis szar ablak

Hosszú szünet után visszatérés morgással.

Árulja már el nekem valaki fejlesztő, hogy mennyivel kerül többe egy olyan ablak, amelyiken vannak méretező kontrollok? Egész egyszerűen nem fér a fejembe, hogy a mai napig sokszor olyan kis szar ablakokat használunk a windows-ban, melyeket képtelenség felnagyítani.

Ma például megint egy levél útvonalát kellett volna feltérképeznem. Outlook, levél, options – és feljött az a hangyaf@sznyi ablak. Aztán nesze, görgessél jobbra-balra, fel-alá, próbálj összerakni egy ilyen bonyolult láncolatot úgy, hogy csak egy bélyegnyi ablakot kapsz rá.

De meggyőződésem, hogy a biztonsági jogosultságok állítgatása is azért kínai a legtöbb informatikusnak, mert kap egy ilyen egérmozi méretű ablakot, aztán turkáljon benne a 40-50 elemi jogosultság között. A jó ég áldja meg, mire a lista végére érek, már rég elfelejtettem, mi volt az elején, egyben meg ugye nem lehet látni a pici ablak miatt. Azon a kurva nagy felbontású képernyőn.

Ez egy akkora ergonómiai baromság, hogy nincs is megfelelő szó a minősítésére. És az MS oldalán szemmel láthatóan úgy gondolják, hogy ez így nagyon jó, hiszen még a Windows7-ben is ugyanolyan pici, méretezhetetlen ablakok vannak, mint az NT4-ben. Pedig biztos nem én vagyok az első, aki hőbörög.

Itt a cédé, hol a cédé

Persze nem csak Exchange fronton történnek érdekes dolgok mostanában. Például – igaz, kényszerből – átálltam a munkahelyi gépemen Windows7-re. Azt kell mondjam, hogy határozottan tetszik, okos, gyors, jól kezelhető. Már azon töröm a fejem, hogyan fogom tudni meglépni a tömeges átállást az otthoni hálózatban.

Két furcsaságot azért tapasztaltam.

Én elvből ellene vagyok annak, hogy user adatok legyenek a C: meghajtón. A telepítések után majdhogynem az az első dolog, hogy a user könyvtárat átmozgatom a D:-re. Windows 7 alatt viszont library struktúra van (tetszik), melynek a gyökérpontján nem lehet változtatni. Ha mozgatni akarok, akkor az alatta lévő összes foldert kell átmozgatnom, egyenként. Nem egy világfájdalom, de egy kicsit kényelmetlen.

A másik viszont tényleg furcsaság. Már telepítés során létrehoztam a két szükséges partíciót, a DVD olvasóm emiatt a keresztségben az E: nevet kapta. Nem is volt ezzel semmi baj, amíg be nem dugtam egy USB hordozható merevlemezt, mely lecsapott az E: betűre. A DVD olvasóm eltűnt. Oké, Disk Management, átállítottam a hordozható lemezt valahová máshová, gép újraindít – volt DVD olvasóm. Csakhogy ugyanezt eljátszotta később az USB kulcsokkal is. (A sajátommal nem, mert azt átraktam az F:-re és onnantól nem ütköztek – de az idegen kulcsokkal igen.) Eluntam, átraktam a DVD olvasót az U: betűre, így legalább nyugtom lesz. Gondoltam én.

Ez ugye egy munkahelyi gép, ahol a net use paranccsal fixen be van konnektálva mindenféle kapcsolat. Nyilván betűütközés nincs, nem is lehet.
Aztán egyszer kellett volna DVD-t írnom… de hiába nyomogattam a burn gombot, nem történt semmi. Megnéztem… és megint nem volt DVD-m. A dolog kezdett komolyan idegesíteni, hiszen a megszokott USB eszközökön (PDA, egér) kívül nem volt bedugva semmi. Turkáltam, keresgéltem, nyomogattam a refresh, rescan gombokat… de hiába. Végül kínomban lefutattam a net use parancsot, megnézni mi is van ott… és láttam egy olyan bejegyzést, hogy K: \\szerver\e$. Azannya. Lehet, hogy ez az E$ üti ki a DVD olvasót? Dacára annak, hogy az eredetileg E: egységet már átraktam U:ra?
Teszt. Töröltem a K: kapcsolatot, gép újraindít… és azóta van DVD-m.
A dolog azért is különösen érthetetlen, mert a share-ek között nincs E$, ott már csak az U$ látszik.

Kezdek újra hinni az ufókban.

Helyesírás-ellenőrzés kinyírása a Chrome-ban

Ezt leginkább csak magam számára írom ide emlékeztetőnek. (Mostanában rendszeresen telepítek újra gépeket és mindig turkálnom kell egy csomót, mire megtalálom az érintett fájlt.)

Tehát az alapvetően kikapcsolhatatlan helyesírás-ellenőrzőt úgy lehet kikapcsolni, hogy bezárjuk a böngészőt, megkeressük a felhasználói profilban a nyelvre utaló bdic fájlt (nálam pl. en-GB-1-1.bdic), megnyitjuk egy txt editorral, kitöröljük a tartalmát majd visszamentjük 0 méretű fájlként. Ha csak letörölnénk, a Chrome újra legyártaná.
Amit nem részleteztem az az, hogy pontosan hol is van a fájl. Nos, ez operációs rendszertől függően változik, nekem most Windows 7 alatt egész pontosan a c:\users\enyimnev\appdata\local\google\chrome\application\dictionaries könyvtárban található.

Már a Google is megbuggyant?

Egyre inkább törzshasználója leszek a Google Office rendszernek. Ez nem baj, ami praktikus, azt célszerű használni is. Kezdődött a Google Calendarral, mellyel végre sikerült egybeintegrálni a család összes tagjának egyéni Outlook naptárait és végre körtelefonálgatások nélkül tudok szinházi programot szervezni, nyaralásokat, rövidebb kirándulásokat tervezni. A következő lépés a Google Reader megjelenése volt, ezt végre már tudom PDA-n, mobilon is olvasni. A FeedDemon itt szerepelt le csúnyán. (Meg a hibás megjelenítésen, meg a lokális keresés hiányán, meg ugye külön alkalmazás, szemben az állandóan nyitva tartott böngészővel.) Aztán belépett a használt alkalmazások közé a Google Documents. Ha valamit gyorsan fel kell írnom valahová és azt szeretném, hogy mindig kéznél legyen, akkor ez majdnem(1) tökéletes. (Gondolatok, linkek szakmai írásokhoz, témák, melyekről majd írni akarok a blogban – bármelyikben(2) – de még rajzötletek is simán elférnek.) Elméletileg lenne erre tökéletes megoldás is az MS-től: a Onenote, PDA szinkronon keresztül. Csak éppen tré. Nem működik. (Ha belejavítok egy már létező és korábban összeszinkronizált szövegbe akármelyik gépen, a módosítás nem megy át a másikra. Ha egy bejegyzés átszinkronizálódott egy másik gépre, akkor már csak úgy lehet törölni, ha off-contact állapotban törlöm mindhárom eszközről.) Az Office-ba épített Notes… azt meg hagyjuk.

(1) Csak azért majdnem, mert nem tudom a PDA-ra úgy rászinkronizálni, hogy a doksik offline is meglegyenek.

(2) Elméletileg erre jók lennének a blogadmin felületek is, de mégsem. Kényelmetlen elmenni az oldalra, belépni, aztán beírni a cuccot a draftokhoz. Ráadásul ekkor keverednek a már kész, de még nem publikált, illetve a még csak piszkozat írások. Inkább fordított folyamat zajlott le: a blogpiszkozatok kerültek át a Google Document-be.

Szóval így álltunk. Egészen pár nappal ezelőttig, amikortól is a következő képet kapom, ha átváltok a Calendar-ra.

Nagyítás

Hiába vártam utána akármennyit is. Minden más Google alkalmazás tökéletesen működik. Kipróbáltam más böngészőből is: IE alatt megy a Calendar. Átmentem más gépekhez. Végül se az otthoni, se a munkahelyi, se a tabletpc nem tudta elérni a Calendar-t Firefox-ból, ellenben mindenféle létező egyéb böngészőből simán ment.
Végiggondoltam a dolgot. Végülis, nekem nem olyan fontos, hogy a háttérben állandóan figyelő Google Office Firefox-on fusson – egyik funkciója sem FF plugin specifikus.

Emiatt döntöttem a Chrome mellett. (Ha már Google.)

Az otthoni két gépre simán fel is szaladt, kicsi, gyors – és mivel csak egy célra használom, nem érdekel, hogyan viselkedik úgy általában a neten.

Csakhogy. A munkahelyemen már megráztam a pofonfát.
A Chrome ugyanis nem olyan, hogy letöltöd és lefuttatsz egy exe fájlt. Az interneten keresztül akar telepíteni. Initializing… initializing… nem sikerült neki. Feldobott egy hibamegoldó ablakot, de a tippek nem segítettek. Jöhetett a jó öreg proxycfg -u parancs, de most hiába. Az se sokat segített, hogy a Chrome oldaláról le lehetett tölteni egy 500KB-os fájlt, mert ez csak trailer. Később ez se tudott túljutni az inicializálós fázison.
Szétnéztem a neten… és megtaláltam ezt. Hát… azért ez elég rendesen gáz. Habár a hiba nem pont ez, de van az oldalon egy link egy _teljes_ telepítőkészletre. Letöltöttem. Elindítottam. Aztán ez is beleveszett az inicializációs folyamatba.
Továbbolvastam a hozzászólásokat. Volt még ott link egy könyvtárra, amelyben komplett Chrome installációk voltak becsomagolva… de valahogy az útvonal neve (buildbot) nem tetszett. Vártam, vártam… aztán ráböktem arra a piros ikszre az inicializálós ablak jobb felső sarkában. Erre feljött az üzenet, hogy a telepítés sikeres volt. ???
Elindítottam. Működött. Beírtam egy címet. Közölte, hogy nem éri el a weblapot.
Aha. Proxy.
Nézzük, proxy konfigurálás. Rákattintottam a gombra – és behozta az IE connection paneljét.
Itt estem le a székről. Hát annyira szarul megy már a Google-nek is, hogy nem fér bele a mérnök munkaidejébe egy beállítóablak legyártása? Hogy bekérje, milyen proxy is van?
De ezzel még nincs vége. Ugyanis nálam az IE is be van állítva, tehát elméletileg át kellett volna tudnia venni az értékeket. Csak éppen a cégnél szkript adja fel az éppen aktuális proxy-t. És azok a zseniális fiúk a Chrome-nál ezt már nem bírták lekezelni.
Így most választhatok:

  • Bekonfigurálom az Internet Explorert egy fix proxyra, elvesztve ezzel a szkript okozta rugalmasságot.
  • Törlöm a francba a Chrome-ot, és – a Firefox hiba miatt – a nagyobb erőforrásigényű Internet Explorert használom a Google Office-hoz. Vicces. Meg persze reménykedek, hogy valakinek eszébe jut majd berakni egy adatbekérő panelt a Chrome proxy beállításaihoz.

MAPI profil direkt elérése Vista alatt

Ezt először nem hittem el. De tényleg nincs.
Akinek Vistája van és Outlook klienst használ, ne is keresse a Control Panelen belül a Mail ikont. Nincs. Megszűnt.
Pedig nagyon hasznos dolog volt. Nem kellett elindítanod magát az Outlook-ot a MAPI profilok menedzseléséhez. Sőt, olvastam olyanról is, hogy valakinek valami rejtélyes hiba miatt a profil kezelése Outlook alól egyáltalán nem működött – csak a Control Panelből.

Mit lehet ilyenkor tenni?

Program Files\Microsoft Office\Office12, azon belül pedig duplaklatty az MLCFG32.CPL fájlon.

Kínos.

Aktívan

5 órája az ActiveSync-kel szopok. Amit be lehetett kapni, azt már mind bekaptam. Igaz, a feladat nem túl egyszerű: hozzunk szinkronba két laptopot és egy PDÁ-t.
Le kellene higgadnom, hogy pontosan leírjam a tapasztalatokat – de erre már nincs idő. Így csak átabotában:

  • A combine rossz. A combine gusztustalan. A combine opciót felejtsd el.
    A gond csak az, hogy nincs más. Amikor észleli ez a dög, hogy itt is, ott is vannak adatok, akkor a következő választást adja fel:

    • Combine a két hely.
    • Felülírjuk a PDÁ-t.
    • Nem csinálunk semmit.

    Ha te pont olyan helyzetben vagy, hogy a PDÁ-n vannak a jó adatok, akkor elvesztél. Csak a combine marad… meg a hajtépés. Ez az idióta ugyanis nekiáll gondolkodni. Helyetted. Például az összes családi ünnepet – a franc se tudja, honnan ismeri fel – berakja a ‘családi ünnep’ kategóriába. Ekkor természetesen mindegyik megduplázódik, mert lesz eredeti kategóriás, meg kiegészített kategóriás változat. A telefonszámok elől véletlenszerűen lehagyja a ‘+’ jelet – és ez természetesen megint duplázáshoz vezet. No, mindegy, kár is részletezni, a lényeg, hogy egy combine durván 3-4000 duplikált bigyót hoz létre. Minden alkalommal. Természetesen manuálisan kell kigyomlálnod a folyamat végén. Mindet.
    De akkor sem jársz jobban, ha van két totálisan összelőtt géped és mindkettőnél azt mondod, hogy mindkettő a PDÁ-t írja felül. A sokezer különbözet állandóan meglesz és egyszer csak meg kell nyomnod a combine gombot. Ahelyett, hogy lenne egy olyan opció, hogy a PDA írja felül a desktop gépet. Idióták.

  • Ez valószínűleg BB-t fogja érdekelni. Mivel nem győztem várni a tabletpc-re, először a benti géppel szinkronizáltam, kihagyva persze az emailt. Utána jött az otthoni gép – és nem engedte a levelek szinkronizálását, mert ezt mondta, hogy két partneri kapcsolat mellett ez lehetetlen. Azaz ugyanazt a hibát kaptam, melyet Jani is pár héttel ezelőtt. A különbség csak az, hogy nekem – ugyanezekkel a szoftverekkel, ugyanezekkel a hardverekkel ez a keresztszinkronizáció egyszer már működött.
    Nem részletezném az odavezető utat, elég csak a megoldás maga. Törölni kell mindegyik partneri kapcsolatot, majd először azzal a géppel kell kapcsolódni, amelyikkel email szinkronizációt is szeretnénk. Mivel ekkor még csak egy partner van, a szinkronizáció remekül létrejön. Utána jöhet a másik partneri kapcsolat, értelemszerűen itt már nincs emailszinkronizáció – de a többi működik.
    Most már csak azt nem értem, hogy ha ez működik, akkor miért kell kapásból tiltani, amikor fordított sorrendben rakom össze? Idióták a négyzeten.

MyUnInst rulez

Adott volt a feladat. Itt van egy gép, telepítsek rá Office2007-et – úgy, hogy korábban volt rajta Office2007 béta. Nem tűnt túl pilótavizsgás küldetésnek.

Először bedobtam a cédét, setup. Tudom, tudom… de alapvetően jóindulatú ember vagyok, adtam egy esélyt, hátha. Nem jött be, a telepítő mogorván csak annyit mondott, hogy itt bizony két dudás próbál bepréselődni ugyanabba a kocsmába, az egyiket pöndörítsem csak bátran ki.

Oké, bétaoffice az addremoveprograms segítségével ki lett tessékelve, megint telepítőcédé, aztán setup. Nos, a telepítő az előbbi akción annyira megsértődött, hogy fogai között csak ennyit vetett oda:

„Setup is unable to proceed due to the following error(s): The 2007 Microsoft Office system does not support upgrading from a prerelease version of the 2007 Microsoft Office system. You must first uninstall any prerelease versions of the 2007 Microsoft Office system products and associates technologies.”

Nodehát… hiszen letöröltem.
A biztonság kedvéért szétnéztem itt-ott, de tényleg le lett törölve.
Gondolkodtam, hogy nekiállok átfésülni a registry-t, de aztán úgy döntöttem, inkább megidézem a guglipowert. És milyen jól döntöttem.
Itt van egy remek kis írás arról, hogy Scott Hanselman hogyan mászott ki ugyanebből a szituációból. Ajánlom mindenkinek szíves figyelmébe, nagyon tanulságos írás. Az ember elég hamar rájön, hogy vannak olyan esetek, amikor a saját szívásai apró törpévé zsugorodnak másokéi mellett.

Scott először a Filemon segítségével megkereste, hová rakja az Office a setup log fájlt. (Már ez is… hol vagyunk mi még ettől, hogy ennyire készség szintű legyen a Filemon? Hogy az ember inkább ezt válassza, mint a manuális matatást a vinyón vagy jobb esetben egy desktop search programot, bizonytalan nevű log fájl után kutatva.)
A logfájlban talált egy GUID-ot, arra rákeresett a registryben és ebből adódott, hogy a bűnös komponens, mely meghiúsította a végleges office beköltözési szándékát, az bizony a Microsoft Office Shared MUI (English) komponens.
Eddig öröm az élet… csakhogy ezt most el is kellene távolítani. Az addremoveprograms meg szégyenlősen hallgat.
Scott ekkor előkapta a titkos fegyvert: MyUninst a NirSoft-tól. Ingyenes, egyszerű, mint a faék – és mindent lát, ami valaha fel lett telepítve a gépre. Sőt, nem csak látja ezeket a programokat, de ki is nyesi őket.
Meglepő módon nem csak a MUI komponens maradt fent, hanem még néhány helyesírásellenőrző szutyok is – azaz az a szerencsétlen előző program annyira béta volt, hogy képtelen volt minden komponensét bőröndbe pakolva elhúzni melegebb égtájakra.
Természetesen a MyUnInst segítségével minden kidobható és utána már rendben mehet is a telepítés.

Tartozom az igazságnak azzal, hogy a hibáról a Microsoft is tud. Van is róla KB cikk.
De tessék alaposan átolvasni: ha először ezt a cikket találom meg, istenbizony fogom és inkább visszatelepítem az Office2003-at, mint hogy ennyit turkáljak a registryben.
MyUnIst rulez.

Kizártam magam és most nem engednek be!

Majd ugyanezzel a vehemenciával lecsapja az asztalra a laptopot a Kedves Felhasználó.

Találkoztunk már ilyennel?
Joe igen.

Az átlagos rendszergazda ilyenkor megvárja, míg a felhasználó elhagyja a szobát és utána headbangel egy picit a Dexion Salgón. Aztán elkezd megoldást keresni. Ha bedobja a problémát egy levlistára, valószínűleg azt a választ fogja kapni, hogy „apukám, ne adj a felhasználónak lokál admin jogot”. Ez oké, minden normális rendszergazda tisztában van vele, hogy ez a hosszú élet titka – de vannak olyan felhasználók, akik elég erősek ahhoz, hogy kiharcolják ezt a jogot maguknak. Sajnos az akarat és a műszaki intelligencia nem mindig korrelál szorosan, így általában pont ezek azok a felhasználók, akik a legkreatívabban tudják szénné konfigurálni a gépeiket.

Szerencsére Joe találkozott egy igazán ravasz rendszergazdával, aki elmagyarázta neki, hogyan lehet megakadályozni azt, hogy a felhasználó betegye a gépét az otthoni tartományba, átnevezhesse a gépét, átírhassa az elsődleges domain suffix-et, meg ilyenek.
Ezen lépések mindegyikét ugyanis a System Properties/Computer Name fül alatt lehet megtenni. Maga a fül mögött a c:\windows\system32\netid.dll lapul – azaz ha ezen a fájlon fizikailag letiltjuk a felhasználó hozzáférését, akkor… akkor az történik, hogy a System Properties alól egyszerűen eltűnik a Computer Name fül.
Nyilván a nagyon okos, nagyon ügyes… nagyon erőszakos lokál admin eszén nem lehet túljárni. De mindenki másén igen.

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.