Prim Hírek

Fő céljuk az volt, hogy ’valamit tanuljanak is a résztvevők, ha már konferenciára járnak’. Nos, mint legutóbb is kiderült, sokan járnak a MS konferenciáira, és még a késő délutánba nyúló programokra is vevők. Nyilván azért, mert tényleg tudnak mit tanulni belőle. Még itt, a felvezetőben, hívjuk föl a figyelmet arra a két legújabb MS konferenciára (V.7. és V.15.), amely a május elején debütáló .NET technológiát mutatja be (ha még valaki nem hallott volna róla).

http://www.microsoft.com/hun/events/default.asp

MS vegyes saláta

Nos, a profi üzemeltető környezetekben ma már az MS DOS és a Windows 3.x az a Microsoft termék, ami csak fehér hollóként található meg (a boltokban is). Amúgy, sajnos, talán még mindenütt felvonulnak a MS teljes 32-bites korszakbeli technikatörténeti relikviái, a W95 (jóllehet, hivatalosan már nem támogatott!), a W98, a W98SE, a WME (főként a játékos kedvűek, a kurióz perifériák és a szűkebb gépi erőforrások miatt), a sziklaszilárd NT4-es, és jövőképes W2K és WXP korszakbeliekkel egy csokorban. Itt-ott már a majdnem végleges állapotú .NET szerverekkel kombináltan. Kevés olyan cég van, amely a mai hazai recessziótól épp az informatikában leginkább sújtott gazdasági környezetben képes legyen a totális eszközkonszolidációra. Pedig a rendszergazda kényelmét nyilván az szolgálná. Ha már ez lehetetlen, akkor meg kell tanulni, együtt élni a realitásokkal, lehetőleg minél kisebb kompromisszumok árán. Ami ma a legkritikusabb, az a biztonságtechnika, az adatok védelme, a hálózatok védelme, és küzdelem a vírusokkal stb. Egyre égetőbb, főként a felgyülemlett adatvagyon miatt, a nagy megbízhatóságú üzemvitel, ami erősen elvezet a korábbi kis PC-LAN-os korszakból, az egyre komplexebb, többrétegű informatikai infrastruktúra kiépítése felé.

Mint a konferencia előzetes összefoglalójában is írtuk, a hardver és az alapszoftver vegyes felvágottat még tovább bonyolítják a Backoffice és az Office technológia különböző generációi. Ezek közül a legkritikusabb elem a levelező rendszer, amely az Exchange 5.5 (vagy az előtti), valamint az Exchange 2000 (vagy az utáni) állapotok keveréke miatt problémás. Ez közvetlenül kapcsolódik a Windows 2000 alapoperációs rendszerben bevezetett teljes TCP/IP szabványosság (DNS), és az Active Directory MS címtári technológia következetes kezeléséből eredő problémákhoz. A Windows XP és az Office XP pedig a .NET filozófia jegyében megreformált MS licenszpolitika miatt okoz a korábbiaktól eltérő üzemeltetői viselkedésmódot, különösen a termékaktiválási procedúra miatt, jóllehet a nagyvállalati alkalmazók ennek hatásait elvileg nem érzik.

Érdekvédelem!

A konszolidáláshoz szükséges szűkös erőforrások kapcsán nem kerülhető ki az érdekvédelem kérdése. Mert jó kérdés, hogy ki az, aki ma ki tudja dobni az összes régi licenszkonstrukciós erőforrását, és lecseréli tiszta XP vagy .NET technológiásra. Legföljebb zöldmezős beruházásnál fordulhat elő, ahol a teljes beruházási összeghez képest ez csak filléreknek számít. Ilyen azért kevés van (az egyik CIO konferencián Homonnay Gábor dicsekedett ilyen irigylésre méltó helyzettel, egy Sanofi nagyberuházás kapcsán). Az ipari érdekvédelmi szervezeteknek mindenesetre nem az ilyen izomcégek állapotát kellene figyelembe venni, amikor a hardver-szoftver szállítók praktikáit nézik, ha egyáltalán nézik, és nem inkább beletörődnek a multik diktátumaiba, nem túl jó szolgálatot téve azoknak, akiknek az érdekeit kellene megvédeniük!

