Active Directory címtár adatainak kezelése scriptek segítségével Konzulens: Szalai László Nyugat-magyarországi Egyetem, Informatika Intézet, Intézeti mérnök Arnhoffer Edit Evosoft Hungary Kft. IT Manager Készítette: Bangó Balázs Gazdasági Informatikus hallgató
34
Embed
Active Directory címtár adatainak kezelése scriptek ...documento.inf.nyme.hu/sites/default/files/Diplomaterv.pdf · Active Directory címtár adatainak kezelése scriptek segítségével
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Active Directory címtár adatainak kezelése scriptek
segítségével
Konzulens:
Szalai László
Nyugat-magyarországi Egyetem,
Informatika Intézet, Intézeti mérnök
Arnhoffer Edit Evosoft Hungary Kft.
IT Manager
Készítette:
Bangó Balázs
Gazdasági Informatikus hallgató
2
Tartalomjegyzék Active Directory címtár adatainak kezelése scriptek ................................................. 1
segítségével ................................................................................................................ 1
I. Bevezetés ............................................................................................................. 4
1. Active Directory bemutatása ........................................................................ 4
2. Active Directory séma bemutatása ............................................................... 5
3. Active Directory séma kezelése ................................................................... 6
II. Active Directoryban tárolt adatok kezelése ..................................................... 8
1. Active Directoryhoz kapcsolódó szolgáltatások adatai ................................ 8
a) DNS kezelése ............................................................................................ 8
b) DHCP kezelése ......................................................................................... 8
c) Csoportházirendek kezelése ...................................................................... 8
2. Active Directory törzsadatai ......................................................................... 9
a) Felhasználók ............................................................................................. 9
b) Számítógépek, Csoportok, Kontaktok ...................................................... 9
c) Objektumok tetszőleges attribútumának módosítása .............................. 10
3. Active Directory adatkezelés hiányosságai ................................................ 10
III. Munkakörnyezet bemutatása .......................................................................... 12
IV. Active Directory programozási lehetőségeinek bemutatása .......................... 13
1. Parancssori eszközök .................................................................................. 13
A lekérdezés eredménye egy recordset típusú objektumban kerül eltárolásra,
melyen a moveNext metódusával lehet végigmenni és a szükséges értékeket további
feldolgozás céljából kivenni belőle.
WHILE NOT OBJRECORDSET.EOF
WSCRIPT.ECHO OBJRECORDSET.FIELDS(„NAME”)
OBJRECORDSET.MOVENEXT
A keresés végén pedig természetesen le kell zárni az adatbázis kapcsolatot, hogy
a zárolt erőforrások felszabaduljanak.
A keresés végrehajtására többféle implementációs megoldás is létezik, azonban az átláthatóság kedvéért ajánlott ugyanazt a módszert használni minden csatlakozásnál.
20
V. Scriptekkel megvalósított feladatok bemutatása
Egy olyan nagyméretű cég, mint az Evosoft Hungary Kft. már nem teheti meg,
hogy az egyes informatikai folyamatok megvalósítását teljes egészében a
rendszergazdák belátására bízza. Egyrészt be kell tartani és be kell tartatni a
folyamatok során képzett adatokra vonatkozó formai és minőségi követelményeket,
másrészt meg kell valósítani a folyamatok nyomon követésének és hatókörök
ellenőrzésének lehetőségét. Emellett az egyre nagyobb felhasználói létszámhoz
kapcsolódó adatkezelést is meg kell oldani, hiszen majdnem minden felhasználóhoz
tartoznak olyan adatok, amik idővel változhatnak és az informatikai rendszerben is le
kell követni. Ilyen például a telefonszám, szobaszám esetleg a projekt, amin a
dolgozik.
A fent leírt problémák kezelésére az Evosoft Hungary Kft. egy saját eszköz
fejlesztésébe kezdett, ami SharePoint alapokon, webes felületet kínál a
felhasználóknak, az egyes folyamatok teljes életciklusát végigköveti, és csoport alapú
jogosultság kezeléssel elkülöníti hatásköröket és feladatokat. Ugyanakkor a folyamat
végén az Active Directory adatbázisban történő adatváltoztatás, valamint létrehozási és
törlési műveletek hagyományos script eszközökkel kerülnek megvalósításra. Habár a
SharePoint képes támogatni nem csak olvasási, hanem írási műveleteket is a
címtárban. Viszont az egyes funkciókat megvalósító scriptek az igényekkel együtt
változnak és ezeket a változásokat a rendszergazdáknak könnyebb scriptekben
implementálni, mint SharePoint oldalon.
1. Új felhasználó felvétele
A dinamikus növekedés miatt az egyik legmindennapibb, ugyanakkor nagy
figyelmet kívánó feladat egy új felhasználó felvétele.
a) A folyamat leírása
Új felhasználói fiók iránti igény többféleképpen keletkezhet. Egyik lehetőség,
hogy új alkalmazott kerül a céghez, akinek hozzáférésre van szüksége, másik
lehetőség, hogy valamelyik partner cég alkalmazottjának van szüksége bizonyos
hozzáférésekre és ezzel együtt felhasználói fiókra. Ezen túl pedig előállhatnak speciális
helyzetek, amikor nem valós személynek, hanem egy szolgáltatásnak kell account.
Valós személy esetén az igénylés először a HR osztályra fut be, ahol
összegyűjtik a szükséges adatokat, majd a kérést ezzel kiegészítve továbbítják az IT
felé. Az IT létrehozza az accountot a kezdő jelszót megbízható módon eljuttatja a
tulajdonosának. Ezzel a folyamat lezárul.
21
b) Korábbi megvalósítás
A korábbi megvalósítás
alapján a HR osztály egy
helpdesk ticketben kérte az IT-
t új felhasználói fiók
létrehozására, a tickethez pedig
excel táblában csatolta az
ehhez szükséges adatokat.
Több kollega esetén ez több
soros táblázatot jelentett,
aminek a szélessége közel két
képernyőnyi, ezért nehezen
olvasható volt, ráadásul
ugyanazokat az adatokat vittük
be kézzel ismét, amiket a HR
már felvitt, ez pedig dupla
hibalehetőséget jelent. A dupla
felvitel során az adatok
helyességét sem lehetett
ellenőrizni, mivel az eredeti
adatok kizárólag a HR számára
álltak rendelkezésre. Csak a
nyilvánvaló elgépelésekre derülhetett fény. Ezt követően az excel tábla adatainak
felhasználásával egy scripthez tartozó formot (4. kép) töltöttünk ki, amely elég
információt kért be ahhoz, hogy Active Directoryban minden szükséges adat kitöltésre
kerüljön. A form egy batch fájlt hív meg, ami bemenő adatként megkapja ezeket az
adatokat a többi szükséges mező tartalmát pedig ezek alapján feltölti. Ezen felül
létrehoz egy Exchange postafiókot a felhasználó számára, generál egy véletlen jelszót
és e-mailben elküldi a teljes rendszergazdai csapatnak. A service usereket a kollegák
közvetlenül az IT-tól kérték és ezeket a grafikus konzol felületen hoztuk létre, mivel
sokkal kevesebb kötelező attribútuma van, nem kapcsolódik hozzá postafiók és más
szervezeti egységhez tartozik.
c) Jelenlegi megvalósítás
A jelenlegi rendszer a korábban említett Share Point alapú webes felületre épül.
Ezen a felületen történik meg a kérvényezés, jóváhagyás és adatbevitel. A korábbi
folyamattal ellentétben csak egyszer, viszont minden lépésben megmarad a korábbi
ellenőrzési lehetőség. A folyamat egyes elemei utólag is lekérdezhetők, így a
személyes felelősség is teljes. Az egyes mezőkre jól testre szabhatók a különböző
szintakszis ellenőrzések, ezzel biztosítani lehet, hogy csak jól formázott adatok
4. kép. – Új felhasználó form
22
kerüljenek a címtárba. Az utolsó lépés azonban továbbra is egy script meghívása, ami
az összegyűjtött adatokat kiegészíti, létrehozza az objektumot és feltölti az
attribútumokat. Ennek a döntésnek a hátterébe az áll, hogy a rendszergazdák jól tudnak
batch fájlokat vagy vb scripteket szerkeszteni, viszont nem értenek a SharePointhoz.
Így ha a felvett adatok alapján valamit változtatni kell a létrejövő objektumon, akkor
elég egy scriptet módosítani és a SharePoint forráshoz nem kell hozzányúlni. Ilyen
változtatás lehet az alapértelmezett levelezési listákban történő változás esetleg új
szervezeti egységek létrejötte vagy azok átnevezése. A korábbi batch fájl alapú
megoldás továbbra is használható lenne, de elég lassú a futása elsősorban a
tartományvezérlők közti replikációra várakozás miatt. Valamint hosszabb, nehezebben
kezelhető kódot jelentett. Ezért szükségesnek éreztük a script Visual Basic script
formában történő újraírását, valamint újragondolását. Az új script első lépésbe egy az
egyben ugyanazt valósítja meg, mint amit a script csinál. Az új script megírása során
kihívást jelentett a megfelelő postaláda létrehozása. A rendelkezésemre álló
tesztrendszerben ugyanis nincs Exchange telepítve, éles hálózatban pedig további
óvintézkedésekre volt szükség Active Directory-t módosító és teszteletlen script
futtatására. Ezért a scriptet munkaidőn kívül előzetes biztonsági mentést követően
tesztelhettem sikeresen. A script a folyamatosan megfogalmazódó igényeknek
megfelelően folyamatos fejlesztés alatt áll. A teljes változat a CD mellékleten
található.
d) Továbblépési lehetőségek
A jelenlegi rendszer nagyban kielégíti a felmerülő igényeket, ugyanakkor a
felhasználó teljes életciklus-követésére nincs felkészítve. Előfordul, hogy
gyakornokként, vagy külsős vállalkozóként kezdő kollegák státusza állandósul, ebben
az esetben minden ehhez kapcsolódó attribútumot meg kell változtatni, ilyen és ehhez
hasonló változtatásokra nincs felkészítve a jelenlegi megoldás. Másrészt a külsős
vállalkozókkal a HR osztály nem vagy csak kis mértékben tartja a kapcsolatot, ezért a
jóváhagyási folyamatot is át kell dolgozni. A legégetőbb problémákra megfelelő
választ jelent a jelenlegi megoldás, a továbbfejlesztése valószínűleg akkor kezdődhet
el, ha minden kritikus IT folyamat legalább ilyen színvonalon implementálásra kerül.
2. Új számítógép felvétele
A felhasználók létszámával párhuzamosan nő a gépek száma is, ezeknek a
nyilvántartása és menedzselése szintén komoly feladatot jelent egy több száz gépből
álló rendszerben.
a) A folyamat leírása
Új számítógép igénylése egy beszerzési folyamattal indul, ami IT szempontból
lényegtelen. A sikeres beszerzési folyamat eredményeként a raktárba kerül a
23
számítógép és erről értesítést kap a beszerzést kezdeményező ágazatvezető. Ez után a
sikeres beszerzésre hivatkozva ír egy ticketet az IT-nak, amivel kéri a gép telepítését és
kiadását valamelyik kollegának. A telepítés és tartományba léptetés korrekt
elvégzéséhez szükséges ismerni az igényelt szoftverek listáját, a gép új gazdájának
nevét és ágazatát. A gép menedzserének beállítjuk a megfelelő személyt, az ágazatnak
pedig az IP cím és gépnév megadásánál van jelentősége. A gép előkészítése után
kiadjuk a gazdájának, aki ezután beállíthatja a saját munkakörnyezetét.
b) Korábbi megvalósítás
Korábban új számítógép felvitelére semmilyen informatikai támogatás nem
tartozott. Minden számítógép objektumot kézzel a grafikus felületen kellett felvinni.
Ez ugyan nem járt jelentős többletmunkával, mert az attribútumok közti összefüggés
minimális. Viszont a kézzel megadott gépnevek és IP címek időnként ütközéshez
vezettek, a hosszabb ideig kikapcsolt, esetleg időlegesen másik telephelyen működő
gépek címe és neve esetleg újra kiosztásra kerülhetett. A precíz rendszergazdai
munkának köszönhetően ritkán fordultak elő ilyen incidensek, viszont minden ilyen
eset felesleges kellemetlenséget jelent, ami megfelelő támogatással jól kivédhető.
További problémát jelentettek az ideiglenes vendég gépek kezelése. Ezeknek a
gépeknek is létrehoztunk egy objektumot a címtárban, letároltuk benne néhány fontos
adatukat és beállítottunk számukra egy lejárati időt. Mivel az Active Directory nem
támogatja közvetlenül a számítógép objektumok accountjának lejárását, ezért a már
lejárt vendéggépekhez tartotó objektumokat kézzel kellett megkeresni és eltávolítani.
Még nagyobb problémát jelentett, ha a lejárati idő a rutinszerű adatfelvitel miatt nem
került rögzítésre az objektumban.
c) Jelenlegi megvalósítás
A fenti problémák, illetve gyengeségek, valamint az egységes eszköz iránti igény
miatt az új számítógép felvétele folyamat is helyet kapott az IT Webworks SharePoint
alapú felületén. A felület jelen esetben is biztosítja a szintaktikahelyes adatfelvitelt, az
életciklus követés lehetővé teszi a felelőségek megállapítását, a háttérben futó script
pedig elvégzi a tényleges adatmódosítást az Active Direcroryban. A script létrehoz egy
számítógép accountot és feltölti a SharePointtól származó adatokkal. Az új script
megvalósítása során folyamatos egyeztetést igényelt, hogy a bekért adatok alapján a
végleges attribútumokat SharePointból vagy scripttel állítsuk elő. A végleges döntést
az indokolta, hogy a scriptben megvalósított formázásokat későbbiekben a
rendszergazdák könnyedén tudják módosítani. Ha ezeket a funkciókat a SharePoint
valósítaná meg, akkor egy kisebb változás is a web programozó segítségét igényelné.
Ebből a szempontból a legfontosabb jelenleg a location mező, ami kötött szintaktika
alapján tartalmazza a gép MAC címének és IP címeinek összerendelését adott
telephelyeken. Ugyanis ezen információk alapján egy script végzi az egyes siteok
24
DHCP szervereibe a rezervációk betöltését. Az ideiglenesnek megjelölt gépek lejárati
dátumát is ebben a mezőben kell megadni és a lejáratot a DHCP-ből való kikerülés
biztosítja, hiszen a lejárt gép nem kaphat IP címet, így nem érhet el semmilyen hálózati
erőforrást. Az új megvalósítással együtt más telephelyeken hasznosnak bizonyuló
gyakorlatot is átveszünk. Ilyen például, hogy az egyes gépen raktári számát is tároljuk
az Active Directoryban, a könnyebb azonosítás érdekében. Egy ilyen nagy gépparkkal
rendelkező cégnél ugyanis az lehet az első probléma, hogy valamilyen módon
meghatározzuk egy gép hardverkiépítését. Jelenleg a legjobb módszer a leltári szám
alapján történő meghatározás. A script jelenleg működő verziójának részletei a I.
Mellékletben olvashatók. A teljes script a mérete miatt csak a CD mellékleten kapott
helyet.
d) Továbblépési lehetőségek
A teljes életciklus követés ebben az esetben is egy későbbi megvalósítandó
feladat. Célszerű lenne valamilyen módon kapcsolatot állítani a beszerzési
adatbázissal, így az új számítógép felvitele lényegében már a beszerzésnél elkezdődne,
majd a gép fizikai megérkezéséről automatikusan értesülne az IT, így felhasználói
jelzés nélkül lehetne felkészíteni a gépeket és a kollegáknak csak az átvételkor kéne
ténylegesen megjelenni az IT-n. Továbbá célszerű lenne átgondolni a jelenlegi IP cím
kiosztási stratégiát és annak megfelelően változtatni a magán a computer objektumon,
illetve a DHCP rezervációkat készítő scripten.
3. Felhasználók személyes adatainak megváltoztatása
Az Active Directoryban tároljuk a felhasználók telefonszámát, szobaszámát,
valamint a telephelyet ahol dolgoznak. Ezek olyan adatok, amik idővel változhatnak és
meg kell kísérelni nyomon követni az Active Directoryban is. Az itt tárolt adatok
szolgálnak alapul egyes telefonos címjegyzékekhez, illetve szerepet játszanak a
Siemenssel történő kommunikáció során is. Ezért törekednünk kell rá, hogy legalább a
kommunikáció szempontjából kritikus telefonszám bejegyzések meglegyenek és valós
adatokat tartalmazzanak.
a) A folyamat leírása
A felhasználói profil eleinte az alapértelmezett adatokkal kerül feltöltésre, mivel
sokszor nem lehet előre tudni, hogy milyen telefonszámot kap az új kollega, sem azt,
hogy melyik szobában kerül elhelyezésre a munkaállomása. Ezért az adatokat a
kollegák önkéntes alapon szolgáltatják, elvileg folyamatosan, a változások hatására, de
a valóságban sajnos csak időnként külön kérésre frissítik az adatokat. Ez a megoldás
nagyban épít arra, hogy mindenkinek érdeke, hogy helyes adatok jelenjenek meg vele
kapcsolatban.
25
b) A korábbi megvalósítás
Korábban a probléma megoldására egy egyszerű eszközt használtunk (5. kép),
melyben a telefonszámot és a szervezeti egységet lehetett megadni, az itt kitöltött
adatok pedig azonnal az Active Directory-ba kerültek. Mint az látható felhasználónév
megadása nem szükséges, mivel a program mindenkinek a saját felhasználói
kontextusában futott, ami lekérdezhető, így
egyértelmű volt, hogy melyik objektumot kell
módisítani. Jogosultsági problémák nincsenek, mert a felhasználónak joga van
módosítani a saját bejegyzését a címtárban.
c) Jelenlegi megvalósítás
A jelenlegi megvalósításnak is az IT WebWork keretein belül adtunk helyet.
Egyfelől bővített funkcionalitással megtartjuk a korábbi megvalósítást, tehát a
felhasználóknak továbbra is lehetősége lesz manuálisan a saját adatait megadni,
másfelől pedig a telefonszámok követését megpróbáljuk megvalósítani a telefon
menedzsment folyamaton belül. Mivel ez az egyetlen folyamat, amihez az IT
közreműködése valóban nélkülözhetetlen, hiszen a telefonszámok kiosztását mi
végezzük. A többi adatot azonban más folyamatokon keresztül nem tudjuk követni és
továbbra is csak az önkéntes információadásra számíthatunk, amihez a magunk
részéről egy átlátható kényelmes felületet és megbízhatóan működő hátteret
biztosítunk. A korábbi megvalósításhoz képest a szobaszám nyilvántartása jelenik meg
újdonságként, a szervezeti egység megadásának lehetőségét viszont elvesszük. A
jelenlegi megvalósítás a II. mellékletben olvasható.
d) Továbblépési lehetőségek
Egyenlőre a jelenlegi megvalósítás kielégíti azokat az igényeket, amiket
támasztottunk a folyamat felmérése és a feladat specifikálása közben. A telefonszámok
automatizált frissítésével nagy előrelépést tettünk a személyes adatok frissen tartása
irányában, a többi adatot azonban továbbra is kézzel kell bevinni. A hálózati
infrastruktúra fejlesztésével folyamatosan újragondoljuk a jelenlegi megoldást és a
lehetőségeknek megfelelően újabb adatok automatikus kezelését fogjuk megvalósítani.
4. További IT WebWorks funkciók
A fenti két folyamat és megvalósításhoz hasonlóan minden IT folyamatot
igyekszünk az egységes SharePoint felület alatt elhelyezni. A projekt jelenleg is
folyamatban van és sorra valósítjuk meg a különböző IT feladatokhoz tartozó felületet.
A folyamatok feltárása és megvalósítása folyamatos iteratív tevékenység, melynek
során az egyes folyamatokat megkíséreljük optimalizálni is, ezzel együtt a különböző
adatbázisokban, így az Active Directoryban tárolt adatok körét és módját is
5. kép. – Data collector
26
felülvizsgáljuk. A jelenlegi tervek szerint összesen több mint harminc kifejezetten IT
szolgáltatás fog megjelenni a weblapon, ezzel nagyban javítva az IT szolgáltatás
minőségét, valamint az SLA-nak való megfelelést. A következőkben röviden
bemutatok néhány további folyamatot:
• Telephone management: Új telefon kiadásánál, vagy a tulajdonos
cserélődésénél indul ez a folyamat. Az Active Directory-t azért érinti,
mert az IP telefonok be vannak jegyezve a címtárba egy számítógép
objektummal, amiben tároljuk a telefon gazdáját, valamint MAC és IP
címét.
• Domain Group management: A csoportok kezelésével kapcsolatos
kéréseket kezeli. Elsődleges feladata a biztonsági csoportok tagságának
változtatása a megfelelő jóváhagyások után. Mivel bizonyos csoportoknál
ehhez nincs szükség az IT engedélyére, ezért ez a feladat szinte teljes
egészében függetlenedhet a rendszergazdáktól.
• Mail redirection: Folyamatosan merül fel olyan igény, hogy a céges
postafiókba érkező levelezést irányítsuk át egy másik e-mail címre. Ezt
rendszergazdai jóváhagyással szinte teljesen automatikusan lehet
megcsinálni egy scriptekkel támogatott rendszerben.
Az IT WebWorks teljes jelenlegi állapotára elmondható, hogy nagy előrelépést
jelent az IT folyamatok automatizálásában, nyomon követésében és ezzel a minőségi
rendszergazdai munka végzésében. Azonban minden funkcióhoz biztosítani kellene a
teljes életciklus követést, egységesíteni kellene az összetartozó funkciók felületét és az
ezekhez a funkciókhoz tartozó scripteket. Így fejlesztői, rendszergazdai és felhasználói
oldalról is egységesebb, áttekinthetőbb lenne a rendszer működése.
5. LDAP kereső
Ahogy korábban is említettem az Active Directory grafikus eszközeibe beépített
keresési lehetőségek nem mindig elégítik ki az igényeket. Egyfelől hiányzik bizonyos
attribútumokra keresésének lehetősége, például az utolsó bejelentkezés ideje szerint
nem lehet keresni, illetve nem lehet szerepeltetni a keresési eredmények között.
Másrész a legnagyobb hiányosság, hogy a keresési kritériumoknál nem lehet megadni
a tartalmazást, mint kritériumot. Így ha egy attribútum valamely részletére szeretnénk
keresni, akkor nem marad más lehetőség, mint scriptet írni.
a) A korábbi megvalósítás
Egészen a közelmúltig nem volt mód egyedi lekérdezések készítéséig csak a
beépített grafikus felületen lehetett lekérdezéseket definiálni. Ezek a legtöbb igényt
maradéktalanul kielégítették, a többi ilyen jellegű problémára pedig más forrásból
kerestek megoldást. Azonban a cég dinamikus növekedésével egyre gyakrabban és
27
egyre komolyabb kérdés merül fel melyre valamilyen Active Directory lekérdezés
adhat könnyen áttekinthető választ. Ezeket a lekérdezéseket a közelmúltban egyedileg
az igényeknek megfelelően írtam meg, illetve paramétereztem fel. A folyamatosan
jelentkező igények arra ösztönöztek, hogy egy univerzálisabb, gyorsan használható
scriptet készítsek, amiben csak a lekérdezést kell megadni, a többi műveletet
tetszőleges számú és fajtájú attribútummal automatikusan elvégzi.
b) Jelenlegi megvalósítás
Egy ilyen keresés során ugyanazokat a feladatokat kell végrehajtani, csupán
mások a feltételek, illetve a keresési feltételek alapján kell az eredményként megjelenő
táblázat oszlopait meghatározni. A feladat végrehajtására lehet írni egy általánosan
használható scriptet, aminek az egyetlen bemenete maga a kereső string, illetve annak
változó attribútumai. Ez lehetne SQL dialektusú SELECT lekérdezés vagy LDAP
dialektusú lekérdezés, attól függően, hogy melyik kényelmesebb vagy célszerűbb.
Mivel az LDAP lekérdezés jobb teljesítményt nyújt és szélesebb körűen használható,
ezért a megvalósításban emellett döntöttem. Habár az SQL utasítások szélesebb körben
ismertek, az LDAP dialektikát sem nehéz elsajátítani, az attribútumok ismerete pedig
ugyanúgy szükséges SQL lekérdezés írásához is.
A lekérdezés eredményét a script egy text fájlba menti, az eredménytábla
oszlopait tabulátorokkal elválasztva. Ezt a formátumot Excelben könnyedén meg lehet
nyitni és további szűréseket, kereséseket végezni vagy akár statisztikai adatokat
kinyerni.
A script az eredménytábla oszlopainak nevét és számát a felhasználói inputként
megadott lekérdezésből határozza meg. Ehhez a scripten belül bizonyos mértékig
értelmezni kell a lekérdezést, a keresett attribútumokat egy tömbbe rakni és a
kimenetben ezt felhasználni. A kész script teljes egészében olvasható a III.
mellékletben.
c) Továbblépési lehetőségek
A script jelenleg egyszerű parancssoros felületről érhető el a bemenetét
parancssori argumentum szolgáltatja. Ez a megoldás ugyan nem a leg tetszetősebb, de
jelenleg tökéletesen megfelel az IT-n jelentkező igények kielégítésére. A későbbiekben
esetleg célszerű lehet egy webes vagy valamilyen más grafikus felületen
megvalósítani, de mivel alapvetően rendszergazdáknak készült az eszköz, ezért ez a
változtatás nem kritikus vagy sürgető. További problémát jelent olyan attribútumok
lekérdezése, amik nem replikálódnak a tartományvezérlők közt. Ilyen például az utolsó
bejelentkezés időpontját tároló attribútum. Ezen túl, problémásak azok az attribútumok
amik nehezen olvasható formában tárolják az információt, ilyen például az account
lejárati ideje, amit az Active Directory 1601 január 1 óta eltelt időként tárolja 100
nano-szekundumban megadva. Jelenleg ezeknek az attribútumoknak a kezeléséhez
28
nem használható a script. Ezen túl a felmerülő hibákat, problémákat folyamatosan
javítom és próbálom igazítani a scriptet az újabb felmerülő igényekhez.
6. További scriptekkel megvalósított feladatok
Az előzőekben bemutatott komolyabb feladatokon kívül folyamatosan meg
kellett oldani kisebb problémákat, illetve további feladatok várnak megoldásra.
• Komoly kihívásnak indult az a feladat, amelyik azt fogalmazta meg, hogy
a cégnél egyre sűrűbben előforduló notebookokon céges hálózaton kívül
aktiválódjon a tűzfal, hálózaton belül pedig kapcsoljon ki. Ezt a funkciót
a Windows tűzfalra a Group Policy támogatja, viszont a notebookok és
az asztali gépek különválasztását is meg kellett oldani, mivel néhány
asztali gépen nem várt működéssel járt a Policy engedélyezése. A
megoldást a Group Policy-hez rendelhető WMI filter jelentette. Más
módon ezt a problémát nem vagy csak nagyon nehezen lehetett volna
megoldani.
• A support tevékenység során folyamatosan szükség lehet a felhasználók
gépein az alapértelmezett megosztások elérésére (pl.: C$, D$, ADMIN$).
Azonban ezek néha valamilyen okból letiltásra kerülnek, így
elérhetetlenné válnak. Amennyiben az csak akkor derül ki, amikor
valóban szükség lenne rá, akkor feleslegesen sok időt rabol a valódi
probléma megoldásától. Ezért készítettem egy scriptet, ami ellenőrzi,
hogy a gépeken minden alapértelmezett megosztás elérhető legyen.
Eredményként a hibás gépek nevét egy fájlba írja a script és megelőző
jelleggel ezeken a gépeken újra engedélyezzük illetve engedélyeztetjük
ezeket a megosztásokat.
• Ahogy az új számítógép felvitele folyamatnál említettem a vendéggépek
számára is hozunk létre accountot a címtárban, viszont egy adott
mezőben ezeknek beállítunk egy lejárati időt is. Ez a beállítás azonban
néha elmaradt, ami oda vezetett, hogy becslésünk szerint több tucat
vendég gép volt az Active Directoryban lejárati dátum nélkül,
feleslegesen. A közel egy teljes C típusú címtartományt kitevő
vendéggépek átböngészése hosszadalmas munka lett volna, azonban egy
scripttel a hiányzó dátumokat néhány másodperc alatt pótoltam. A
következő lépés a lejárt bejegyzések törlése lesz, de ez inkább csak az
áttekinthetőség érdekében szükséges.
• Komoly problémát jelent, hogy a kollegák egy része a számítógépét nem
kapcsolja ki, sem éjszakára, sem hétvégére. Részben talán lustaságból,
részben pedig a távmunka szükségessége miatt, ez milliós töbletköltséget
jelent csak az energiaköltségben. A Wake On LAN (WOL) technológia
megoldást kínál kikapcsolt gépek ébresztésére, de hibernált vagy alvó
29
gépek ébresztését Windowsból is engedélyezni kell. Ennek a
problémának megoldása a következő hetek feladata lesz. A megoldás
után reményeink szerint a kötelező géplekapcsolás, illetve takarékosabb
energiaellátási séma alkalmazása éves szinten milliós nagyságrendű
megtakarítást hozhat.
Ahogy ebből a négy egyszerű példából is látszik a scriptekkel olyan kis
mindennapi bosszúságot okozó problémákat lehet megoldani, amik egy nagyobb
infrastruktúra esetén akár egy teljes embert is foglalkoztatnának főmunkaidőben. Így a
hatékony scriptelés csökkenti a költségeket és időt ad az adminisztrátoroknak, ezzel
teret enged a komolyabb fejlesztési és kutatási tevékenységnek.
30
VI. A scriptek jövője
Jó és hatékony scriptek készítése folyamatos feladat egy közepes vagy
nagyméretű informatikai rendszerrel rendelkező szervezet esetében. Legyen szó akár
logon/ logoff scriptekről, akár egyedi lekérdezésekről vagy a géppark egy részén vagy
egészén érvényes konfigurációs változtatásról. Ugyanis a rendszergazdai feladatok
csak egy bizonyos határig végezhetők el a grafikus felületen, a többit szinte kizárólag
scriptekkel lehet megvalósítani.
1. A VB Script jövője
Maga a Visual Basic Script és a hozzá kapcsolódó interfészek régóta részét
képezik a Windows rendszernek és hasznos segítőtársat jelentenek a rendszergazdai
feladatok gyors és hatékony elvégzésében. A legjelentősebb interfészek a WMI és az
ADSI folyamatosan fejlődnek és a lehetőségek széles tárházát nyújtják a
rendszergazdáknak. A VB Script eltűnésére az újabb scriptelési technológiák
megjelenésével sem kell számítani rövid időn belül, mivel széles körben elterjedt
technológiáról van szó és jellemzően a funkciók megvalósításához a gyártó független
CÍM szabvány alapú eszközöket használjuk fel. Tehát bátran állíthatom, hogy a VB
Script a rendszeradminisztráció terén élő technológia és a következő néhány évben
még biztosan nem szorítja ki teljesen a Microsoft új script platformja a PowerShell.
2. A PowerShell
A PowerShell a Microsoft új parancssori illetve script eszköze, programnyelve.
A Windows 2008 szervernek, illetve Windows Vistának gyárilag része, a korábbi
operációs rendszerekhez pedig külön telepíthető. Microsoft alapú technológiákat
használó rendszerek esetében hosszabb távon várhatóan ez fogja felváltani a VB
Scripteket, valamint parancssoros felületének köszönhetően részben a hagyományos
parancssor szerepét is átveheti. Alapértelmezésben több mint 130 parancsot tartalmaz,
valamint alkalmas a WMI, ADSI és egyedi interfészek elérésére, ez utóbbit plug-inek
importálásával. A PowerShell mindemellett új névkonvenciókat használ, ezáltal ugyan
egységesebbek lettek az elnevezései, de a használatához az egész nyelvet teljesen az
elejétől kell tanulni, ez pedig várhatóan még egy ideig távol tartja az adminisztrátorok
egy részét az új eszköztől. Várhatóan a következő években a PowerShell és a VB
Script egymással párhuzamosan lesz jelen, de lassan és biztosan a PowerShell teret fog
nyerni és a nagyobb szervezeteknél idővel egyeduralkodóvá válik.
31
VII. Összefoglalás
A következőkben összefoglalom az általam végzett munka jelentőségét, szerepét
a rendszeradminisztrátori munkában, valamint az elért eredményeket bemutatom azok
jelentőségét a mindennapi munkavégzésben.
1. Elért eredmények összegzése
Az elmúlt három hónapban megismerkedtem azokkal az alapvető problémákkal,
amikkel egy közepes méretű informatikai rendszer üzemeltetése során nap mint nap
találkoznak az adminisztrátorok. Megismertem az ezekhez a problémákhoz tartozó
üzleti és informatikai folyamatokkal, valamint azokkal a vezetői megfontolásokkal,
amik mentén ezek kialakításra kerültek, illetve amik alapján folyamatosan
újragondoljuk őket. Ezzel párhuzamosan megismertem a Visual Basic Script nyelvet,
valamint az ADSI és WMI interfészeket és felismertem, hogy hatékony megoldást
nyújthatnak több aktuális problémára. A munkám során szerzett scriptelési
tapasztalatot rendszeresen használom a napi problémák megoldásában is.
A legfontosabb eredménye a tevékenységemnek, hogy a scriptek használata
versenyképes alternatívaként jelentkezik a legtöbb probléma megoldására és sokszor
valóban ez mutatkozik a legjobb és leggyorsabb megoldásnak. Ezzel értékes
munkaórákat spórolunk meg, amit más fejlesztésekre, szakmai fejlődésre vagy az IT
szolgáltatásminőségének javítására használhatunk fel. Emellett folyamatban van egy
nagyszabású projekt, az IT WebWorks, ami szinte az összes IT folyamat egységes
felületre helyezését célozta meg. Ebben a munkában a scriptekért felelős
rendszergazdaként veszek részt és az első néhány folyamat végleges megvalósításához
már rendkívül közel állunk, jelenleg széleskörű tesztelési munkákat végezzük.
2. Következtetések, javaslatok
Kétségtelen, hogy a scriptek alkalmazása nélkülözhetetlen már egy kisméretű
informatikai rendszerben is, gondoljunk csak a logon/logoff scriptekre. Ezek azonban
általában kötegelt állományok és csupán az alapértelmezett parancssori eszközöket
használják. Ezek az eszközök illetve az általuk nyújtott lehetőségek azonban
megfigyelésem szerint elégtelenek egy nagyobb rendszerrel rendelkező szervezet
esetében. Az Evosoft Hungary Kft.-nél jól megfigyelhető, hogy a régi örökségből
származó batch scriptek szűk keresztmetszetet jelenthetnek a rendszer
működtetésében. Például a DHCP rezervációkat kezelő parancssor alapú script-
gyűjtemény jelentősen lassabban fut, mint ami kívánatos lenne. Ezeknek a scripteknek
az újragondolása a következő hónap munkája lesz. Továbbá a group policy-k
alkalmazásának testre szabásához is WMI szűrők használhatók, így a gépek
tulajdonságai alapján lehet a szabályokat érvényesíteni. Komoly problémát jelent a
startup és logon scriptek túlzott elnyúlása is, ez részben természetes következménye az
32
egyre növekvő cégben jelentkező újabb és újabb elvárásoknak, részben pedig a
parancssori eszközök alacsonyabb hatékonysága és a változásmenedzsment hiányára
vezethető vissza. Egy jól átgondolt és dokumentált VB Script a várakozások szerint
jobb teljesítményt és gyorsabb gépindulást adhat.
A fent leírt példák is mutatják, hogy professzionális scriptek alkalmazása nagyon
hasznos, sőt nélkülözhetetlen egy komoly informatikai rendszerben. Várhatóan az
Evosoft Hungary Kft. is folyamatosan átáll erre a gyorsabb és hatékonyabb
megoldásra, valamint a későbbiekben felmerülő ilyen jellegű igényeket elsősorban
scriptek segítségével valósítja meg. Igaz, hogy ez a rendszergazdai csapattól és
különösen a scriptekkel kiemelten foglalkozó adminisztrátortól egy új kompetencia
megszerzését követeli, de a folyamatos képzés szükséges velejárója ennek a
szakmának.
Az előző fejezetben is említettem már azt az új technológiát, ami várhatóan
idővel a VB scriptek helyére léphet, a PowerShell-t. Ez egy olyan technológia, amit
feltétlenül érdemes figyelemmel kísérni és megtanulni, bár az alkalmazása csak
Windows 2008 szerver és Windows Vista környezetben lehet teljes körű.
Mindenképpen ajánlott a váltásra olyan mértékben felkészülni, hogy a PowerShell által
nyújtott új lehetőségeket minél előbb ki tudjuk használni. Ennek érdekében az év
második felére beütemeztünk egy Microsoft tanfolyamot ebben a témakörben.
33
VIII. Köszönetnyilvánítás
Ezúton szeretnék köszönetet mondani munkám során nyújtott hathatós
segítségért:
• Szalai Lászlónak az évek óta tartó folyamatos motiválásért és szakmai
támogatásért.
• Az Evosoft Hungary Kft-nek és különösen Arnhoffer Edit IT managernek
az infrastruktúra biztosításáért.
• Az Evosoft Hungary Kft. rendszergazdai csapatának a folyamatos
szakmai támogatásért.
34
IX. Irodalomjegyzék
(1) Ed Wilson: Microsoft Windows Scripting Self-Paced Learning Guide
(2) William R. Stanek: Microsoft Windows Parancssor