In Exchange 2007 wordt er anders omgegaan met recipient policies. Ze heten nu dus ook Email Address Policies (EAP). Waar je voorheen nog de Recipient Update Service had die de recipient policies verwerkte en met enige vertraging emailaddressen stampte op mail(box) enabled objecten, gaat dat nu direct bij het aanmaken van een mail(box) enabled object of bij het aanmaken van een nieuwe EAP.

Een andere verandering bij Exchange 2007 is dat het LDAP filter vervangen is door een OPATH filter, wat het leven makkelijker moet maken. In principe werkt het nog hetzelfde als een LDAP filter alleen hebben ze de | en & tags vervangen door -and en -or en zijn deze tags niet meer opgenomen aan het begin van je geneste scope, maar tussendoor.

Een LDAP filter dat er vroeger zo uit zag:

(&(&(|(&(&(objectCategory=user)(msExchHomeServerName=/o=ORG/ou=SITE/cn=Configuration/cn=Servers/cn=*)))(&(|(objectCategory=group)(objectCategory=msExchDynamicDistributionList))(displayname=IT*)))))

Ziet er nu zo uit:

(ServerLegacyDN -like "/o=ORG/ou=SITE/cn=Configuration/cn=Servers/cn=*" ) -or ( ( RecipientType -eq "MailEnabledUniversalDistributionGroup" –or RecipientType -eq "MailEnabledUniversalSecurityGroup" -or RecipientType -eq "MailEnabledNonUniversalGroup" -or RecipientType -eq "DynamicDL") -and ( DisplayName -like "IT*" ) )

Als je het mij vraagt, maakt het allemaal weinig verschil, maar ze moeten de programmeurs natuurlijk wel wat te programmeren geven ;). Er zit echter wel een addertje onder het gras, zoals je ziet aan de propertynamen. Hier kom ik verderop in de post op terug.

Een nadeel van de nieuwe policystructuur is dat je in Exchange 2003 niet de nieuwe Exchange 2007 policies meer kan bewerken. Vice versa wel. Je moet dan de Exchange 2003 policy 'upgraden' tot Exchange 2007 EAP met het commando:

Set-EmailAddressPolicy "Default Policy" –IncludedRecipients AllRecipients

note: Dit is meteen het juiste commando om je default policy te upgraden

LET OP: Er bestaat ook een -ForceUpgrade parameter voor Set-EmailAddressPolicy. GEBRUIK DEZE NIET!!!
Deze is namelijk alleen bedoelt om een vraag voor confirmatie te onderdrukken. Het vervangt dus niet het filter. Je zult echt de LDAP string moeten ombouwen naar OPATH en deze meegeven bij de 'Upgrade'

De reden dat je een EAP niet kan wijzigen in Exchange 2003 is omdat Exchange 2007 bij het verwerken van de policy gebruik maakt van het RecipientFilter property en Exchange 2003 van het LdapRecipientFilter. Aangezien Exchange 2003 niet kan omgaan met OPATH wordt deze property niet aangepast. Exchange 2007 zal echter wel het LdapRecipientFilter aanpassen.
Wees gerust. Bij het gebruik van Set-EmailAddressPolicy zal de policy niet meteen uitgevoerd worden. Hiervoor moet je gebruik maken van Update-EmailAddressPolicy.

Dit is anders dan bij het aanmaken van nieuwe policies. Bij het maken van nieuwe policies worden de policies meteen applied op alle objecten waar de policy van op toepassing is en waar de EmailAddressPolicyEnabled property op $true staat. GOED testen dus alvorens je het implementeert.

Bij het creeren of wijzigen van een policy kan je gebruik maken van een aantal standaard condities die allemaal met een AND worden gewaardeerd, of van een custom filter (waardes binnen een conditie worden met OR gewaardeerd). De standaard condities zijn de volgende:

-ConditionalCompany
-ConditionalCustomAttribute1 t/m 15
-ConditionalDepartment
-ConditionalStateOrProvince
-IncludedRecipients

Als iets anders wilt, zul je gebruik moeten maken van een OPATH filter en de volgende parameter:

-RecipientFilter

Als je deze gebruikt, mag je geen van de standaard condities meer gebruiken. Voor simpele policies kan je gebruik maken van de standaard condities, maar in de praktijk zit je al snel vast aan een OPATH filter.

Een voorbeeld van een nieuwe policy met standaard condities is de volgende:

New-EmailAddressPolicy -Name:"Test Policy" –IncludedRecipients:AllRecipients -EnabledEmailAddressTemplates:"SMTP:%g.%r .%s@test.com","smtp:@test.com"

Bovenstaand commando maakt een nieuwe policy aan onder de naam "Test Policy" en applied deze op alle mail(box)enabled objecten. Het address template dat gebruikt wordt is een verplicht primair SMTP address met de opmaak voornaam.achternaam@test.com, waarbij alle spaties in de achternaam vervangen zijn door punten, en een secundair SMTP address met de opmaak exchangeallias@test.com".

Voor een overzicht hoe je addresstemplates maakt.. Neem HIER een kijkje.

Een van de meest gebruikte condities is de -IncludedRecipients parameter.
Hierbij geef je het objecttype mee waar de policy op van toepassing is. Hieronder heb ik een overzicht geplaasts van de verschillende types. Je kan zowel de waarde als de waarde naam meegeven als waarde:

Zoals ik al eerder melde zit je al snel aan OPATH filters vast. Het lullige van OPATH filters is dat je niet direct de LDAP naam van het property mag gebruiken en dat ook niet alle LDAP properties van een object beschikbaar zijn. Voor het gemak heb ik het huidige overzicht opgenomen:

Het maken van OPATH filters is verder redelijk gelijk aan de oude LDAP filters behalve dan het verschil in gebruik van operators. In plaats van $ en |, gebruik je -and en -or, en je plaatst ze niet aan het begin van de scope, maar tussen scopes. Dit is eigenlijk zoals je bij veel gebruikte programmeertalen je EN en OF clausules zou opbouwen. Ik zal hier verder niet op ingaan. Oefening baart kunst zeg ik altijd. Maar..... PAS nogmaals op... Een nieuwe policy wordt meteen applied. Het is handiger je OPATH filter te testen, door bijvoorbeeld een Dynamic Distribution Group aan te maken, zodat je kan zien wie de members zijn.

Voor wat basisbegrippen voor het creeren van een OPATH filter kan je hier terecht:
http://technet.microsoft.com/en-us/library/bb124268.aspx

Als je hulp zoekt bij het converteren van je huidige LDAP filters, lees dan dit:
http://msexchangeteam.com/archive/2007/03/12/436983.aspx

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

Heel vaak heb ik een lijstjes moeten genereren van allerlei parameters m.b.t. Active Directory.. Meestal vergeet ik die commando's het moment dat ik ze gebruikt heb. Op de SAPIEN website vond ik een tijdje terug een zeer handige lijst met one-liners, gepost door Jeffery Hicks, die ik voor het gemak ook maar hieronder gepost heb:

FSMO Roles
ntdsutilroles Connections "Connect to server %logonserver%" Quit "selectOperation Target" "List roles for conn server" Quit Quit Quit
Domain Controllers
Nltest /dclist:%userdnsdomain%
Domain Controller IP Configuration
for /f %i in ('dsquery server -domain %userdnsdomain% -o rdn') do psexec \\%i ipconfig /all
Hotfix info
wmic qfe
Stale computer accounts
dsquery computer domainroot -stalepwd 180 -limit 0
Stale user accounts
dsquery user domainroot -stalepwd 180 -limit 0
Disabled user accounts
dsquery user domainroot -disabled -limit 0
AD Database disk usage
for /f %i in ('dsquery server -domain %userdnsdomain% -o rdn') do dir \\%i\admin$\ntds
Global Catalog Servers from DNS
dnscmd %logonserver% /enumrecords %userdnsdomain% _tcp | find /i "3268"
Global Catalog Servers from AD
dsquery * "CN=Configuration,DC=forestRootDomain" -filter "(&(objectCategory=nTDSDSA)(options:1.2.840.113556.1.4.803:=1))"
Users with no logon script
dsquery * domainroot -filter"(&(objectCategory=Person)(objectClass=User)(!scriptPath=*))"-limit 0 -attr sAMAccountName sn givenName pwdLastSet distinguishedName
User accounts with no pwd required
dsquery * domainroot -filter "(&(objectCategory=Person)(objectClass=User)(userAccountControl:1.2.840.113556.1.4.803:=32))"
User accounts with no pwd expiry
dsquery * domainroot -filter"(&(objectCategory=Person)(objectClass=User)(userAccountControl:1.2.840.113556.1.4.803:=65536))"
User accounts that are disabled
dsquery * domainroot -filter "(&(objectCategory=Person)(objectClass=User)(userAccountControl:1.2.840.113556.1.4.803:=2))"
DNS Information
for /f %i in ('dsquery server -domain %userdnsdomain% -o rdn') do dnscmd %i /info
DNS Zone Detailed information
dnscmd /zoneinfo %userdnsdomain%
Garbage Collection and tombstone
dsquery * "cn=Directory Service,cn=WindowsNT,cn=Services,cn=Configuration,DC=forestRootDomain" -attrgarbageCollPeriod tombstoneLifetime
Netsh authorised DHCP Servers
netsh dhcp show server
DSQuery authorised DHCP Servers
Dsquery * "cn=NetServices,cn=Services,cn=Configuration, DC=forestRootDomain" -attr dhcpServers
DHCP server information
netsh dhcp server \\DHCP_SERVER show all
DHCP server dump
netsh dhcp server \\DHCP_SERVER dump
WINS serer information
Netsh wins server \\WINS_SERVER dump
Group Policy Verification Tool
gpotool.exe /checkacl /verbose
AD OU membership
dsquery computer -limit 0
AD OU membership
dsquery user -limit 0
List Service Principal Names
for /f %i in ('dsquery server -domain %userdnsdomain% -o rdn') do setspn -L %i
Compare DC Replica Object Count
dsastat ?s:DC1;DC2;... ?b:Domain ?gcattrs:objectclass ?p:999