Inkább fokozottan kereshetnék az együttműködést az Európai Unió érdekvédelmi szerveivel, a közös fellépés végett. Az Uniós csatlakozás kapcsán nem csak a mezőgazdaságra kellene odafigyelni, hanem a korszak-meghatározó informatikára is. A gyorsabb terjedés előmozdításához közös erővel kiharcolt kedvezményekre is szükség van a szállítókkal szemben (és ez, persze, nem csak a Microsoftra vonatkozik). A Magyar Kormány, és a mellette működő ITK (amelynek munkájában az elmúlt pár évben a szakmai tényezők egyébként jobban domináltak, mint más területen), már eddig is jelentős sikereket ért el, amit persze még lehet tovább növelni. Az így keletkező piacbővülés a szállító cégeknek is jó, tehát érdekükben állna. Nem beszélve a magasabb szintű licensztisztaság jótékony hatásairól (és hogy a magyar BSA alapjaiban logikus politikája ne torkolljon rendőrségi túlkapásokba).

NT4 és W2K házassága

Visszatérve a szakmai részletekhez, a Windows NT4-es változat az elmúlt 8 év során kőkemény üzleti platformmá érett. Azonban a MS már rég szabadulna tőle, de a végfelhasználók, egyrészt igen elégedettek vele, másrészt a 2000. év kapcsán teremtett nagy Y2K hisztériában alaposan kiköltekeztek miatta, jelentős pénzeket verve a rendszereik Y2K konformmá tételébe. Ez kifacsarta az informatikai vezetők zsebét a cégek igen nagy százalékánál, úgyhogy a gazdasági igazgatótól olykor elemi üzemeltetési költségigényekre is csak indulatos válaszokat remélhetnek: épp most stafíroztunk ki benneteket, most egy darabig hallgassatok, jó? Reméljük, hogy két év elmúltával ez a riposzt már egyre nehezebben tartható, mivel a korlátozás rendszerint az intézményi pénzügyet is sújtja. Így a váltás már összintézményi érdek.

Mindenesetre, az MS már az összes fontos csatlakozó technológiáját a 2 éves W2K platformjára igazítja, ráadásul napokon belül a következő, .NET-es generáció is itt kopogtat az ajtón. Az üzemeltetők, de leginkább a végfelhasználók, ma már gyakorlatilag egy teljes technológiaváltás kihagyását is megkockáztathatják. Addig azonban együtt kell élni a meglévő realitásokkal, az ’ebből is egy kicsit, meg abból is egy kicsit’ Hyppolitos filmszlogen jegyében. Egy ’csak kicsit W2K áttérésnek’, a két szervizcsomaggal szilárdított állapotot is figyelembe véve, fontos betanulási szerepe lehet, nem föltétlen fölösleges kitérő. Annál is inkább, mivel a .NET technológiára való áttérés esetleg jóval keményebb feladat lesz, mint a fokozatos áttérés (nem is beszélve az x.0-s változat tipikus veszélyeiről, jóllehet a MS-nál a termékszilárdságra újabban jobban odafigyelnek). Viszont a hardverátállási koncepciót már ma is az új generáció igényeihez igazítva kell fejleszteni. Ugyanakkor a Windows terminálszerver technológia miatt a gyengébb teljesítményű, régebbi gépeket sem kell kapásból kidobni (a kidobásnál, persze, az is jobb, ha hazaadjuk a dolgozóknak, hogy a világhálós penetráció növekedését, vagy az inkább csak szavakban emlegetett otthoni munkavégzést segítsük).

