Exchange themablog
RSSHoe zit het met een legacy redirection icm ISA als reverse proxy?
De huidige situatie bij het bedrijf Virtuall
We nemen even als voorbeeld het bedrijf Virtuall. Virtuall heeft 500 werknemers, deze 500 werknemers maken allen gebruik van Outlook Web Access op Exchange 2003. De gebruikers benaderen de Exchange 2003 Outlook Web Access functionaliteit middels de url https://webmail.virtuall.nl/exchange.
Virtuall heeft besloten om de huidige Exchange 2003 omgeving te migreren naar Exchange 2010 (binnen hetzelfde domein). Er is besloten om de gebruikers in twee shifts te migreren omdat Virtuall de gemigreerde gebruikers maximaal wil kunnen ondersteunen. Uitgangspunt voor de migratie is wel dat alle gebruikers gemigreerd of niet, gebruik kunnen maken van de URL https://webmail.virtuall.nl/. Voor het publiceren van de Exchange 2003 webdiensten gebruikt Virtuall het product ISA 2006. De ISA 2006 server wordt niet vervangen.
De Legacy URL
Om alle gebruikers deze zogenaamde single namespace te bieden dienen we binnen Exchange 2010 de legacy URL te configureren. Door het configureren van een legacy URL worden gebruikers die middels https://webmail.virtuall.nl/ uitkomen op de Exchange 2010 CAS server maar nog een mailbox hebben op de Exchange 2003 server automatisch ge-redirect. De bestaande URL https://webmail.virtuall.nl/ laten we verwijzen naar de Exchange 2010 CAS server door het DNS A-record voor webmail te wijzigen. Zodra deze wijziging is doorgevoerd maken we een nieuw DNS A-record voor legacy (in de DNS zone voor Virtuall.nl). Dit laatste DNS record verwijzen we naar de Exchange 2003 server. In deze situatie ga ik er gemakshalve even vanuit dat de installatie van de CAS server al gedaan is en dat tijdens de installatie aangegeven is dat de Client Acces rol naar het internet gepubliceerd wordt middels webmail.virtuall.nl. Ok, na het aanmaken van een DNS record voor legacy.virtuall.nl gaan we de nodige configuratie op de Exchange 2010 CAS server doen. Op een willekeurige Exchange 2010 server openen we de Exchange management shell en voeren daarin de volgende commando’s uit:
- Set-OWAVirtualDirectory CASSERVER01\OWA –Exchange2003URL https://legacy.virtuall.nl/exchange
Let op dat je op de Exchange 2003 server Form based authentication inschakeld om single-sign on mogelijk te maken!
Een belangrijk aandachtspunt tijdens deze transitieperiode is het gebruik van certificaten. Het SSL certificaat dat door de client gebruikt wordt moet gewijzigd worden omdat er een nieuwe URL geïntroduceerd is: legacy.virtuall.nl. Deze URL moet toegevoegd worden aan het certificaat. Overigens heeft Ilse van Criekinge een handige video gemaakt hoe je zo’n certificaat aanvraag maakt.
Schematisch ziet het redirecten er als volgt uit (let op dat hier de ISA server even is weggelaten):
Zoals al gezegd is de ISA server hier weggelaten maar wat gebeurt er nu wanneer we de ISA server aan het plaatje gaan toevoegen? Waar moeten we dan allemaal rekening mee houden?
De ISA configuratie aanpassen
ISA 2006 SP1 heeft nog geen wizard voor het maken van web publishing rules ten behoeve van Exchange 2010 (wel voor Exchange 2007 en Exchange 2003). We moeten dus gaan sleutelen in ISA. Naast het aanmaken van de nodige web publishing rules moeten we niet vergeten dat er een URL aan het certificaat is toegevoegd (legacy.virtuall.nl). Dit certificaat moet ook geïmporteerd worden in ISA.
Het is aan te raden een zogenaamde CAS web farm te definiëren binnen ISA. Binnen zo’n web farm voeg je dan alle CAS servers toe. ISA kan dan load balancing toe passen op alle CAS servers in deze web farm. Daarnaast zal uitval van een CAS server niet gelijk problematisch zijn om dat de ISA server dan een andere server uit de farm zal aanspreken. Wanneer je op een later tijdstip bijvoorbeeld web publishing rules moet aanmaken dan kun je eenvoudig verwijzen naar de aangemaakte farm.
Outlook Web App publiceren
Voor Outlook Web App moet nu een web publishing rule worden aangemaakt. Deze rule publiceert de webdienst Outlook Web App via ISA naar het internet toe. Vanuit de taakbalk kun je gewoon kiezen voor ‘Publish Exchange Web Client Access’. Zodra je een versie moet kiezen selecteer je ‘Exchange Server 2007’. Kies voor de optie ‘Publish a server farm of load balanced Web servers’. Verwijs in de wizard vervolgens naar je CAS web farm die je hebt aangemaakt. Geef vervolgens de interne en externe URL op waarop Outlook Web App te bereiken is (webmail.virtuall.nl).
Tijdens deze wizard krijgen we de mogelijkheid om een nieuwe web listener te maken. Kies voor deze optie en laat de optie ‘Require SSL secured connection with clients’ aangevinkt staan. Selecteer de externe interface waarop de ISA server moet gaan luisteren voor de betrefende URL en last but not least verwijs je naar het nieuw geimporteerde certificaat.
We hebben nu de ISA server zover dat hij luistert naar verzoeken die binnenkomen voor https://webmail.virtuall.nl. Vervolgens publiceert ISA, Outlook Web App aan de client op het internet. Wat nu als er een redirection moet plaatsvinden naar legacy.virtuall.nl omdat de gebruiker nog een mailbox heeft in de Exchange 2003 omgeving?
Legacy URL publiceren
Ook voor legacy.virtuall.nl moeten we in ISA een web publishing rule aanmaken. Een aparte web listener is niet nodig want de client zal verbinding maken met http(s)://webmail.virtuall.nl. Deze wordt afgevangen door de web listener die in de vorige stap is aangemaakt. ISA stuurt het verzoek door naar de Exchange 2010 CAS server. Deze Exchange 2010 CAS server doet op zijn beurt een query in Active Directory en zal constateren dat de mailbox op een Exchange 2003 server staat. De URL die nodig is om deze mailbox te benaderen wordt terug gegeven aan de ISA server (http(s)://legacy.virtuall.nl). De ISA server geeft deze URL vervolgens weer als antwoord aan de client terug.
Om de publishing rule aan te maken voor legacy.virtuall.nl nemen we de volgende stappen:
- We kiezen weer voor de optie ‘Publish Exchange Web Client Access’
- Na het opgeven van een naam kiezen we bij Exchange version voor Exchange Server 2003 en selecteren ‘Outlook Web Access’.
- We kiezen uiteraard voor SSL en geven de interne en externe URL op (legacy.virtuall.nl).
- Bij de volgende stap selecteren we de Exchange 2003 server en vervolgens de web listener die we bij de vorige publishing rule hebben aangemaakt.
- Maak als laatste de keuzes voor authenticatie en welke gebruikers deze dienst mogen gebruiken.
Overschakelen naar de nieuwe publishing rules
Zodra de nieuwe publishing rules zijn geconfigureerd kunnen ze worden geactiveerd. Na het activeren van de nieuwe regels kunnen de “oude” Exchange 2003 publishing rules uitgeschakeld worden. Werkt alles naar behoren dan kunnen vervolgens de “oude” Exchange 2003 pubishing rules worden opgeruimd.
Door bovenstaande te hebben uitgevoerd ziet het plaatje er als volgt uit:
Ik hoop dat door middel van deze post duidelijk is geworden waar je aan moet denken als je gaat migreren naar Exchange 2010 en je gebruikt een ISA server voor het publiceren van de webdiensten.
Veel succes met de migratie!
Sander van den Burg overleden
In de nacht van vrijdag 12 februari op zaterdag 13 februari is Sander van den Burg overleden. Dit gebeurde volkomen onverwacht en zonder directe aanleiding.Vorige week dinsdag was hij nog op de NGN Exchange middag aanwezig als Expert. Sommigen van de Exchange Themablog kenden hem als collega of als teamgenoot bij verschillende projecten. Anderen hebben hem dinsdag pas voor het eerst ontmoet. Allemaal zijn we geschrokken van de plotselinge dood van zo'n aardige kerel.
Onze gedachten gaan uit naar zijn vrouw, vrienden en familie. Sander is 31 jaar geworden en wordt vrijdag 19 februari begraven.
Exchange 2010 en Information Rights Management
Om het risico te verlagen dat informatie gelekt kan worden heeft Microsoft Information Rights Management (IRM) geïntroduceerd. IRM gebruiken i.c.m. Exchange is al mogelijk vanaf Exchange 2003 maar wat is er nu allemaal veranderd wanneer je het wil gebruiken i.c.m. Exchange 2010?
In dit artikel leg ik uit wat je met IRM kunt doen en wat de mogelijkheden zijn met Exchange 2010.
Wat is IRM?
| NGN Evenement |
| "Exchange Middag"
op 9 februari
Je kan je hier inschrijven Johan Veldhuis zal hier als 'Ask the Expert' en als spreker aanwezig zijn |
| Leden gratis,-, Niet-leden €75,-
Lid worden kan hier |
- Financiële schade, een bedrijf kan inkomsten mislopen
- Imago beschadiging, een bedrijf kan in diskrediet gebracht worden wanneer verkeerde informatie uitlekt.
- Zakelijke schade, bijvoorbeeld een overname van een concurrent welke vroegtijdig uitlekt.
Het client gedeelte zit voor een deel verwerkt in het OS en voor een ander deel in de applicatie(s). Windows Vista en 7 bevatten deze client standaard voor Windows XP en Windows 2000 dien je eerst de client te downloaden en te installeren. Wanneer je bijvoorbeeld naar het Office pakket kijkt dan zul je, wanneer ADRMS aanwezig is binnen de Active Directory, onder voorbereiden, XXXXXXXXXX vinden. Hier kan een gebruiker kiezen om zelf de beveiligingsinstellingen in te stellen of dit middels de vooraf gedefinieerde templates te doen. Een beheerder kan er voor kiezen vooraf gedefinieerde templates te maken zodat gebruikers makkelijk documenten kunnen beveiligen met deze templates.
Maar nu zul je je afvragen wat kan ik dan aan een document of e-mail beveiligen? Onderstaand een overzicht met de mogelijkheden:
- Doorsturen
- Printen
- Bewerken
- Faxen
- Kopiëren
- Opslaan
Exchange en IRM
Vanaf Exchange 2007 Service Pack 1 is het mogelijk om de prelicensing agent te gebruiken om berichten automatisch te versleutelen. D.m.v. deze prelicensing agent wordt het mogelijk voor gebruikers om versleutelde berichten te openen middels Outlook zonder zich te hoeven authenticeren richting de ADRMS server. Dit maakt het mogelijk om versleutelde berichten ook offline te lezen. Deze agent bevindt zich op elke Hub Transport server binnen de Exchange omgeving maar is in Exchange 2007 standaard uitgeschakeld, in Exchange 2010 is de agent automatisch ingeschakeld.In Exchange 2010 zijn er echter een aantal nieuwe features om IRM te gebruiken:
- IRM ondersteuning voor OWA, dit geeft de mogelijkheid voor gebruikers om berichten ook te beveiligen wanneer berichten worden verstuurd vanuit OWA.
- Protected UM, biedt de mogelijkheid om voicemail berichten welke worden afgeleverd door de Exchange UM rol te beveiligen middels IRM.
- Transport decryption, dit maakt het mogelijk om berichten te ontsleutelen zodat een virusscanner/spam oplossing het bericht kan controleren en dit vervolgens weer beveiligd door kan sturen.
- Journal decryption, het kan zijn dat een bedrijf ervoor kiest om Journaling in te schakelen, dit maakt het natuurlijk wel wat lastiger i.c.m. IRM. In Exchange 2010 is het mogelijk een bericht te versturen naar een Journal box en hier zowel een versleutelde als ontsleutelde versie te bewaren.
- Search decryption, maakt het mogelijk om berichten te ontsleutelen voor content indexing, hiermee wordt het mogelijk om ook een discovery search ook uit te voeren op versleutelde berichten.
- Automatic e-mail protection, deze feature werkt alleen in combinatie met Outlook 2010 en beveiligd een bericht automatisch. De gebruiker zal hiervan op de hoogte worden gebracht middels een melding bovenaan in het scherm.
| Commando | Uitleg |
| Set-OwaMailboxPolicy –IRMEnabled $true | Zorgt ervoor dat IRM ingeschakeld wordt in de OWA Mailbox policy. Het is bijvoorbeeld mogelijk dit voor bepaalde gebruikers uit te schakelen en slechts voor een selecte groep gebruikers beschikbaar te stellen. |
| Set-OwaVirtualDirectory – IRMEnabled $true | Zorgt ervoor dat IRM gebruik in OWA wordt toegelaten. |
| Set-IRMConfiguration –OWAEnabled $true | Schakelt IRM gebruik voor OWA in, standaard is deze optie ingeschakeld. |
| Set-IRMConfiguration –SearchEnabled $true | Wanneer dit commando wordt gebruikt wordt toegestaan dat IRM beveiligde berichten wel doorzocht kunnen worden m.b.v. een discovery |
| Set-IRMConfiguration – TransportDecryptionSetting $true | Met deze waarde kan de configuratie van transport decryptie ingesteld
worden:
|
| Set-IRMConfiguration – JournalDecryptionEnabled $true | Hiermee kan ingesteld worden of er een niet geëncrypte versie naast de encrypte versie wordt opgeslagen in de journal mailbox. |
| Set-IRMConfiguration –InternalLicensingEnabled $true | Schakelt IRM gebruik in voor interne berichten. Standaard zal IRM namelijk niks doen met berichen welke naar gebruikers binnen de Exchange omgeving worden verstuurd. |
| Set-IRMConfiguration – ExternalLicensingEnabled $true | Schakelt IRM gebruik in voor externe berichten. Standaard worden berichten welke naar gebruikers buiten de Exchange omgeving worden verstuurd niet versleuteld. |
Wanneer je alleen van plan bent om interne berichten te beveiligen middels IRM is het uitvoeren van onderstaande commando’s voldoende:
Get-OwaMailboxPolicy | Set-OwaMailboxPolicy –IRMEnabled $true
Get-OwaMailboxPolicy | Set-OwaVirtualDirectory – IRMEnabled $true
Set-IRMConfiguration –OWAEnabled $true
Set-IRMConfiguration –SearchEnabled $true
Set-IRMConfiguration –InternalLicensingEnabled $true
Mocht je een liever alle commando’s in één keer uit willen voeren kopieer dan bovenstaande regels even in Notepad en sla dit op als een PS1 bestand. Wanneer je nu Outlook Web Apps opent zul je zien dat er een extra optie bij is gekomen wanneer je een nieuw bericht maakt:
In bovenstaande afbeelding is te zien dat er een aantal categorieën beschikbaar zijn. Alleen de no restriction en do not forward templates zijn standaard, de overige drie zijn templates heb ik zelf aangemaakt in ADRMS.
Stel dat we dit bericht nu verzenden met de do not forward template geselecteerd wat krijgt een ontvanger dan te zien ?
Wanneer we in de mailbox van de ontvanger kijken met bijvoorbeeld Outlook dan zien we dat het het standaard mail icoontje is veranderd en dat er bovenaan de mail een omschrijving staat van de template.
De template die nu is toegepast zal voorkomen dat deze gebruiker dit mailtje door kan sturen naar andere personen.
In Exchange 2010 is het mogelijk om transport rules automatisch RMS templates toe te laten passen aan de hand van kenmerken van mails. Deze regels kunnen zowel via de Exchange Management Console als Exchange Management Shell aangemaakt worden. Met bijvoorbeeld onderstaand Powershell commando maken we een regel aan:
New-TransportRule -Name "Protect mails with bankaccountnumbers" -SubjectOrBodyMatchesPatterns"\w\w\w\w\w\w\w\w" -ApplyRightsProtectionTemplate "Do Not Forward"
Deze regel zal op elk bericht met daarin een bankrekeningnummer beveiligen met de Do Not Forward template.
Outlook 2010 bevat een nieuwe feature welke het mogelijk maakt voordat het bericht wordt verzonden het bericht automatisch te beveiligen. Outlook maakt hierbij gebruik van een kleine rule engine, deze regels worden opgehaald door de Exchange Web Services (EWS) site te benaderen op de CAS server.
Aan de hand van bijvoorbeeld de afzender en ontvanger wordt een transport rule toegepast welke op zijn beurt weer een RMS template toepast.
Wel nodig?
Veel bedrijven en mensen zullen zich afvragen of het wel nodig is om dit soort beveiligingsmaatregelen te nemen. In Amerika zie je dat ADRMS al veel meer in gebruik is dan in Nederland. Hoogstwaarschijnlijk komt dat door alle regelgeving die daar geldt bijvoorbeeld Sarbanes Oxley. Zolang dit soort regels in Nederland nog niet van toepassing zijn is de vraag maar of je dit in Nederland veel tegen zal komen. Daarnaast zullen naast de technische maatregelen die je treft ook organisatorische maatregelen genomen moeten worden. Het management van het bedrijf moet namelijk wel achter deze maatregelen staan. Als dit niet het geval is dan heeft het inzetten van dit soort oplossingen geen/weinig effekt.Outlook cachen van een gesharede mailbox
Een vaak gehoorde vraag van gebruikers is: "Hoe kan ik de gesharede mailboxen die ik geopend heb in outlook, ook in offline mode nog gebruiken?"Deze vraag kreeg ik recent ook weer te horen, dit is middels een registry/policy wijziging mogelijk. Microsoft heeft dit beschreven in een knowledge base artikel. Echter wordt hier verwezen naar een registry key "Cached Mode", op mijn systeem was deze niet aanwezig.
Na de key en value toe te voegen, werkte deze cached mode prima.
De stappen zijn dus als volgt.
| NGN Evenement |
| "Exchange Middag"
op 9 februari
Je kan je hier inschrijven Kay Sellenrode zal hier als 'Ask the Expert' en als spreker aanwezig zijn |
| Leden gratis,-, Niet-leden €75,-
Lid worden kan hier |
- Ga naar HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\ of HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\12.0\Outlook.
- Indien de key "Cached Mode" aanwezig is open deze, anders dient deze aangemaakt te worden.
- Maak vervolgens de DWORD value "CacheOthersMail" aan en geef deze een waarde van 1.
- Herstart Outlook en controleer via "Bestand – cached exchange mode" of alleen “download volledige items” aangevinkt staat.
- Hierna worden alle mail items uit gedeelde mappen gecached.
Let echter wel op dat alles in dezelfde OST wordt gezet, Office 2007 met SP2 kan prima omgaan met grote ost/pst’s echter zijn er natuurlijk limieten.
Tot 10 GB zal je weinig problemen ervaren, hierboven zal je af en toe last hebben van pauzes binnen outlook en boven de 25 GB zal het zeer regelmatig voorkomen dat outlook pauzeert.
Exchange 2010 en archiving
Dit artikel gaat dieper in op deze archiving mogelijkheden en informeert je over de ins- en outs van deze feature.
3rd Party Archiving
Archiving bestaat al een tijd en was vooral in Exchange 2003 populair omdat het de mogelijkheid bood om de altijd maar groeiende mailbox databases enigszins handelbaar te houden. (De gemiddelde opslagcapaciteit groeit ongeveer 30% per jaar, met e-mail als belangrijkste veroorzaker. De gemiddelde gebruiker verstuurt en ontvangt ~20MB mail per dag).Met deze getallen is het logisch dat een archiveringsoplossing verlichting biedt. Voor de komst van Exchange 2010 was het alleen mogelijk om via third-party oplossingen (Symantec Enterprise Vault, Commvault) te archiveren. Met de komst van Exchange 2010 zien deze bedrijven een belangrijke concurrent in de vorm van Microsoft zelf verschijnen in archiveringsland. Deze zelfde beweging hebben we natuurlijk eerder gezien met Hyper-V (VMware) en Remote Desktop Services (Citrix).
| NGN Evenement |
| "Exchange Middag"
op 9 februari
Je kan je hier inschrijven Sander van den Burg zal hier als 'Ask the Expert' aanwezig zijn |
| Leden gratis,-, Niet-leden €75,-
Lid worden kan hier |
Op dit moment biedt de Microsoft oplossing wel archiving, maar kent deze nog een aantal belangrijke beperkingen. Zo is het alleen mogelijk om een archive mailbox aan te maken binnen de zelfde mailbox database als de normale mailbox. Het verplaatsen naar 2nd-tier –goedkopere- storage is dus (nog) niet mogelijk. Het benaderen van de archive mailbox is daarbij alleen mogelijk vanuit een Outlook 2010 client (of via Outlook Web Access). De volledige Outlook 2010 client is nog niet beschikbaar en Outlook 2007 wordt niet ondersteund.
De huidige third-party archiving oplossingen zoals o.a. Symantec Enterprise Vault, Commvault of GFI baseren zich natuurlijk vooral op het plaatsen van archives op goedkopere storage terwijl Exchange dat native niet doet.
DAG
De oplossing vanuit Exchange is simpel: DAG. Doormiddel van Database Availability Groups is het mogelijk om (eenvoudig) databases in meerdere kopieën op SATA schijven kan zetten die dus veel minder kosten. Hierdoor is het mogelijk om goedkope storage in te zetten en verdwijnt de noodzaak om archivering om deze redenen in te zetten.Hier komt nog bij dat het Exchange team erin geslaagd is een +90% I/O reductie te realiseren tov Exchange 2003 (en een 70% reductie tov Exchange 2007) met oplossingen als sequentiële I/O en het toepassen van database compressie.
Dit hele begrip heeft tijd nodig om in de markt te landen. Men is nog veel te druk bezig met RAID sets en SAN oplossingen voor het hosten van Exchange databases, terwijl DAG misschien net zo goed past.
Nog niet voldoende
Gelukkig beseft MSFT zelf ook door dat de oplossing op dit moment niet voldoet. Tijdens TechEd Europe afgelopen november gaf Kamal Janardhan (Principal Lead Program Manager in the Microsoft Exchange Engineering Team, verantwoordelijk voor de Archiving feature in Exchange 2010) een sessie waarin dit duidelijk naar voren kwam. In deze sessie werd duidelijk dat het Exchange team zeer sterk overweegt om in de volgende grote Exchange release (waarschijnlijk SP1) o.a. de volgende zaken toe te voegen:
- Ondersteuning voor archive mailboxen in andere databases
- Ondersteuning voor Outlook 2007
- Automatisch importeren van PST files in een archive mailbox
Goed nieuws voor de toekomst dus, hoewel het onduidelijk is of, en in welke Exchange update functionaliteiten geïntroduceerd gaan worden.
Huidige functionaliteit
In de huidige implementatie van archiving zijn de volgende punten al geïmplementeerd en geven een goed beeld van de huidige functionaliteit:- Eindgebruiker zoekmogelijkheden werken ook voor de archive mailbox
- Het is niet mogelijk om meerdere archive mailboxen per gebruiker aan te maken. De reden dat mensen meerdere PST files hadden was waarschijnlijk toch de bekende 2GB limiet (in het geval van non-unicode pst files)
- De dumpster (litigation hold) grootte kan ingesteld worden (via Powershell)
- In de RTM versie van Exchange 2010 hebben delegates standaard geen toegang tot de archive mailbox. Dit kan wel ingesteld worden. Ook dit wordt waarschijnlijk aangepast in de volgende Exchange versie
- Toegang tot je archive mailbox via je mobiel is technisch mogelijk maar op dit moment nog niet geïmplementeerd
- Retentie policies voor mailboxen kunnen ingesteld worden via een GPO
- De retentie policy werkt met de datum waarop de mail ontvangen is
- Het is mogelijk om de retentie policy is te stellen op basis van message class (b.v. mail, contacts, calendar enz.)
Archiving wel nodig?
Ten slotte natuurlijk de vraag of je überhaupt nog archiving zou willen gebruiken. Met de opslagmogelijkheden van tegenwoordig en de verhoogde limieten in Exchange 2010 is het misschien wel beter om gewoon één grote mailbox aan de gebruiker te bieden. Is alle mail ook gewoon beschikbaar via OWA en je mobiel, met voldoende ruimte voor je UM voicemails. Natuurlijk hebben third-party oplossingen daar weer software voor, maar dat maakt het beheer van clients weer niet makkelijker.Het zal afwachten blijven hoe Microsoft de archiving oplossing gaat ontwikkelen en welke kant het op zal gaan. Het inzetten van archiving voor compliancy redenen (in de VS veel groter dan in Europa) zal in de toekomst wellicht groter worden dan archiving vanwege storage kosten.
Mocht je naar aanleiding van dit artikel nog verder willen praten over archiving, tijdens de Exchange middag van de NGN op 9 februari ben ik ook aanwezig samen met een aantal Exchange experts voor vragen en discussie.
Sender ID Framework
| NGN Evenement |
| "Exchange Middag"
op 9 februari Je kan je hier inschrijven Jaap Wesselius zal hier een presentatie houden en aanwezig zijn als 'Ask the Expert'. |
| Leden gratis,-, Niet-leden €75,-
Lid worden kan hier |
Maar wat is het Sender ID Framework (SIDF) nu precies? SIDF is Microsoft’s implementatie van SPF, het Sender Policy Framework. Dit is echter wel zodanig gedaan dat beide oplossingen compatible met elkaar zijn. Met Sender ID wordt een extra TXT record aan DNS toegevoegd waarmee een ontvangende partij kan bepalen of de verzende server inderdaad wel de server is die hij zegt dat hij is. Dit werkt als volgt:
- Een gebruiker stuurt van Server A een mailtje naar een gebruiker op Server B;
- Server B ontvangt het mailtje van Server A;
- Server B checkt de externe DNS van het betreffende domein van Server A op de aanwezigheid van een SPF record. Als de inhoud van dit SPF record matched met de IP gegevens van Server A dan gaat het mailtje door. Komt het niet overeen dan kan het mailtje:
- Geblokkeerd worden;
- Naar de junk mail folder gestuurd worden;
- Naar de quarantaine mailbox gestuurd worden;
Hoe maak je nu zo’n SPF record aan?
Microsoft heeft een wizard hiervoor gemaakt welke je kunt vinden op http://www.microsoft.com/senderid/wizard. Je kan ook naar de site http://www.openspf.org gaan.
Je hebt naast je domeinnaam, bijvoorbeeld jaapwesselius.nl ook het IP adres van de verzende server nodig. In dit voorbeeld zijn de IP adressen van de verzendende servers 194.165.34.157 en 194.165.34.159.
In de Microsoft wizard voer je als eerste je domeinnaam in. De wizard kijkt vervolgens of er al een SPF record is en checkt de aanwezigheid van A en MX records.
Vervolgens kan je de outbound servers invoeren. In mijn geval zijn inbound servers (A en MX records) tevens outbound servers. Je kan ook aangeven of er nog andere domeinen in gebruik zijn, of je PTR records wil gebruiken voor Reverse Lookup en of er eventueel nog andere servers zijn die mail kunnen versturen voor dit domein. Dat is bij mij niet het geval.
De wizard komt vervolgens terug met dit record:
“v=spf1 mx mx:mail.exchange14.nl mx:mail2.exchange14.nl ~all”
Vervolgens log je in op je publieke DNS en maak je een TXT record aan welke je bovenstaande waarde geeft.
Op http://www.openSPF.org vind je een soortgelijke wizard die iets meer achtergrond informatie geeft. Uiteraard moet het resultaat hetzelfde zijn.
Naast MX records kan je ook nog IP adressen gebruiken, hierdoor wordt het SPF record als volgt:
“v=spf1 mx ip4:194.165.34.157 ip4:194.165.34.159 ~all”
Of een network range gebruiken (doe ik zelf wel in het datacenter):
"v=spf1 mx ip4:194.165.34.0/24 ~all"
Komt de mail vanuit een ander domein, bijvoorbeeld je provider en heft deze zijn eigen SPF records aktief dan kan je dit als volgt aangeven:
"v=spf1 mx ip4:194.165.34.0/24 include:exchange14.nl ~all"
De volgende webpagina geeft een overzicht van de syntax: http://www.openspf.org/SPF_Record_Syntax
Hoe configureer je Sender ID op je Exchange Server?Om het gebruik van Sender ID te configureren log je in op de Edge Server (of de Hub Transport Server als je daar de anti-spam functionaliteit hebt enabled) en open je de Exchange Management Console. Ga vervolgens naar de Organization Configuration, selecteer Hub Transport en selecteer de Anti-Spam tab.
Sender ID is standaard enabled. Als je dubbel klikt op Sender ID heb je de mogelijkheid om de instellingen te wijzigen via het Action tabblad:
1. Reject Message
2. Delete Message
3. Stamp message with Sender ID result and continue processing
Optie 3 is wel de veiligste optie omdat nog niet iedereen Sender ID of SPF gebruikt en je wilt natuurlijk niet dat onbedoeld e-mail wordt geweigerd.
Hoe gezond is mijn Exchange 2010 omgeving?
Wanneer ik als consultant bij een klant kom dan wil ik eigenlijk het zelfde weten. Hoeveel servers heeft de klant, hoeveel gebruikers zijn er? En hoe staat de boel er eigenlijk bij? In dit artikel behandel ik het Exchange 2010 Organizational Health scherm welke mij, en dus ook u, daarbij kan helpen.
Organizational Health
De Exchange Management Console (EMC) heeft in Exchange 2010 een flinke opfrisbeurt gekregen. Gebleven is die MMC console met een interface van 3 kolommen die we kennen uit onder andere Outlook. Net als bij Exchange 2007 is de console slechts een schil om de Exchange PowerShell cmdlets, de bouwblokken waarmee Exchange tot in de kleinste details beheerd kan worden. Nieuw is onder andere de Organizational Health view, een scherm wat we vinden als we in de linkerkolom onze on-premise Exchange organisatie selecteren.
In de middelste kolom, op het eerste tabblad zien we nu de Organizational Health view. De gegevens zijn opgedeeld in 3 onderdelen: Organization Summary, Servers Summary en Recipients Summary. Die onderverdeling is niet toevallig gekozen, dat zijn ook de drie hoofdtakken waaruit de EMC is opgebouwd en welke we kunnen kiezen in de linker kolom. In mijn omgeving ziet de data er zo uit:
Opvallend is dat de databases in Exchange 2010 naar het Organization level zijn verhuisd, de reden is dat met de nieuwe Database Availability Groups (DAG) een database kopieën op meerdere servers kan hebben. Verder valt op dat bij Recipients ook informatie te vinden is over het gebruik van features.
Iets wat helaas niet helemaal goed gaat is het tellen van de benodigde Standard en Enterprise CALs, door een fout in de logica worden alle gebruikers waarop de Default Exchange ActiveSync Mailbox Policy (EAP) van toepassing is ten onrechte meegeteld voor een Enterprise CAL. Laten we eens naar een tabblad van die EAP kijken:
Onderaan op het tabblad kunnen we lezen dat voor het wijzigen van deze opties een Enterprise CAL benodigd is voor iedere mailbox waarop deze policy van toepassing is. Zolang je geen vinkje weghaalt is er geen sprake van een wijziging dus is er geen Enterprise CAL nodig. Deze bug is inmiddels bekend en er komt een update in SP1. “Enterprise CALs required” kunnen we dus negeren.
Gegevens verversen
Terug naar de Organizational Health view, helemaal onderaan in beeld zie we wanneer deze gegevens voor het laats geactualiseerd zijn. Ook kunnen we deze regel aanklikken om de laatste gegevens op te halen.
Wanneer we hier op klikken wordt de Collect Organizational Health Data gestart en kunnen we eerst aangeven of we de gegevens direct op willen halen of dat we dit later willen doen. In veruit de meeste gevallen kunnen we dit direct starten.
Het is een korte wizard, want al in het volgende scherm wordt ons een samenvatting getoond van de volgende stappen.
Die zijn achtereenvolgens:
- Het bestand ExBPA.StayingInformed.Config.xml wordt ingelezen, aan de hand van deze file worden de gegevens verzameld. In deze file staat onder andere een verwijzing naar het script CalCalculation.ps1 welke verantwoordelijk is voor het bepalen van de benodigde Standard en Enterprise CALs.
- De informatie wordt daadwerkelijk verzameld.
- De verzamelde en nu actuele informatie wordt opgeslagen in Active Directory met het Set-OrganizationConfig cmdlet en de parameter –OrganizationSummary. De volgende keer dat de Organizational Health view geopend wordt, ziet de gebruiker dus de in AD opgeslagen gegevens.
Wanneer we nu weer naar de gegevens kijken dan zien we dat deze helemaal up to date zijn gebracht:
Conclusie
We kunnen vaststellen dat de Organizational Health snel en simpel inzicht geeft door de belangrijkste waarden van de Exchange organisatie op te noemen. In Exchange 2010 RTM mogen we de telling van de benodigde Enterprise CAL gerust negeren. Maar vertelde dit ons nu echt iets over de gezondheid van de organisatie? Hooguit zien we dat er een probleem is met één van de database kopieën, maar als we iets aan pro-actief beheer doen dan wisten we dat natuurlijk al. Een betere naam zou misschien Organizational Summary zijn geweest.Nee, om echt inzicht te krijgen in de gezondheid van de omgeving moeten we andere tools gebruiken. Daarover meer in een volgend artikel.
Trivia
Kijk eens in het script wat gebruikt wordt om de CALs te tellen en ontdek wat één van de werknamen van Exchange 2010 is geweest.Exchange 2010 Delegatie Model
Wie nu Exchange 2007 SP1+ gebruikt en overstapt op Exchange 2010 krijgt te maken met een aantal wijzigingen ten aanzien van autorisaties binnen een Exchange omgeving. Voor wie nog op Exchange 2003 zit (of eerder...) zijn de veranderingen niet veel groter.Exchange 2007
Voordat we het gaan hebben Exchange 2010 even kort hoe het ook al weer zit (zat?) met het delegeren van permissies binnen een Exchange 2007 SP1+ omgeving. Hiervoor zijn standaard de volgendesecurity groepengedefiniëerd:- Exchange Organization Administrators;
- Exchange Recipient Administrators;
- Exchange Server Administrators;
- Exchange View Only Administrators;
- Echange Public Folder Administrators.
Exchange 2010
Nieuw in Exchange 2010 is dat autorisaties toegekend worden het zogenaamde Role Based Access Control model, afgekort RBAC. RBAC is deels te configureren via de RBAC User Editor (Exchange Management Console> Toolbox) of volledig via cmdlets. Dit model gaat uit van een drietal pijlers, namelijk Wie, Wat en Waar.Wie
Hierin wordt bepaaldaan welke gebruiker (mailbox) of USG(Universal Security Group) er dadelijk rechten worden toegekend.Hiertoe dienen in RBAC de zogenaamdeRolgroepen (RoleGroup), welke te beheren zijn met de RoleGroup en RoleGroupMember cmdlets.Om een nieuwe RoleGroup aan te maken gebruiken we New-RoleGroup bijvoorbeeld:
New-RoleGroup “UM Pincode Resetter” –Roles “Reset UM Pin”
Gebruikers of groepen kunnen direct bij de definitie van de Rolegroep worden opgegeven of later worden toegevoegd via Add-RoleGroupMember, bijvoorbeeld:
Add-RoleGroupMember “UM Pincode Resetter” –MemberAngelique
Om een Rolgroep te beheren dient men wel lid te zijn van de Organization Management Rolgroep of men is manager van de Rolgroep via het ManagedBy attribuut. Let wel op: leden van de Organization Management beheren ook de Organization Management Rolgroep. Het is dus mogelijk teveel zaken te verwijderen waardoor beheer onmogelijk wordt.
Merk op dat een Rolgroep niks anders is dan een Universal Security Group met een speciaal vlaggetje dat aangeeft dat het een Rolegroep betreft. Binnen AD zijn de Rolgroepen terug te vinden onder de Microsoft ExchangeSecurity Groups OU.
Wat
Hierin wordt bepaald welke rechten er worden toegekenddoor te bepalen welke cmdlets en parameters iemand ter beschikking heeft. Hiertoe dienen in RBAC de zogenaamde Beheerrollen (ManagementRole) , welke te beheren zijn met de ManagementRole en ManagementRoleEntry cmdlets.Exchange 2010 kent van zichzelf 65 Beheerrollen, welke opvraagbaar zijn met:
Get-ManagementRole
De rechten van een Beheerrol zijn opvraagbaar met Get-ManagementRole (via Roles attribuut) maar overzichtelijker is het als we Get-ManagementRoleEntry gebruiken, bijvoorbeeld:
Get-ManagementRoleEntry “UM Mailboxes\*”
Wat we zien zijn alle toegestane cmdlets en parameters die horen bij de Beheerrol “UM Mailboxes”. Bij de definitie van een aangepaste Beheerrol moeten we deze koppelen aan een bestaande Beheerrol:
New-ManagementRole –Name “Reset UM Pin” –Parent “UM Mailboxes”
Let op dat alleen eigen Beheerrollen kunnen worden verwijderd en dat alle rechten van een Beheerrol moeten worden verwijderd voordat de Beheerrol zelf kan worden verwijderd. Door het specificeren van de Recurse parameter bij de Remove-ManagementRole kunnen eigen Beheerrollen met een parent-child recursief worden verwijderd.
Hierna dienen we zelf de gewenste rechtente verwijderen c.q. toe te voegen.Omdat voor het kunnen uitvoeren van een Set cmdlet ook het bijbehorende Get cmdletnodig is, en omdat een Beheerrol minimaal één activiteit moet hebben, verwijderen we alle taken op één na:
Get-ManagementRoleEntry “Reset UM Pin” | where { $_.name –ne “Get-UMMailboxPIN”} | Remove-ManagementRoleEntry
Vervolgens kunnen we rechten toevoegen met Add-ManagementRoleEntry:
Add-ManagementRoleEntry “Reset UM Pin\Set-UMMailboxPIN” –Parameters “Identity,Pin,PinExpired,LockedOut”
Wat handig is dat Get-ManagementRoleEntry ook kan worden gebruikt om op te vragen welke Beheerrollen bepaalde cmdletsmet welke parameters mogen gebruiken, bijvoorbeeld:
Get-ManagementRoleEntry “*\*” | where { $_.Name –eq “Set-User” }
Waar
Hierin wordt het bereik bepaald, oftewel scope.De scope kan een bepaalde groep gebruikers zijn, een server, een Site, een OU of de complete organisatie. RBAC maakt onderscheid tussen vaste scopes die aan de standaard Beheerrollen gekoppeld zijn (implicit scopes) en voorgedefiniëerde of eigen scopes (explicit scopes). RBAC kent de implicit scopes Organization, MyGAL, Self, MyDistributionGroups, OrganizationConfig en None.Voor het opvragen van de scopes van een Beheerrol gebruiken we Get-ManagementRole, bijvoorbeeld:
Get-ManagementRole “UM Mailboxes” | fl *scope*
We zien dat er sprake is van vier scopes per Beheerrol, namelijk:
- Recipient Read Scope: Welke AD recipient objecten kan men lezen;
- Recipient Write Scope: Welke AD recipient objecten kan men aanpassen;
- Configuration Read Scope: Welke AD configuratie objecten kan men lezen;
- Configuration Write Scope: Welke AD configuratie objecten kan men aanpassen.
Zoals eerder gezegd moeten nieuwe Beheerrollen altijd een bestaande Beheerrol als basis hebben. Bij het aanmaken krijgen zij de scopes van de parent mee, waarna deze naar wens kunnen worden omgezet naar eigen scopes.
Voor het aanmaken van een eigen scope gebruiken we New-ManagementScope met een van de volgendeelkaar uitsluitende filters:
- RecipientRestrictionFilter voor het filteren van Recipients. Eventueel kan met RecipientRoot het startpunt worden gedefinieerd, anders betreft het de gehele organisatie;
- ServerRestrictionFilter voor het filteren van Server objecten;
- ServerList voor het filteren op namen van servers.
Bijvoorbeeld:
New-ManagementScope –Name “NL Site” –ServerRestrictionFilter {ServerSite –eq “NL”}
New-ManagementScope –Name “StaffSecretaresses” –RecipientRoot “domain.local/Staff” –RecipientRestrictionFilter{memberofgroup -eq "cn=Secretaries,ou=Users,dc=domain,dc=local” }
Voor de mogelijkheden tot het filteren op properties wordt in Exchange 2010 naar een Exchange 2007 informatie verwezen. Voor meer achtergrondinformatie over de scopes.
1+1+1=3
Nadat we het Wie, Wat en Waar hebben bepaald kunnen we nu deze drie elementen in RBAC combineren via een Roltoewijzing, oftewel een Role Assignment.Kort gezegd, een Role Assignment is de schakel tussen een RoleGroup en een ManagementRole met als extra attribuut een Recipient of Configuration scope.Bestaande toewijzingen binnen een Rolgroep kunnen we opvragen via Get-RoleGroup, bijvoorbeeld:
Get-RoleGroup “UM management” | fl
Het attribuut RoleAssignment geeft aan welke toewijzingen er zijn. Alle bestaande toewijzingen kunnen worden opgevraagd met Get-ManagementRoleAssignment, bijvoorbeeld:
Get-ManagementRoleAssignment “UM Mailboxes-UM Management” | fl
Zoals je zult ziet heeft Microsoft de namen van de Role Assignments gebaseerd op een samenvoeging van van de naam van de ManagementRole en naam van de RoleGroup. Handig, want zo weet je op welke ManagementRole en RoleGroup een toewijzing betrekking heeft.
Met New-ManagementRoleAssignment kunnen we een ManagementRole toewijzen aan een RoleGroup of andere USG, een policy (meer hierover wellicht later) of een gebruiker. Bijvoorbeeld:
New-ManagementRoleAssignment –Name “Reset UM Pin-UM PincodeResetter” –Role “Reset UM Pin”-SecurityGroup“UM PincodeResetter”–CustomRecipientWriteScope “Staff Secretaresses”
Conclusie
Met de komst van Exchange 2010 RBAC verandert er nogal wat voor wat betreft autorisaties. Vooral grote organisaties waar een men reeds een delegatiemodel heeft uitgewerkt staan voor een uitdaging. Geen eenvoudige, maar wel een waarin men meer ondersteund wordt door de techniek en standaard voorzieningen als het gaat om delegatie van permissies. Eenvoudigere, plattere organisaties kunnen vermoedelijk volstaan met de standaard verzameling van rollen, groepen, scopes en toewijzingen.
Exchange 2010 Database Compressie
Een van de (onder water) voorzieningen van Exchange versies tot en met 2007 is Single Instance Storage. Het grote voordeel hiervan is dat berichten verzonden aan meerdere ontvangers op dezelfde mailbox database slechts éénmaal opgeslagen worden.Met de komst van Exchange 2010 heeft Microsoft de ESE (Extensible Storage Engine) weer eens onder handen genomen (tja, nog steeds geen SQL :) ) . Veel van deze aanpassingen komen de performance (lees: minder IOPS) ten goede. Zo gebruikt Exchange 2010 grotere pages en wordt in de achtergrond data in de store zoveel mogelijk sequentieel geordend. In een optimale situatie zorgt dat voor een reductie in lees IOPS van 70% (ten opzichte van Exchange 2003 90%).
Echter, een van de functies die met de Exchange 2010 ESE verdwijnt is Single Instance Storage. Dit lijkt erger dan het is. Doordat tegenwoordig Gb mailboxen eerder regel dan uitzondering zijn, de hogere limiet qua aantal databases en de afweging database omvang versus recovery tijden heeft een mailboxserver tegenwoordig vaak al meerdere databases. Hierdoor neemt de effectiviteit van Single Instance Storage af. Ook is de prijs van opslag enorm gedaald en ligt de focus nu eerder op performance dan op diskruimte.
De nieuwe ESE engine doet ook aan storage compressie. Dat wil zeggen, bepaalde delen van berichten (headers en body) worden met compressie opgeslagen. Attachments worden niet gecomprimeerd (maar dat zijn vaak toch ZIP of PDF bestanden, dus dat heeft weinig toegevoegde waarde). Eerste metingen laten zien dat storage compressie de toename in omvang door het wegvallen van Single Instance Storage teniet kan doen. Sterker nog, doordat storage compressie niet afhankelijk is van of ontvangers op zelfde database gehuisvest zijn is de potentie vele malen groter.Uit metingen bleek overigens dat de overhead van (de)compressie gelijk of minder is dan de overhead voor de benodigde extra IOPS zonder compressie.
Overigens, het soort compressie wat hiervoor gebruikt wordt is dezelfde als die gebruikt wordt voor onder andere MAPI en DAG netwerkverkeer: XPRESS, een Microsoft implementatie van het LZ77 algorithme.
Voor de geïnteresseerden of wie slecht kan slapen, storage compressie is gebaseerd op de RTF Extensions Specificatie, hier na te lezen (pdf).
Exchange 2010 dynamische disclaimer
Exchange 2007 bracht ons transport rules, met transport rule konden we heel gemakkelijk een disclaimer plaatsen onder bijvoorbeeld alle uitgaande berichten. Voor veel klanten was een transport rule voor dit doel de eerste en vaak ook de enige rule die ze aanmaakten. Maar naast het toevoegen van een juridische boodschap kunnen we natuurlijk ook ieder uitgaand bericht voorzien van de zelfde ondertekening. Een veel gestelde vraag was of we hier ook dynamische gegevens in konden opnemen en dat was helaas niet mogelijk. Exchange 2010 brengt daar verandering in en in dit artikel laat ik zie hoe eenvoudig het is om dit in te stellen.Het maken van een transport rule in Exchange 2010 gaat precies het zelfde als in Exchange 2007: in de Exchange Managemens Shell met de New-TransportRule cmdlet of in de Exchange Management Console. In dit artikel kies ik de EMC om een disclaimer toe te voegen die dus geen juridische tekst bevat maar een gepersonaliseerde handtekening, de gegevens hiervoor halen we uit Active Directory.
Om te beginnen openen we de EMC en browsen we naar Organization Configuration, Hub Transport. In het rechterpaneel kiezen we New Transport Rule… en de volgende wizard wordt voor ons gestart:
Geef de transport rule een naam en indien gewenst een commentaar, een nieuwe transport rule is standaard gelijk Enabled, haal het vinkje weg als je dat nog niet wilt en klik op Next.
Een transport rule bestaat uit 3 componenten: een voorwaarde, een aktie en een uitzondering. In mijn voorbeeld heb ik als Condition gekozen voor mail die verzonden wordt door gebruikers van mijn organisatie, naar mensen buiten mijn organisatie. Klik op Next.
De actie is duidelijk hier, we willen een disclaimer toevoegen. Wanneer we dit vinkje gezet hebben kunnen we in het onderste deel van de wizard klikken op ‘disclaimer text’.
Zoals je ziet kunnen we hier HTML-tags gebruiken, in dit voorbeeld heb ik alleen een h3-tag gebruikt maar je kunt ook denken aan een specifiek lettertype of een link naar het bedrijfslogo. Verder kunnen we hier dus met variabelen uit Active Directory werken, we zetten de naam van de variabel simpelweg tussen %%. In de praktijk zul je hier misschien nog een hr-tag en daaronder je disclaimer-text aan toe willen voegen. Klik op OK en druk op Next.
In dit voorbeeld heb ik geen Exception gekozen en klikken we op Next.
Hier kunnen we onze keuzes nog een keer controleren en bevestigen we ze met een klik op New.
En zoals we inmiddels van Exchange gewoon zijn krijgen we hier te zien dat de opdracht met succes is uitgevoerd en welke PowerShell regel er onder de motorkap voor ons is uitgevoerd. Klaar is Kees!
Maar hoe ziet het eindresultaat er nu uit? Minder spectaculair dan je misschien zou verwachten:
Dan nog even terug naar de AD properties die we gebruikt hebben in onze handtekening, je vraagt je misschien af welke properties je daar kunt kiezen en welke naam je precies aan moet houden. Daar is een handig truukje voor. Hiertoe openen we de eigenschappen van een mailbox en passen we de gewenste velden aan, bijvoorbeeld door een leeg veld met een waarde te vullen of een ingevuld veld met één karakter aan te passen, zoals ik hier gedaan heb.
Zodra we de eerste aanpassing doen wordt er een button klikbaar die daarvoor nog greyed out was. Dit is een nieuwe functie van Exchange 2010, dit is de ‘Show Exchange Management Shell command’ button. Wanneer we hier op klikken krijgen we de PowerShell regel te zien welke uitgevoerd wordt wanneer we de wijzigingen bevestigen door op OK te klikken, vergelijkbaar met de terugkoppeling die we op de laatste pagina van de wizard zagen.
Hier zien we de parameters van de Set-Mailbox cmdlet die gewijzigd zouden worden: StreetAddress, City en Department, dit zijn de namen die we hierboven gebruikt hebben. Speel maar eens met de velden die voor jou interessant zijn, op deze manier vind je snel welke namen je zoal kunt gebruiken.
Met dit eenvoudige voorbeeld hoop ik jullie fantasie geprikkeld te hebben, ik weet zeker dat jullie een slimmere of nettere toepassing van deze functionaliteit weten te bedenken. Succes!
Exchange Transaction Logs
- Transactie logs, te herkennen aan een hexadecimale bestandsnaam en de extensie log. Daarnaast bestaan er nog twee vooraf gereserveerde log bestanden. Deze bestanden zorgen ervoor dat mocht een schijf vollopen de database toch netjes afgesloten kan worden.
- Checkpoint bestand, te herkennen aan de extensie chk.
Stap 1
De data staat in het geheugen en wordt weggeschreven naar een log bestand. Dit log bestand bevat alle wijzigingen die toegepast moeten worden op de database. Ontstaat er een fout tijdens zo’n transactie dan wordt de transactie in de log file gemarkeerd en start het wegschrijven opnieuw.Stap 2
De data wordt vanuit het geheugen weggeschreven naar de database file.Stap 3
Wanneer data uit het geheugen is toegepast op de database dan zal de checkpoint file bijgewerkt worden naar aanleiding van deze laatste transactie. Dit bestand houdt namelijk bij welke informatie uit welk log bestand als laatst succesvol is toegepast op de database. Wanneer je een database dismount, de checkpoint file verwijdert en de database vervolgens weer mount zullen alle log bestanden opnieuw afgespeeld worden en zullen de bestanden die nog niet zijn toegepast op de database aan de database toegevoegd worden.Maar waar zijn die log bestanden nou nog meer makkelijk voor?
Wanneer er geen logs gebruikt zouden worden en de database zou er plotseling mee stoppen dan zou het kunnen zijn dat de database niet meer gemount kan worden en er data verloren gaat. Met transactie logs worden de log bestanden tijdens het mounten van de database opnieuw toegepast op de database.De log bestanden van Exchange zijn te herkennen aan het volgende hexadecimale formaat E0000000009.log. Een log bestand zal pas een opvolgnummer krijgen wanneer het log bestand is afgesloten. Elk log bestand is maximaal 1 MB groot. Wanneer de 1 MB wordt bereikt zal het log bestand worden afgesloten en zal er een nieuw log bestand aangemaakt worden. Dit proces wordt ook wel log file roll-over genoemd. Wanneer een log bestand wordt afgesloten ondanks dat de 1 MB niet gebruikt is, wordt dit een forward roll genoemd. Dit gebeurt bijvoorbeeld bij het maken van een backup.
In Exchange 2007 bevat de Extensible Storage Engine (ESE) Lost Log Resiliency (LLR). Dit component kan, in het geval er één of meerdere recente log bestanden niet aanwezig of beschadigd zijn, er toch voor zorgen dat de database gemount kan worden. Deze nieuwe functionaliteit is standaard actief op alle mailbox servers. In het geval van een CCR omgeving is deze functionaliteit alleen actief op de actieve node.
Zoals al eerder gemeld is de volgorde voor het wegschrijven van data in de database geheugen -> log -> database. LLR zorgt ervoor dat schrijfacties naar het log bestand worden vertraagd totdat het aantal log bestanden wat een server maximaal mag achterlopen is bereikt. Afhankelijk van hoeveel tijd dit in beslag neemt heeft dit ook een gevolg voor het updaten van de database zelf, deze updates hier naartoe worden namelijk ook op dit moment vertraagd.
Het checkpoint bestand bevat de naam van het laatste log bestand wat is toegepast op de database. Met LLR wordt er naast de informatie in het checkpoint bestand ook informatie aan het einde van elk log bestand toegevoegd:
- Waypoint, dit is het log bestand dat minimaal nodig is om een succesvolle recovery uit te voeren.
- Committed log, welk log bestand als laatst is toegepast op de database.
- Lossless, er mag geen log bestand verloren gaan
- Good Availability, er mogen 3 log bestanden verloren gaan
- Best Availability, er mogen 6 log bestanden verloren gaan
Diskruimte en logging
Allemaal leuk en aardig al die log bestanden maar deze nemen dus ook diskruimte in beslag. De log bestanden worden pas verwijderd als er en full backup is gemaakt van de database.Daarnaast bestaat er natuurlijk nog de manier van handmatig verwijderen. Hiervoor dient de database wel in een clean shutdown te zijn. Het handmatig opschonen van de logs is echter niet echter niet aan te raden.In principe blijven in alle overige gevallen de log bestanden bewaard. Log bestanden kunnen overschreven worden indien “circular logging” wordt gebruikt. Als dit het geval is dan staan er gemiddeld 20 log files op een Exchange (2007) server. Oudere logfiles worden dan overschreven en zijn niet meer beschikbaar. Nadeel hiervan is dat de kans op recovery afneemt. De laatste log files kunnen eventueel worden gebruikt na een crash van de server, maar recovery door het replayen van log files is niet meer aanwezig.
In Exchange 2007 kun je CCR combineren met circular logging. Dit wordt ook wel continuous replication circular logging (CRCL) genoemd. Het verschil met circular logging is dat CRCL geregeld wordt door de Microsoft Exchange Replication Service en circular logging wordt geregeld door de Microsoft Exchange Information Store Service. Normaliter zou een log bestand telkens hergebruikt worden, in het geval van CCR is dit natuurlijk wel wat lastiger, het log bestand dient immers eerst gekopieerd te worden naar de andere node. Om deze reden zal de Replication Service wachten met het overschrijven van het bestand totdat het bestand is gekopieerd naar de andere node en daar succesvol is verwerkt.
De information store ziet pas dat circular logging is ingeschakeld wanneer de database een keer gedismount en opnieuw gemount wordt.
Voor CCR, LCR en SCR omgevingen dienen onderstaande stappen uitgevoerd te worden:
- Pauzeer de replicatie tijdelijk
- Schakel circular logging in/uit
- Dismount de database en mount deze vervolgens weer
- Schakel de replicatie weer in
Nu vraag je je af "waarom via deze procedure?"
De Microsoft Exchange Replication Service, welke verantwoordelijk is voor het repliceren van de data, detecteerd automatisch of CCR aan/uit staat. Voor een database in een LCR omgeving is de Microsoft Exchange Information Store verantwoordelijk voor het detecteren van de aan/uit staan van circular logging. Wanneer de procedure niet gevolgd wordt kan dit tot gevolg hebben dan de Information Store denkt dat circular loggin aanstaat terwijl de Replication Service denkt dat deze uit staat.Microsoft adviseert om circular logging niet te gebruiken vanwege de eerder genoemde reden, de kans op recovery neemt namelijk aanzienlijk af. Maar wanneer zou je nou wel gebruik kunnen maken van circular logging? Eén van de redenen zou kunnen zijn tijdens een migratie van mailboxen, tijdens dit proces wordt namelijk veel logging gegenereerd.
Niet vergeten na de migratie circular logging weer uit te zetten overigens ;-)
Je server voorbereiden voor de installatie van Exchange 2010
Voordat we Exchange 2010 op een server kunnen installeren moeten eerste een aantal Windows onderdelen aanwezig zijn, anders zal de installatie niet kunnen starten. In dit artikel wil ik een variant beschrijven die ik zelf erg handig vind, namelijk het gebruik van ServerManagerCMD.exe en xml-files.Wanneer we de installatiebestanden van Exchange 2010 downloaden of op DVD hebben dan staat in de installatiedirectory een directory met de naam Scripts. Hierin vinden we een aantal xml-bestanden:
Exchange-Typical.xml
Exchange-CAS.xml
Exchange-Hub.xml
Exchange-MBX.xml
Exchange-UM.xml
Deze bestanden kunnen we gebruiken als invoerbestand voor ServerManagerCMD.exe met de switch -ip. Voor een server die alle standaard Exchange 2010 rollen gaat draaien bijvoorbeeld gebruiken we het commando:
ServerManagerCMD.exe -ip Exchange-Typical.xml -Restart
Voor een Edge Transport server ziet het commando er zo uit:
ServerManagerCMD.exe -ip Exchange-Edge.xml -Restart
Goed, wat de bedoeling van de overige bestanden is spreekt wel voor zich, denk ik. Dan zijn er verder nog twee bijzonderheden, ten eerste voor een server die de Unified Messaging rol uit gaat voeren. Voor deze installeren we ook nog de Desktop Experience feature met het volgende commando:
ServerManagerCmd -i Desktop-Experience
En tot slot moeten we voor servers met de Client Access rol een service op 'Automatic' zetten, wat is er handiger om dit ook met een makkelijke opdrachtregel te doen:
sc config NetTcpPortSharing start= auto
Nu zul je misschien zeggen dat je het net zo makkelijk in de GUI kunt doen allemaal, en dit lijkt misschien wel eens handiger. Maar wanneer je 4 servers of 40 servers moet inrichten dan is het alweer een heel stuk makkelijker om de opdrachten in een script of batch-bestand te zetten en deze op de servers te laten draaien.
Een ander voordeel van de commandline is de mogelijkheid om heel eenvoudig een logboek bij te kunnen houden van alle stappen die je genomen hebt. Het maken van screenshots kost tijd en is vaak wat omslachtig, maar een snelle copy-paste van de gebruikte commando's is zo gedaan. Als je nog geen logboek bijhoudt, dan raad ik het je bij deze aan.
Exchange 2010: Edities en licenties
Microsoft producten en licenties, het heeft de naam het meest complexe gebied van ons vak te zijn. En laten we wel zijn, het is doorgaans ook niet eenvoudig om de juiste keuze te maken uit alle verschillende mogelijkheden. In dit artikel wil ik wat licht schijnen op de verschillende versies en bijbehorende licenties van Exchange 2010.Net als bij Exchange 2007 zijn er twee verschillende versies te koop van Exchange Server 2010, Standard en Enterprise Edition. Voor beide versies installeer je de zelfde software en pas wanneer je een product key invoert worden bepaalde functies uitgeschakeld. Zolang je nog geen key hebt ingevoerd zit je in de trial-mode, die is 120 dagen geldig en komt overeen met de functionaliteit van Enterprise Edition.
Op dit moment zijn de volgende kenmerken van de verschillende server-edities bekend:
| Exchange Server 2010 | Standard Edition | Enterprise Edition |
| Aantal databases maximaal | 5 | 100 |
| Maximale database grootte | Onbeperkt (*) | Onbeperkt (*) |
| Database Availability Group (DAG) | Ja | Ja |
Naast de verschillende edities van de Server licentie zijn er ook nog 2 verschillende Client Access Licenses (CAL). Het zal je niet verassen dat ook deze Standard en Enterprise in de naam hebben. Voor Exchange 2010 CALs geldt dat je voor iedere gebruiker een Standard CAL nodig hebt. Wanneer je bepaalde features wilt gebruiken waarvoor de Enterprise CAL benodigd is, dan schaf je die aan bovenop de Standard CAL en alleen voor het aantal gebruikers waarvoor je deze functionaliteit nodig hebt.
Exchange Server edities en CALs kunnen door elkaar gebruikt worden, dus je kunt Standard CALs gebruiken om met een Enterprise server verbinding te maken. Onderstaande tabel geeft aan welke functionaliteit de verschillende CALs bieden:
| Standard | Enterprise | |
| E-mail, agenda en contactpersonen | Ja | Ja |
| Exchange ActiveSync | Ja | Ja |
| ActiveSync Over-the-air updates (**) | Ja | Ja |
| Outlook Web App | Ja | Ja |
| Mail archivering | Nee | Ja |
| Retentiebeleid | Nee | Ja |
| Unified Messaging | Nee | Ja |
| Forefront Protection (***) | Nee | Ja |
(***) Alleen bij bepaalde licentie-/contractvormen, vraag je leverancier.
Samengevat geldt dat je eerst een keuze maakt voor de server licenties, bekijk per server(!) welke editie je nodig hebt: Standard of Enterprise Edition. Vervolgens schaf je voor alle gebruikers Standard CALs aan en alleen voor bepaalde functionaliteit de aanvullende Enterprise CAL. Overigens kun je een server met Standard Edition eenvoudig upgraden naar Enterprise Edition door simpelweg een andere product key in te voeren.
Ik wens jullie veel plezier met Exchange 2010!
Exchange Server 2007 CCR Fail-over
De eerste blogpost in het Exchange Themablog is geschreven door Johan Veldhuis. Johan is Exchange Server MVP en werkzaam bij Axians. Dit is zijn bijdrage:
Continious Cluster Replication
Een van de mogelijkheden van Exchange 2007 om de mailbox server hoogbeschikbaar te maken is Continious Cluster Replication, ook wel CCR genoemd.
Een CCR mailboxomgeving bestaat uit een node met aan actieve database, een node met een passieve database en een node welke als File Share Witness fungeert. De passieve database wordt geupdate middels asynchrone log replicatie. Dit wil zeggen dat de logs pas verstuurd worden naar de andere node als het logbestand is afgesloten en niet meer gebruikt wordt door de actieve node. Het kan dus voorkomen dat de passieve node niet altijd over alle logs beschikt. Dit kan bijvoorbeeld voorkomen wanneer een beheerder een handmatige failover doet. Voordat het logbestand wordt afgespeeld worden er een check gedaan of het logbestand niet corrupt is. Pas als het logbestand deze check heeft doorlopen wordt het logbestand afgespeeld en worden de wijzigingen in de database weggeschreven. De logbestanden zijn 1 MB per stuk, dit in tegenstelling tot Exchange 2003 waar de logbestanden nog 5 MB per stuk waren. Voordeel hiervan is dat er een minimale hoeveelheid data verdwijnt als er een logbestand verloren gaat tijdens een failover. De Microsoft Exchange Replication service is verantwoordelijk voor het overbrengen van de logbestanden van de actieve node naar de passieve node. De service doet dit door connectie te maken naar een share en het logbestand te kopieeren of te pullen. De share heeft als naam de guid van de storage groep met een $ eraan vastgeplakt om te zorgen dat de share niet zichtbaar is voor iedereen.
De initieële kopie slag van de actieve node naar de passieve node wordt ook wel seeding genoemd en vindt plaats tijdens het installeren van de passieve node en wanneer er een database wordt toegevoegd aan het CCR cluster.
Zoals met elk cluster heb je geplande en ongeplande failovers. Vooral dit laatste is iets wat je natuurlijk liever niet hebt. Maar wat zijn de mogelijkheden met CCR in geval van een ongeplande failover? Exchange bevat een parameter AutoDatabaseMountDail met deze parameter kan bepaalde worden hoe Exchange omgaat met een ongeplande failover:
- Lossles, zoals de naam al doet vermoeden gaat met deze methode geen log bestand verloren. In veel gevallen zal er gewacht worden totdat de node welke gefaalt is weer online is, de node moet dan wel alle log bestanden bevatten en mogen deze niet corrupt
zijn. Na de failover zal de passieve node gepromoveerd worden naar actieve node en zal de Exchange Information Store Service gestart worden. Deze service zal bij het opstarten controleren of de database zonder dataverlies kan worden gemount. Wanneer dit kan dan zal de database gemount worden, wanneer de node logbestanden mist dan zal periodiek geprobeerd worden om de log bestanden te kopieeren van de gefaalde node. Wanneer de gefaalde node echter niet online komt en er dus log bestanden ontbreken, dan zal de database niet gemount worden. Als beheerder heb je altijd de mogelijkheid om de database alsnog te mounten, dit kan echter wel inhouden dat niet alle inhoud van de database beschikbaar is. - Good availability, met deze methode gaan er maximaal 3 logbestanden verloren. Good availability maakt gebruik van volledig automatische recovery wanneer de replicatie goed werkt en repliceert de logs afhankelijk van de snelheid waarmee nieuwe logbestanden aangemaakt worden.
-
Best availability, met de methode kunnen er maximaal 6 log bestanden verloren. Best availability is de standaard methode welke gebruikt wordt wanneer je een CCR gebruikt. Deze methode werkt bijna hetzelfde als good availability maar biedt als voordeel dat de automatische recovery ook toegepast kan worden wanneer er een kleine vertraging zit in het repliceren van de logs. Dit heeft als voordeel dat de passieve node iets verder qua logs mag achterlopen dan de actieve node.
Maar waarom zou je dit willen wijzigen? Een van deze redenen zou kunnen zijn de SLA waar je aan moet voldoen. Garandeer je bijvoorbeeld dat er geen data verloren gaat dan zou je dit wijzigen naar lossless omdat de database alleen gemount wordt als alle logbestanden aanwezig zijn.
Het wijzigen van bijvoorbeeld Best Availability naar Losless brengt natuurlijk wel wat risico’s met zich mee. Het is namelijk heel belangrijk dat beide nodes over de correcte log bestanden beschikken en dat deze logbestanden niet corrupt zijn. Daarnaast kan Losless wel leiden tot een ongeplande lange downtime, dit omdat indien één van de logbestanden niet aanwezig is of er één corrupt is de database niet automatisch gemount zal worden maar middels een handmatige actie online gebracht moet worden door de administrator zelf. Voordat de administrator dit doet zal hij/zij moeten controleren wat de status is van de copy. Dit kan gedaan worden middels het command Get-StorageGroupCopyStatus.
Wanneer de administrator besluit om de database te mounten zal hij/zij er eerst voor zorgen dat de replication source aangepast wordt. Vervolgens kan de database gemount worden het volgende commando in Powershell uit te voeren Mount-Database -Identity:
Goed nu genoeg tekst, hoe kun je de parameter aanpassen. Heel simpel:
- Via de Exchange Management Console
-
Via de Exchange Management Shell
Exchange Management Console
Wanneer de Exchange Management Console is geopend kun je via server configuration naar de mailbox server rol. Hier zul je alle servers zien waarop de mailbox server rol is geïnstalleerd. Vraag vervolgens de eigenschappen op van de mailbox server. Onderstaande scherm zal nu getoond worden, kies hier de tab Clustered Mailbox Server:
In het dropdown-menu zie je dat standaard Best Availability staat geselecteerd. Door een andere optie te selecteren in het dropdown-menu zal de parameter AutoDatabaseMountDial een andere waarde krijgen. Er is echter één beperking aan dit instellen via de GUI, de parameter ForcedDatabaseMountAfter kan niet ingesteld worden. Deze parameter kan alleen ingesteld worden via de Exchange Management Shell.
Exchange Management Shell
Om in de Exchange Management Shell te kijken wat de huidige instelling is dien je het commando get-mailboxserver
Wanneer we nu de AutoDatabaseMountDial parameter willen wijzigen dienen we dit via het commando set-mailboxserver
Deze waarde kan een van de volgende zijn:
- Lossless
- GoodAvailability
-
BestAvailability
Met de parameter ForcedDatabaseMountAfter kunnen we configureren hoelang er gewacht moet worden voordat de database geforceerd gemount wordt. Deze waarde kunnen we aanpassen door het commando Set-MailboxServer
De waarde dient ingesteld te worden volgens de volgende syntax dd.hh:mm:ss of dient ingesteld te worden op unlimited. Deze ForcedDatabaseMountAfter parameter wordt alleen gebruikt als de AutoDatabaseMountDial parameter staat ingesteld op GoodAvailability of BestAvailability. Wanneer je bijvoorbeeld de volgende waarde insteld: 01:30:00 dan zal de database na 1,5 uur gemount worden ook al mist Exchange 50 log bestanden. Dit kan tot gevolg hebben dat niet alle items terug te vinden zijn in de database en dient dus met zorg gebruikt te worden.
Wanneer de database ingesteld staat op unlimited zal de database nooit geforceerd gemount worden.
Naast de 2 nodes dient er een File Share Witness te zijn, dit om te voorkomen dat er een split-brain situatie ontstaat. Een split-brain kan ontstaan wanneer de netwerk-verbindingen die gebruikt worden voor cluster verkeer verbroken zijn en wanneer de nodes onderling het heartbeat signaal niet naar elkaar kunnen versturen. Split-brains kunnen voorkomen worden door ervoor te zorgen dat er altijd minimaal 2 nodes online zijn en met elkaar kunnen communiceren. In het geval van een CCR kan er dus 1 van de nodes uitvallen of de File Share Witness. De twee nodes bepalen middels de File Share Witness welke node de eigenaar is van het cluster.
De File Share Witness kan in principe iedere server zijn welke toegang heeft tot de Exchange nodes. Echter meestal wordt de HUB server hiervoor gebruikt om alles van Exchange toch een beetje bij elkaar te houden. Indien je Windows 2003 als OS gebruikt dien je eerst een update te installeren om het type quorum Majority Node set beschikbaar te maken.
Over Johan Veldhuis:
Johan Veldhuis werkt als server & storage engineer bij AXIANS (www.axians.nl). In deze functie is hij verantwoordelijk voor het uitvoeren van projecten op server & storage gebied waaronder: Microsoft Server omgevingen, Lefthand storage-omgevingen, Backup oplossingen, Citrix/Terminal server omgevingen en antivirus/antispam oplossingen. Hiervoor heeft hij gewerkt als service desk engineer waar hij verantwoordelijk was voor het oplossen van issues bij klanten voor diverse produkten waaronder Windows servers, Exchange servers, Citrix/Terminal servers, Anti-virus/Antispam oplossingen, Backup oplossingen en netwerkcomponenten. Sinds Exchange 2003 is hij zich meer gaan verdiepen in Exchange.
Sinds vorig jaar heeft een eigen website welke de nadruk heeft op Exchange.
Naast de certificeringen MCSE en MCITP Exchange 2007 is Johan ook Trend Micro Security Master. In 2009 is hij gewaardeerd door Microsoft voor zijn werkzaamheden voor de community met een MVP Award.
Exchange Thema blog
Hallo allemaal,
Na wat eigen gebakken blogjes zo hier en daar heb ik met Ernst Fuld een deal gemaakt, ik ga wat bloggen op de NGN site. Uiteraard ter meerdere eer en glorie van mijn eigen persoontje, maar ook om wat meer informatie rondom Exchange Server te kunnen publiceren.
Daarom is het een themablog geworden en geen persoonlijke blog. Als je wilt weten wanneer ik bijvoorbeeld precies onder de douche sta (om het netje te houden) dan moet je op Twitter zijn.
Qua Exchange denk ik uiteraard aan Exchange Server 2010 wat binnen een redelijke tijd uit gaat komen (komt allen naar TechNet Live: http://www.microsoft.com/netherlands/technetlive/) maar ook Exchange Server 2007 en 2003 behoort tot de mogelijkheden.
Zijn er onderwerpen waarvan jij vindt dat ik er aandacht aan moet schenken geef dan gewoon een gil. Uiteindelijk is deze themablog er voor jullie en niet voor mij (nou ja, bijna dan ;-)
Groetjes
Jaap Wesselius
Biografie auteurs Exchange themablog
Jaap Wesselius
Jaap Wesselius is consultant bij DM Consultants, een organisatie met een sterke focus op Messaging and Collaboration solutions. Voor DM Consultants heeft Jaap 8 jaren bij Microsoft Nederland gewerkt, eerst als Technical Account Manager en later als Consultant. Exchange Server heeft sinds de allereerste release in 1996 als een rode draad door zijn leven gelopen. Na zijn vertrek bij Microsoft heeft Jaap veel tijd geinvesteerd in “de community”, zowel voor Exchange Server en later ook voor Hyper-V. Dit heeft geresulteerd in een MVP Award in de categorie Exchange Server.Daarnaast schrijft Jaap ook regelmatig artikelen voor de LANVision van de NGN, voor Red Gate in Engeland en is Jaap bijna klaar met zijn boek over Exchange Server 2010.
Mocht er dan nog wat vrije tijd over zijn dan wordt dan besteedt aan de drie zonen, of aan lekker wandelen (minimaal 20 km) of fietsen.
Jetze Mellema
Jetze Mellema is werkzaam als Infrastructure Consultant bij PQR, een organisatie die als Microsoft Gold Partner, Citrix Platinum Solution Advisor, VMware Premier en Consultancy Partner in Nederland vooraan loopt bij het ontwerpen, implementeren en migreren van geavanceerde ICT-Infrastructuren. Jetze richt zich in zijn functie primair op het ontwerpen en bouwen van allerlei Microsoft omgevingen en het uitvoeren van migraties. Zijn specialisatie is Microsoft Exchange, een onderwerp waar hij gepassioneerd over kan spreken.Verder is Jetze actief in de Nederlandse publieke Microsoft nieuwsgroepen en diverse andere webfora. Hier ligt zijn focus op Microsoft servers, Active Directory en met name Exchange Server. Ook schrijft hij stukjes over dit onderwerp op zijn eigen blog en draagt hij bij aan diverse andere blogs.
Wanneer hij zich niet bezig houdt met Exchange, spendeert hij tijd met zijn vrouw, zoon en twee dochters of ontvlucht hij de drukte door een ritje op zijn quad te maken.
Johan Veldhuis
Johan Veldhuis werkt als system engineer bij Communicativ. In deze functie houdt hij zich vooral bezig met Microsoft Exchange en Office Communications server. Hiervoor heeft hij gewerkt als server & storage engineer waar hij verantwoordelijk was voor het uitvoeren van projecten op server & storage gebied waaronder: Microsoft Server omgevingen, Lefthand storage-omgevingen, Backup oplossingen, Citrix/Terminal server omgevingen en antivirus/antispam oplossingen. Sinds Exchange 2003 is hij zich meer gaan verdiepen in Exchange.Sinds vorig jaar heeft een eigen website welke de nadruk heeft op Exchange.
Naast de certificeringen MCSE en MCITP Exchange 2007 is Johan ook Trend Micro Security Master. In 2009 is hij gewaardeerd door Microsoft voor zijn werkzaamheden voor de community met een MVP Award.
Michel de Rooij
Michel de Rooij is werkzaam als Technical Consultant bij Inter Access, een organisatie met met 8 Microsoft Gold Certified Partner erkenningen. Na een start als developer heeft Michel zich ontwikkeld in het de infrastructuur vakgebied. In die periode heeft hij ruimschoots ervaring opgedaan in migraties en infrastructuur projecten bij klanten met o.a. Windows Server, Exchange, AD, Citrix, Netware, GroupWise en scripting. De primaire focus van Michel is het ontwerpen van Microsoft infrastructuur omgevingen, met name op het gebied van Exchange, AD en aanverwante produkten. Michel is ook actief op de (engelstalige) Technet Fora. Je kunt hem vinden in de Exchange, AD, ForeFront en Windows Server topics.
Michel besteed zijn vrije tijd aan vriendin en dochtertje of aan een ritje op de motor.
Kay Sellenrode
Kay Sellenrode is als Technical Consultant bij Platani werkzaam en bezit de specialisaties Messaging en Security. Hij is dan ook een van de weinige Microsoft Certified Masters op Exchange 2007 in Nederland. Naast deze Exchange kennis heeft hij ook uitgebreide kennis van ISA/TMG.
Jaap Wesselius is consultant bij 
Jetze Mellema is Infrastructure Consultant bij 
Johan Veldhuis is System Engineer bij 
Michel de Rooij is Technical Consultant bij 
