Exchange 2007 is de opvolger van Exchange 2003 en is de eerst Exchange versie sinds 5.5 waar ik het gevoel krijg dat Microsoft echt iets significants gewijzigd heeft aan het product. Ze zijn duidelijk ingesprongen op de vraag van vele bedrijven om iets te leveren wat stand houdt in de moderne IT organisatie. Of het ze al helemaal gelukt is, is een tweede, maar ik moet zeggen dat ik vind dat ze in ieder geval een stap in de goede richting hebben gezet en dat Exchange 2007, net als zijn voorgangers, straks niet meer weg te denken is uit de backoffice.

Server rollen
Het eerste wat iedereen meteen opvalt zijn de serverrollen. Pre-2007 waren alle Exchange servers nagenoeg gelijk aan elkaar, in de zin dat ze allemaal bij installatie dezelfde services hosten en dus geen afwijkende functionaliteit hadden. Er was de keuze om een Exchange server als front-end in te zetten als 'Outlook Web Access'-proxy en als back-end als Mailbox server en dan hield het ook wel op. De overige 'rollen' kwamen meer voort uit het feit dat beheerders en engineers deze de exchange servers zelf bestempelden. Met wat policies en delegatiemodellen kwam je vaak al een heel eind, maar dit was allemaal maatwerk.
Het feit dat dus elke Exchangeserver per definitie gelijk was, maakte een Exchange server die bijvoorbeeld als front-end in een DMZ werd ingezet, dus onnodig kwetsbaar. Daarnaast verbruikt een dergelijke server dus onnodig resources. Wat moet een OWA proxy immers met een SMTP server, Information Store en MTA stacks?
Microsoft is hier heel handig op ingesprongen door meerdere serverrollen te definieren die elk hun eigen applicatiebestanden hebben, hun eigen vereisten en ook hun eigen functionaliteit en securitypolicies. Zo hebben we de Mailbox Server, Hub Transport, Edge Transport, Client Access server en Unified Messaging server. Deze rollen kunnen gecombineerd worden op een en dezelfde server, met uitzondering van de Edge transport server en wanneer een maiboxserver geclusterd dient te worden. Een andere limitatie is dat ELKE Active Directory site waar een Mailbox server staat ook een Hub transport en client access server moet hebben.

De Mailbox Server is een schot voor open doel... Dit is de server waar de mail fysiek wordt opgeslagen in de jet-database. JA... We hebben nog steeds een jet database, draaiend op de Extensible Storage Engine. We zijn alleen de STM database kwijt. We hebben dus alleen nog maar een EDB file. Uiteraard zijn er op database management gebied wat wijzigingen, maar dit valt voor dit moment even buiten de doelstelling van dit artikel. In Exchange 2007 kunnen er 50 database aangemaakt worden. We kunnen dus 50 storagegroups aanmaken met elk 1 database, of 5 met elk 10 databases etc etc. Dit in tegenstelling tot Exchange 2003 met maximaal 5 storage groups en maximaal 5 databases per storagegroup. Nu zul je denken... BIG DEAL.., maar vanuit een performance/storage oogpunt kunnen meerdere storage groups zeker meerwaarde bieden. Dit zal ik binnenkort behandelen in een artikel over storage voor Exchange 2007. De public folder store bestaat ook nog steeds, maar wordt niet meer geinstalleerd in een heterogene Exchange 2007 - Outlook 2007 omgeving. Voor oude clients en in een coexistence omgeving is de public folder store vereist voor de replicatie van de free-busy data en het leveren van het Outlook Address book voor clients. De laatste opvallende wijziging zijn een aantal nieuwe typen mailboxen zoals de ROOM en TOOLS mailboxen en de clustermogelijkheiden, waar ik later in dit artikel op terug kom.