A kiinduló, még W2K nélküli, tipikus üzemeltető környezetet a konferencia előadói a mellékelt illusztráción látható komponensekből képzelték. Felmerülhet akár néhány telephely, több NT4-es szerverrel, és (legalábbis jobb helyeken) NT4-es munkaállomásokkal. Az NT4-es grafikus interfészéről jó tudni, hogy az a MS által már halálra ítélt W95 technológiánál ragadt le. Így a terepen előforduló, adatvédelmi korlátai miatt nagyon nem profi ipari környezetbe való, Windows 98-as konfigurációk előfordulása a korszerűbb interfész miatt sok helyen, esetleg épp az alkalmazói szoftverek miatt, nem kerülhető el. Az Exchange 5.5-ös mellett jellemző az Office régebbi változatainak a jelenléte is, egyebek közt a könnyebben kezelhető licenszkérdések miatt. A hálózati architektúra alapvetően a MS egyedi, Windows domén és WINS koncepciójára alapul, amely elsődleges és háttér doménvezérlő szerverek köré épül. A rendszergazda munkáját ebben a katyvaszban a házirendek elég jól kidolgozott technológiája segíti. Ez utóbbit a konferencia előadói több részletfeladat bemutatásával igyekeztek szemléltetni, mindennapi praktikák címén, de már az új, vegyes NT4-W2K-X55-X2K környezetre koncentrálva.

A W2K és X2K korszakváltás

A jövő irányába történő elmozdulást egyáltalán nem a W2K W98 koncepciójú új grafikus interfésze határozza meg, jóllehet a W98-as színvonal megjelenése a W2K-ban végre azonos szerver és munkaállomás oldali kezelést tesz lehetővé. A gyökeres változások jóval a motorháztető alatt találhatók. A teljesen új tartománykoncepció, szorosan illeszkedve a világhálón szabványos TCP/IP DNS UNIX-domén technológiához, valamint az egyébként nem kötelező Active Directory (AD) címtári technológia megjelenése. Az AD kapcsán fontos megjegyezni, hogy bár használata nem kötelező, és akár tovább lehet csöttönözni a MS WINS munkacsoportos környezetében is, ezzel a W2K lényegét nem fogjuk használni, az Exchange 2000-re történő áttérés pedig lehetetlen. A W2K áttérés kulcskérdése tehát az AD címtár bevezetése. A fokozott adatvédelem a Kerberos minőségű ellenőrzési rendszert is igényelheti.

A W2K áttérés tervezése

Az áttérés körültekintő megtervezése még kisebb konfigurációk esetén sem elhanyagolható feladat. A szempontokat a mellékelt illusztráció foglalja össze. Az új konfigurációban a kliens oldalon már a WXP technológiára is számíthatunk, hisz már az is túl van egy szervizcsomagon, ráadásul folyamatos karbantartása még a W2K-énál is hatékonyabbnak tűnik. Vele szinkronban az Office XP használata merül föl. A sima SCSI arzenálos PC-szervereket azonban ma már, főként a megbízhatóság növelésére, ajánlatos a hálózatra direkt kapcsolható önálló társzerverekre, SAN-okra cserélni. A rendszerint megnövekedő populációjú alkalmazók és alkalmazások kordában tartására ugyancsak a házirendi technológiák használhatók, annak W2K korszakbeli, az AD címtárhoz illeszkedő csoportos házirend változatával (GPO).

Vészfékek

A teljes áttérés persze egyrészt önmagában is véges idő alatt képzelhető el, de az esetek többségében tartósan be kell rendelkezni a régi és az új architektúra együttélésére. Vészfékeket kell behúzni, ha valamelyik létfontosságú alkalmazás bemondja az unalmast. Némelyik még az NT4-es újabb szervizcsomagjának is ellenáll, nemhogy egy W2K, O2K vagy X2K váltásnak. Sokszor még csak nem is a bináris programokkal, hanem az üzemeltető scriptekkel gyűlik meg a bajunk. Ezek a látszólag szöveg alakú programocskák azonban a bináris programokban, vagy az adatbázisokban kapcsolódnak komoly átalakítást igénylő trükkökhöz, ami esetleg sok időt és pénzt követel a továbblépéshez. Ami biztos, ezek a változtatások előbb, vagy utóbb lenyelendők. A fő baj, ha előre nem tervezhető módon derülnek ki. Ez az áttérést jó időre megakaszthatja, de legalább tisztázza a megoldandó problémákat. Az áttérés tehát nem valami, hurrá, a hétvégén megejtjük aktus!