Check AD ACLs
acldiag dc=domainTree
NTFRS Replica Sets
for /f %i in ('dsquery server -domain %userdnsdomain% -o rdn') do ntfrsutl sets %i
NTFRS DS View
for /f %i in ('dsquery server -domain %userdnsdomain% -o rdn') do ntfrsutl ds %i
Domain Controllers per site
Dsquery * "CN=Sites,CN=Configuration,DC=forestRootDomain" -filter (objectCategory=Server)
DNS Zones in AD
for /f %i in ('dsquery server -o rdn') do Dsquery * -s %i domainroot -filter (objectCategory=dnsZone)
Enumerate DNS Server Zones
for /f %i in ('dsquery server -o rdn') do dnscmd %i /enumzones
Subnet information
Dsquery subnet ?limit 0
List Organisational Units
Dsquery OU
ACL on all OUs
For /f "delims=|" %i in ('dsquery OU') do acldiag %i
Domain Trusts
nltest /domain_trusts /v
Print DNS Zones
dnscmd DNSServer /zoneprint DNSZone
Active DHCP leases
For /f %i in (DHCPServers.txt) do for /f "delims=- " %j in ('"netshdhcp server \\%i show scope | find /i "active""') do netsh dhcp server\\%i scope %j show clientsv5
DHCP Server Active Scope Info
For /f %i in (DHCPServers.txt) do netsh dhcp server \\%i show scope | find /i "active"
Resolve DHCP clients hostnames
for /f "tokens=1,2,3 delims=," %i in (Output from 'Find Subnets fromDHCP clients') do @for /f "tokens=2 delims=: " %m in ('"nslookup %j |find /i "Name:""') do echo %m,%j,%k,%i
Find two online PCs per subnet
Echo. > TwoClientsPerSubnet.txt & for /f "tokens=1,2,3,4delims=, " %i in ('"find /i "pc" 'Output from Resolve DHCP clientshostnames'"') do for /f "tokens=3 skip=1 delims=: " %m in ('"Find /i /c"%l" TwoClientsPerSubnet.txt"') do If %m LEQ 1 for /f %p in ('"ping -n1 %i | find /i /c "(0% loss""') do If %p==1 Echo %i,%j,%k,%l
AD Subnet and Site Information
dsquery * "CN=Subnets,CN=Sites,CN=Configuration,DC=forestRootDomain" -attr cn siteObject description location

