SBS2003-SBS2008 migráció nagy piros gomb nélkül


Ez a fejezet tárgyalja a vegyes hálózatok, SBS2003, vagy más Windows tartományok SBS2008 tartománnyá alakításának lehetőségeit. Az alapvető különbség az előző fejezet témájához képest, hogy a meglévő tartományi, vagy címtárinformációk nem kerülnek felhasználásra az új SBS2008 tartományban.

A legjobb, legszakszerűbb szándékunk és előkészítésünk ellenére is előfordulhat, hogy nem lesz eredményes a migrációs varázsló működése. Milliónyi oka lehet ennek, nem is kezdek bele a tárgyalásukba. Tény, hogy ha 1-2 nap alatt nem sikerül megoldani a problémát, egy 10-15 gépes hálózatban egyszerűbb az érintett adatokat kézzel áthelyezni egy üresen telepített SBS2008-tartományba. Tapasztalataim szerint megfelelő előkészítéssel ez egy 1 napos munka 1 gyakorlott szakembernek.
Melyek lehetnek ezek az érintett adatok, és hogyan lehet okosan "migrálni" őket?
- Tartományi információk
- Csoportházirendek
- Felhasználói fiókok
- Számítógép fiókok
- Felhasználói profilok a kliensgépeken
- Megosztott könyvtárak
- Hálózati beállítások, VPN
- Exchange postafiókok (külső postafiók beállítások)
- Exchange publikus mappák
- WSUS frissítések
- Sharepoint v2-v3 munkaterületek

Lássuk sorban a kérdéses területeket!
Tartományi információk
Mit is jelent ez? Felhasználói fiókokat, számítógépeket, csoportházirendeket, szervezeti egységekhez rendelve. A tapasztalatok azt mutatják, ha sok egyedi beállítás lenne az egyes objektumokhoz, itt az idő konszolidálni őket! Itt a lehetőség, hogy átgondoljuk újra, mire van szükségünk, tervezzük újra címtárunkat, dobjuk ki az évek óta gyülekező felesleges információkat, evolúciós maradványokat! Hozzuk létre újra a felhasználói fiókokat az üresen telepített SBS2008 szerveren!
Az esetleges egyedi csoportházirendjeinket cseréljük ki az új, .admx formátumú csoportházirendekre!
A kliensgépeket léptessük ki a régi tartományból, majd jelentkeztessük be az új tartományba! A helyi felhasználói profilok tartalmát az USMT vagy a WET (windows áttelepítő) eszközökkel költöztethetjük az új profilkörnyezetbe.
A megosztott mappák szabályos migrálása után is kötelező a jogosultságok ellenőrzése. Itt a lehetőség, hogy a jogosultságrendszer nélkül átmásolt-összefésült fájlokon tervezett módon alakítsuk ki a hozzáférési jogosultságokat.

Milyen távoli elérhetőséget biztosítunk a dolgozóknak? Az SBS2008 már nem olyan sértődékeny, mint elődje, tehát ha nem használjuk ki hálózati lehetőségeit, akkor is be lehet illeszteni a meglévő infrastruktúrába. Lényegében a DHCP-kiszolgáló és a VPN kapcsolódási pont, amely funkciót nyugodtan külső eszközre bízhatunk. A DNS-névfeloldás viszont továbbra is a tartományvezérlő kezében kell, hogy legyen az egészséges tartományi működéshez.

A meglévő Exchange 2003 postafiókokat .pst állományok segítségével tudjuk az új kiszolgáló postafiókjaihoz illeszteni. Ezt az Exchange 2003 szerveren az exchmerge eszközzel, kliensoldalon meglévő Outlook 2003 segítségével tudjuk véghezvinni. Az utóbbi kissé körülményesebb, általában hosszabb ideig is tart, ám a nagyobb méretű postafiókok, vagy hibás szerver esetén is sikerrel kecsegtet. Arra ügyelni kell, hogy az Outlook 2003 utáni verziók .ost állományba szinkronizálnak a szerverrel alapértelmezetten, azonban ez a fájl csakis a felhasználó saját profiljában használható, más helyre nem csatolható fel! Tehát az archiválás-exportálás .pst fájlba külön lépést igényel: létrehozunk egy új adatfájlt (a 2003-as verzió az UTF támogatás miatt 20Gb-ig hízlalható), és drag-and-drop-pal átmásoljuk az exchange mappa tartalmát (levelestől-naptárastól-névjegyestől).
Az új tartományba léptetett gépen bejelentkezünk az új tartományi felhasználókkal, létrehozzuk az Outlook-profilunkat. Ezután felcsatoljuk a .pst állományokat, amelyek régi levelezésünket tartalmazzák, majd kijelölve az összes mappát, naptárat, stb. bemásoljuk az Exchange levelezés struktúrába. Az Outlook ezután felszinkronizálja a tartalmat a szerveren lévő fiókba. Elegendő
időt hagyva a szinkronizálásra, bejelentkezünk az Outlook Web Access felülettel, mivel ez a felület mindig a szerveren lévő tartalmat mutatja, ellenőrizhetjük az eredményt.
A publikus mappák tartalmát ugyanígy költöztethetjük. Javasolom e célra külön adatfájl nyitását, illetve ügyeljünk, hogy elegendő jogosultsággal rendelkező felhasználóval (pl. Domain Admin) hajtsuk végre az export-import lépéseket.