Ami egyáltalán nem tartható, hogy az éles működő rendszerrel kezdjük el az áttérést. Az áttérést tesztelő környezethez külön erőforráskészlet kell! Elvileg ezzel mindig és mindenki egyetért, aztán a kapkodás folytán többé-kevésbé eltekint tőle, olykor igen súlyos árat fizetve a ’gyorsítási szándékért’. Ugyancsak fontos az áttérés előtti állapotok alapos, dokumentált, és lehetőleg redundáns, netán bankszéfben is elhelyezett példányos mentése. Jelentős kapacitásigény problémát okozhat a munkatársak átképzése is. Egy W2K szakmérnök kiképzése a tapasztalatok szerint az NT4-eshez képest vagy négyakkora erőforrást igényel. Mind pénzben, mind kiképzési időben, bár a hazai képzési centrumok igyekeznek erre kidolgozott speciális tematikával csökkenteni mindkét paramétert.

A vegyes üzem jellemzői

Hogy a régi NT4-es domének és szerverek folyamatosan használhatók maradhassanak az áttérés, vagy legalábbis a vegyes üzem alatt, a W2K alatti AD vegyes (mixed) módot kell használni a PDC szimulációhoz. A régi szervereket ugyanis már rendszerint nem lehet frissíteni W2K-ra, mert a hardver erőforrások gyengék, és bővítésük sem lehetséges, vagy az alkalmazások kötődnek túlzottan a régi konfigurációhoz. Ugyancsak a vegyes mód merül föl az X2K levelező együttes használatánál. Vegyesen használandók a munkaállomásokon a házirendek és a csoportos házirendek is. A tapasztalat szerint a vegyes rendszer menedzselése a leghatékonyabban egy – tipikusan új, erősebb – Windows XP kliensgépről végezhető, kihasználva az XP/.NET technológia még a W2K-énál is hatékonyabb adminisztrátori újdonságait. Ez olykor aktivációs kóddal sújtott állapot, ha a többi kliensgép tömeges WXP áttérése még nem lehetséges a kedvezőbb tömeglicensz konstrukció elérésére. A fokozott adatvédelem fontos eszköze a W2K-ban bevezetett DFS (Distributed FileSystem) elosztott állománykezelő rendszer, megfelelő paraméterezéssel.

A mellékelt illusztrációban ugyan nem szerepel, de fölmerül a W2K-ba alapszolgáltatásként beépített Windows terminálszerver szolgáltatások használata is, bár ezért külön licenszdíjat szed Mr. MS. Ez a rendszergazdák életét drámaian tudja javítani, de a rendszer stabilitását is jelentősen növeli, miközben a régi, gyengébb erőforrásokkal rendelkező rendszerkomponensek is új feladatokat kaphatnak a vékonykliens szoftvermegoldások révén. Nem kevésbé fontos előny, hogy az alkalmazók is kényelmesebben dolgozhatnak, méghozzá akármelyik munkaállomásról. A teljesebb megoldás persze majd csak a WXP és .NET szerver RDP (Remote Display Protocol) 5.1-es változatától várható, vagy a Citrix Metaframe-re kell némi pénzt áldozni. Az utóbbi a szerverek közti terheléselosztást a W2K-nál, sőt, XP-s változatában, még a .NET-nél is magasabb színvonalon tudja megszervezni. Egyéb Citrix szolgáltatásokat ugyanis már a WXP-ben megjelent RDP 5.1-es protokoll is tud.

Vegyesházassági problémák

A következő problémák merülnek föl az NT4-es és W2K szerverek vegyes használatánál. Hogy történik az AD replikáció az NT4BDC-k és a W2KDC-k között? Hogy működik az autentikáció? Melyik doménvezérlő választódik ki elsődlegesként? Van egy hasznos eszköz, a DS Client, az AD kliensoldali ügynökszoftvere, amit kicsit elhanyagolnak, pedig sokszor igen hasznos volna a használata. Van egy reális babona: minden AD probléma gyökere, hogy a DNS névfeloldó szerver(ek) körül bűzlik valami. És olykor a regisztrációs adatbázisban is előfordulnak aknák, mindkét típusú szerverekben.

