XP-ről Windows 7-re. Miért is?

Már nem is egészen mostanában egy kolléga arra kért, hogy pár összeszedett gondolatot írjak, milyen kockázattal jár egy nagyobb informatikai szervezet számára a Windows XP-n való maradás, illetve milyen előnyöket jelenthet a Windows 7 bevezetése. Az írás elkészült, el is feledtem, aztán ma valahogy rátaláltam. Anonimizáltam, kissé felfrissítettem és gondoltam megosztom. Elsősorban nagyobb informatikai szervezeteket tartottam szem előtt, kisebb környezetekben vagy otthoni felhasználóknál az érvek egy része nem, vagy csak nehezen értelmezhető. Az érvrendszer tehát nem teljes körű. de ha valaki épp döntés előkészítő tanulmányt ír, hasznos lehet a számára.

A Windows XP-n maradás hátrányai, kockázatai:

Támogatás

• A Windows XP egy, a kilencvenes évek végén tervezett, 2001-ben kiadott operációs rendszer. A kiterjesztett támogatása eredetileg 2011-ig szólt volna, amelyet a Microsoft meghosszabbított 2014-ig. Jelenleg a Windows XP ún. meghosszabbított támgatási periódusban van. Ez azt jelenti, hogy további funkciók fejlesztése nem várható, visszaportolás (egy új OS képesség visszamenőleges biztosítása a régi operációs rendszereken) pedig nem történik. A meghosszabbított támogatási időszakban felbukkanó tervezési hibákat (design bug), ingyenesen nem, csak egyedi árazás mellett javítja. Bár ez nem tűnhet komoly problémának, magyarországi viszonylatban is előfordult ilyen eset. Javítócsomagot a Microsoft nem jelentet meg, kizárólag biztonsági frissítéseket adunk ki a támogatási periódus végéig.
• Az OEM Windows XP-k árusítása befejeződött, a hardver gyártók ma már csak Windows 7-tel árusítanak PC-ket. A Windows XP eszköz ellátottsága szűkül, a meglévő hardverekhez az eszközkezelő fejlesztés leállt, az új PC-khez a Windows XP eszközkezelők fejlesztése másodlagossá vált, vagy nem is történik meg.
• Várható, hogy hamarosan megjelennek olyan alkalmazások, amelyek kihasználják a Windows 7 által nyújtott alkalmazás-fejlesztési környezetet, de épp emiatt, már nem lesznek futtathatók Windows XP-n. (Most mást ne említsek, ilyen alkalmazás az Internet Explorer 9 is!). A Windows XP-n maradás egyik veszélye, hogy nem lehet majd egy adott feladathoz, funkcióhoz a szoftvert rendszert választani, mert a szabványok a Windows XP-hez kötik a szervezetet.

Biztonság

• A Windows XP tervezése jóval a Trustworthy Computing kezdeményezés előtt történt, az eredeti termék tervezése és fejlesztése során pedig még nem alkalmazták a Secure Development Lifecycle (SDL) módszertant. Emiatt a mai napig több sérülékenységet fedeznek fel a rendszerben, mint a későbbi operációs rendszerekben. Az SDL-nek köszönhetően ugyanakkor elvétve akad olyan sérülékenység, amely a Windows XP-ben nem, csak a Windows Vistában vagy Windows 7-ben található. Mindennek következtében a Windows XP naprakészen tartása és biztonságos üzemeltetése több erőfeszítést igényel, mint az újabb operációs rendszereké.
• A beépített biztonsági eszközeit tekintve a Windows XP ma már nem tekinthető korszerűnek. Beépített kétirányú tűzfala például nincs, ezt csak harmadik gyártótól lehet fizetés ellenében beszerezni. Számos kernel szintű védelmi lehetőség ( Address space Layout randomization, service hardening stb.)* nem található meg benne, és nem is pótolható.
• Egy Windows XP feleslegesen tartalmazhat olyan kódot a merevlemezen, amelyek nagy szervezetek nem használnak. Ilyen például a Windows Messenger (a Live Messenger elődje) vagy az Outlook Express, amely helyett többnyire a vállalati célra szánt Microsoft Office Outlook az elterjedt. Ezek a kódok szükségtelen addicionális karbantartást igényelnek.

Funkcionalitás

• A Windows XP-ből számos funkció hiányzik, amelyek szükségesek lehetnek egy nagy szervezet rendszerének üzemeltetésekor, és csak harmadik gyártó megoldásával pótolhatók. Ilyen a merevlemez titkosítás, amely az elveszett vagy eltulajdonított mobil számítógépek adatvédelmét biztosítja.
• A Windows XP számos olyan kiegészítő alkalmazást tartalmaz, amelyek nem eléggé funkció-gazdagok, ezért gyakran ingyenes vagy fizetős változattal pótolják (Merevlemez töredezettség-mentesítő, számológép, wifi- segédprogramok). Ezek az addicionális alkalmazások szükségtelenül drágítják az alap-image elkészítését és karbantartását, valamint az üzemelő rendszerek naprakészen tartását.
• A Windows XP lemezképek függnek az ún. Hardware Abstraction Layer-től (HAL), ezért minden eltérő HAL-t igénylő rendszerhez külön-külön kell elkészíteni a szervezet által támogatható lemezképet. Többezres PC parknál – és itt ez a helyzet – ez jelentős többletköltséget eredményez.

Logisztika

• A magyar informatikai szervezetek Infrastruktúra érettségi szintje desktop management területén többnyire „Basic”. Ez azt jelenti, hogy invesztíció nélkül a Windows 7 migrációt MA elkezdve valószínűsíthető, hogy körülbelül a XP támogatás lejáratának idejére lehetne a feladatot befejezni. A migráció halasztásával előfordulhat, hogy a teljes támogatás elvesztése után is még jelentős számú Windows XP működne a rendszerben. Ez a korábbi generációs Windowsokhoz képes azért nagy probléma, mert az elmúlt évtizedben mind a hálózatos, mind pedig a hálózatot nem használó malware támadások száma megsokszorozódott, így az esetleges védekezési költségek (proaktív illetve reaktív) is megnőttek.

A Windows 7 használatának előnyei:

Támogatás

• A Windows  jelenleg az aktív támogatási periódusában van, de már közel két éve a piacon lévő operációs rendszer, világszinten a második legjelentősebb operációs rendszer.
• A Windows 7 a leggyorsabban növekvő részesedésű rendszer, lényegében minden OEM gyártó kizárólag ilyen rendszerű PC-ket gyárt
• A Windows 7 elfogadottsága magas, a bevezetési tapasztalatok rendkívül jók.

Biztonság

• A Windows 7 teljes egészében a SDL fejlesztési elvek mellett tervezték és készítették, ezért minden szempontból a legbiztonságosabb operációs rendszernek mondható. Szignifikánsabb kevesebb javítás érkezett hozzá, mint a Windows XP-hez azonos életciklus-szakaszban.
• A Windows 7-ben a legkorszerűbb szoftver-védelmi mechanizmusok is megtalálhatók (ASLR, DEP, service hardening)
• A Windows 7 a ma ismert összes online és offline támadási módra tartalmaz védelmi eszközt. Beépített merevlemez-titkosítása van, kétirányú, házirendből szabályozható tűzfala van, beépített malware- védelmet kapott.

Funkcionalitás