AD Site Information
dsquery * "CN=Sites,CN=Configuration,DC=forestRootDomain" -attr cn description location -filter (objectClass=site)
Printer Queue Objects in AD
dsquery * domainroot -filter "(objectCategory=printQueue)" -limit 0
Group Membership with user details
dsget group "groupDN" -members | dsget user -samid -fn -mi -ln -display -empid -desc -office -tel -email -title -dept -mgr
Total DHCP Scopes
find /i "subnet" "Output from DHCP server information" | find /i "subnet"
Site Links and Cost
dsquery * "CN=Sites,CN=Configuration,DC=forestRootDomain" -attr cn costdescription replInterval siteList -filter (objectClass=siteLink)
Time gpresult
timethis gpresult /v
Check time against Domain
w32tm /monitor /computers:ForestRootPDC
Domain Controller Diagnostics
dcdiag /s:%logonserver% /v /e /c
Domain Replication Bridgeheads
repadmin /bridgeheads
Replication Failures from KCC
repadmin /failcache
Inter-site Topology servers per site
Repadmin /istg * /verbose
Replication latency
repadmin /latency /verbose
Queued replication requests
repadmin /queue *
Show connections for a DC
repadmin /showconn *
Replication summary
Repadmin /replsummary
Show replication partners
repadmin /showrepl * /all
All DCs in the forest
repadmin /viewlist *
ISTG from AD attributes
dsquery * "CN=NTDS Site Settings,CN=siteName,CN=Sites,CN=Configuration,DC=forestRootDomain" -attr interSiteTopologyGenerator
Return the object if KCC Intra/Inter site is disabled for each site
Dsquery site | dsquery * -attr * -filter "(|(Options:1.2.840.113556.1.4.803:=1)(Options:1.2.840.113556.1.4.803:=16))"
Find all connection objects
dsquery * forestRoot -filter (objectCategory=nTDSConnection) ?attr distinguishedName fromServer whenCreated displayName
Find all connection schedules

adfind -b "cn=Configuration,dc=qraps,dc=com,dc=au" -f "objectcategory=ntdsConnection" cn Schedule -csv
Software Information for each server
for /f %i in (Output from 'Domain Controllers') do psinfo \\%i &filever \\%i\admin$\explorer.exe \\%i\admin$\system32\vbscript.dll\\%i\admin$\system32\kernel32.dll \\%i\admin$\system32\wbem\winmgmt.exe\\%i\admin$\system32\oleaut32.dll
Check Terminal Services Delete Temp on Exit flag
For /f %i in (Output from 'Domain Controllers') do Reg query"\\%i\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TerminalServer" /v DeleteTempDirsOnExit
For each XP workstation, query the current site and what Group Policy info
@dsquery * domainroot -filter"(&(objectCategory=Computer)(operatingSystem=Windows XPProfessional))" -limit 0 -attr cn > Workstations.txt & @For /f%i in (Workstations.txt) do @ping %i -n 1 >NUL & @if ErrorLevel0 If NOT ErrorLevel 1 @Echo %i & for /f "tokens=3" %k in ('"regquery "\\%i\hklm\software\microsoft\windows\currentversion\grouppolicy\history" /v DCName | Find /i "DCName""') do @for /f %m in('"nltest /server:%i /dsgetsite | find /i /v "completedsuccessfully""') do @echo %i,%k,%m
Information on existing GPOs
dsquery * "CN=Policies,CN=System,domainRoot" -filter"(objectCategory=groupPolicyContainer)" -attr displayName cnwhenCreated gPCFileSysPath
Copy all Group Policy .pol files
for /f "tokens=1-8 delims=\" %i in ('dir /b /s\\%userdnsdomain%\sysvol\%userdnsdomain%\policies\*.pol') do @echo copy\\%i\%j\%k\%l\%m\%n\%o %m_%n.pol
Domain Controller Netlogon entries
for /f %i in ('dsquery server /o rdn') do echo %i & reg query\\%i\hklm\system\currentcontrolset\services\netlogon\parameters
WINS Statistics
for /f "tokens=1,2 delims=," %i in (WINSServers.txt) do netsh wins server \\%i show statistics
WINS Record counts per server
for /f "tokens=1,2 delims=," %i in (WINSServers.txt) do netsh wins server \\%i show reccount %i
WINS Server Information
for /f "tokens=2 delims=," %i in (WINSServers.txt) do netsh wins server \\%i show info
WINS Server Dump
for /f "tokens=2 delims=," %i in (WINSServers.txt) do netsh wins server \\%i dump
WINS Static Records per Server
netsh wins server \\LocalWINSServer show database servers={} rectype=1
Find policy display name given the GUID
dsquery * "CN=Policies,CN=System,DC=domainRoot" -filter (objectCategory=groupPolicyContainer) -attr Name displayName
Find empty groups
dsquery * -filter "&(objectCategory=group)(!member=*)" -limit 0-attr whenCreated whenChanged groupType sAMAccountNamedistinguishedName memberOf
Find remote NIC bandwidth
wmic /node:%server% path Win32_PerfRawData_Tcpip_NetworkInterface GET Name,CurrentBandwidth
Find remote free physical memory
wmic /node:%Computer% path Win32_OperatingSystem GET FreePhysicalMemory
Find remote system information
SystemInfo /s %Computer%
Disk statistics, including the number of files on the filesystem
chkdsk /i /c