De Hub transport server en Edge transport server zijn de rollen die het mailtransport afhandelen, waarbij het verschil tussen beiden hem zit in de plaatsing binnen de mailinfrastructuur. De Hub Transport server is bedoelt als interne mailserver en handelt verkeer af binnen de Exchange organisatie en vertrouwde interne mailomgevingen. De architectuur van de transport services op de Hub transport stellen de onderneming in staat te voldoen aan interne en externe (beleids-)regel- en wetgeving. Waar het in vorige versies van Exchange vaak lastig was policybased te voldoen (compliant te zijn ;)), maakt Exchange 2007 het extra makkelijk. Dit zit hem voornamelijk in het feit dat ELK bericht via een Hub transport server moet alvorens het bij de ontvanger terecht komt. In pre-2007 systemen werden berichten binnen dezelfde database door de Information Store behandelt en alleen ,voor de database, externe berichten via SMTP verstuurt. Dit maakte het lastig om policies te definieren, die in de meeste gevallen gebaseerd zijn op SMTP events via een eventsink, los te laten op alle email. Exchange 2007 zorgt ervoor dat alle email, dus ook binnen de eigen store en mailbox, eerst via de Hub Transport verstuurt wordt. Door middel van bijgeleverde transportagents en transportrules, en een geweldige API is een bedrijf in staat om grip te krijgen op elk emailtje in de organisatie en bijv. Chinese muren en Auditing te implementeren, zonder ingewikkelde constructies. Door deze verschuiving van transportverantwoordelijkheid wordt voor een groot deel ook de druk op resources van de mailboxserver beperkt. Antivirus wordt gedaan op de Hub transport (SMTP AV, store AV kan uiteraard ook nog steeds) en ook journaling vind daar nu plaats. Meer hierover in verdere paragrafen.
De Edge transport server is bedoelt om geplaatst te worden in het perimeter netwerk / DMZ en is in principe een aangepaste hub transport server. Wanneer je de achitectuur van beide rollen bekijkt, zijn ze redelijk gelijk. Het grote verschil zit hem in het feit dat de Edge Transport server geen domain member is en getuned is voor positionering in de DMZ. Zo heeft hij standaard antispam agents, stript hij automatisch interne headerinformatie en levert hij een aantal andere mogelijkheden om ongewenste post buiten te houden en gevoelige informatie binnen. Voor grotere omgevingen ben ik persoonlijk niet gecharmeerd van de edge transport server, maar dat ligt voornamelijk aan het feit dat andere leveranciers beter zijn in het afhandelen van grote hoeveelheden mail en centraal beheer van de mailsystemen. De Edge Transport server draait op Windows en maakt dus gebruik van de standaard TCP/IP stack met alle limitaties die dat met zich meebrengt. Wat ik wel een leuke feature vind is EdgeSync waar een Hub Transport server via secure LDAP verbinding maakt met een ADAM installatie en daar configuratiegegevens en, in versleuteld formaat, gegevens over interne ontvangers en blocklists naartoe schrijft. De blocklists (persoonlijke black- en whitelists) werken alleen met Outlook 2007. Op deze manier kan dus naast de normale antispam configuratie ook meteen gechecked worden of een gebruiker wel of niet bestaat en of de gebruikers wel mail willen ontvangen van de verzender. Al met al erg handig, maar niet geschikt voor grote omgevingen.

De Client Access server is de server waar alle niet-MAPI verbindingen met de mailboxservers worden afgehandeld. Dit betreft dus Web verbindingen, waaronder Outlook Web Access, Active Sync, RPC over HTTPS (Nu Outlook Anywhere) en Mobile Access, EN legacy protocollen als POP3 en IMAP4. NNTP bestaat niet meer. Naast de toegang tot email, levert deze server ook de Availability service en Autodiscover service. Beide zijn webservices waar de Autodiscover service Outlook clients in staat stelt de configuratie voor het Outlook profiel automatisch op te halen uit Active Directory. De Availability service is de vervanger van de free busy data uit Exchange 2003 en Outlook 2003. Een Outlook 2007 client zal bij het plannen van een afspraak verbinding maken met de Availability service op de eigen Client Access server, welke op zijn beurt verbinding zal maken met de Availability services van de Client access servers die verantwoordelijk zijn voor de mailboxservers waar de genodigden hun mailbox hebben. Ik ben een beetje huiverig wat dit gaat betekenen voor extreem grote omgevingen, met grote netwerken en trage WAN verbindingen, maar de tijd zal het leren. Wat wel opvallend is, is dat in tegenstelling tot Exchange 2003 cross-forest beschikbaar stellen van free busy een eitje is. Je hoeft in principe niet eens een forest trust te hebben. Heb je dit wel, kan je ook gebruik maken van een andere nieuwe verbetering. Een gebruiker kan nu voor een uitgebreid scala aan afspraakeigenschappen instellen wat hij/zij met andere mensen wilt delen. Dus wil je wel of niet dat mensen kunnen zien met wie je een afspraak hebt of waar. Ik vind dit persoonlijk iets wat erg handig is.