• A Windows 7 kernel fejlesztéseinek köszönhetően 20-25%-kal kevesebbet energiát használ fel az alatta futó PC, mint az történne a Windows XP esetén. Egy magyar pénzintézetben (2200 desktop) előzetes számításokat végeztek a várható megtakarításokat illetően, és azt találták, hogy a teljes átállás projektköltségét egy évi energia-megtakarítás már fedezi, a következő években pedig – pusztán ezzel a kimutatható költséggel – már nyereségbe fordul a beruházás.
• A Windows  számos hatékonyságot növelő eszközt tartalmaz, amelyet nem kell külön beszerezni. Ilyen például a „Problem Step Recorder”, amellyel a felhasználók egyszerűen képesek hibabejelentést készíteni.
• A Windows 7 számos olyan kernerfejlesztést tartalmaz, amely miatt alkalmasabb Virtuális Desktop környezetben való használatra. Optimalizálták az IO műveleteket így azonos storage-on több virtuális gépet futtathatunk.
• A Windows 7 hardver-agnosztikus rendszer-lemezképet tartalmaz. Segítségével akár egyetlen lemezképpel le lehet fedni a legnagyobb informatikai hálózatokat is. A lemezképek utólag, offline is módosíthatók, betartva a biztonsági előírásokat. A lemezképeknek nem kell tartalmaznia eszközmeghajtókat, azokat a rendszer képes telepítés közben online forrásból letölteni. Mindemiatt Windows 7-tel sokkal könnyebb az ITIL fogalmai szerint ún. támogatható konfigurációt (supported configuration) készíteni és fenntartani.
• A Windows 7 hatékonyabban képes dolgozni távoli, kis sávszélességű vonalakon, mint azt a Windows XP tesz. Ez köszönhető egyrészt az új SMB 2.0-ás, optimalizált hálózati protokollnak, továbbá a Windows 7 beépített cache funkcióinak. Mindez lehetővé teszi, hogy bérelt vonalak bővítését lehessen elhalasztani vagy elhagyni, illetve ugyanazt az infrastruktúrát kevesebb szerverrel üzemeltetni.
• A Windows 7 Enterprise és Ultimate változatai rendelkeznek DirectAccess képességgel. Ez lehetővé teszi, hogy a tartományi tag Windows 7 állandó jelleggel kapcsolatot tartson a vállalati rendszerrel. A módszer nem csak a VPN szoftverek szükségességét eliminálja nagy részben, hanem jó felügyeletet biztosít a belső IT berkeket elhagyó gépek számára, amelye állandóan képesek frissíteni antimalware adatbázisaikat, letölthetik a biztonsági frissítéseket stb..

Uppsz! Az eredeti szövegben az szerepelt, hogy a Windows XP nem tartalmaz Data Execution Prevention-t. (DEP). Ez nem pontos. Az RTM termék valóban nem, de az SP2 óta ez a képesség a rendszer része. Mivel a mai gépek túlnyomó része SP3-on fut, ezért a DEP hiánya nem állja meg a helyét.

Windows Thin PC – a nagyvállalati vékonykliens OS

A június 7-é RTM-mé vált és július 1-től elérhető Windows Thin PC sokak figyelmét és fantáziáját felkeltette, olyannyira, hogy számos tévhit is kering már róla. Ezek közül néhány hozzám is eljutott, s azt hiszem, egy blog bejegyzést megér tisztázni, mi is ez a fura figura. Tehát a meghatározás:

A Windows Thin PC (WinTPC) egy Windows 7 Embedded alapú operációs rendszer, nagyvállalati felügyeleti képességekkel kiegészítve.  Csak érvényes nagyvállalati szerződés esetén használható, kizárólag vékonykliens operációs rendszerként.

A cikk további részében ezt a meghatározást próbálom kifejteni.

Windows 7 Embedded alapú operációs rendszer

A Microsoft 2006-ban jelentette meg a “Windows Fundamentals for Legacy PC (WinFLP)” fantázia nevű operációs rendszerét, mely felhasználási célját nézve a WinTPC elődjének tekinthető. A WinFLP alapja egy Windows XP Embedded, annak minden előnyével és hátrányával együtt. A Windows 7 Embedded – ahogy a nevéből is látható – egy Windows 7 kernellel rendelkező OS, amelyet a gyártó elsősorban célrendszerek számára fejlesztett. Windows 7 Embedded futhat egy ATM terminálban, egy reptéri check-in terminálban és még sok más célrendszerben. Jellemzője, hogy a komponensei tetszőleges módon variálhatók, az OEM gyártó beleteheti vagy kiveheti azokat a lemezképből. A Windows TPC-t úgy kell elképzelni, mintha egy OEM gyártó már előállított volna a komponensekből egy alap-lemezképet, ennek mérete tehát nem változtatható (2 GB körülbelül, tehát jóval kisebb, mint egy teljes Windows 7). A relatív kis méret miatt kényelmesen elindítható egy USB kulcsról vagy SD kártyáról. A WinTPC képességei között találunk “Write Filter”-t, amely megakadályozza, hogy a rendszerre bármit írjunk – pontosabban újraindítás után mindig egy alapállapotot vesz fel és minden mást elfelejt. E két képesség már egészen firmware szerű kezelést tesz lehetővé. De ez még nem elég az üdvösséghez.

Nagyvállalati felügyeleti képességekkel

Az eredeti Windows 7 Embedded lemezképet az OEM gyártó állítja elő – más ezt nem teheti meg. A Windows Thin PC-nél a végső  – WIM alapú – lemezkép kialakítása a rendszerüzemeltetők feladata. Ez nem csak feladat, de lehetőség is: a lemezképben a szokásos meghajtókon túl az IT a bevett rendszerfelügyeleti ügynökeit is belevarrhatja. Egy gyári vékonyklienshez többnyire a gyártó adja (vagy tukmálja) a rendszerfelügyeleti ügynököt. Vajmi kevés esély van rá, hogy Zenworks-szel, LanDesk-kel vagy más (például SCCM) klienssel együtt kapjuk az eszközöket. A WinTPC-nél ellenben szabad kezet kapunk: olyan felügyeleti eszközt teszünk fel, amilyet csak szeretnénk. Emellett élvezhetjük mindazt, amit egy Windows 7 tud: tartománytagság, csoportházirend alapú szabályozás, IPv6 képességek, IPSec és Bitlocker használat. A tartománytagságot és a csoportházirendek alkalmazhatóságának fontosságát nem tudom eléggé hangsúlyozni. De éppúgy kritikus lehet a DirectAccess, az Applocker, a WSUS, a Windows Deployment Service (WDS)  bevethetősége vagy a már meglévő Windows 7 driver store, nem is beszélve a tömeges aktiválás (KMS, MAK) használatának lehetőségéről.

A Windows Thin PC rendszer létrehozásának egyik célja éppen ez volt: egy szerkezetében és működésében beágyazott rendszer képességeket mutató OS, amelynek felügyelhetősége semmivel sem marad el egy PC-s rendszer mögött.

Érvényes nagyvállalati szerződés

A Windows Thin PC nem kapható OEM csatornán – vagyis nem vásárolható meg egy vékonykliens hardverrel együtt (nem is kell, arra ott a Windows 7 Embedded). De nem kapható “boltban”, dobozos formában sem. Akkor juthat hozzá valaki, ha az alábbi licencek egyikével rendelkezik:

• Nagyvállalati szerződésben érvényes Windows SA (frissítésvédelem)
• Virtual Desktop Access (VDA)
• Windows Intune

Ezeknek a licenceknek jellemzője, hogy desktopokra (PC-kre, notebookokra) érvényes, méghozzá abban az esetben, ha ezeket a rendszereket megfelelő operációs rendszerrel vásárolták (Valamilyen üzleti Windows változattal). Egyéb megkötés nincs, vagyis bármely vállalati licenc modellben (Open, Open Value, Select, Enterprise Agreement (EA), Enterprise Agreement Subscription (EAS), Campus and Schools Agreement (CASA).) elérhető.

A Windows Thin PC egy SA előny. Akkor telepíthető, ha egy desktop a fenti licencek keretében rendelkezik SA-val és addig használható, amíg az SA érvényes. A szerződés lejártával a használat joga is lejár.

Vékonykliens operációs rendszer

Nem csak a hozzáférés módja, de a felhasználása is erőteljesen korlátozott. A létrehozott rendszeren futtathatók:

• Biztonsági alkalmazások (pl. antivírus, harmadik gyártó tűzfala stb.)
• Rendszerfelügyeleti alkalmazások
• Terminal emulációs szoftverek (mainframe, Unix stb. rendszerekhez)
• Remote Desktop és hasonló technológiák (ICA, PC over IP stb.)
• Böngészők (nem csak Internet Explorer)
• Média lejátszók
• Azonnali üzenetküldő alkalmazások (Windows Live Messenger, Skype stb.)
• Dokumentum nézegetők (Word Viewer, Adobe Reader stb.)
• A fentiek futtatásához esetlegesen szükséges .NET Framework vagy Java Virtual Machine

Egyéb alkalmazások viszont nem! Licenc megkötések miatt nem futtatható helyben Microsoft Office vagy egyéb Office csomag, LOB alkalmazások, kliens-szerver alkalmazások stb. A Windows Thin PC feladata, hogy egy meglévő desktopból vékonyklienst varázsoljon. Egy vékonykliensen viszont nincsenek “helyi alkalmazások”. Egy ilyen környezet üzembe állításakor különösen hól jöhet az AppLocker, ami még véletlenül sem engedi a helyi alkalmazások futtatását.

Megint csak látni kell: a WinTPC a nagyvállalati “csináld magad” vékonykliens operációs rendszer. A Windows 7 alapoknak köszönhetően működik rajta a RemoteFX, a DirectAccess és a Bitlocker is, de a gyártó nem engedi, hogy más célra is használjuk: nem általános célú operációs rendszer, nem a Win 7 egy kikönnyített változata.

A létezése a cáfolat

A vékonykliens alapú rendszerek (Citrix, RD, VDI) kialakításánál az egyik fontos érvként gyakran elhangzik, hogy a vékonykliensek nem igényelnek felügyeletet – állapot nélküli gépek, s éppen ez az ilyen megoldások legnagyobb előnye. Az igazság az, hogy ilyet csak az állít, aki sohasem üzemeltetett vékonyklienseket, vagy tudatosan szeretne megtéveszteni másokat. A vékonykliensek felügyelete egyáltalán nem elhanyagolható dolog. Olyannyira nem, hogy a vékonykliens gyártók a saját rendszerfelügyeleti eszközeiket megkülönböztető képességként tűntetik fel. A Win TPC létezése maga a cáfolat arra, hogy vékonyklienseknél nincs szükség felügyeletre. Dehogy nincs! Az állapot nélküli gép egyáltalán nem jelenti azt, hogy konfiguráció nélküli gép, még kevésbé, hogy sohasem változó gép. A konfiguráció kialakítására, változtatására és követésére pedig rendszerfelügyeleti eszközökre van szükségünk. Itt pedig a Win TPC nagyon vonzó képességekkel rendelkezik.

SCCM és a WebDAV probléma

A minap SCCM ügynököket szerettem volna kiszórni néhány gépre, de csodálkozva láttam, hogy a telepítés nem sikerül. Leellenőriztem minden feltételt, amely a kliensek telepítéséhez szükséges – elvileg semmi semi hiányzott. Végül a célgépek C:\Windows\CCMSetup mappa ccmsetup.log-jában nyomra akadtam: “<![LOG[Failed to correctly receive a WEBDAV HTTP request.]LOG]!>”.

Az SCCM működéséhez szükség van IIS-re, továbbá az IIS-hez le kell tölteni  a WebDAV-ot a Microsoft download oldaláról. A letöltés után, de még az SCCM telepítés előtt konfigurálni kell ezen oldalon leírtak alapján. Én ezt meg is tettem, ám valahogy ez a beállítás “elállítódott”. Amikor az IIS konzolon meg szerettem volna nyitni a WebDAV részt, ilyen üzenet fogadott.

Jó volna tudni, hogy miért, mert a hivatkozott sorban korántsem volt dupla bejegyzés, de még a <clear  /> sor beírása sem segített rajtam. Viszont a helyes sorrendű komponens újrarakás megoldotta a helyzetet. Vagyis:

1. Eltávolítottam az SCCM konzollal a Management Point Site System-et.- ez használja a WebDAV-ot.
2. A Server Manager “Remove Role Service” funkciójával kikapcsoltam a WebDAV-ot. Kaptam egy felhívást a rendszer újraindítására.
3. Újraindítás.
4. WebDAV újbóli felrakása (Add Role Service) WebDAV beállítások ellenőrzése – érdekes módon minden beállítás, ami az SCCM-hez kellett, megvolt.
5. SCCM Managment Point hozzáadása a Site System szerepkörökhöz.

Ennyi – az SCCM ügynökök már kúsztak is fel a gépekre.

Windows Thin PC automatikus telepítése

Bár még minden ágát bogát nem jártam végig, egy bosszantó szituációba belefutottam. A Windows Thin PC gyakorlatilag egy testre szabott Windows 7 Embedded, amely a Windows 7 gyökerekből adódóan élvezi mindazon rendszerfelügyeleti eszközök áldását, amelyet egy Windows desktopnál megszoktunk. Ilyen az AD, vagy éppenséggel az én esetemben a Windows Deployment Service. A Thin PC, mint egy ideje minden Windows, WIM fájlformátumban ül a telepítő lemezén, amelyet néhány kattintással be lehet importálni egy WDS környezetbe. Ettől kezdve pont úgy viselkedik, mint egy Windows 7: megjelenik a menüben, automatikus script rendelhető hozzá, telepítés közben magára rántja az eszközkezelő katalógus rá vonatkozó meghajtóit stb. stb. Az importálásnál ugyanakkor érdemes figyelni. Én először a képen is látható “Client” lemezkép csoportba importáltam, amit zokszó nélkül megtett. A csoport már tartalmaz Windows 7 lemezképeket. A telepítés folyamán a Thin PC 0×80070570 hibával a lemezkép kicsomagolásának 1%-os állapotánál ellszállt. A megoldás csupán annyi, hogy egy új lemezkép csoportot hoztam létre – és máris működött minden, mint a karikacsapás. Érdemes odafigyelni erre. Nekem néhány órám elment a hiba megoldásával.

SCVMM 2008 R2 SP1 RC frissítése végleges SP1 verzióra