Query IIS web sites
iisweb /s %Server% /query "Default Web Site"
Check port state and connectivity
portqry -n %server% -e %endpoint% -v
Forest/Domain Functional Levels
ldifde -d cn=partitions,cn=configuration,dc=%domain% -r"(|(systemFlags=3)(systemFlags=-2147483648))" -lmsds-behavior-version,dnsroot,ntmixeddomain,NetBIOSName -p subtree -fcon
Forest/Domain Functional Levels
dsquery * cn=partitions,cn=configuration,dc=%domain% -filter"(|(systemFlags=3)(systemFlags=-2147483648))" -attrmsDS-Behavior-Version Name dnsroot ntmixeddomain NetBIOSName
Find the parent of a process
wmic path Win32_Process WHERE Name='notepad.exe' GET Name,ParentProcessId
Lookup SRV records from DNS
nslookup -type=srv _ldap._tcp.dc._msdcs.{domainRoot}
Find when the AD was installed
dsquery * cn=configuration,DC=forestRootDomain -attr whencreated -scope base
Enumerate the trusts from the specified domain
dsquery * "CN=System,DC=domainRoot" -filter "(objectClass=trustedDomain)" -attr trustPartner flatName
Find a DC for each trusted domain
for /f "skip=1" %i in ('"dsquery * CN=System,DC=domainRoot -filter(objectClass=trustedDomain) -attr trustPartner"') do nltest /dsgetdc:%i
Check the notification packages installed on all DCs
for /f %i in ('dsquery server /o rdn') do @for /f "tokens=4" %m in('"reg query\\%i\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa /v"Notification Packages" | find /i "Notification""') do @echo %i,%m
List ACLs in SDDL format
setacl -on %filepath% -ot file -actn list -lst f:sddl
Find out if a user account is currently enabled or disabled
dsquery user DC=%userdnsdomain:.=,DC=% -name %username% | dsget user -disabled -dn
Find servers in the domain
dsquery * domainroot -filter "(&(objectCategory=Computer)(objectClass=Computer)(operatingSystem=*Server*))" -limit 0
Open DS query window
rundll32 dsquery,OpenQueryWindow

Een van de grotere uitdagingen bij het ontwerpen van een Exchange serverinstallatie is storage.
In Exchange 2007 luistert dit welliswaar een stuk minder zwaar, maar het is wel handig om wat meer te weten over hoe Exchange gebruik maakt van de beschikbare storage.

Voordat ik begin met de uitleg, wil ik even melden dat ik geen storage expert ben, en dat er misschien een schoonheidfoutje in mijn uitleg is geslopen. Ik stel het daarom ook zeer op prijs als iemand mij, waar nodig, verbeteringen toestuurt