Külső vagy nem Microsoft alapú levelezőrendszerek
Amennyiben eldöntöttük, hogy levelezésünket az Exchange 2007 fogja ellátni, igényünk lehet a régi levelezésünket viszontlátni az új postafiókokban. Általában két forgatókönyv létezik:
Jelenlegi levelezésünket külső szolgáltató postaládájában tartjuk. Ebben az esetben a bejövő levelezést a POP3 connector segítségével szinkronizálhatjuk helyi postaládáinkkal, vagyis az Exchange 2007 közvetlenül, mint levelezőkliens tölti le a leveleket. A kimenő levelezést rendszerint helyben tároljuk, de ha nem, akkor is szükség lesz ismét az Outlook export-import lehetőségére, mivel a POP3 connector csak a bejövő levelezést tudja a szerveren lévő postafiókokba importálni (ha nem is ez az elsődleges célja). Könnyebb az út, amikor belső szerveren vannak a leveleink, ekkor az Exchange importáló metódusaival tudunk kapcsolódni a meglévő kiszolgálóhoz, így összepároztatva az egyes postafiókokat, közvetlenül kerülhetnek át a meglévő levelek az új környezetükbe.
A második forgatókönyv sajnos nem ennyire egyértelmű. Ha olyan levelezőprogramban tároljuk leveleinket, amely közvetlenül nem támogatja a .pst használatát, akkor nekünk kell közös nevezőre hozni levelezőrendszereinket. Ez általában az Outlook Express közbeiktatását jelenti, mivel e program formátumát szinte minden egyéb levelezőprogram támogatja. Nagyobb mennyiségű fiók /adatmennyiség esetén esetleg fizetős, e célra fejlesztett programok után is érdemes kutatni.

WSUS-frissítések
Akár a beépített WSUS2/3-ról, akár általunk üzemeltetett WSUS-ról van szó, érdemes teljesen nulláról újraindítani a központi frissítések kezelését, méghozzá az SBS2008-ban használt formában. Több oka is van ennek:
- A szolgáltatás majd' 10 éves pályafutása alatt nem volt képes korrektül az öntakarításra. Vagyis csak hízni és hízni tud.
- Rejtett hibajelenségek jelentkezhetnek migrálás alkalmával, amelyek kikalapálására szánt idő nem térül meg soha.
- Újra tervezhetjük az esetlegesen megváltozott körülmények miatt frissítési stratégiánkat.
Mindezt elkerülhetjük, ha kompletten eldobjuk az előző WSUS szerverünket, és az újnak adunk egy-két éjszakányi időt az új frissítések letöltésére, amely - okosan beosztva - 10-15 Gb-nyi letöltést jelent.

SQL adatbázisok
Elsősorban a "nagyverziós" MS-SQL adatbázisszerver adatköltöztetésre gondoljunk, vagyis ne a Health Monitor, vagy ISA2004 log adatbázisaira, amelyek SQL2000 alapú MSDE adatbázispéldányok. Ugyanis ezek nem használhatók az új kiszolgálón, mivel teljesen más szolgáltatások veszik át feladataikat. Az első tétel költöztetéséhez ki kell kérnünk az adatbázisszervert használó alkalmazás üzemeltetőjének-fejleszőjének véleményét, hogy az új 64 bites környezetben, esetleg SQL2005-SQL2008 támogatottság miként valósítható meg.

WSS2-3 költöztetés
Ennek lépései nem különböznek a hivatalos leírásokban közöltektől SBS2008 környezetben. Akár meglévő WSS2-WSS3 áttérésről van szó, akár WSS3 átköltöztetése az új kiszolgálóra, a dokumentációkon túl nagy valószínűséggel szükségünk lesz utólagos tesztelésre és hibajavításra (mint pl. a megosztott mappák mozgatásakor).
Ebben a lépésben, amennyiben rendelkezünk "nagy" SQL szerver verzióval, érdemes elgondolkodnunk, hogy ha már költöztetjük intranetes szolgáltatásainkat, nem az alapértelmezett, beépített WMSDE-SSEE adatbázispéldányt használjuk.