De laatste rol is de Unified Messaging rol. Toen ik dit voor het eerst hoorde wilde ik het heel graag in levende lijve zien. Nu ik het eenmaal heb gezien, hoeft het van mij niet meer. De gedachte achter de UM rol is heel leuk, maar het is het toch net niet. (of laat de net toch maar weg).
De UM rol zet een stap in de richting van een oude Hype 'Unified Messaging' waar het erom gaat dat alle messagingmiddelen (niet te verwarren met Unified Communications, wat alle communicatiemogelijkheden omvat) die een kantoormedewerker tot zijn/haar beschikking heeft, zijn gecentraliseerd in 1 systeem/ heterogene infrastructuur en via 1 interface te bedienen zijn. Volgens marktanalisten eind jaren 90, moest dit miljoenen gaan besparen en de efficientie van medewerkers met tientallen procenten gaan vergroten. Nou... nu is het 2007 en komt Microsoft met veel bombarie op de markt met Unified Messaging in Exchange 2007.
Wat levert het precies... Nou.. het stelt de gebruiker in staat om fax, sms en voicemail te ontvangen in de Mailbox. LEES te ontvangen. Om te versturen heb je nog steeds third party software nodig. Nu denk ik als IT-er... Leuk, maar hadden we al niet third party leveranciers die dat konden voor Exchange 2007? Ja die hadden we, MAAAAAAAAr..... We hebben nu ook Voice access. Voice access is een dienst die bedrijven in staat stelt om via VOIP te praten met je mailbox (Of eigenlijk de UM server). Je kan zo je mail en agenda laten voorlezen en ook afspraken verzetten. Op zich klinkt dat allemaal leuk, maar de tijd zal het leren hoe het functioneert in een grote omgeving en of mensen erop zitten te wachten om met een computer te praten. Naast deze functionaliteit biedt het ook een uitgeklede versie van een voicemail en een autoattendant (zo'n keuze menu, wat je te horen krijgt als je weer eens een helpdesk probeert te benaderen.). Mij krijgen ze er niet warm mee, maar wie weet... voor kleine bedrijven misschien best het overwegen waard. Let wel... het is GEEN telefooncentrale, dus je zult OF een IP-based telefooncentrale (SIP-over TCP ondersteuning is een vereiste) moeten hebben, OF een VOIP gateway moeten aanschaffen.

64 bit
De tweede grote wijziging is de overstap naar 64 bits architecturen. Wat mij betreft hadden ze dit een aantal jaar geleden mogen doen, want dit was voor Exchange 2003 ook al nodig geweest. In nagenoeg alle grote omgevingen waar ik de laatste jaren geweest ben of over gehoord heb, hadden beheerders problemen met Exchange 2003 en storage (met name op SAN). Exchange is een echt I/O beest en iedereen die wel eens een storage plan heeft opgesteld voor Exchange 2003 weet dat je snelle storage nodig hebt. De DAS oplossingen moeten zoveel mogelijk kleine snelle SCSI disken hebben en op het SAN zit je vast aan dedicated LUN's en bij voorkeur ook dedicated fiberrouters (MS beveelt zelfs dedicated SAN aan in een Exchange Datacenter scenario waar Exchange servers gecentraliseerd zijn in 1 datacentre). De grootste reden dat Exchange 2003 zoveel I/O genereerd is door geheugengebrek. mailbox users genereren over het algemeen aardig wat queries op de database gedurende de dag. Exchange probeert zoveel mogelijk van de database op te slaan in het geheugen. Bij geheugen toegang spreken we in nanoseconden en bij disktoegang in miliseconden, dus reken het verschil maar uit. Doordat Exchange 2003 alleen op 32 bits draait, kan het OS slechts 4 GB geheugen addresseren, waarvan standaard 2 GB wordt gebruikt door het besturingssysteem. Door de alombekende /3GB switch en /USERVA switches te gebruiken in de boot.ini, kon er een verschuiving gemaakt worden, waarbij het OS 1 GB kon aanspreken en applicaties de overige 3. Echter... met meerdere databases van 20 a 30 GB op een server, kon je toch slechts een klein portie van alle data cachen in geheugen. Er werd dus toch nog heel veel I/O gegenereerd. In Exchange 2007 is dat over. Je kunt nu terabytes aan geheugen addresseren en dus ook - in theorie - terabytes aan databases cachen. Uit de eerste berichten is het aantal I/Os van Exchange 2007 in vergelijking to enigsinds gelijke Exchange 2003 installaties teruggebracht tot 70%...... Dat is nogal wat. Dit stelt ons in staat grotere databases te gebruiken en dus ook meer en grotere mailboxen en dus een hogere mate van centralisatie.

Goodby routing groups!
In Exchange 200x een eerder hadden we nog sites en routing groups waar we via connectoren de meest geweldige routingtopologien konden maken. In Exchange 2007 kun je concept overboord gooien. Microsoft heeft ervoor gekozen om voor de routering gebruik te gaan maken van het AD sitemodel. Omdat ad-sites net als routinggroups meestal gebaseerd zijn op 'via-highspeed-connecties-verbonden-Local-Area-Networks' waren veel routingtopologien nagenoeg gelijk aan het AD sitemodel, waardoor het eigenlijk alleen maar extra werk opleverde.
Nu routinggroups niet meer bestaat, zijn de IP-sitelinks de vervanging van de routinggroup connectoren. De least-cost-route wordt dus bepaald door de IP-sitelink. Een ander verschil met Exchange 2003 is dat er niet meer sprake is van een multihop delivery, maar verbind de verzendende Exchange server, waar mogelijk, direct met de ontvangende Exchange server. Het zal dus geen route via meerdere Exchange server volgen, TENZIJ een site gekenmerkt wordt als een dedicated Hub-site. Wanneer een dergelijke site op de route ligt, zal het bericht op de eerste hub site op de route afgeleverd worden, alvorens het zijn weg vervolgt. Een ander concept wat ervoor kan zorgen dat er een tussenstop gemaakt wordt, is delayed fan-out. Dit is een mechanisme wat ervoor zorgt dat de opsplitsing - bij een mail met meerdere ontvangers op verschillende servers - plaats vindt op de meest efficiente plek in de route. Dit om bandbreedte te besparen. Een laatste uitzondering op directe aflevering, vindt plaats wanneer de ontvangen mailserver niet bereikbaar is. De verzendende server zal het bericht dan afleveren bij de dichtsbijzijnde server op de route.

Message hygiene & compliancy
Message hygiene & compliancy zijn onderwerpen waar je bij het ontwerpen van mail infrastructuren niet omheen kan. Exchange 2007 levert functionaliteit voor beiden.
Bij Message hygiene denken we meteen aan malware en spam. Helaas waren we in het verleden voor antispam en antivirus altijd gebonden aan third party software. Door de acquisitie van Sybari in 2005 heeft Microsoft een van de beste - zo niet het beste - antivirusproduct(en) voor Exchange, Antigen, binnenshuis gehaald. Het wordt nu uitgebracht onder de naam 'Forefront security for Exchange'. Om nou meteen te denken dat het gratis is, gaat uiteraard te ver, maar voor een schappelijke prijs (in vergelijking met wat Antigen koste) zijn je Exchange servers beveiligd. De software wordt meegeleverd met Exchange. Antispam agents zijn beschikbaar voor de Hub Transport-en Edge Transport server en de updates worden beschikbaar gesteld door Windows update. Hierbij kan gebruikt worden van de standaard methodieken als signitures, Sender-ID, (online) blocklists en keywords. Net als UM en de Edge Transport is deze functionaliteit leuk, maar voor grote omgevingen voel ik persoonlijk meer voor een oplossing als BrightMail van Symantec of IronMail van Cyphertrust, wat toch schaalbaarderde oplossingen zijn en qua beheermogelijkheden duidelijk gericht zijn op grote ondernemingen.
Qua compliancy ben ik erg te spreken over de aanpassingen die Microsoft aan de architectuur heeft aangebracht. Compliancy wordt door velen 1 op 1 gekoppeld aan emailarchiving, maar dit gaat veel verder. Compliancy staat voor 'conformeren aan' en heeft niet alleen betrekking op externe regelgeving als Sarbanes-Oxley Act, maar vaak in grotere mate op interne regelgeving. Vat hebben op de communicatiestromen en dataopslag binnen je infrastructuur is daarbij onontbeerlijk. Wanneer we het hebben over Exchange, hebben we het dus over de fysieke mailboxen, en het SMTP verkeer. Voor Exchange 2007 hadden we al redelijk wat mogelijkheden om de opslag en het transport van email te regulieren. We hadden mailboxstore- en serverpolicies en konden via allerlei properties op verschillende niveau's ((virtual)server, connector, sg, database, gebruiker en organisatie) afdwingen wat, hoe, hoeveel, wanneer en waarheen iets verstuurt gestuurt en opgeslagen kan worden. Toch liepen we af en toe tegen beperkingen aan. 1 daarvan - het vat krijgen op email binnen een store - heb ik al eerder benoemd; andere zijn quota's en dataretentie. Voorheen was er de mogelijkheid om per mailbox te bepalen hoe groot deze mocht worden, meer dan dat was niet mogelijk. Ook qua dataretentie waren de mogelijkheden beperkt. We konden emailjournaling aanzetten per mailboxstore, en een retentieperiode instellen voor verwijderde mailboxen. Wanneer we iets gebruikersspecifiek wilden, dan moest dat via Outlook en pst's, OF moesten we aan de slag met SMTP eventsinks. In Exchange 2007 komt Microsoft met een aantal toevoegingen die deze beperkingen teniet doen, namelijk managed folders, transport rules, multi-mailbox search en een uitbreiding op journaling. Om maar meteen met het laatste te beginnen; journaling is in Exchange 2007 en kan per gebruiker, distributielijst of database ingesteld worden. Ook zijn we nu flexibeler over waar email naartoe gejournaled wordt. We kunnen naar willekeurige emailaddressen en sharepointsites journalen. In combinatie met managed folders is dit een krachtige oplossing. Managed folders stelt ons namelijk in staat om per mailbox folder te bepalen wat de quota's zijn, wat de content is en wat het retentiebeleid is. Hierbij kan tevens onderscheid gemaakt worden tussen interne en externe email. Een bijkomend voordeel hierbij is dat we nu per gebruiker kunnen bepalen wat er gejournaled moet worden, wat niet en wanneer; vanuit een storage perspectief, een zeer wenselijke toevoeging.

Permissioning en zo
Ook het delegatiemodel is weer op de schop gegaan. Had je in Exchange 2003 nog een handvol rollen die je op organisatie op administrative group niveau kon uitdelen. In Exchange 2007 heb je 4 Universal Security Groups en daarmee houdt het op. De Administrative Groups bestaan niet meer. Je bent nu Organizational Administrator, View-Only administrator, Server administrator of Recipient administrator, waarbij je als Server administrator via de local Admin groups bepaald op welke server je ook daadwerkelijk administrator bent. Wil je dus servers groeperen, zoals met de vroegere administrative groups, zul je met GPO's moeten werken.
Een andere, en nog belangrijkere, wijziging in het hele rechtenmodel is de strictere scheiding tussen Exchange en AD permissioning. Je hoefde dus geen Exchange administrator te zijn om mailboxen te kunnen manipuleren, tot grote ergernis van veel bedrijven. Om hier wat aan te doen heeft Microsoft het Split-permissioning model verzonnen, waarbij er een strikte scheiding komt tussen Exchange rechten en AD rechten. Een mailbox kan dus alleen aangemaakt en verwijdert worden, wanneer je rechten hebt binnen Exchange. Op zich zijn ze daar aardig in geslaagd. Een account operator in AD kan nu niet zomaar meer de Exchange attributen aanpassen en mailboxen verwijderen. Op zich handig, maar heeft heeft wel wat voeten in de aarde gehad. Om het split permissioning model effectief door te kunnen voeren, moet het niet meer mogelijk zijn om mailboxen te kunnen aanmaken en bewerken vanuit Active Directory. Hierdoor hebben ze ervoor gezorgt dat alleen via de System Attendant mailboxen aangemaakt kunnen worden. De wijzigingen in AD vinden plaats vanuit Exchange via de System Attendant. In Exchange 200x hoefde je in principe alleen de Exchange attributen op een user object te vullen en was de mailbox impliciet gecreeerd. Dit kan dus nu niet meer, wat bestaande management tooling dus onbruikbaar maakt voor Exchange 2007.

Management tooling
Iedereen die Microsoft producten beheert heeft, is er wel eens tegen aangelopen. De beperkingen binnen een product om het te interfacen via scripts. Sommige zaken moesten gewoon via de GUI gedaan worden, andere zaken vereisten scripts met tientallen, zo niet honderden, regels code. Voor Exchange 2007 is Microsoft een hele andere weg ingeslagen. Alles, maar dan ook alles, kan gedaan worden via script en commandline. Sterker nog, de GUI praat tegen een commandshell aan; namelijk de Powershell. Ik moet zeggen dat ik in het begin vreselijk aan het vloeken was, omdat het een hele omslag is om van GUI naar commandshell te verhuizen, maar nu ik er een tijd mee werk, open ik nog zelden de GUI. Maar of dit alleen komt omdat de Powershell zo lekker werkt, of omdat de GUI te beperkt is, weet ik nog niet. Microsoft beweert dat 80% van de configuratie bereikbaar is via de GUI en dat je voor de overige 20% aangewezen bent op de Powershell. Ik durf te beweren dat dit eerder 50% om 50% is. Voor mijn gevoel is de GUI te veel uitgekleed. Blijkbaar vinden veel meer mensen dat, want Microsoft heeft al toegegeven dat ze te weinig tijd hadden om de GUI door te ontwikkelen, en beloven verbetering in SP1.
Een andere wijziging m.b.t. managementtooling is het overboord gooien van de vertrouwde users&computers snap-in (ADUC) voor de MMC. Door het split permissioning model is het niet meer mogelijk Exchange 2007 mailboxen te managen via ADUC. Wanneer er nu mailboxen beheert dienen te worden, moet dat via de Exchange GUI en Shell.
Waarom ze er niet voor hebben gekozen om een revisie op de snap-in uit te brengen is mij - en velen anderen met mij - een raadsel, maar zo liggen de zaken nu eenmaal. Op zich heb ik persoonlijk niet zo'n probleem met een nieuwe interface, maar voor mailbox beheer is de console veel te beperkt. Voor het simpelweg toekennen van Mailboxpermissies zit je al vast aan een Shellcommando. Voor een doorgewinterde beheerder geen probleem, maar voor een startende helpdesker kan dit vaak al lastig zijn. En laten we eerlijk zijn, user management is vaak onderdeel van het werk van een eerste lijns helpdesk, en daar zitten niet altijd de meest bedreven IT-ers. Zeker wanneer het aankomt op de commandline, schieten sommige medewerkers te kort (niet om een helpdesk af te vallen, want ik ben er ook begonnen, maar ik denk dat iedereen op de helpdesk nu wel een naam van een collega in zijn/haar hoofd heeft). Voor grote bedrijven zal een stuk opleiding dus onontbeerlijk zijn. Ik hoop dat in SP1 dit verbetert is en dat er misschien zelfs nog een revisie op de ADUC komt.

High Availability
Het laatste onderwerp waar ik het over wil hebben is High Availability. De meesten van jullie zullen we eens gehoord/gewerkt hebben van/met Exchange op clusters. Mijn ervaring is dat een goede oplossing vaak erg complex om te implementeren en te beheren. In Exchange 2003 had je active-passive multinode clusters en active-active 2node clusters, waarbij gebruik gemaakt werd van shared storage op SAN. In Exchange 2007 heb je nog steeds de mogelijkheid tot multinode active-passive clusters, maar active-active is niet meer mogelijk. Wel hebben ze een nieuwe clusterconcept toegevoegd, namelijk Cluster Continuous Replication. CCR kan opgezet worden als een 2-node active-passive cluster en maakt gebruik van datareplicatie via logshipping om een exacte kopie te maken van de databases op een andere locatie. De active node zal elke 1MB logfile (was voorheen 5MB) versturen naar de passive node, waarna deze hem zal afspelen op zijn kopie van de database. In geval van een storing zal de passive node het werk met zijn eigen kopie overnemen. Deze kopie zal meestal maximaal 1 logfile achterlopen, maar dit wordt deels opgevangen door gebruik te maken van de transportdumpster van de Hub Transport Server. Alle emails die de mailboxserver mist zullen opnieuw verstuurt worden uit deze dumpster, die vaak op een aantal dagen staat ingesteld. Omdat dit een 2-node cluster betreft, maar er geen shared storage is, kan er niet gewerkt worden met een local quorum. Ook een majority node set is niet mogelijk, omdat ze slechts met zijn tweeen in het cluster zitten. Hiervoor heeft Microsoft een update uitgebracht voor de Windows Cluster Service, welke de service uitbreidt met een nieuwe quorumtype, namelijk de 'Majority node set with Fileshare Witness' wat inhoudt dat er een derde server (welke niet onderdeel is van het cluster) is, waar een fileshare wordt gebruikt om de clusterconfiguratiedatabase op bij te houden.
Over het geheel genomen vind ik dit type clustering erg solide, en is in ieder geval heel simpel te installeren. Een kind kan de was doen, zou ik bijna zeggen. Dit in tegenstelling tot clustering bij Exchange 2003. Helaas zitten we bij CCR nog steeds vast aan de limitaties van de Windows cluster service, wat ons nog steeds beperkt, wanneer we denken aan failover tussen meerdere datacentres. De voornaamste limitatie is dat beide nodes in hetzelfde subnet moeten zitten, wat een failover tussen datacentres alleen mogelijk maakt door gebruik te maken van stretched subnets, iets wat bij Netwerkbeheerders de haren overeind doet staan.
Dit zou opgelost moeten zijn met Windows Longhorn. We zullen zien.
Een alternatief voor CCR zal geboden gaan worden met SP1 van Exchange 2007. Hier wordt een nieuw clusterconcept geintroduceerd genaamd Standby Continuous Replication. Wat het precies in gaat houden is nog niet bekend, maar ik hou jullie op de hoogte. Het zou 'Site-resilience' in ieder geval mogelijk moeten maken.
Naast de nieuwe clusterconcepten, introduceert Microsoft ook Local Continuous Replication, wat het mogelijk maakt een exacte kopie van de database elders op te slaan, en een uitbreiding op de backup mogelijkheden, wat het mogelijk maakt backups te trekken (Alleen VSS) van de kopien in een CCR of LCR setup.

Tot Slot
Ik moet zeggen dat ik tot op heden goed te spreken ben over Exchange 2007. Het is stabiel, snel, makkelijk te implementeren en maakt je erg flexibel. Over de tooling ben ik minder positief, maar Microsoft belooft verbetering in SP1. We zullen zien ;)
Mocht je nog vragen en/of opmerkingen hebben, mail dan naar Webmaster ET mpriem PUNT com