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

Microsoft heeft een closed beta van SP1 vrijgegeven voor Technet en MSDN abonnees.
De release notes zijn HIER te vinden....

Later deze week zal ik ingaan op de inhoud van SP1

De eerste patches voor Exchange 2007 zijn beschikbaar. Helaas zijn ze alleen verkrijgbaar voor de 64 bits versie, waardoor 32 bits VM's niet gepatched kunnen worden...

De rollup omvat fixes voor:

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

Een tijdje geleden zag ik een heel leuk artikel over Shared hosting van meerdere bedrijven in 1 Exchange organisatie. Ik wilde jullie dat niet onthouden..

Hierbij de links van deel 1 en 2

Veel plezier!