Ha korábban már frissítetted az SCVMM 2008 R2 szoftveredet az SP1 Release Candidate verziójára, akkor az SP1 végleges kódra közvetlenül lehet upgrade-elni. Ehhez azonban szükséged lesz az SCVMM adatbázisa sémájának a frissítésére. A frissítés egy UpgradeVMMR2SP1RC.exe eszközzel végezhető el, amely a Microsoft Connect-ről tölthető le.

Ha a frissítés előtt mindezt elmulasztottad volna, akkor a folyamat meg fog állni egy "the virtual machine manager database could not be upgraded" hibával, a hibakód 10224 lesz.

Ezen kívül további buktatók is előfordulhatnak, ezért ajánlott a migrációs cikk teljes elolvasása: http://technet.microsoft.com/en-us/library/gg318084.aspx

Opalis – a mindent összeragasztó ragasztó

Bár már több mint egy éve, hogy a Microsoft a portfóliójába illesztette, mégis kevesen hallottak róla. Jelenleg a System Center termékcsalád tagja, s amikor bemutatjuk, valami ehhez hasonló ábrán szokott szerepelni.

Bár semmi kétség, hogy az Opalis jó helyen van a System Center családban, meglehetősen furcsa tag a többiekhez képest. Szemben ugyanis a Configuration Managerrel vagy az Operations Managerrel, az Opalis igazából nem menedzsel semmit. Ha a korábbi családtagok egyikét használni kezdjük, akkor képesek leszünk telepíteni, monitorozni, eseményt gyűjteni, menteni stb. stb. Az Opalis semmi ilyesmit nem tud. Telepítés után magától nem csinál semmit

Az Opalis egy IT folyamat-automatizációs motor, a pontos angol kifejezéssel Run Book Automation software. Nem az a feladata, hogy cselekedjen, hanem az, hogy rögzíteni (megalkotni) lehessen benne számos folyamatot, amelyben szerepelhet telepítés, frissítés, mentés vagy szinte bármi más, az Opalis pedig gondoskodik róla, hogy a megfelelő eszköz a megfelelő műveletet végrehajtsa. A műveletekből úgy lesz folyamat, hogy az egyik művelet eredményét felhasználhatja egy másik, az egyik művelet végére várhat a másik, sőt egy művelet eredményétől függően több végrehatási ágra is szétválhat a végrehajtás.

Az Opalis nagyszerűsége abban rejlik, hogy mindezt nem programozással, hanem ikonok összehuzogatásával, viszonylag gyorsan és egyszerűen létre lehet hozni. Mivel ez így talán még mindig eléggé ködös, mutatok egy pár perces videót egy lehetséges folyamatról.

A bemutató során emlegetett 6.3-as verzió egyébként november végén megjelent, frissítésévédelemmel a System Center vásárlók (SMSE/SMSD tulajdonosok) elérhetik. Természetesen mindez csak egyetlen példa, a szoftver lényege, hogy intuitív módon szinte bármit automatizálni lehet. További érdekes információk:

• 8-Minute-Demo – Opalis CMDB Federation and Event Remediation
• 8-Minute-Demo Opalis and the SharePoint Integration Pack
• 8-Minute-Demo – Opalis Manual Workflow Initiation
• VMM Workflows
• Integration Pack for Windows Tasks
• Workflow Authoring Examples and Samples

Az Opalis nem a világegyenlet megoldása. Automatizáció létezett korábban is scriptek formájában, nem is beszélve arról, hogy ezeket a tevékenységeket kézzel el lehet végezni. Ugyanakkor azt mindenki tudja, hogy igazán jó scripteket kevesen tudnak írni, legalábbis sokkal kevesebben, mint ahányuknak erre egyébként szükségük lenne. De még a jó scriptelőknek is csak egy töredéke dokumentálja a munkáját  – így aztán a scripttől sokan idegenkednek. Kézzel, emberi erőforrással szintén sok minden megoldható, csak éppen nem nyomon követhető, illetve ismétlődés esetén gyakran nem ugyanazt az eredményt adja a “biorobot” (És már a kifejezés is mutatja, hogy a lélektelen ismétlődő feladatokat nem szeretik az emberek.)

Az Opalis ezzel szemben viszonylag egyszerűen, átlátható módon – öndokumentáló jelleggel  – képes automatizálni. Alkalmas az ismétlődő feladatok precíz végrehajtására, de jó lehet az egyszer vagy ritkán végrehajtandó feladatok rögzítésére is. Nem kódolásban gondolkodik – bár azzal igény szerint könnyen kiegészíthető – hanem a vizualizációra helyezi a hangsúlyt. Az egyes rendszerfelügyeleti (vagy éppenséggel nem rendszerfelügyeleti) szoftverek tevékenységeit (activity) ismeri, azokat képes megszólítani.

Ez azonban még mindig kevés. A video láttán az első kérdés az emberben az, vajon hogyan működik ez nem Microsoft szoftverekkel. Jó hírem van: majdnem azt mondhatom, hogy jobban együttműködik a nem Microsoft rendszerfelügyeleti szoftverekkel, mint a saját System Center családtagokkal. Olyannyira, hogy a 6.3-as verzió előtt nem is létezett integrációs csomag (IP) System Center termékhez az SMS-t (!!) és a SCOM-ot leszámítva. Íme a jelenlegi IP lista – nem számítva a Codeplexről letölthetőket:

• BladeLogic Operations Manager
• BMC Atrium CMDB
• BMC Event Manager
• BMC PATROL
• BMC Remedy ARS
• CA AutoSys
• CA eHealth
• CA NSM
• CA Service Desk
• CA Spectrum
• EMC Smarts InCharge
• FTP
• HP Asset Manager
• HP iLO
• HP OpenView Operations
• HP OpenView Service Desk
• HP Service Manager
• HP Network Node Manager
• IBM Tivoli NetCool / OMNIbus
• IBM Tivoli Enterprise Console
• IBM Tivoli Storage Manager
• Microsoft Active Directory
• Microsoft System Center Configuration Manager
• Microsoft System Center Operations Manager
• Microsoft System Center Virtual Machine Manager
• Microsoft System Center Service Manager
• Symantec Net Backup
• VMware vSphere

Értelem szerűen, minél több integrációs csomaggal rendelkezik a szoftver, annál nagyobb a szabadságfoka, s annál többféle folyamat automatizálható vele. Azt gondolom, hogy az Opalis jelentősége nem lebecsülhető. A legegyszerűbb sharepoint lista figyeléstől egy teljes private cloud automatizációig bármit képes elvégezni, s alapvető szerepet játszhat az informatikai üzemeltetésben. Azt hiszem, sokat foglalkozom majd ezzel a technológiával.

Szervezetek egyesülése és a virtualizáció

Érdekes egybeesés, hogy mind a vállalati, mind pedig az állami szektorban belefutottam egy szervezeti egyesüléses történetbe, s mindkét helyen azonos szituáció alakult ki. Az egyik előd VMware-t futtat, a másik Hyper-V-t. Adódik a kérdés, vajon mi maradjon az egyesülés után? Lehet persze “szerelemből” válaszolni, és nyugodtan elhiheti mindenki, a döntéshozók részéről van is erre hajlam, én mégis azt mondom, mérlegeljünk józanul, ugyanis nem csak technológia és nem is csupán csak pénz áll a dolgok mögött. Nézzük a döntési teret, vagy legalábbis annak nagyobbik részét:

