Migreren Microsoft Exchange

Achtergrond

Het upgraden van systemen is, of we het nou leuk vinden of niet, een noodzakelijk onderdeel van onze technologische wereld. In een poging kosten te besparen, kiezen bedrijven ervoor om terughoudend te zijn met de uitrol van nieuwe technologie.

De keerzijde van de medaille is dat als een upgrade eindelijk wordt goedgekeurd, vaak diverse complexe systemen tegelijkertijd moeten worden geupgrade – soms zijn daar hardware, software en andere IT-infrastructuuritems bij betrokken. We noemen dit het ‘net zo goed’-syndroom. Een vaak gehoord argument is namelijk: “Als we toch ons [noem een willekeurig IT-item] upgraden, kunnen we net zo goed [vul nog een item in dat het bedrijf nodig heeft] toevoegen. En als we dat toch aan het doen zijn, kunnen we net zo goed nieuwe …” Klinkt bekend?

Als dat zo is, weet u ook dat van de vaak toch al drukke IT-afdeling wordt verwacht dat ze een gecompliceerde upgrade op heroïsche wijze voltooien en dat allemaal binnen de afgesproken tijdspanne en budgetten. Terwijl meerdere upgrades het risico op complicaties juist verhogen, waardoor de productiviteit van medewerkers kan worden aangetast door vertragingen of in het ergste geval zelfs dataverlies tijdens de upgrade.

Hieronder staat een case study van een organisatie die teveel IT-systemen  en – assets tegelijk wilde upgraden, omdat ze niet voldoende mankracht hadden om de reguliere IT-onderhoudsprojecten bij te houden. Het bedrijf had te maken met een IT-infrastructuur die alleen op noodzakelijke punten was uitgebreid en er was geen documentatie of configuratie-informatie voorhanden. Daardoor moest de IT-afdeling niet alleen de fundamenten van het netwerk upgraden, maar ook zorgen voor het belangrijkste onderdeel van het project – de upgrade van de emailserver.

Een grote IT-dienstverlener met meerdere internationale vestigingen besloot tot een Exchange 2010 migratieproject voor alle regio’s. De scope van het project was twintig kantoren, drie netwerkdomeinen en meer dan  zesduizend mailboxen. Daarnaast omvatte het project: een Blackberry Enterprise Server (BES), Outlook Web Access (OWA) services en de introductie van  Microsoft Forefront servers in de infrastructuur.

Het grootste obstakel in de planning was de vertraging van een Microsoft Windows Server Domain Active Directory (AD) consolidatieproject dat inmiddels al bijna een jaar liep. Door de groei van het bedrijf hadden veel vestigingen inmiddels hun eigen domains opgezet met alleen een ‘trust relationship’ met het domein van het hoofdkantoor. Gebruikers in de vestigingen konden niet inloggen op het domein van het hoofdkantoor, laat staan bij de data op dat netwerk, zelfs niet als ze de juiste toegangsrechten hadden gekregen tot die data. De afgelopen jaren waren er houtje-touwtje oplossingen bedacht om gebruikers toch toegang te geven tot de bedrijfssystemen. Een aantal van deze oplossingen verhoogde de complexiteit van gebruikersaccounts en stelde het bedrijf eveneens bloot aan beveiligingsrisico’s. Een van de internationale vestigingen had continu problemen met de toegang tot het systeem, maar kreeg bijzonder weinig aandacht en ondersteuning van de IT-afdeling doordat ze in een verschillende tijdzone werkten. De office manager raakte zo gefrustreerd dat hij het recht in eigen hand nam en een tweede internetverbinding aan liet leggen, waarmee een connectie kon worden gemaakt met het hoofdkantoor en een computer in het salesteam op afstand kon worden bediend zodat men toegang had tot het CRM-systeem van de organisatie.

Met een groot risico stuurde de buitenlandse vestiging via een aansluiting met lage encryptie data over het internet die via een ongebruikte netwerkpoort weer terug kwam in het bedrijf. Hoe de officemanager die open poort in de firewall wist te vinden en wie van de salesafdeling met hem samenwerkte, bleef altijd een mysterie. Toen de IT-afdeling achter de niet toegestane verbinding kwam, werd deze direct afgesloten en kon de buitenlandse vestiging wederom niet bij bedrijfsdata, behalve via de officiële weg langs de IT-afdeling.

Er waren zoveel  niet gedocumenteerde aanpassingen in de netwerkinfrastructuur dat de IT-engineer die aan de Active Directory werkte het liefst opnieuw wilde beginnen en het systeem vanaf de grond opnieuw wilde opbouwen. Helaas was dat geen optie gezien de hoeveelheid gebruikers en de afhankelijkheid van de organisatie van het netwerk. 

Oplossing

De IT-afdeling begon met een systematische inventarisatie van alle serversystemen op iedere vestiging en startte met het documenteren van het upgradeproces waarmee de AD-stap zouden worden gefinaliseerd en waarmee de fundering voor de Exchange 2010 migratie zou worden gelegd. De impact was groter dan in eerste instantie werd gedacht en het complete project nam achttien maanden in beslag, zes maanden langer dan was gepland.

Een van de meer ingewikkelde migraties was voor het BES-systeem. Er was niet genoeg IT-personeel voorhanden om de migratie uit te voeren voor alle medewerkers, dus werden er specifieke instructies geschreven voor gebruikers zodat zij handmatig de mailbox op hun mobiele telefoon konden afronden. Als de instructies niet precies werden gevolgd, werkte het synchronisatieproces voor de BES-mailbox omgekeerd en verloor de gebruiker al zijn gearchiveerde emaildata. Onvermijdelijk verloor een aantal gebruikers data doordat zij de instructies niet opvolgden. Gelukkig was, voorafgaand aan de upgrade, door het business continuity plan van de IT-afdeling geregeld dat er diverse back-ups voorhanden waren zodat het dataverlies tot een minimum werden beperkt.

Dit was een lang en vervelend project en het vereiste veel toewijding en geduld. De grootste klacht kwam van een aantal gebruikers die door middel van dubbele accounts een manier had gevonden om binnen het domein te werken. Zij konden vaak geen gebruik maken van de kalender en planningssoftware van het bedrijf.