Eind van dit jaar is het zover: de gratis support van Windows NT 4.0 stopt. Veel bedrijven die de overstap naar Windows 2000 of Windows Server 2003 nog niet hebben gemaakt, staan voor de keuze: overstappen of (met betaalde support) blijven waar ze zijn en de migratie nog even uitstellen. Navraag bij Microsoft leert dat zo’n 20 procent van de servers in Nederland nog op Windows NT 4.0 draait. En nog steeds wordt ongeveer 8 procent van de nieuwe machines met dit besturingssysteem uitgevoerd. Velen zien het als een onweersdreiging, maar er zijn ook positieve kanten. Een migratie biedt immers een enorme kans om grote schoonmaak te houden en de IT-huishouding weer op orde te brengen onder het mom van: ‘als we toch moeten, dan maar liever goed’.
De grotere bedrijven zijn vaak al over en in veel gevallen hebben zij daarbij de hulp ingeroepen van externe consultants, die in dit soort trajecten de nodige ervaring hebben opgedaan. Kleinere bedrijven moeten het allemaal zelf doen en zien hier als een berg tegenop. Hoe groot of hoe klein de omgeving ook is, in principe zijn de stappen hetzelfde. Het enige dat verschilt, is de duur en omvang van het traject. Welke stappen moet een bedrijf zetten om de overstap soepel te laten verlopen?

Inventariseren
Als je iets wilt bereiken, zijn twee dingen van belang: de beginsituatie en het doel dat je wilt bereiken. Ook bij een migratie is dat het geval. Eén van de grootste problemen is dat een IT-afdeling niet helemaal precies weet wat de huidige situatie is. De omgeving is een aantal jaren geleden ingericht (soms waren de huidige beheerders er niet bij betrokken) en als deze ooit al goed gedocumenteerd was, is het in veel gevallen maar de vraag of de informatie nog steeds klopt. De omgeving is in de loop der tijd uitgebreid en veranderd. Er kwam eens een extra domein bij voor afdeling X, een nieuwe server voor afdeling Y et cetera. Applicaties zijn gekomen en gegaan, soms ook zonder dat de IT-afdeling erbij betrokken was en zo langzamerhand is het overzicht zoek.
Om te beginnen is het dus van belang om te inventariseren/controleren hoe de huidige omgeving eruit ziet. Welke informatie is van belang? Hoeveel domeinen zijn in gebruik, hoeveel gebruikers, groepen en werkstations zijn er, hoe zijn rechten uitgedeeld (zowel op share als NTFS-niveau), welke applicaties zijn er in gebruik en hoe handelen deze applicaties de authenticatie af (vanuit Windows, via een script, opnieuw userid en wachtwoord opgeven), hoeveel servers zijn er en welke services leveren die? Kortom: inventariseren.
Het beoogde doel wordt duidelijk als er een ontwerp wordt gemaakt. Een gedegen ontwerp is uiterst belangrijk en onmisbaar voor een goed resultaat. Bij het maken van het ontwerp is ervaring belangrijk, want voor een aantal beslissingen moeten soms gevoelige knopen worden doorgehakt. Op dat gebied heeft een klein bedrijf een voorsprong op grote multinationals, waar diverse autonome afdelingen nu samen in één Active Directory komen. Politiek en wantrouwen leveren vaak oneindige discussies op die een vruchtbaar ontwerptraject enorm vertragen. Een ander struikelblok is naamgeving. Afhankelijk van het aantal mensen dat hierover consensus moet bereiken, duurt het een uurtje of maanden om tot een naamgevingconventie te komen.
Als een IT-afdeling zelf een ontwerp moet maken, waar dan te beginnen? Het internet barst van de whitepapers en casestudies. Alles lezen kost een ontwerper een jaar. Mede daarom heeft Microsoft een (gratis) voorbeelddesign uitgewerkt, gebouwd en getest (zie kader). Deze referentiearchitectuur is goed bruikbaar.