• A vSphere lesz a “szabvány”. Szokták volt mondani, hogy “Sohasem rúgtak még ki senkit azért, mert IBM-et vásárolt”. Vagy a sárkányfűárus sárkányfűre vonatkozó megjegyzése is ideillik: “Ha ez nem segít, akkor semmi”. Nagyjából kiviláglik, hogy az ilyen döntés mögött a legfontosabb hajtóerő a biztonságra törekvés. Előnye még a megoldásnak, hogy homogenitást teremt, amely végső soron és hosszú távon a leginkább kívánatos az üzemeltetési költségek szempontjából. Emellett optimális erőforrás használatot tesz lehetővé, hiszen a egyesített homogén rendszer valószínűleg nagyobb “egybefüggő” kapacitással rendelkezik, mint az egyesülés előtti rendszerek. Persze ennek a döntésnek vannak hátrányai is. Szoftver licenc beszerzést igényel – sokszor nem is keveset. Végre kell hajtani egy migrációs projektet, ez szintén idő és pénz. Ha a Hyper-V-s környezet System Centerrel felügyelt, akkor a beruházás esetleg még nem térült meg, a migráció után pedig néhány komponens (például DPM) nem, vagy csak részben lesz használható. Ezen felül képezni kell a munkatársakat is: vagy azért, mert az üzemeltetői csapatok érintetlenül megmaradnak, ekkor a hyper-v-s részleget fel kell hozni Vmware tudásszintre, vagy azért, mert a vmwares csapat átveszi az összes virtualizációs feladatot, de ekkor a hyper-v-s üzemeltetőknek kell más munkát végeznie, s ahhoz képzés is járul. Végül, ha a csapatot megvágják, akkor végkielégítésekkel kell számolni.
• A Hyper-V lesz a “szabvány”. A fenti helyezet fordított előjellel. A fő motiváció itt a költségtakarékosság lehet. A Hyper-V ár/érték aránya jobb, ha pedig műszakilag is kielégíti az igényeket, akkor nincs akadálya ennek az útnak. Előnye a lépésnek a korábban már emlegetett homogenitás, optimális erőforrás kihasználás. Költségek itt is felmerülnek, nem is kevés: ugyanúgy van migrációs projekt, jelentkezhetnek addícionális System Center licenc költségek. Éppúgy , mint az első esetben, itt is felmerülhet, hogy a korábbi (VMware) beruházás még nem térült meg, a migráció után pedig lehet, hogy további szoftverekről kell lemondani, miközben azok még amortizálódnak.
• Mindkét technológiai a helyén marad, külön rendszerfelügyelettel. Ha az első két verzió hátrányai (migrációs projekt, korábbi, meg nem térülő beruházás, nem kívánatos szervezeti átalakulás) túlságosan is fájnak, akár az is elképzelhető, hogy mindkét rendszer marad a helyén. Ekkor nincs migrációs projekt, minden korábbi befektetés ketyeg tovább, viszont a technológiai erőforrásokkal nem bánik hatékonyan a szervezet, illetve a rendszerfelügyelet emberi erőforrás igénye sem változik.
• Mindkét technológia a helyén marad, egyesített rendszerfelügyelettel. Elsőre ez egy remek ötlet. A Virtual Machine Manager  segítségével a VMware napi üzemeltetési feladatok elláthatók. Nincs migrációs projekt, nincs meg nem térült beruházás, sőt még az üzemeltetési szervezet is csökkenthető valamilyen mértékben. Persze az egyesített rendszerfelügyelet papíron szép, de egyelőre nem varratmentes megoldás. Az SCVMM számos limitációval rendelkezik, a DPM VMware-nél csak a vendég Windows rendszerekhez használható, a SCOM pedig többnyire nem egy VMware, hanem egy HP, BMC, CA vagy IBM megoldással néz szembe – az megér egy külön bejegyzést.

  Láthatjuk, hogy nincs egyetlen járható út, bármely döntésnek előnyei és hátrányai is vannak. Azt pedig, hogy melyiket érdemes választani nem kis mértében befolyásolhatja néhány egyéb tényező is. Ilyen például:

• Licenc szerződések és/vagy támogatás lejárta. Ha az egyik rendszer nagyon öreg, az a migráció felé billentheti a mérleget. Ha már nem is támogatott, az még inkább.
• A rendszer súlya. Ha az egyik egy éles környezet, a másikkal pedig legfeljebb kísérletezget az IT csapat, ott nem kétséges, hogy a homogenizáció vonzóbb lehetőség. Ha mindkét rendszer “nagy”, akkor az az együttélési szituációkat helyezi előtérbe. A “nagy” persze egy relatív fogalom, a szervezet méretéhez, változtatási képességéhez viszonyítok.
• Az üzemeltetők agilitása. Ha az egyik virtualizációs csapat önálló, lelkes és agilis, míg a másik azt sem tudja pontosan, hogy mi van a kezében, akkor ez a homogenitás megteremtése felé terelheti a döntést..
• Az informatikai szervezet érettsége. Az érettebb szervezetek kisebb költséggel, hatékonyabban és agilisen működnek. Ez könnyedén ellensúlyozni képes migrációs költségeket vagy éppenséggel egyik vagy másik termék árelőnyét. Legjobb példa erre a Microsoft 2010 nyári felmérése. A diagramokból látszik, hogy az IT érettség sokkal jobban befolyásolja a költségek alakulását, mint egy adott technolgia kiválasztása.

Azt hiszem sikerült felvillantanom, hogy a probléma sokkal összetettebb annál, minthogy csupán zsigeri preferenciák alapján szülessenek döntések. “Szerelem” helyett bölcs körültekintést ajánlok.

Service Manager 2010 képzés – első nap

Hohó! Ezek a srácok a jó oldalán fogták meg a dolgokat. A tanfolyam tematikáját nem gépiesen a termékre építették, hanem alaposan végigondolták. Hezitáltak, súlyoztak, tanakodtak. (Sőt, mindezt el is mondták nekünk ) Megérte! Az első napot nem a Service Manager-rel töltöttük, hanem a ITIL és a MOF témához vágó részleteit vettük át (Változáskezelés, Incidenskezelés,. probléma kezelés, Konfiguráció kezelés, GRC) Elő sem vettük a billentyűzetet, viszont tudjuk, hogy mitől jelentős egy változás és mitől szabványos, hogy milyen bejelentési kategóriák vannak és mit jelent egy incidensnél a hatás (Impact) és a sürgősség (urgency). Feladatokat oldottunk meg, megvitattuk őket, kerestünk több jó megoldást. Hmm. Le a kalappal az előadók előtt!

Jól látható, hogy azok a dilemmák, amelyeket most a tanfolyam kapcsán velünk megosztottak, a projekteknél is elő fognak jönni. Nekünk kell majd az elején elkergetni a gép elől a rögtön telepíteni igyekvőket, rávenni a csapatot egy közös MOF tréningre, rávenni őket a projekt kemény fókuszálására. Nem lesz egyszerű: az IT társadalom az egész világon az eszközökben látja a megoldást, nem pedig a folyamatokban. Este a vacsoránál megkérdezték, hogy nem volt-e túl merész egész nap folyamatokkal foglalkozni a technológia helyett. Hát nem, nem volt az! Az viszont igaz, hogy egy ITIL Foundation és egy MOF Essentials nélkül némileg nehezebb lett volna követni a témát, vagy legalábbis kevesebb megvilágosodásom lett volna. Ebből meg az következik, hogy MOF/ITIL fogalmi ismeretek nélkül még beszélni is nehéz a Service Manager-ről. Hogy fogjuk ez megmutatni a Techneten?

