2010. július 29., csütörtök

Blogspot blog

Összehasonlítva az előző cikkemben szereplő blog-szolgáltatással, csak egy pár gondolat, erről az blogról.

Kapásból, ami nem tetszik, hogy nem találtam még arra megoldást, hogy a Word-ben szerkesztett cikket szépen, egy-az-egyben át tudjam ide másolni. Ugyanis, két fő probléma merült fel:

1. áthozatal után úgy elvesztek a bekezdések, mint a huzat. Kézzel kellett ismét betennem őket, utána kiderült, hogy nem WYSIWYG módon kezelte, tehát túl sok lett, így ismét meg kellett variálnom - HTML kódban. 2010-ben. Copy/Paste után. No comment.

2. nem hozta át a kész, szépen megformázott hivatkozásokat. Ezért itt, helyben, ismét ki kellett alakítsam a linkeket :(

Másik - nem olyan égető, de zavaró - problémám a hozzászólásokhoz kötődik. Mint egyik sorstárs kollégának is jeleztem, amikor valaki létrehozza magának a blog-tárhelyet, arra kell figyelni, hogy a megjegyzések rovata nem teljesen nyitott (nem tud mindenki megjegyzést hozzáfűzni), ezért hiába is vártam volna, hogy bárki is ide írja a hozzászólásait. Ugyanakkor az általam használt Omea Reader nem is tudja beolvasni a hozzászólásokat (van olyan progi, amely olvassa?).

S hogy ne csak panaszkodjak, így hirtelen két dolgot tudnék felsorolni, ami tetszik:

1. néhány dolgot részletesen lehet szabályozni (pl. email-kérés bizonyos esetekben), jobban személyre lehet szabni, mint a Spaces-t. A blog kinézete elég jól variálható, még nem öltötte fel végleges formáját, hiszen ideiglenesnek indult - lehet, hogy végleges lesz? Még eldől...

2. természetesen a statisztikai oldal, mint egyik váltó-okot sem hagyhatom ki. Meg kellett ismerkedjek annak a felépítésével, az eddigi pőre, 1 hetes adatok helyett adatok tömege, igazi statisztikák állnak rendelkezésre. Annyira, hogy még most sem merem állítani, hogy minden részletét ismerem :)

Eddig még nem találtam olyan megoldást, amivel a Spaces-ről át tudnám mozgatni a blogom. A Blogspot tud xml-t kezelni, de állítólag az átjárhatóság még ennek ellenére sincs megoldva - valószínűleg a Spaces hibájából. Ha sikerül áthozni, akkor lehet, hogy itt maradok - főleg, ha jön egy Wave 5 Live :)

2010. július 28., szerda

Windows Live Spaces blog

Ma reggel tapasztaltam azt, hogy a Windows Live ismét változott. Részben a kinézete is, meg egy pár új dolog is került bele - de a legrosszabb, hogy eddig a levelezésből egy kattintással át tudtam menni a bloghoz... Most már ez sincs.

