Just do I(nformation)T(echnology) : 101

Debugging voor dummies

mpriem — Thu, 19 Mar 2009 15:10:59 GMT

Een groot gedeelte van de supportcalls bij premier support heeft te maken met crashes, memory leaks en andere van die voor velen ongrijpbare problemen. In veel gevallen is de oorzaak echter redelijk simpel te achterhalen, en zou je een support call en veel tijd en ergernis kunnen besparen. Het probleem is dat velen niet weten dat je geen die-hard debugger hoeft te zijn om een memory dump te analyseren (ok. Ok. Eerste stap daartoe J.), of een memory leak te traceren.

Je hebt alleen de juiste tools nodig een klein duwtje in de goede richting. Die ga ik je vandaag geven J

Tools

Er zijn een aantal tools die in mijn optiek niet mogen ontbreken in de gereedschapskist van een admin. Dat zijn:

Windows debugging tools: http://www.microsoft.com/whdc/DevTools/Debugging/default.mspx
DebugDiag 1.1: http://www.microsoft.com/downloadS/details.aspx?FamilyID=28bd5941-c458-46f1-b24d-f60151d875a3&displaylang=en

De installatie spreekt voor zich, dus daar ga ik jullie niet mee vervelen, echter voor de debugger die we gaan gebruiken (WinDBG) is het aan te raden een symbolserver te configureren (http://www.microsoft.com/whdc/DevTools/Debugging/debugstart.mspx) . In principe is dat voor deze eerste stapjes in de wereld van debugging nog niet nodig, maar ik zou het niet laten, daar het je toch net even wat meer inzicht geeft in wat er precies gebeurd onder de motorkap. Ik prefereer de Environmental Variable, aangezien deze door veel debugtools automatisch wordt opgepakt.

Introductie

In deze post ga ik drie type scenario's behandelen. Dat zijn:

Eerste analyse van een kerneldump, naar aanleiding van een crash/BSOD (Blue-Screen-Of-Death).
Troubleshooten van usermode crashes.
Troubleshooten van memorydumps.

Voordat we daaraan beginnen zal ik toch een klein stukje theorie moeten behandelen, om een en ander duidelijk te maken.
Moderne CPU architecturen hebben verschillende modi waarin zij opereren. Deze noemen we ook wel Rings (er zijn nog tig andere benamingen). Deze modi stellen een ontwikkelaar in staat bepaalde functionaliteit van de CPU architectuur niet toe te staan voor de code die op dat moment wordt uitgevoerd. Denk hierbij aan toegang tot bepaalde CPU registers of onderdelen van het geheugen. Dit om de stabiliteit en veiligheid van het systeem te waarborgen. In Windows NT besturingssystemen (Alles behalve 3.*, 9* en ME) maken we gebruik van 2 van deze modi, namelijk de modus waarin alles is toegestaan, welke wij 'Kernelmode' noemen (Ring 0) en een modus waarin toegang tot hardwareresources beperkt worden, welke wij 'Usermode' noemen (Ring 3; in x86 en x64 architecturen zijn het er 3 (Ring 1,2,3), maar Windows gebruikt alleen de meest beperkte). De structuur van Windows zorgt ervoor dat eigenlijk alleen code die hoort bij het operating system in Kernelmode mag draaien. Er zijn wat uitzonderingen, waarvan drivers de meest belangrijke zijn.
Code wat in Kernelmode draait heeft dus onbeperkt toegang tot systeemresources, en kan dus ook geheugen structuren veranderen van andere processen, wat kan leiden tot datacorruptie, dataloss en een instabiel systeem. Windows beschermt zich hiertegen door in dergelijke gevallen op de noodknop te drukken en het systeem te stoppen of bugchecken met een BSOD. Wij noemen dit een crash, maar het is eigenlijk Windows die je redt van nog grotere problemen. Windows zal dan op basis van de instellingen wel of niet een dump maken van het kernelgeheugen. Dit heb je niet voor usermode processen.
Code wat in Usermode draait heeft dus beperkte toegang tot systeemresources. Zo heeft het alleen toegang tot geheugenbereik dat het proces toegewezen heeft gekregen en dient het toegang tot hardware aan te vragen bij het operating system. Qua performance lever je hierdoor wel wat in, maar bijkomend voordeel is dat het ene proces niet zo makkelijk een ander proces om zeep kan helpen, laat staan een BSOD kan veroorzaken, en je een verhoogde mate van veiligheid hebt, doordat geheugenstructuren van het ene proces niet uit te lezen zijn door het andere proces.

Waarom is deze informatie nu belangrijk?

Voor deze post om twee redenen:
Enerzijds is het belangrijk om te weten dat een BSOD dus in bijna alle gevallen veroorzaakt wordt door OF een bug in het operating system, OF een driver.
9 van de 10 keer zal het gaan om een driver.
Anderzijds is het belangrijk om te begrijpen dat het analyseren van een usermode crash anders is dan het analyseren van een kernelmode crash. Bij een kernmode crash heb je vaak de beschikking over een volledige dump van het geheugen. Bij usermode crashes, moet je memorydumps zelf generen en verzamelen.

Blue Screen of Death – BSOD

Wanneer een systeem geplaagd wordt door BSODs is de eerste plaats waar je gaat kijken de memorydump. Ik ben van mening dat elk systeem geconfigureerd moet zijn om een volledige dump te maken, daar in de volledige dump de meeste informatie staat. Je kan met een MiniDump soms ook wel af, maar meestal zal een support engineer vragen om de volledige dump. Ik neem aan dat je jouw systeem niet nogmaals wilt laten crashen met alle gevolgen van dien voor de data en uiteindelijk de business. Opties voor het maken van een memorydump kan je vinden op http://support.microsoft.com/kb/254649/en-us

Verder adviseer ik mijn klanten altijd, dat als er een memorydump heeft plaatsgevonden, deze veilig te stellen. Een volgende dump overschrijft deze namelijk. Meerdere dumps is handig daar de oorzaak van de crash niet altijd meteen duidelijk is. Helaas is dit vaak het geval. Het kan namelijk zijn dat de veroorzaker van de crash allang uit het geheugen is verdwenen, voordat het systeem struikelt over het probleem dat deze code veroorzaakt heeft. Door meerdere dumps te analyseren kan je soms correlaties trekken, en zo tot een conclusie komen.

Goed… We hebben een crash gehad en we hebben een memory dump. What's next??

We starten WinDBG en openen de memory dump. Deze dump is standaard te vinden op %SystemRoot%\Memory.dmp. Je kan uiteraard de memory dump naar een andere machine kopiëren en hem daar analyseren:

Nu je de memorydump geopend hebt, zal WinDBG de dump snel analyseren. Dit levert al vaak meteen waardevolle informatie op, zoals je kan zien op de analyse van 1 van mijn recente dumps:

Probably caused by : rismcx64.sys … Schijnbaar geeft WinDBG rismcx64.sys de schuld. Een korte blik in mijn drivers, gaf aan dat het om een smartcard driver ging uit 2006. Even een bezoekje aan de Windows Update en de vendor website en voila.. Nieuwe drivers. Sindsdien heb ik die crash nooit meer gehad.

Nu kan je WinDBG een verbose output laten zien van deze analyse, waar je vaak ook wel wat aan hebt. Dit doe je door !analyze –v uit te voeren. De output laat dan bijvoorbeeld ook de stacktrace zien, die je een idee kan geven, van wat het systeem op dat moment aan het doen was:

Je leest een stacktrace altijd van onder naar boven. In mijn dump was windows duidelijk bezig met het afhandelen van een IO request richting mijn smartcard device, te zien aan termen als IopXxxControlFile, NTDeviceIoControlFile en andere IO routines. Verder zie je verwijzingen naar Wdf modules wat staat voor Windows Driver Foundation. Deze informatie kan ik zien doordat ik WinDBG geconfigureerd heb om de public symbols van de Microsoft SymbolServer te halen. Zonder symbols ziet de output er anders uit.

Een hele hoop van de functienamen zijn weggevallen. Hierdoor is het lastig in 1 oogopslag te bepalen of de modules behoren tot het besturingssysteem of niet. Ik kijk altijd even naar de stacktrace. Je kan bijvoorbeeld zien of er nog andere 3rd party modules zijn die rond die tijd acties aan het uitvoeren zijn geweest. Deze kan je dan vervolgens eveneens aan een grondig onderzoek onderwerpen.

Zo zie je… In een aantal simpele stappen kan je al snel wat zaken uitzoeken en proberen voordat je een case aanmeldt om een BSOD te laten onderzoeken.

User mode crash

Voor usermode crashes heb je standaard geen memory dumps. Echter je kan een debugger attachen aan een proces en een memory dump laten generen op het moment dat deze klapt. In de debugging tools kan dat op verschillende manieren, maar ik gebruik eigenlijk altijd DebugDiag, wat een schil rondom de debuggers uit de debugging tools is.

In mijn geval crashed een application pool regelmatig. Ik start dus debugdiag en kies voor de 'Crash' optie (een Hang is niet hetzelfde als een crash):

Vervolgens kan ik twee kanten op. Ik kan kiezen voor een proces, en selecteer gewoon het juiste w3wp.exe proces, of ik kies voor Application Pool. Dit is uiteraard eenvoudiger dus doe ik dat:

Vervolgens kies ik de application pool, en krijg ik de mogelijkheid om advanced opties mee te geven, zoals op welke Exceptions debugdiag moet reageren. Ik selecteer gewoon de standaard opties, daar dat in de meeste gevallen voldoende is.

Uiteindelijk kies ik Next > Next > Activate Rule.

Als dan vervolgens het proces klapt, maakt DebugDiag een memory dump, welke geanalyseerd kan worden. Na een paar keer mijn webapplicatie te hebben geprobeerd te starten, had ik 3 memory dumps:

Ik kan dan vervolgens kiezen om de data te laten analyseren door Analyze Data te selecteren. Na een tijdje door de dumps te hebben gewroet, laat DebugDiag een rapport zien met de bevindingen. In de meeste gevallen kan je dat rapport gebruiken om verder onderzoek te plegen. In mijn geval wist ik wat het probleem was, daar ik zelf een kapotte ISAPI filter had gebakken om demo's van DebugDiag te geven. Het rapport laat daarom ook netjes zien dat mijn UpCaseStackOverflow.dll filter het probleem heeft veroorzaakt.

Memory Leaks

Memory Leaks worden vaak gezien als zeer lastige problemen om te analyseren, maar met de juiste tools valt dat best mee. Ook hier gebruik ik meestal DebugDiag voor. Je start DebugDiag en kiest voor Memory and Handle Leak. Vervolgens kies je het proces waaraan je de debugger wilt koppelen. Het valt hier op dat we nu niet de keuze hebben om een Application pool te kiezen. Als je nu meerdere application pools hebt, en deze ook nog eens onder hetzelfde application pool account draait, lijkt het lastig deze processen te onderscheiden. Gelukkig is er een redelijk makkelijke manier om erachter te komen om welke application pool het gaat. Je scrolled helemaal naar rechts in het DebugDiag window en controlleert de commandline kolom. Dit bevat de naam van de application pool:

Je dient vervolgens aan te geven wanneer er precies een Memory dump gemaakt moet worden. Dit kan na een bepaalde tijd, maar vaak is het handiger een maximum aantal MB's aan te geven. Dit doe je door te kiezen voor Configure in de Userdump generation sectie:

Ik kies hier meestal voor Virtual Bytes, omdat Private Bytes daar een subset van is. Virtual Bytes is namelijk het aantal bytes dat het proces gealloceerd heeft binnen het Virtual Address Space van het proces. Private Bytes is het geheugen dat gealloceerd is dat exclusief te benaderen is door het proces. Wanneer een proces namelijk een module laadt met shareable data (code afhankelijk dus), die al geladen is door een ander proces, wordt deze niet nogmaals in het geheugen geladen, maar gedeeld door processen. Dit geheugen wordt gemapped naar het proces. De virtual bytes geven vervolgens aan dat het proces het aantal bytes voor die module gealloceerd heeft, maar fysiek is er geen extra geheugen gebruikt. Deze shareable bytes zie je dus ook niet terug in de Private Bytes.

Om te bepalen wanneer een memory dump te maken, zal je monitoring moeten inregelen. Dit kan door System Monitor (perfmon) te gebruiken en de Private Bytes en Virtual Bytes van het systeem en processen te monitoren.

Als laatste selecteer ik weer Next > Next > Activate Rule en kan het wachten beginnen.
Zodra er weer een memorydump is gemaakt, kies je wederom voor Analyze Data en Voila… een rapport.

Net als bij de Usermode Crash, was het in mijn geval wederom een zelf geschreven ISAPI filter, met ditmaal een memory leak. Het rapport laat ook netjes zien dat er een module UpCaseLeak.dll is in mijn w3wp.exe proces die aardig wat geheugen heeft gealloceerd. In dit geval heeft DebugDiag te kort gelopen om echt een harde analyse te doen, maar je snapt waar dit heengaat.

Zo zie je… Debugging is niet alleen voor code junkies, maar iedereen kan een aantal basis stappen zetten, die in veel gevallen al tot de oorzaak van het probleem kunnen leiden!

Exchange 2007 101

mpriem — Thu, 19 Apr 2007 12:13:00 GMT

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