Várom a következő napot!

Féregírtás és evangelizáció

Mostanában szomszédékkal gyakrabban beszélgetünk számítástechnikai témákról. És ahogy az már a papokkal és a doktorokkal is lenni szokott, hogy tudnillik kiderül, hogy ekkor meg akkor nem tartotta a böjtöt, (orvos esetén: itt meg ott fáj), no nálunk előbb-utóbb előkerül egy-két gép, amit “meg tudnál nézni"?” És persze ahogy a szakmáját szereti az orvos meg a pap, úgy mi szívesen segítünk. Na jó, embere válogatja, de én a szívesen segítők kategóriájába tartozom. Még akkor is, ha be kell vallani, már rég messze vagyok attól, hogy azt mondhassam magamról, értek a PC-hez, attól pedig főleg, hogy támogatni is tudom. De hát ott van, ugye, az elárvult szomszéd, meg aztán milyen az már, hogy egy informatikus azt mondja, hogy még a PC-hez sem ért?

Elkalandoztam, jöjjön a történet. Pár napja szólt Zsuzsa, hogy van egy kis gond a gépével, nem jön be rajta az Internet, ha volna egy kis időm, akkor nézzek rá. Hétfő délután átugrottam, és gyorsan dobtam egy csont nélküli kosarat. Pár napja pakolták ki a szobájukat, amely korábban irodaként szolgált, és az ADSL router ment a “céges holmikkal” együtt az új irodába. Maradt egy pucér Ethernet kábel, Rubicom Internet hozzáférés. Ebből aztán már adódott a megoldás, a notebook – mert egy hordozható gépről van szó  – MAC-címét kellett regisztráltatni a szolgáltatónál, hogy a hozzáférés működjön. Betelefonáltunk, azonosítottuk magunkat, negyed óra múlva jött is a net, ahogy kell. Ha úgy nézem, itt véget érhetett volna a szerepem, de engem zavart, hogy egy notebookot csak úgy kiraknak pucéran a Netre, gondoltam megnézem, napra kész-e a gép, hogy ezt a kockázatot vállalni lehessen. Naív voltam. XP SP1, tűzfal nélkül, nem működő automatikus frissítéssel és Trend-Micro 2002 (!) próbaverziós antivírussal. No ez már mégsem maradhat így! Az világos, hogy egymagam nem küzdhetek a nagy botnetekkel, de nehogy már a szomszédtól kapjak spam-et! Az a minimum, hogy a gépre SP3, meg új böngésző, meg tűzfal kerüljön. A szomszédasszonynak nem volt ellene kifogása, úgyhogy el is kezdtem egy SP2 telepítést. Mivel azonban egy ilyen dolog sokáig tart, azt mondtam neki, hogy ha kérdez valamit a rendszer, akkor válaszoljon mindig igent, én meg majd később átnézek. Megegyeztünk, így is történt. Mikor visszaértem látom ám, hogy egy fájl másolásánál elakadt a telepítés, CRC hiba vagy ilyesmi, biztos a fájlrendszer sem tökéletes. Na, nem baj, gondoltam, majd letöltök én kézzel egy SP2-t, és kicserélem azt a hibás fájlt, aztán mehet tovább a telepítés. Mondtam az asszonykának, hogy hagyják így a gépet, este mindenképpen jövök, mert így nem maradhat.

Mentem is, de egy kis meglepetés ért. Közben “kicsit használták” a gépet és “azokat az ablakokat bezárták”. Hmm!! SP2 telepítés közben! Most aztán derítsem ki, hogy milyen állapotban van a gép. Félig SP2, félig SP1. A logok alapján ugyan visszagörgött a MSI, de azért ez így veszélyes helyzet. Megpróbáltam újraindítani a telepítőt, de erre csak annyit mondott a notebook, hogy “nice try”, előbb a korábbi telepítést koronázzam meg egy újraindítással. Bátraké a szerencse: megtettem.

Ahogy az igazi rossz álmokban lenni szokott: Home Edition, indulás, majd újra csak indulás, majd újra csak indulás…. a bejelentkezésig sohasem jutottam el. Safe Mode-ban sem, VGA módban sem, az utolsó jó konfiguráció betöltésével sem (ami érthető, hiszen fájlokat írtam felül, nem registry bejegyzéseket.) Hmm. Hétfő este volt, nekem szerdára egy fontos demót kellett összeraknom. Ebbe a slamasztikába viszont már belemásztam, nem lehet itthagyni. Megkérdeztem, folytathatnám-e szerdán, akkor több időm lesz. Persze. OK. Hibajavítás szerdára halasztva. Addig meg felkészülök a lehetetlenre: kipucolni egy félig felment SP2-t.

A szerdából csütörtök este lett, a készülésből meg semmi, de azért nekiugrottam. Volt talonban egy ERD Commander 5-ös lemezem, először azt néztem meg, hogy ha minden kötél szakad, akkor lementhetem-e az állományokat. Ez működött. Indítottam “Safe mode”-ban a gépet, az agp440.sys-ig jutott, aztán újraindult. Netezés: kapcsoljuk ki az agp440.sys-t mert megsérülhetett. Az ERD5-tel ezt megtettem. Változott a helyzet, most a mup.sys nem indult. Mi az a mup.sys? Egy UNC Provider driver. Jó, akkor most megleszünk nélküle. Az állományok dátuma szerint ugyan SP1-es, de lehet, hogy megsérült. Kikapcsoltam azt is. Ekkor az ndisproxy.sys-nél akadt el: tovább hátráltam. A következő az NTFS.SYS-volt. Hát ennek a próbasornak itt a vége. Fájlrendszer nélkül nincs semmi. Különben is, valamennyi driver SP1-es, úgy tűnik, hogy működött a telepítő visszagörgetési funkciója.

Egyik-másik oldalon olvastam, hogy a mup.sys kiakadásának számos oka lehet, de valahogy nem passzolt egyik sem az én problémámhoz. Ezek a cikkek ugyanis azt feltételezték, hogy az állományok, amelyekkel dolgoznia kellene a Windowsnak, jók, csak a registry mutat rossz helyre vagy tartalmaz rossz bejegyzéseket. Ezért a cikkek lényege az volt, hogy produkáljunk egy alap registry-t (OEM Windows esetén ez újabb aktiválást jelent), majd ha van System Restore (nálam volt), akkor álljunk vissza egy korábbi verzióra. Nekem viszont az volt az ideám, hogy nem jók a fájlok – csak éppen azt nem tudom, melyik nem jó.

Végiggondoltam az egészet és rájöttem, hogy fordítva kell elindulni. Nem azokkal az állományokkal van baj, amelyeket nem tölt be a rendszer, hanem azokkal amelyeket betölt, de nem jó verziót használ, mert az SP2 már felülvágta. Így aztán előbb elvégeztem egy olyan indítást, amikor nem a safe mode-ot, hanem az “Enable boot log” opciót választottam, majd az ERD5-öt indítva megnéztem milyen naplót produkált a gép, mit töltött be illetve mit nem. Elég érdekes eredményt kaptam. Láttam például, hogy egy PCIDump.sys állomány betöltése sikertelen volt. Mi ez a PCIDump? Aha, sok minden lehet: vírus, rootkit, trójai. Úgy tűnik, hogy nincs a gépen, de ha rootkit, akkor esetleg elrejtette magát. Van itt más is:

Az első egy nagyon különös helyre települt eszközmeghajtó . A másik képen meg egy látszólag telepítéshez való szolgáltatás. Minek ilyen szolgáltatás, amikor van a rendszerben egy saját, beépített? Csak nem egy Win32/IRCBot.IW? Szóval itt vírusok is lesznek, vagyis lesz még dolgom az életre lehelés után is. Nagyjából így tértem nyugovóra csötörtök éjjel.

Nem tudom, ki hogy van vele, de elalvás előtt pörög a legjobban az agyam. Ilyenkor még 4-5 ötletet összegyűjtök és teljes nyugalommal alszom el. Most is így történt. Az egyik ötletem az volt, hogy mindent kikapcsolok, azokat a szolgáltatásokat is, amelyek működnek. Aztán arra is gondoltam, hogy leellenőrzöm, hogy az így, szűkítetten induló gép egyes dll-jei milyen dátumúak. Csak SP1-esnek szabad lennie. Ha valamelyik kilóg a sorból, akkor meglesz a ludas.

Másnap ezt is tettem. Leállítottam mindent, amit csak tudtam, hogy elég kevés eszközkezelő maradjon, azok meg mind SP1-esek voltak (és SP1-es volt a kernel is, természetesen). Vagyis az ötlet nem jött be. Közben azonban kigondoltam valami mást. Az ERD5-ben van egy összeomlás elemző is. Hátha elemzi, mi történik. Itt sem jártam sikerrel. 2007 decemberében volt ugyan egy összeomlás a sentinel eszközkezelő miatt (hardverkulcs, ugye?), de a mostani újraindulások semmilyen naplóba sem kerülnek be, túl korai fázisban történik.

No de milyen összeomlás ez? Azonnal újraindul a rendszer, mert úgy van beállítva, hogy a kékhalál után legyen újraindulás. Kapcsoljuk ki. (HKLMSYSTEMCurrentControlSetControlCrashControl ban kell az AutoReboot értéket 0-ra állítani). Szépen meg is állt a megfeleleő pillanatban:

STOP: c000021a {Fatal System Error}
The Windows Logon Process system process terminated unexpectedly with a status of (0xc0000080 0×00000000 0×0000000)
The system has been shutdown.

Találtam rögtön egy cikket (Q156669), ami szerint ilyen hibák például akkor szoktak előfordulni, ha nem sikerül felrakni egy javítócsomagot. Bingó! Most már csak végig kell haladni a cikken és kész. Aha. Nem ilyen egyszerű az élet. A cikk azt feltételezte, hogy NÉHA így dobja el magát a rendszer, de minden esetre legalább egy safe mode-ban el lehet indítani, hogy aztán a Dr.Watson-t regisztrálni lehessen mint alapértelmezett debuggert. Ez nekem nem ment. Nem működött az utolsó jó konfiguráció sem, a harmadik gyártótól származó kódokat meg már rég kikapcsoltam. Marad a helyből frissítés? Hátha mégse… Esetleg egy ASR (Advanced System Recovery). Ahhoz kellene egy SP1-es telepítő. Felhívtam Gál Tamást – nem volt neki. (Home Edition, ne feledjük!) Aztán felhívtam öcsémet, hátha neki van. Volt. Megígérte, hogy beküldi Pomázról, mert egy kollégája épp jött be Pestre. Ez nagyszerű. Egy fél órával később eszembe jutott, hátha van neki valami olyan CD-re, amely bebootol és vírust írt. (Hiába, na, nem dolgom, akkor nem tartok magamnál ilyet. Az ERD5-ben nincs ilyen. Az ERD6-ban van, de az meg csak Vistához jó.). Megkaptam a CD-ket, el is indítottam az ASR-t, de csak akkor jutott eszembe, hogy ja, ide floppy is kellene – az meg ebben a notebookban már nincs. A vírusírtót is futtattam, de régi lehetett az adatbázisa, mert nem talált semmit.

Így jött el a szombat. Beszta Janit kerestem telefonon, hátha ő tud olyan helyet, ahonnan működö Antivírus rescue disket lehet letölteni. Sajnos nem vette fel. A c0000021a hibára keresgettem cikkeket, fórumbejegyzéseket, de csak olyan oldalakat találtam, ahol ugyanez a hiba és nincs más megoldás, mint az újratelepítés. Ez nem igaz! Én ezt a gépet NEM fogom újrahúzni. Ez már preztizskérdés! Szombat délután, amikor a feleségem a gyerekekkel a játszótérre indult, úgy búcsúztam tőle, hogy már nem sok munícióm maradt, és ha minden kötél szakad, akkor újra kell húznom a gépet. Aztán ahogy nagy csend lett a lakásban, hirtelen támadt egy ötletem.

Hátha a Winlogon-t vírus írta felül? Megnéztem, dátum szerint a fájl érintetlen volt. Viszont sikerült találnom a merevlemezen egy i386 könyvtárban egy ugyanolyan dátumú winlogon.exe-t. Egy mappába másoltam őket, íme az eredmény:

A .orig végződésűvel szeretett volna indulni a rendszer, csak hát férges a szentem. Csere-bere, és BINGÓ! Elindult a masina.  Csupán azért nem ugráltam körbe a lakást, mert még nem gyógyult meg a bokám.

Jani továbbra sem volt elérhető, pedig a vírus vonal egyre valószínűbb. Az is lehet, gondoltam, hogy egy Rootkittel van dolgunk. Gyorsan letöltöttem a SysInternals oldalról a RootkitRevealer-t, ami hozott is némi eredményt:

Jó, ezeket a kulcsokat lehet törölni, de ettől még szükség van egy Offline vírusírtásra. Vajon melyik vírusírtó cégnek van boot CD-je naprakész vírusírtó adatbázissal letölthető, formában? Kutakodtam a neten, de egyetlen használható rendszer sem volt. Annyi legalább kiderült, hogy minden vírusírtóhoz SP2 kell, és hogy a ForeFront kínálja a leghosszabb próbaperiódust – 120 napot.

Amíg meglesz a bootolható CD, gondoltam, felteszem az SP2-t (meg az SP3-at). Így is tettem. És ha már van SP3, akkor feltettem egy 120 napos ForeFront Client-et is, hátha nem fut a vírus, akkor szerencsém van. Azt tudtam, hogy a ForeFront adatbázisának frissítéséhez nem Windows, hanem Microsoft Update kell. Viszont amikor át szerettem volna állni, és a frissítéseket leszedni, úgy találtam, hogy nincs internet hozzáférésem. Hmm. Pont a Windows Update-hez? Ez tipikus vírus-szokás. Esetleg a host állományt írta volna felül? A kis huncut! Nem beleírta magát NtKrnlpa.info-ként! Ez a W32.Virut.CF szokása.