Ha ez így megy, akkor nem lesz más, mint itt maradnom :( Pedig tényleg örültem volna, ha minden marad a régi-régiben - sőt, jobb irányba változik...

u.i. úgy látom, nem csak én vagyok kiakadva a Spaces rombolása miatt: link

2010. július 26., hétfő

Windows 7 és akkucsere

Mivel nálam is „felütötte” a fejét a probléma, kicsit tüzetesebben utánanéztem annak a „hibá”-nak, mely már a Windows 7 RC óta zavar egyes felhasználókat, s mely szerint a laptop-akkumulátoruk cseréje szükséges.

Szóval, az eddig összegyűjtött tények alapján a következőt tudom: minden akkumulátornak van egy tervezett kapacitása (Designed Capacity), valamint egy teljesen feltöltött állapotú kapacitása (Fully charged capacity), egyes hivatkozások szerint „Last full charge capacity”. Vadonatúj akkunál a kettő egybeesik, ez a normális. Gyártása után az akku állapota nem marad változatlan, akár a szekrényben áll, akár használjuk, valamilyen mértékben elhasználódik – vagyis a teljesen feltölthető kapacitása folyamatosan csökken. Az elhasználódás mértéke értelemszerűen változó, van, hogy egy év alatt 4-5%-ot, van, hogy egy év alatt 50%-ot is romlik a tárolási mértéke.

Az eddigi operációs rendszerek tudtommal nem mérték az elhasználódás mértékét. Ők csak azt jelezték, hogy a teljesen feltöltött állapothoz képest mennyire van feltöltve. S bár a teljesen feltöltött állapot kapacitásának értéke folyamatosan csökkent (az elhasználódás miatt), ez a csökkenés sehol nem volt jelezve.

A Windows 7 viszont figyelembe veszi a két érték arányát. Amennyiben a teljesen feltöltött állapot kapacitása nem éri el a tervezett kapacitás 40%-át, akkor jelzi a felhasználónak, hogy érdemes figyelnie az akkura, lehet, hogy többé-kevésbé hamarosan cserére szorul. Az, hogy mennyi idő múlva, ismét a felhasználón, illetve annak akku-kezelésén múlik. Hiszen a tervezett kapacitás 40%-ával is el lehet egy ideig lenni, de a tervezett költségbe majd bele kell számolni egy akku-cserét is (ami, tudjuk, nem olcsó).

S itt jön egy másik dolog: sokan azt állítják, hogy a W7 „elrontja” az akku-t ezzel a kijelzéssel. Tudtommal nem így van, hiszen az említett két érték (tervezett kapacitás és teljesen feltöltött állapot kapacitása) csak olvasható értékek – mármint az operációs rendszerek részére. A kezelésük teljes mértékben a gyártóra van bízva. Ezt igazolja az is, hogy ha megnézünk egy W7-et soha nem látott laptopot, ott is láthatjuk az értékek változását. De mivel ott nincs riasztás, csak azt tapasztaljuk, hogy folyamatosan csökken az akkuról használhatóság időtartama… Ide még egy pontosítás jön: láttam én is olyan gépet, ahol az akku kapacitása, kora ellenére, mindenhol maximális értéket mutatott. Sejtésem szerint nincs kizárva, hogy eddig nem minden gyártó foglalkozott rendesen az akku értékeinek karbantartásával…

Van még egy pont, ahol ezt meg szokták támadni: az új akkumulátorok. Nos, erre nem tudok mit mondani, támpontot tud nyújtani a KB981200, mely alapján a laptop BIOS-a rosszul kezeli a tervezett kapacitást, sokkal nagyobbnak beállítva a valóságnál, melynek következtében a másik értékkel képezett aránya riasztást vált ki.

Egy dolgot nem próbáltam ki, hátha valaki elektromosságban jártas szaki tud majd segíteni: a kalibrálást. Nem tudom, ez mennyire segít, mennyire nem, a neten találtak alapján finomvegyes a válasz…

2010. július 11., vasárnap

(Windows 2008 R2 és ) Windows 7 - újra

Ebben a cikkemben, bő egy éve írtam egy pár sort erről a két termékről.
Aminek a legjobban örülök, hogy akkori érzésem bevált. Azaz igaz, hogy van még pár kisebb-nagyobb hiba a termékekben (de tudjuk, tökéletes program nincs) - de nagyjából hozták a várt formát. S mielőtt valaki félreértené, nézze meg régi blogom, ott egy párszor azért panaszkodtam rájuk...

Nem egészen egy éve használom aktívan a W7-t, hiszen ez van a gépemen, s jelentem: elég stabilnak érzem, hogy egy hétköznapi felhasználó is elboldoguljon vele. Nem hiába olvasom mind több helyen, hogy lassan a cégek is kezdenek elgondolkozni a "tömeges" áttérésen - már ahol az (anyagi) lehetőségek megengedik.

Ugye tudjuk, hogy az SP1 sem fog forradalmi változást hozni - gyakorlatilag szinte csak egy összefoglaló csomagja lesz az apró javításoknak. Nem azt mondtam, hogy csak, de kevés ember fogja kihasználni azt a pluszt, amit még fogunk kapni.

Eddig egyetlen egyszer sikerült kékhalálra bírnom a rendszert :) Pedig nem kímélem... Ami a drivereket illeti (64 bites), hát... eleinte voltak nézeteltéréseink a géppel, mert finnyáskodott - de mostanra nagyjából mindennel összebarátkoztunk. Ami a programokat illeti - nos, igen, van néhány gyártó, aki csak azért sem akar 64-bit alá fejleszteni, s a 32-bites nem segít - erre van egy külön virtuális gépem. Nem, nem az XP Mode, bár azt is kipróbáltam. S ha már itt tartunk: az XPM önmagában véve tényleg nagyszerű ötlet, hogy látatlanul fut a háttérben, mi meg csak a program ablakát látjuk. Viszont látszik, hogy még gyerekbetegségekben szenved (a napokban a fórumon egyik kérdés pont erre irányult) - de majd kinővi. S azzal sem teljesen lopta be magát a szívembe, hogy akárhogy vesszük, az egy külön rendszer - annak is kell a Windows frissítés, kell (nem árt) víruskereső, stb. Amik mind-mind erőforrást zabálnak - feleslegesen...