Zoals je al weet slaat Exchange alle mail op in een database. Het maakt gebruik van de Extensible Storage Engine (ook wel JET-Blue, een doorontwikkelde versie is van de aloude JET engine die Microsoft Access databases aanstuurt), wat hetzelfde database management systeem is als waar Active Directory op draait. De Exchange databases bestaan uit een aantal database bestanden en logfiles. ESE maakt gebruik van log recovery om te herstellen van corruptie in de database. Hierbij worden de logfiles replayed op de database om zo weer een consistente staat terug te keren. Om dit te bereiken wordt elke transactie eerst weggeschreven in een logfile alvorens het gecommit kan worden naar de database. Erg veel I/O dus. Zelfs zo veel dat een database al snel te traag zou worden, en niet meer werkzaam zou zijn als er geen maatregelen genomen zouden worden om de I/O footprint te beperken.
Om de performance op te schroeven, maakt ESE gebruik van een databasecache in het fysieke geheugen, dit is namelijk vele malen sneller dan disk (zoeksnelheid = nanoseconden ipv miliseconden). Via een slim algoritm wordt er geprobeerd de juiste data in het geheugen te houden, want uiteraard kan niet de hele database gecached worden. Dit is zeker het geval voor Exchange 200x, waar we te maken hebben met een limiet van 4GB aan geheugen wat een 32 bits platform kan addresseren. Hiervan is standaard 2GB in gebruik door het besturingssysteem. Via de /3GB en /USERVA switches kunnen we dit beperken tot 1GB, waardoor er 3GB overblijft voor applicaties. De cache was default beperkt tot 900MB, maar kon via het registry opgeschroeft worden naar maximaal 1,2GB. Dit in tegenstelling tot Exchange 2007 welke in principe terabytes kunnen cachen doordat het draait op een 64 bits platform. Aangezien elke transactie eerst veilig naar een logfile wordt geschreven kan er gemakkelijk gewerkt worden met een deel van de database in het geheugen; mocht er immers wat verkeerd gaan, hebben we altijd de logfiles nog. Microsoft adviseert om met Exchange 2007 extra rekening te houden met de cache en je voordeel eruit te trekken. Een simpel ezelsbruggetje voor het schalen van geheugen voor Exchange 2007 is dan ook: 2GB voor Exchange + 2-5MB cache per user. Een 3000 user server heeft dus tussen de 9 en 17GB geheugen nodig. Een ander principe wat hierdoor mogelijk is is 'Checkpoint Depth' wat inhoudt dat er een deel van de logfiles in geheugen gehouden wordt, en met een vertraging naar de database geschreven wordt. Meestal zijn het een aantal logfiles, wat de database achterloopt. Waar is dat nou goed voor zou je denken... nou het bespaart aanzienlijk wat I/O. Doordat Exchange een verzameling transacties in geheugen houdt alvorens het ze wegschrijft naar de database, kan het veelal voordeel halen uit het analyseren ervan. Zo kunnen bepaalde transacties elkaar opheffen en kunnen transacties dusdanig geordend worden dat ze op efficiente manier verwerkt kunnen worden.

Dus door gebruik te maken van cache en checkpoint depth, zorgt Exchange dat het aantal I/O's op de database beperkt blijft. De database I/O's zorgen altijd voor de meeste problemen, omdat deze willekeurig zijn. De schrijfkoppen op je disken zijn continu van de ene kant naar de andere kant aan het verplaatsen. Dit zorgt ervoor dat de gemiddelde seek time (positioneren van de schrijf/lees kop) per I/O vele malen hoger is dan bij logfiles, waar data sequentieel geschreven en gelezen wordt. Dit resulteert in een lager aantal I/O operaties per seconde (IOPS). Door dit verschil in type datatoegang is het raadzaam (ik zeg liever verplicht) om database partities en logpartities fysiek van elkaar te scheiden en dus te hosten op aparte LUNS (logical Units Numbers = diskdevice; hetzij een array, hetzij een drive). Het mixen van willekeurige en sequentiele datatoegang is dodelijk voor je prestaties.

Bij het berekenen van de storage vereisten voor Exchange servers wordt er maar al te graag gerekend in IOPS, en ik zal bij deze uitleg hier ook vanuit gaan. Hoeveel IOPS je nodig hebt is sterk afhankelijk van hoeveel gebruikers je gaat hosten en wat voor soort gebruikers dit zijn. Wanneer je uitgaat van een bestaande Exchange omgeving kan je dit berekenen door het aantal READS en WRITES te delen door het aantal gebruikers. Hierbij kan je gebruik maken van de 'PhysicalDisk\Disk Reads' en 'PhysicalDisk\Disk Writes' (Hierbij ga ik ervanuit dat een enkele LUN OF alleen gebruikt wordt voor Logs OF alleen gebruikt wordt voor Databases. Anders zal je met LogicalDisk counters moeten gaan werken, welke standaard uitgeschakeld zijn.) Een andere methode is door te kijken naar het aantal actieve gebruikers bij piekbelasting. Dit geeft een stuk nauwkeuriger beeld van het echte gebruik. Je kunt de actieve gebruikers zien in de System manager, wanneer je de database opzoekt en kijkt onder Logons. Ook kan je gebruik maken van de 'MSExchangIS\ Active Users' counter, echter deze counter vertekend heel erg als de server ook Public folders bevat, dus ik prefereer de eerste manier. Als je nu het aantal IOPS per user weet in de oude situatie en je vermenigvuldigd het met het aantal mailboxen waarop je de nieuwe databases wilt schalen, plus een extra 20% voor mogelijke groei, dan heb je een redelijk goed uitgangspunt voor de nieuwe situatie.

De formule is dus: ((Gemiddelde Reads/sec + Writes/sec) / (#(actieve)users) * (#users in nieuwe ontwerp)) * 1.2