AD vegyes mód csak akkor kell, ha a hálózaton NT4 BDC-k is előfordulnak. Ha ezeket sikerült frissíteni W2K-ra, akkor az AD natív módba kapcsolható. Emellett még mindig maradhat a hálózaton tetszőleges számú sima NT4-es (member) szerver, és NT4-es munkaállomás is, tehát, még mindig vegyes lehet a rendszer. AD vegyes módban az egyik erre kijelölt W2K DC képezi a PDC emulátort, és ennek a vezérlő adatai replikálódnak az NT4-es BDC háttérvezérlőkre (általában 5-percenként, kivéve a kritikus adatokat, amelyek azonnali hatállyal replikálódnak, de, sajnos, a jelszóváltoztatás NEM, azt ki kell erőszakolni!). A BDC-k replikációja aláaknázható, ha az Everyone felhasználónak tiltjuk a hozzáférést a PDC emulátor szerverhez, úgyhogy vigyázni kell a korlátozásokkal, de más hozzáférési problémák is okozhatnak gondot a vegyes környezetben.

Az NT4-en a replikációs szolgáltatás neve Directory Replicator, míg a W2K-n már a logikusabb File Replication, de nem kompatibilisek. A W2K szervereknél a replikáció oda-vissza történhet, míg az NT4 PDC-ről (vagy a W2K PDC emulátorról) csak a BDC-re mehet. A kétféle rendszer közti ingázás tehát nem kevés lelki bánatot tud okozni a rendszergazdáknak, de a helyzet azért nem reménytelen, kézben tartható. Olykor például tényleg kézzel kell kierőszakolni a replikációt (például a logon scriptek esetében). A Windows 2000 Resource Kit Ibridge.cmd programocskájával ütemezhetjük ezeket az egyébként kézi beavatkozásokat.

Az autentikáció a vegyes környezetben a jó öreg LAN Manager koncepció szerinti, de az NT4 SP4-es óta ennek az NTLMv2-es változata használatos. Ez alkalmas már az NT4-es munkaállomásokon is az AD címtár alapú autentikációra. A W9x, nem professzionális munkahelyek autentikációja szintén megszervezhető NTLMv2 szerint, amit az ilyen gépekre telepíthető DS kliens program tesz lehetővé. Csak tisztán W2K szerverek környezetében használható a teljes Kerberos azonosítás! Az NTLMv2 azonban, a Kerberosszal azonos módon, időérzékeny. 30 percnél nagyobb időeltérést nem tűr, és megtagadja a felismerést, amiből igen ravasz szituációk keletkezhetnek! Az LM és NTLMv2 a regisztrációs adatbázisból vezérelhető. Egy apró bibi: Windows ME-hez nem létezik DS kliens! A DS kliens érdekessége viszont, hogy segítségével a W98 és NT4-es munkahelyek is szerves részeivé válhatnak a DFS elosztott állományrendszernek.

Hogy találnak doménvezérlőt a hálózati gépek? Ha nincs rajtuk DS kliens, akkor NetBIOS névfeloldást használnak. Ha van DS kliens, akkor a DNS feloldással keresnek egy W2K DC-t, vagy ha ilyen nem érhető el, jobb híján egy NT4-es BDC-t. A W2K SP2 előtt sajnos ebből gondok is támadtak, ugyanis olykor egy helyi NT4 BDC helyett egy távoli, lassabban elérhető, és ráadásul emiatt túlterhelődő W2K DC fog autentikálni minden NT4-beli munkahelyet is. A W2K SP2-ben ezt korrigálták. A DS kliens csak a PDC emulátor W2K szerveren engedi meg a jelszómódosítást, ami olykor zavarokat okoz, mert az NT4-es BDC-kre nem kerül át. Nem lehet minden tökéletes.

Egy speciális NT4-es W2K inkompatibilitási probléma a RestrictAnonimous kulcs a regisztrációs adatbázisban. A W2K-ban fölvettek neki egy új, 2-es értéket is. Ennek hatására a W2K az autentikációnál nem adja át az Everyone csoport adatait, ami egy sereg NT4-es alkalmazást futtat zátonyra, mert azok az anonim hozzáférést szeretnék használni. Ezért csak tiszta W2K-WXP környezetben szabad 2-re állítani, ami a házirendekben szabályozható. A rossz beállításra utaló jelek: nem működik a géptallózó, nem lehet a lejárt jelszavakat módosítani, régi kliensek nem tudnak belépni stb.

A következő részben az Exchange 5.5 és 2000 közti együttműködésről, és a mindennapi praktikákról lesz szó.