Most akkor fut a vírus, vagy nem? A Microsoft Update-et valahogy sikerült elindítanom, és le is jött az új motor meg a szignatúra-adatbázis, ekkor azonban a rendszer teljesen megkergült. A Forefront gyakorlatilag azonnal mindent karanténba zárt, bármihez értem, bármit indítottam és W32Virut.AC vírusra panaszkodott. Újra kellett indítanom a gépet és bár elindult, elfogadta a felhasználók jelszavát is, a bejelentkezés azonban 2 másodperc után kijelentkezéssé alakult, vagyis a gépbe nem tudtam belépni. Szerencsére a safe mode működött, de a a Forefront 2 másodperc után abbahagyta az ellenőrzés. Szereztem egy egyedi, kifejezetten a Virut eltávolítására való szoftvert is a Symantec oldaláról, de csalódnom kellett: két futó processz kiírtásán túl egyetlen vírust sem talált. Ennyi töketlenkedést!

Ekkor sikerült végre beszélnem Beszta Janival. Fantasztikus javaslata volt! Az ESET cég NOD32-es vírusírtója tartalmaz egy Rescue Disk előállító alkalmazást is, és ha van a gépen Windows Automated Installation Kit (WAIK), akkor az abban lévő WinPE segítségével készít egy naprakész antivírus adatbázissal ellátott, bootolható CD-t. Hoppá! Van, aki támaszkodik a Microsoft ingyenes eszközeire? Ez igen! A hír szombat este érkezett, és tudtam, hogy egy ESET letöltés telepítés, WAIK telepítés, majd diszk készítés barátok között is legalább két óra, feltéve, hogy van használható XP a közelben. Nekem szerencsére volt egy, virtuális gépben futtatott példány. Vacsora és gyerekfürdetés közben/alatt/mellett kipreparáltam a gépemet, telepítettem rá egy NOD32 4-es verziót, illetve emlékeztem, hogy a Windows 7-hez letöltöttem már egy WAIK-ot, felraktam hát azt.

Persze a lusta ember kétszer dolgozik. Az ISO készítő rutin gyorsan elhasalt. A neten való keresgélés során hamar kiderült, hogy a hiba az új (béta) WAIK-kal van. No, ekkor gyorsan visszaálltam az eredeti XP preparátumra (Hyper-V snaphot), NOD32 újra letölt, telepít, aktuális WAIK letölt, telepít. Az antivírus adatbázisa február 20-a volt, és nem akart frissülni, nem baj, jó lesz ezzel is. Az ISO elsőre sikerült, de amikor visszatértem, a NOD32 jelezte, hogy van mai adatbázisa. Na, akkor még egyszer ISO készítés. Az elkészültét azonban nem vártam meg, véget ért a szombat, elmentem aludni.

Vasárnap reggel az első dolgom a ISO kiírása, majd futtatása volt. Legnagyobb meglepetésemre egyetlen vírust sem talált. Ez hihetetlen! És ami még furcsább, a lemezen nem volt felület, ahol meg lehetett volna nézni, milyen dátumú adatbázissal dolgozik a program. A könyvtár kilistázása meg azért nem segített, mert ott a ISO elkészítési dátuma szerepelt. Hogyan lehetne leellenőrizni ezt a merevlemezt? Kell, hogy legyen vírus! Megint következett egy óra gondolkodás.

Végül a megoldás egyszerű volt, mint a pofon: az ERD5 képes megosztani meghajtókat! Megosztottam, majd távolról a NOD32 BIZTOSAN naprakész adatbázisával végeztem egy ellenőrzést. Először csak egy javítás nélküli átfésülést, majd egy tényleges írtást hajtottam végre. Több mint ezer víruspéldányt találtam (valószínűleg a Forefront ellenőrzés szórta szét a nagy részét), de típus szerint is gazdag volt a felhozatal:

1. 1. Win32/Virut.AV – vírus
2. 2. Win32/Hatob.E – féreg
3. 3. Win32/Injektor.KT – trójai
4. 4. Win32/Injektor.MM – trójai
5. 5. Win32/Rbot – trójai (image.jpg-ben!)
6. 6. Win32/Injektor.KT változat – trójai
7. 7. Win32/IRCBot.ANC

A kép tanusága szerint mindet le is irtotta. Ezután már be tudtam lépni a gépbe, naprakészre frissítettem a ForeFrontot, és mivel volt néhány tömörített állomány, amelyet az NOD32 a hálózaton át nem nyitott meg, még egy ellenőrzést végeztem. Megérte. A hálón fennakadt még további hat példány és még egy típus. TrojanDownloader.BAT/FTper.gen. Ezzel a javítás befejeződött. Már csak annyi dolgom volt, hogy naprakészre frissítsem a gépet, bekapcsoljam a tűzfalat és feltegyek egy IE8-at, abban legalább van adathalász-szűrő, meg ha kell automatikusan frissül.

Vasárnap estére elkészültem, átkopogtam a szomszédhoz, majd amennyire csak lehetett mellőztem a szakmai fogalmakat, de elmeséltem, mi történt. Ezután egy gyorstalpaló következett: mi mindent kell megtenni annak érdekében, hogy az ember biztonságosan Internetezhessen.

Csodálkoztak rajta, hogy ennyi vírus hogyan kerülhetett rá, hiszen nem is volt hálózaton. Aztán amikor a férj megjött, kiderült a működési üzemmód: előkerült egy mobil internetes kártya és már jött is a net. Aha. Hát így.

Szakmai szempontból – utólag persze – a sok kanyar símán levágható lett volna. Élni lehetett volna a gyanúperrel, hogy “ilyen környezetből” vírusos gép várható, ezért mindjárt az ESET-tel kellett volna kezdeni – vagyis, tulajdonképpen bármilyen naprakész vírusírtó megtette volna, csupán az ERD5 megosztási képességét kellett volna igénybe venni mindjárt az elején.

Ebből is látszik, hogy ez a feladat nem a szakmám. Megoldottam, mert meg akartam oldani, de egy otthoni felhasználókat nap mint nap támogató mellékállásos rendszergazda egy óra alatt elintézte volna. Lehet, hogy nem tudta volna kideríteni, hogy a winlogon.exe miatt nem indul a gép, de a vírusírtó megoldotta volna helyette a problémát. A frissítés nem már rutinművelet.

Jó kaland volt. Egy időre elég is belőle

Apró figyelmesség a DHCP konzolban

Megoszlanak a rendszergazdák abban a tekintetben, hogy a kiszolgálók számára inkább rögzített címet adnak, vagy hagyják, hogy a DHCP szolgáltatás végezze a dolgát. Én egy járható középutat képviselek: hacsak egy alkalmazás (pl: DHCP szerver, DNS szerver stb.) nem követeli meg a fix IP-címet, én a dinamikus – de lefoglalt címkiosztást (reservation) konfigurálom be. Így állandó IP-címeket kapok, mégis központi felügyeletet. Egy gond van csak ezzel, az, hogy macerás a rekordok rögzítése. Megnézni a MAC címet, majd bepötyögni, ellenőrzni, hogy a kiszolgáló biztosan az a címet kapja… Fárasztó, na.

A fejlesztők is ezt gondolhatták, mert a minap telepített Windows Server 2008 R2-es DHCP konzolban észrevettem egy új funkciót. Egy kiosztott címre jobb egérgombbal kattintva azonnal “rögzíthetjük” a foglalást az “Add to Reservation” menüvel. Ah, minő kényelem!

 
Persze lehet, hogy ez csak nekem új és már a Windows Server 2008-ban is megvolt (nem jártam utána). Ez mindenesetre pár tucat kattintással rövidíti a munkát egy-egy gép esetén. Örülök.