Migreren
Als de huidige omgeving en het ontwerp van de nieuwe omgeving bekend zijn, blijft de vraag over: Hoe moeten we migreren? Vragen die daarop aansluiten zijn: Wat moet er worden gemigreerd: werkstations, gebruikers, groepen, servers? Wanneer en in welke volgorde? En moet alles in één keer of in fases? Afhankelijk van de grootte van de organisatie, de spreiding van het bedrijf en de mogelijkheden moet de IT-afdeling een strategie kiezen. Praktische vragen die de keuze beïnvloeden zijn: Hoe groot is de belasting om twee omgevingen naast elkaar te laten draaien (co-existentie)? Hoe kunnen gebruikers vanuit het nieuwe domein de resources in het oude domein benaderen? Moeten er tools worden aangeschaft? (Zie kaders.)
Na de migratie moet de nieuwe omgeving beheerd worden. In de praktijk levert dat ook nogal eens de nodige problemen op. Vaak is de beheerorganisatie niet betrokken bij het ontwerp. Vanuit het migratieproject moet er heel duidelijk gewerkt worden aan de samenwerking met de beheerorganisatie en moet er veel aandacht besteed worden aan de overdracht. Tijdens de ontwerpfase worden bijvoorbeeld keuzes gemaakt met betrekking tot de inrichting van de Active Directory. Passen deze keuzes in de strategie die de beheerafdeling volgt? Strookt de visie van het projectteam op gedelegeerd beheer met die van de beheerafdeling zelf? Het is dus verstandig het beheer mee te nemen in het ontwerp en samen met deze afdeling de migratie te doen, dan wordt de overdracht slechts een formaliteit.
Tot zover de migratiestappen. Er zijn echter verschillende zaken nog niet behandeld, die toch veel aandacht vereisen. Als er geen aandacht wordt besteed aan de gebruikers, de applicaties en de testfase is de kans op slagen bijna nihil.

Lastig
Voor de gebruikers is een migratieproject vaak alleen maar lastig. Ze krijgen een nieuw userid en password, moeten anders aanloggen, de werkwijze gaat veranderen en wellicht krijgen ze een nieuwe e-mailomgeving. In de praktijk blijkt dat een gedegen, tijdige en heldere communicatie heel veel weerstand wegneemt en dat daardoor de acceptatiegraad van de nieuwe omgeving wordt verhoogd. Een creatieve communicatiemedewerker kan allerlei manieren verzinnen om de communicatie met de gebruikers te stroomlijnen. Een paar voorbeelden: het organiseren van een klankbordgroep, het tonen van een testopstelling tijdens de maandelijkse borrel, het sturen van een persoonlijke brief met uitleg, het organiseren van bijeenkomsten per afdeling en het aanbieden van een eventueel op maat gemaakte cursus.
Ook zijn er zeker momenten in het bedrijfsproces te vinden, waarop een verstoring absoluut ongewenst is, zoals het einde van de maand als er financiële rapportages moeten worden opgeleverd. Een goede planning en uitgebreide communicatie zijn noodzaak.
Ten tweede de applicaties. Zij vormen één van de grootste obstakels bij een migratieproject. Daarom is een inventarisatie zo belangrijk. Er zijn veel applicaties die niet onder Windows 2000/2003 werken. Vaak is een upgrade nodig. Ook zijn er heel vaak nog oude DOS-applicaties in gebruik, die eveneens niet meer gaan draaien. Het is verbazingwekkend hoeveel applicaties er tijdens een inventarisatie boven water komen. Vaak gaat het daarbij om ongeveer alle versies die een bepaalde toepassing ooit heeft gehad. En alle applicaties zijn, volgens de meeste gebruikers, bedrijfskritisch en absoluut onmisbaar. Het is dus altijd een hele opgave om applicaties te saneren en naar een nieuwere versie te brengen. Een krachtig mandaat vanuit de bedrijfsleiding is onontbeerlijk om voortvarend te werk te kunnen gaan.
Naast de officiële applicaties, zijn er ook nog talloze spreadsheets en access-achtige toepassingen die gebruikers of afdelingen zelf ontwikkeld hebben en die soms heel vernuftig in elkaar zitten. Zo vernuftig soms dat niemand weet wat de consequenties zijn, als bijvoorbeeld het UNC-pad van de data-server verandert. Ook deze applicaties moeten na de migratie nog werken. Testen en communiceren is het devies.
Ten derde het testen. De testfase is veelal een ondergeschoven kindje, maar onmisbaar. Meestal is er tijdens een project alleen tijd ingeruimd voor ontwerp, bouw en migratie. Vaak loopt de ontwerpfase en de bouw wat uit en moet er toch een datum gehaald worden. Het testen van het geheel komt dan in het gedrang, want daar was geen tijd voor ingecalculeerd. ‘Testen hoort toch bij het bouwen?’ Het is de grootste fout die gemaakt kan worden. Testen betekent niet alleen testen of de nieuwe omgeving voldoet. Testen betekent ook een paar keer een proefmigratie uitvoeren. Vaak komen daarbij onvoorziene situaties naar voren, die je maar beter vooraf kunt weten.
Kortom, een migratietraject is een ingrijpend proces dat alleen kan slagen als er een duidelijk ontwerp klaar ligt. Een goede strategie zorgt voor de kortste route, uitgebreid testen verkleint de risico’s onderweg. Communicatie met iedereen die meereist, zorgt voor een aangename reis.