De sebaj. Megvagyok én XPM nélkül is. :) De hogy visszatérjek XP-re, s az RSAT előnyeit (mint rendszergazda, végül is az lennék :) ) is mind elveszítsem - hát, inkább nem...

2010. július 1., csütörtök

Exchange backup/restore 1.

Egy kolléga megkért, hogy segítsek neki pár dolog tisztázásában. A feladat adott volt: ügyfélnél, 2003-as Exchange-el, történt valami a levelezéssel, s emiatt mentésből vissza kellene állítani egy adott postafiókot. Ehhez egy mentést úgy kellene visszaállítani, hogy utána újra lejátsszuk a mentés óta keletkezett logokat, ezáltal naprakész állapotba hozva a delikvens levelezését.

Természetesen utánanézett a dolgoknak, viszont csak angol anyagot talált, magyarul valóban csak elvétve van erről iromány, így néhány fogalom nem teljesen volt érthető részére, ezért úgy döntöttem, kezdő szinten írom meg a doksit. Ha jól tudom, akkor nagy része még Exchange 2007 alatt is megállja a helyét.

Nem túlzottan belemélyedve, de felsorolva a szerepet játszó állományok típusai: értelemszerűen az adatbázis (edb, stm), a logok (log), illetve a checkpoint (chk). Szerencsére itt nem körkörös log volt beállítva (ugyanis nagyon régi mentés volt, ejnye :) ).

A backup típusa kétféle lehet: offline és online.

Offline, vagyis fizikai állomány-másolás. Előnye, hogy nincs szükség logok visszajátszására, hátránya, hogy ehhez le kell állítani a szolgáltatást (azaz addig senki nem levelezik), s természetesen tudnunk kell, hogy mit másolunk.

Online, vagyis mentőszoftver segítségével. Előnye, hogy észrevétlen, mert a szolgáltatást nem kell leállítani, illetve kihasználhatjuk a mentő-program előnyeit (differenciális és inkrementális mentés, adott programok esetén pedig a granuláris mentést). Hátránya viszont az, hogy tisztában kell lenni a kiadott parancsok használatával.

A helyreállítás szintén két szinten történhet: soft és hard recovery.

Soft recovery /r

- minden alkalommal lefug a SG minden tárolójára, ha bármelyiket csatoljuk

- még feldolgozatlan logok bejátszása, félbemaradt tranzakciók visszagörgetése

- véletlen leállás után újraindításkor automatikusan lefut

- offline mentés visszaállításakor is lefut

Hard recovery (Restore) /cc

- online backupból való visszaállítás esetén fut

- lementett és még feldolgozatlan logok visszajátszása

- ehhez szükséges a restore.env állomány, ez tartalmazza, hogy mely logokat játssza le

Ha már tisztáztuk az elméleti részét, lássuk a gyakorlatot.

A KB824126 cikk alapján először is természetesen létrehozzuk az RSG-t. majd következő lépésünk az RSG adattal való feltöltése lesz, itt máris kétfelé válik az utunk, a mentésünk típusa alapján.

  1. Hard recovery

Hozzávalók: a log fájlok és a restore.env ideiglenes mappában, adatbázis RSG könyvtárban és ízlés szerint a lejátszandó logok az RSG éles könyvtárában vagy egy másik könyvtárban.

Első lépésben a mentést állítjuk vissza, mondjuk a Windows beépített eszközével készült biztonsági másolatról. Az NtBackup a legelején megkérdi, hogy ugyan már, hova is tegye a mentett logokat és a restore.env-t. Ez az útvonal lesz megadva a későbbiekben használt parancs /cc paramétereként, mint ideiglenes könyvtár.

Ezen továbblépve máris újabb problémába ütközhetünk: ha kijelöljük a teljes Storage Group-ot, akkor az eseménynaplóban hibákat fogunk találni.

ExchangeIS 9635 - Failed to find a database to restore to from the Microsoft Active Directory. Storage Group specified on the backup media is 4cec8935-1fae-40e9-9839-9a3e73e0b7d8. Database specified on backup media is Public Folder Store (SBS), error is 0xc7fe1f42.

ESE Backup 920 - Information Store (4920) Callback function call ErrESECBRestoreGetDestination ended with error 0xC7FE1F42 Database not found.

End Restore to 'SBS\Microsoft Information Store\First Storage Group' 'Failed' Verify: Off Consult the backup report for more detail.

Ez ugye teljesen normális, hiszen a cikkben is le van írva, hogy a Public Folder-eket nem támogatja. Ugyanakkor viszont az egyenes következménye, hogy a restore.env mérete 0 lesz, illetve nem lesz visszaállítva az utolsó log-állomány sem. Előbbinek további következménye, hogy a /cc kapcsolóval nem fogjuk tudni lefuttatni a javítást.

Ha viszont csak a logokat és a Mailbox store-t pipáljuk be, akkor az ntbackup sem panaszkodik, s a visszaállítást is elvégezhetjük.

Még mielőtt megijednénk, természetesen visszaállítás után az

eseutil /mh "E:\ExData\RSG.edb"

segítségével lekérdezett állapot „Dirty” lesz.

A mentés óta történt változásokat a nem mentett logok bejátszásával tudjuk megkapni, ennek két lehetősége van:

  1. átmásoljuk a mentés óta keletkezett logokat a RSG éles log-mappájába (értelemszerűen az E00.log-ot ne is erőltessük)
  2. megadjuk a logok elérési útvonalát (jobb, ha nem az éles FSG log-útvonalát adjuk meg, hanem átmásoljuk valahova), ekkor a /f"E:\ExData\Remained logs" paramétert kell még az alábbi parancs után biggyeszteni (az „f” után nincs szóköz!)

Mindkét esetben a következő lépés az alábbi parancs futtatása (esetleg a /f kapcsolóval kiegészítve):

"%ProgramFiles%\Exchsrvr\bin\eseutil" /cc "E:\ExData\RSG Temporary"

Hatására lejátssza az ideiglenes könyvtárban található, lementett logokat (amelyekre a restore.env állomány utal), majd az „éles” logokat a korábban említett két lehetőség alapján. A végeredmény egy tiszta, naprakész adatbázis lesz, amit már csak csatolni kell, valamint az „éles” logokat tartalmazó könyvtárban (a. esetben az RSG log-mappája, b. esetben a megadott útvonalon) létrejön egy e00.log és e00.chk is – ezért nem szabad az FSG logjainak útvonalát megadni! Ezeket nyugodtan lehet törölni (a bejátszott logokkal együtt), hiszen az RSG az r00.log és r00.chk állományokat fogja használni. Az ideiglenes könyvtár tartalmát eleve törli, tehát ott már csak a könyvtár-struktúra marad.

A művelet ideje a logok mennyiségétől is függ, a kollégánál pl. 3 GB bejátszása bő egy óra alatt ment végbe.

2010. június 25., péntek

"Receive as..." 2. rész

Ezt a cikkem egészítem ki, Exchange 2007 infóval: 1. a. lépésnél, AD Full-jogosultságok helyett az Exchange Management Shell-ben kiadjuk az Add-MailboxPermission -Identity Felhatalmazó -User Kedvezményezett -AccessRights FullAccess -InheritanceType all parancsot, s ezzel ugyanazt érjük el.

Az AccessRights lehetséges értékei:

FullAccess SendAs ExternalAccount DeleteItem ReadPermission ChangePermission ChangeOwner