Tussen de twee uitersten (Big Bang of gefaseerd) liggen vele varianten met elk hun voor- en nadelen.

Big Bang:
• Kort maar hevig.
• Huidige structuur blijft bewaard.
• Weinig rompslomp met autorisaties.
• Lastig om terug te draaien.
• Hoog risico.
• Weinig mogelijkheden tot consolidatie.
• Ingewikkelde oude domeinstructuren blijven in tact.
• Herstructurering kost veel inspanning achteraf.

Gefaseerd:
• Nieuwe, schone omgeving.
• Relatief laag risico.
• Steeds mogelijkheid stapje terug te doen.
• Veel zorg om tijdelijk twee omgevingen parallel te hebben.
• Autorisaties moeten overgezet worden.
• Alles moet vanuit het oude domein naar het nieuwe worden gemigreerd.
• Lang lopend traject.

Architectuur
Windows Server System Reference Architecture (WSSRA, voorheen Microsoft Systems Architecture: MSA) is één van de minder bekende initiatieven van Microsoft om bedrijven te helpen een goede en betrouwbare omgeving in te richten. WSSRA is een uitgebreid gedocumenteerde en geteste architectuur waarin de belangrijkste Microsoft-technologieën zijn opgenomen. Alles is tot in de kleinste details beschreven, waaraan diverse experts van zowel Microsoft als partners hebben bijgedragen. WSSRA helpt bij het maken van ontwerpbeslissingen en biedt een gedegen basis voor een goed ontwerp.

Zie www.microsoft.com/wssra

Tools
Natuurlijk zijn er allerlei tools te koop om migraties zo gemakkelijk mogelijk te laten verlopen (onder meer van Quest en NetIQ). Deze tools kosten geld, maar bieden meer functionaliteit dan de gratis tools van Microsoft (ADMT, USMT). Vergelijk het met een auto: een Rolls Royce is duur maar comfortabel, met een middenklasser bereik je echter ook je bestemming.
Active Directory Migration Tool (ADMT) is een gratis tool van Microsoft waarmee users, groepen en computers kunnen worden gemigreerd van het ene domein naar het andere. ADMT kan ook passwords en SidHistory meenemen en kan zonodig ook zorgen voor het aanpassen van de rechten in de oude omgeving voor gebruikers en groepen die naar de nieuwe omgeving gemigreerd zijn. Ook kan ADMT het primary account in een Exchange 5.5-omgeving aanpassen.
Zie www.microsoft.com/windowsserver2003/upgrading/nt4/upgradeassistance/default.mspx.
Met behulp van het User State Migration Tool (USMT) kunnen gebruikersprofielen op werkstations overgezet worden van de oude gebruiker naar de nieuwe.

Zie www.microsoft.com/technet/itsolutions/techguide/mso/bdd/bddusmt.mspx.

Valkuilen
De meest voorkomende valkuilen zijn:
• geen accuraat beeld van de huidige omgeving;
• geen overzicht over de gebruikte applicaties en de beheerders daarvan;
• geen goed ontwerp;
• de beheerders zijn niet betrokken bij het ontwerp en het verdere traject;
• onvoldoende communicatie met gebruikers;
• onderschatting van de impact van een migratie;
• beheerders zonder voldoende opleiding.

SIDHistory
Als een gebruiker rechten krijgt op een resource (bijvoorbeeld een file-share of printer) gebeurt dat doordat de SID (een reeks tekens waarmee een resource - gebruiker, groep, computer - binnen een Microsoft-omgeving geïdentificeerd kan worden) van de gebruiker wordt toegevoegd aan de ACL (Access Control List, de lijst met SID’s en hun autorisatie) van de resource. Als een gebruiker (of groep) wordt gemigreerd naar een nieuw domein, krijgt hij in het nieuwe domein een nieuwe SID en heeft hiermee geen toegang tot de resources in het oude domein die voor de migratie wel benaderd konden worden. Door nu tijdens de migratie de SID uit het oude domein mee te nemen (via een parameter in het migratie-tool), krijgt de gebruiker in het nieuwe domein 2 SID’s (een nieuwe en de oude) en daardoor blijft de toegang tot de resources in het oude domein nog steeds mogelijk.

AUTEUR: René Scholten
René Scholten (rene.scholten@capgemini.com) is managing consultant en enterprise infrastructure engineer bij Capgemini.