NGN: HET PLATFORM VOOR DE ICT PROFESSIONAL

Geplaatst op 12-7-2010 10:31 door Michel de Rooij Met al dat Exchange 2010 geweld zou je bijna vergeten dat menig bedrijf nog oudere versies van Exchange in gebruik hebben. Dat Microsoft deze groep niet vergeet laat ze onder ander zien met het uitbrengen van Exchange 2007 Service Pack 3. Naast dat dit Service Pack installatie van Exchange 2007 op Windows Server 2008 R2 ondersteunt, heeft deze een handige toevoeging met betrekking tot wachtwoordbeheer.

Wie een pre-Exchange 2007 SP3 versie beheert is wellicht bekend met het probleem van het wijzigen van wachtwoorden, of beter, het gebrek daaraan. Wel is het mogelijk door middel van IISADMPWD (zie Q297121) om na het aanloggen het bestaande wachtwoord te wijzigen. Het probleem ontstaat bij organisaties waarbij het wachtwoord van de gebruiker verlopen is. Erg onhandig als je in het buitenland zit en je niet bij je webmail kan om die belangrijke e-mail te lezen omdat je wachtwoord net verlopen is. Dit geldt overigens ook voor OWA gebruikers die hun initiële wachtwoord moeten wijzigen.

Exchange 2007 SP3 introduceert de mogelijkheid om voor het aanloggen reeds het wachtwoord te wijzigen:

Deze functionaliteit moet wel geactiveerd worden voordat deze gebruikt kan worden. Hiertoe dienen op alle Client Access Servers de volgende registry key geconfigureerd te worden:

Key: HKLM\SYSTEM\CurrentControlSet\Services\MSExchange OWA\ChangeExpiredPasswordEnabledValue
Type: REG_DWORD
Value: 1

Overigens, het gerucht gaat dat deze functionaliteit ook toegevoegd wordt in de uiteindelijke versie van Exchange 2010 SP1. Je leest het goed; in Exchange 2010 wordt je nog steeds geacht IISADMPWD te gebruiken.

Geplaatst op 23-6-2010 14:07 door Johan Veldhuis Voor Exchange 2010 moest je nog gebruik maken van 3rd party produkten voor het archiveren van mailboxen. Vanaf Exchange 2010 RTM zit de archiverings functionaliteit echter standaard in Exchange. Hiermee wordt het mogelijk om voor elke gebruiker een persoonlijk archief aan te maken wat dus voorkomt dat gebruikers PST’s gaan aanmaken Naast het aanbieden van het personal archive dien je in dit geval ook nog een Group Policy aan te maken waarin het niet meer toegestaan wordt om PST’s aan te maken.

Eén van de nadelen is echter dat de archief mailbox zich in dezelfde database bevind als de mailbox van de gebruiker zelf. Hiermee is het dusniet mogelijk om het archief in een database te plaatsen welke op goedkopere storage wordt opgeslagen.

In de beta van Service Pack 1 heeft Microsoft echter een belangrijke wijziging doorgevoerd. Het is nu wel mogelijk om de archief mailbox in een aparte database op te slaan. Daarnaast biedt Microsoft de mogelijkheid om het archief in een remote archief te plaatsen. Dit laatste is een service die afgenomen kan worden via Microsoft Online Services. Hierover is op dit moment echter helaas niet meer info beschikbaar maar.

Zoals in het screenshot te zien is vereist de archiverings functionaliteit wel een Exchange Enterprise CAL.

Maar stel dat je nu al de archiverings optie gebruikt van Exchange 2010 kun je dan alsnog de archiverings mailbox verplaatsen naar een andere database? Het antwoord daarop is ja, dit kan middels dezelfde functionaliteit die je gebruikt om een mailbox te verplaatsen van de ene mailbox database naar de andere.

Maar hoe komt de mail nu terecht in het personal archive ?Dit gebeurt middels retention policies. Standaardbevat Exchange 2010 al twee retention policies die je kunt gebruiken, maar natuurlijk kun je ook besluiten er zelf één te maken. De retention policies bevatten één of meerdere retention policy tags. Misschien zul je wel denken hadden we hier in Exchange 2010 RTM niet de managed folders voor. Dat klopt, in Exchange 2010 RTM heeft deze functionaliteit nog de naam managed folders en customer managed folders. Exchange 2010 SP1 gebruikt, net als Exchange 2010 RTM, hiervoor MRM 2.0Eén van de extra functionaliteiten die MRM 2.0 biedt is dat gebruikers zelf kunnen beslissen een andere tag toe te wijzen aan een item. Er zijn drie soort tags:

Retention Policy tags (RPTs)

Deze worden toegepast op de standaard mappen van Outlook. Items welke zich bevinden in de mappen krijgen automatisch de tag toegewezen. Een gebruiker kan er zelf voor kiezen om een andere tag toe te wijzen aan items welke zich in een map bevinden. Een gebruiker kan zelf niet de tag aanpassen welke op de standaard mappen is ingesteld. Daarnaast is er een limiet van één RPT per map.

Default Policy tags (DPTs)

Default Policy tags worden toegepast op objecten die niet getagged zijn door een andere Policy tag.  Een Retention Policy kan slechts één Default Policy tag bevatten.

Personal tags

Gebruikers kunnen zelf persoonlijke tags aanmaken, dit kan alleen wanneer een gebruiker gebruik maakt van Outlook 2010 en Outlook Web App (OWA). Gebruikers kunnen deze Personal tags toewijzen aan mappen die ze zelf hebben aangemaakt of aan items.
Dus kort samengevat: voor het archiveren hebben we een retention policy nodig met hierin één of meerdere retention policy tags.

Hoe configureer je retention policies en retention policy tags?

Dit kan zowel via de Exchange Management Console (EMC) als via de Exchange Management Shell (EMS).
Stel je voor dat we een tag willen aanmaken om items ouder zijn dan 180 dagen naar het archief te verplaatsen.
In de Management Console selecteren we via de organizational configuration het  mailbox item en selecteren vervolgens de tab retention policy tag. Kies vervolgens in het rechter menu de optie new retention policy tag. Dit zal ervoor zorgen dat het volgende venster wordt geopend:

Klik op new en de tag is aangemaakt. Uiteraard kun je dit ook met Powershell doen:
New-RetentionPolicyTag –name “180 days – move to archive” –Type “Personal” –Comment “” –AgeLimitForRetention “180.00:00:00” –RetentionAction “MoveToArchive” –RetentionEnabled $true

Naast dat je retention policy tags kunt gebruiken voor het archiveren kun je deze ook gebruiken om bijvoorbeeld de deleted items map op te schonen. Hiervoor dien je als action to take when the age limit is reached de optie delete and allow recovery te selecteren en als tag type deleted items.

New-RetentionPolicyTag –name “30 days – cleanup deleted items” –Type “DeletedItems” –Comment “” –AgeLimitForRetention “30.00:00:00” –RetentionAction “DeleteAndAllowRecovery” –RetentionEnabled $true

Nu we de tags hebben aangemaakt kunnen we deze gaan gebruiken in een retention policy. Hiervoor gaan we naar de tab retention policies en selecteren hier in het rechter menu de optie new retention policy.

Zoals te zien is in bovenstaand screenshot kunnen we een naam opgeven en vervolgens via Add de zojuist aangemaakte retention policy tags toevoegen. De volgende stap is het selecteren van de mailboxen waarop je de policy op wil toepassen, dit is een optionele stap en je kunt ervoor kiezen om deze policy pas later toe te wijzen aan één of meerdere gebruikers.
Uiteraard kun je dit ook via Powershell doen, dit kan op de volgende manier:
New-RetentionPolicy –name “Company retention policy” –RetentionPolicyTagLinks “180 days – archive”, “30 days – Cleanup deleted items”

Nu we de benodigde configuratie hebben uitgevoerd kun je de policy toe gaan wijzen aan gebruikers. Dit kan  op diverse manieren:

• Via de retention policy zelf: eigenschappen van de policy opvragen, tab mailboxes.
• Via de mailbox: eigenschappen van de mailbox opvragen, tab mailbox settings, eigenschappen van Messaging Records Management opvragen.
• Via Powershell: set-mailbox –identity “Johan Veldhuis” –RetentionPolicy “Company Retention Policy”.

Het kan even duren voordat de wijzigingen zijn doorgevoerd, hier moet namelijk de managed folder assistant een keer voor gedraaid hebben. Deze draait 24 uur per dag en wordt aangestuurd door de throttle service. Wil je dit forceren gebruik dan onderstaand Powershell commando:

start-managedfolderassistant

Hoe kan een gebruiker zijn archief benaderen?

Op dit moment is het alleen nog mogelijk om het archief te benaderen als gebruiker wanneer je beschikt over Outlook 2010 of wanneer je je mailbox opent via Outlook Web App (OWA). Microsoft heeft wel aangekondigd dat er een add-in voor Outlook 2007 komt waarmee het ook mogelijk wordt om je archief te openen.

Hoe het er uit ziet via OWA

Je krijg dus naast de inhoud van je mailbox een extra optie erbij: Online Archive. Hierin bevinden zich alle items die in het archief worden geplaatst.
Zoals al eerder aangegeven kan een gebruiker zelf middels de tags op item niveau een ander archiefbeleid toepassen. In onderstaande afbeelding is hiervan een voorbeeld te zien:

Standaard wordt dus het mappenbeleid gebruikt wat door de beheerder op map niveau ingesteld heeft. Mocht een gebruiker toch besluiten een andere tag hieraan toe te wijzen dan is dit mogelijk.

Let op: de screenshots en informatie uit dit document zijn gebaseerd op Exchange 2010 Service Pack 1 Beta. Het is dan ook mogelijk dat de screenshots/functionaliteit nog gewijzigd wordt.

Geplaatst op 21-6-2010 11:02 door Jetze Mellema Al eerder schreef ik over Outlook 2003 met Exchange 2010, toen ben ik in gegaan op encryptie en de juiste instellingen om Exchange en Outlook met elkaar te laten praten. In de praktijk is er nog een ander in het oog springend issue, iets wat lastiger op te lossen is helaas.

Wanneer je Outlook 2003 in Online Mode draait, vertrouwt Outlook op UDP notificaties om het scherm te verversen. Wanneer je bijvoorbeeld een bericht verwijdert zal Exchange, na een succesvolle verwijderding,  aan Outlook terugkoppelen dat het bericht niet meer in de huidige map getoond moet worden maar bijvoorbeeld in de map Deleted items. Het zelfde zie je als je Outlook op twee computers aan hebt staan en op de ene computer een mailtje verwijdert, ook Outlook op de andere computer wordt op de hoogte gebracht van de verwijdering en zal het scherm aanpassen.

Het probleem met Outlook 2003 in Online Mode is dat Exchange 2010 geen UDP notificaties meer geeft. Hierdoor valt Outlook 2003 terug op ‘plan B’, namelijk dat hij periodiek aan Exchange vraagt of er nog updates zijn voor de schermweergave. De standaard polling interval is 60 seconden.

Wat betekent dit voor de gebruikers? Als een gebruiker een mail verwijdert dan blijft het bericht gewoon in beeld staan, als gebruiker hem nogmaals probeert te verwijderen geeft Outlook een ‘An unknown error has occurred’ of ‘Er is een onbekende fout opgetreden’. Na afsluiten en weer opstarten van Outlook is het bericht wel verwijderd, hoewel gebruiker ook gewoon maximaal 60 seconden kan wachten tot Outlook het scherm ververst.

Er zijn 3 min of meer bruikbare oplossingen voor dit verschijnsel:

1. Schakel over op Cached mode. Houd rekening met het OST-bestand wat Outlook aan zal maken, niet geschikt voor Outlook op Terminal Servers.
2. Upgrade naar Outlook 2007 of hoger.
3. Verklein de polling interval naar 10 seconden, wat het minimum is wat door Outlook 2003 ondersteund wordt.

Dat laatste kun je doen door op de servers met de Client Access rol de volgende registry key aan te maken:

Subkey: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeRPC\ParametersSystem
Type: DWORD
Naam: Maximum Polling Frequency
Waarde: 10000 (decimaal)

Zorg wel dat minimaal Update Rollup 1 voor Exchange 2010 geïnstalleerd moet zijn. Deze wijziging geldt voor alle connecties die nu met de server gemaakt worden, bestaande connecties gebruiken nog de oude waarde.

Een echte oplossing is dit niet, maar het zorgt er wel voor dat de overlast iets beperkt wordt.
Geplaatst op 4-6-2010 09:38 door Jetze Mellema Wanneer een Exchange 2010 gebruiker in Outlook Web App naar Opties gaat, komt hij ongemerkt in het Exchange Control Panel. Nou ja, niet helemaal ongemerkt want als je naar de url in de adresbalk kijkt dan zie je de ‘ecp’ vDir staan:

De gebruiker kan daar een grote hoeveelheid instellingen aanpassen, waaronder een aantal waar voorheen een helpdesk of beheerder gebeld moest worden. Zo ook bijvoorbeeld het aanpassen van zijn telefoonnummer of adresgegevens. Nu is dit niet voor ieder organisatie even aantrekkelijk, het is heel g0ed mogelijk dat men dit graag centraal wil regelen en dat de gebruiker deze gegevens niet aan mag passen. Hoe doen we dat?

Alle beheerfunctionaliteit is in Exchange 2010 toegewezen op basis van Role Based Access Control (RBAC), ook de mogelijkheid voor een gebruiker om zijn eigen contactgegevens aan te passen. Om dit aan te passen voor alle gebruikers kunnen we een rol verwijderen uit de standaard policy voor gebruikers.

De makkelijkste manier is om ook als beheerder het ECP te gebruiken. Log in op OWA en klik op Opties, bent nu in het ECP. Bij ‘Kies wat er moet worden beheerd:’ kies je Mijn organisatie:

Klik op Gebruikersrollen. Bij een standaardinstallatie vinden we hier maar één policy, de Default Role Assignment Policy:
Dubbelklik er op om de policy te kunnen bewerken:
In dit scherm zien we dat we deze 4 rollen makkelijk toe kunnen wijzen door een vinkje te zetten of te verwijderen, er zijn nog meer rollen maar om die te wijzigen gebruik je de Exchange Management Shell (EMS).

In ons voorbeeld halen we het vinkje weg voor Mijn contactgegevens, en klikken we op Opslaan. That’s it. Geplaatst op 12-5-2010 11:14 door Jetze Mellema Onlangs kreeg ik de volgende vraag in mijn mailbox: "Ik heb een probleem met een certificaatfout bij outlook web exchange. Onze server is https://61.236.1.137/exchange zodra je deze site bezoekt krijg ik de foutmelding. Nieuwe gebruikers met thuis Windows Vista kunnen nu helemaal niks meer door deze foutmelding."

Bij navraag bleek het te gaan om een server met Small Business Server 2003 die blijkbaar netjes geconfigureerd is met de Configure E-mail and Internet Configuration Wizard (CEICW). Laten we eens kijken wat er precies gebeurt als we naar die url toe gaan met onze browser:



Daar lezen we dat het certificaat van deze website niet is uitgegeven door een vertrouwde Certificate Authority. Dit betekent dat we niet met zekerheid vast kunnen stellen of deze website wel de site is dit we denken dat het is, misschien staat de site wel op een server die probeert ons wachtwoord te stelen. Naast de controle op de uitgever van het certificaat zal de browser ook de geldigheidsdatum van het certificaat controleren en ten slotte kijkt hij of de hostnaam in de adresbalk overeenkomt met de naam die op het certificaat staat. Als één of meer van die controles mislukken, dan wordt de gebruiker lastig gevallen met deze waarschuwing.

Bij dit voorbeeld is de waarschuwing relatief onschuldig en te verwachten bovendien. In de volgende stappen gaan we dit probleem oplossen, waarna de gebruiker niet meer wordt lastig gevallen door deze waarschuwing.

Om te beginnen openen Windows Vista of 7 gebruikers een ‘elevated’ Internet Explorer. Zoek in het Start Menu de snelkoppeling voor Internet Explorer, bijvoorbeeld voor het woord ‘internet’ in het zoekvakje te typen. Klik op de snelkoppeling met de rechtermuisknop en kies voor Run as Administrator.

In het browservenster wat nu geopend wordt typen we het adres van de website in de adresbalk. Wanneer bovenstaande waarschuwing verschijnt klikken we op Continue to this website (not recommended). De adresbalk kleurt rood en de website verschijnt in beeld:

Om meer te weten over het probleem met het certificaat klikken we op Certificate Error. Nu volgt nog eens een duidelijke uitleg van het probleem, de uitgever van het certificaat wordt door onze computer niet vertrouwd:

Omdat we dat certificaat wel eens willen zien klikken we op View certificates, het certificaat wordt nu getoond:

Ook hier worden we nog een keer geattendeerd op het feit dat de uitgever van dit certificaat niet vertrouwd wordt. Ook wordt uitgelegd dat we, om deze uitgever in het vervolg wel te vertrouwen, het certificaat kunnen installeren in de Trusted Root Certification Authorities store. Die ‘store’ kun je vergelijken met een opbergkast in je computer, in die kast zitten een aantal vakjes en worden de diverse certificaten opgeslagen. Eén van die vakjes is bestemd voor uitgevers van certificaten die wij vertrouwen, in dat vakje willen wij dit certificaat dus plaatsen.

Dat doen we door op de knop Install Certificate… te klikken. Er start nu een wizard waarbij we op de eerste pagina op Next klikken. Op de volgende pagina mogen we kiezen waar we dit certificaat willen installeren, klik op Browse en kies de Trusted Root Certificate Authorities store:

Bevestig de keuze met een klik op OK en vervolg de wizard door op Next en vervolgens op Finish te klikken. De volgende waarschuwing verschijnt nu:

Dit is misschien wel de belangrijkste vraag in het hele proces. Om zeker te weten dat je een certificaat installeert van de juiste website zou je nu eigenlijk de beheerder van de site moeten bellen om te vragen of deze vingerafdruk (Thumbprint) overeenkomt met die op het certificaat wat hij aan de echte website gekoppeld heeft. Maar in de praktijk zal dat zelden gebeuren. Dus klikken we op Yes, bevestigen de keuzes nog twee keer met een klik op OK en sluiten alle openstaande browservensters. Die laatste stap is belangrijk om zeker te weten dat de wijziging opgepikt wordt door Internet Explorer, voordat we dit gaan testen.

We openen vervolgens een nieuwe browser en gaan weer naar de bewuste url. We krijgen nu geen waarschuwing meer en de adresbalk kleurt niet meer rood:

Let op het gesloten slotje wat rechts van het adres staat, deze geeft aan de alle controles geslaagd zijn en dat er een versleutelde verbinding is opgebouwd. Het is nu veilig om in te loggen met je gebruikersnaam en wachtwoord, deze zullen niet eenvoudig afgeluisterd kunnen worden.

Tip voor beheerders

Wanneer jij een server beheert waarbij je een self-signed certificaat gebruikt, dat wil zeggen een certificaat wat standaard niet door internetbrowsers vertrouwd wordt, maak dan een verkorte handleiding voor je gebruikers. Laat de uitleg weg en geef alleen de te nemen stappen, eventueel met screenshots van een Nederlandstalige versie van Windows.

Maar overweeg ook eens om een certificaat aan te schaffen bij een uitgever van certificaten die vertrouwd wordt door de client computers. De kosten voor een certificaat wat 3 jaar geldig is zullen niet veel hoger uitvallen dan zo’n 300 euro. (prijsindicatie Digicert) Reken maar eens uit wat het kost als je 150 gebruikers elk een kwartiertje bezig zijn met bovenstaande handleiding, en dat opnieuw zullen doen voor een andere werkplek of mobile device. Een officieel certificaat duur? Dat valt dus best wel mee.
Geplaatst op 26-4-2010 09:15 door Jetze Mellema Wanneer ik met klanten over een implementatie van Exchange 2010 spreek, dan is een vaak gestelde vraag welke versies van Outlook ze kunnen gebruiken in combinatie met Exchange 2010. Het antwoord daarop is simpel: Outlook 2003 en hoger worden door Microsoft ondersteund in combinatie met Exchange 2010.  Natuurlijk mis je in Outlook 2003 handige features als MailTips en kun je het Personal Archive niet benaderen, maar alle basic functionaliteit werkt gewoon.

En toch lopen veel mensen tegen problemen aan wanneer ze met Outlook 2003 verbinding willen maken met een mailbox op Exchange 2010. De oorzaak daarvan is meestal encryptie. Exchange 2010 vereist namelijk dat MAPI/RPC verkeer tussen client en server versleuteld is, wanneer een client onversleuteld verbinding probeert te maken krijgt hij een foutmelding. Afhankelijk van het exacte scenario kunnen dat 9 verschillende foutmeldingen zijn, waaronder:

• Kan uw standaardmappen voor e-mail niet openen. Kan het informatiearchief niet openen.
• Kan Microsoft Outlook niet starten. Kan het Outlook-venster niet openen. Kan de set mappen niet openen. De server is niet beschikbaar. Neem contact op met de beheerder als deze situatie zich blijft voordoen.
• Kan geen verbinding met de computer met Microsoft Exchange Server maken omdat er netwerkproblemen zijn opgetreden. Als dit probleem blijft bestaan, neemt u contact op met de systeembeheerder.

De 6 andere foutmeldingen zijn varianten op bovenstaande, het komt er op neer dat Outlook 2003 geen verbinding kan maken met de database. Daarnaast zie je bij clients die in Cached Mode draaien, dat de status rechts onder op Disconnected blijft staan.

In principe zijn er 2 oplossingen: Outlook aanpassen of Exchange. In het Outlook 2003 profiel kunnen we op het tabblad Security een vinkje zetten voor Encrypt data between…

Voor een enkele werkplek is het probleem hiermee opgelost, voor een gecentraliseerde oplossing voor alle werkplekken zul je dit liever met een GPO doen, in combinatie met de Office 2003 Administrative Templates.

Een minder fraaie oplossing is een aanpassing in Exchange 2010. De vereiste voor encryptie is een instelling op de Client Access server namelijk. Door die uit te schakelen kan ook een Outlook client verbinden welke geen gebruik maakt van versleuteling, maar dit gaat ten koste van het beveiligingsniveau van de oplossing. Je vindt deze property met de cmdlet Get-RpcClientAccess en kunt hem aan op uitschakelen met Set-RpcClientAccess:

Set-RpcClientAccess -Server -EncryptionRequired $false

Misschien ten overvloede, maar deze aanpassing is dus niet aanbevolen. Beter is het om de instelling van Outlook aan te passen, zodat de verbinding met Exchange 2010 versleuteld wordt.
Geplaatst op 25-3-2010 16:18 door Peter Noorderijk Wanneer je op regelmatige basis een e-mail moet versturen naar een groep gebruikers dan is het praktisch om deze gebruikers te groeperen in een distributiegroep. Je hoeft dan, wanneer je het e-mail bericht gaat opstellen, niet telkens na te denken over de geadresseerden. Door het e-mail bericht te sturen naar een distributiegroep ontvangen alle leden van de groep automatisch het betreffende bericht. Echter is het zaak om deze distributiegroepen wel voor de juiste doeleinden te gebruiken. Wanneer je een distributiegroep aanmaakt met daarin alle Exchange beheerders dan maak je deze groep waarschijnlijk met als doel Exchange gerelateerde berichten te sturen naar deze groep. E-mail berichten die gaan over SQL zijn voor deze groep niet relevant en vaak ook niet gewenst.

Exchange 2010 introduceert gemodereerde distributiegroepen. Door een moderator aan te wijzen voor een distributiegroep kun je voorkomen dat niet relevante of niet gewenst berichten de groep niet bereiken. In dit blogartikel wil ik uitleggen hoe je een distributiegroep aanmaakt en hoe moderatie werkt.

Hoe maak je een distributiegroep aan?

Een distributie groep kun je aanmaken vanuit de Exchange Management Console en vanuit de Exchange Management Shell. Het aanmaken van een distributiegroep met behulp van de Exchange Management Console is heel heel eenvoudig.

Het beheer van distributiegroepen vind je terug onder ‘Recipient Configuration’ –> ‘Distribution Group’ (It’s in the name). Je kunt nu twee typen distributiegroepen aanmaken; normale distributiegroepen of dynamische distributiegroepen. Het verschil zit in de manier waarop de leden van de groep worden samengesteld. Bij een normale distributiegroep moet je handmatig leden toevoegen aan de groep. Bij een dynamische distributiegroep worden de leden samengesteld op basis van een gedefinieerd kenmerk. Echter is moderatie op een dynamische distributiegroep niet mogelijk! Wil je gebruik maken van moderatie dan moet je dus kiezen voor een normale distributiegroep.

Door te klikken op ‘New Distribution Group’ wordt de wizard gestart en kun je aangeven in welke OU de distributiegroep geplaatst moet worden, wat de naam van de groep wordt en welke alias je wilt gebruiken. Vanuit de Exchange Management Shell kun je met het volgende commando een groep aanmaken die Exchange beheerders heet, als alias exchange_beheerders krijgt en in de OU ‘Distribution Groups’ geplaatst wordt:

new-DistributionGroup -Name 'Exchange beheerders' -Type 'Distribution' -OrganizationalUnit 'virtuall.local/Virtuall/Special Users and Groups/Distribution Groups' -SamAccountName 'Exchange beheerders' -Alias 'exchange_beheerders'

Hoe wijs ik een moderator aan?

Nu we een distributiegroep hebben aangemaakt gaan we een moderator van de groep aanwijzen. Door de eigenschappen van de groep op te vragen en vervolgens naar het tabblad ‘Mail Flow Settings’ te gaan zien we de optie ‘Message Moderation’. Selecteer deze optie en kies vervolgens voor properties. Nu verschijnt het venster waarin we een moderator kunnen aanwijzen:

Door een vinkje te zetten voor ‘Messages sent to this group have to be approved by a moderator’ wordt moderatie ingeschakeld. In bovenstaande voorbeeld is de gebruiker Peter Noorderijk aangewezen als moderator voor de groep. Ook is er een uitzondering geconfigureerd; e-mailberichten die door de gebruiker Jetze Mellema gestuurd worden zullen niet gekeurd worden door de moderator. Als laatste kun je nog instellen wie er notificatie ontvangen in het geval dat een bericht afgekeurd wordt.

 

Ennuh… nu een voorbeeldje?

Nu er een moderator is aangewezen gaan we eens kijken hoe dit in de praktijk werkt. We gaan vanuit de mailbox van de gebruiker ‘Virtuall’ een e-mail bericht sturen naar de groep ‘Exchange beheerders’ met als onderwerp SQL 2008:

De oplettende lezer ziet dat er boven in het e-mailbericht een MailTip verschijnt met de melding dat je naar een distributiegroep gaat e-mailen die onder toezicht staat. Het inschakelen van deze MailTip is wel aan te raden. Hierdoor stel je de gebruiker vroegtijdig op de hoogte van het feit dat het e-mailbericht geweigerd of uitgesteld kan worden (meer informatie over MailTips vind je in een eerdere post van mij: MailTips).

Helaas hebben we hier te maken met een minder oplettende gebruiker en besluit de gebruiker het e-mailbericht toch te sturen. Het e-mailbericht zal dan eerst ter goedkeuring aan de moderator van de groep worden aangeboden. Het originele e-mailbericht wordt als bijlage meegezonden:

Aangezien dit bericht niet voor Exchange beheerders bestemd is kan de moderator dit bericht afwijzen. Door te kiezen voor de optie ‘Het antwoord bewerken voor verzending’ kan de moderator nog een persoonlijke boodschap meegeven. Wanneer de moderator kiest voor ‘Goedkeuren’ zal het bericht naar alle leden van de groep gestuurd worden. De verzender van het bericht krijgt in de bovenstaande situatie netjes het bericht dat het e-mailbericht afgewezen is:

Door gebruik te maken van moderatie voorkom je dat niet gewenste e-mailberichten bij een distributiegroep terecht komen. De leden van deze groep hoeven geen inspanning te verrichten om dit bericht te bekijken of hierop te reageren.

Wanneer je binnen je organisatie te maken hebt met ‘onzin’ berichten die gestuurd worden naar lukrake distributiegroepen dan adviseer ik om zo snel mogelijk te migreren naar Exchange 2010!

Geplaatst op 15-3-2010 13:08 door Peter Noorderijk Exchange 2010 heeft een mooie wizard voor het aanmaken/ aanvragen van een certificaat, helaas kun je deze wizard niet altijd gebruiken…

De Exchange 2010 wizard

Exchange 2010 heeft een grafische wizard welke helpt met het aanvragen en installeren van een certificaat. Wanneer je een publiek certificaat wil aanvragen dan moet je een certificate signing request (CSR) aanmaken. In zo’n CSR staat bijvoorbeeld de informatie over het bedrijf dat het certificaat gaat gebruiken en de URL’s waarvoor het certificaat moet gelden. Wanneer je de wizard in Exchange 2010 gebruikt dan selecteer je de diensten waarvoor je het certificaat wil gebruiken. Aan de hand van de geselecteerde diensten worden de juiste URL’s in het CSR opgenomen en verschijnen uiteindelijk de juiste URL’s op het certificaat. Wanneer je een certificaat request wil maken voor de Exchange 2010 diensten AutoDiscover en Outlook Web App dan kun je hiervoor de wizard gebruiken:

Wanneer je de diensten hebt geselecteerd die je wilt gaan gebruiken dan heb je ook nog de mogelijkheid om alternatieve URLs toe te voegen. Daarnaast moet je nog selecteren wat de zogenaamde Common Name (CN) van het certificaat wordt:

 

Door een FQDN te selecteren en vervolgens te klikken op ‘Set as Common Name’ stel je de CN in. Vervolgens kun je de gegevens van je organisatie invullen en uiteindelijk wordt er een zogenaamd ‘.req’ bestand aangemaakt. Hoewel je de wizard gebruikt, wordt er onderwater natuurlijk gewoon een Exchange Management Shell commando geïnitieerd. Dit commando ziet er als volgt uit:

New-ExchangeCertificate -FriendlyName 'Test' -GenerateRequest -PrivateKeyExportable $true -KeySize '2048' -SubjectName 'C=NL,S="Utrecht",L="De Meern",O="Virtuall",OU="Systeembeheer",CN=webmail.virtuall.nl' -DomainName ‘server1.virtuall.local','server2.virtuall.local','webmail.virtuall.nl','autodiscover.virtuall.local','autodiscover.virtuall.nl' -Server 'server1'

De inhoud van het req bestand is nodig bij de certificaat aanvraag. Een req bestand kan er als volgt uitzien:

-----BEGIN NEW CERTIFICATE REQUEST-----
MIIEljCCA34CAQAwezEcMBoGA1UEAwwTd2VibWFpbC52aXJ0dWFsbC5ubDEWMBQG
A1UECwwNU3lzdGVlbWJlaGVlcjERMA8GA1UECgwIVmlydHVhbGwxETAPBgNVBAcM
CERlIE1lZXJuMRAwDgYDVQQIDAdVdHJlY2h0MQswCQYDVQQGEwJOTDCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBANPFLiULJ9yVUaKAVjc9PrzjbgjPy69f
Nwffaf8Hu9aydhbD7DHmP7HGwbHEedGLZMqLE4V4D1o5XY7VKXVYD4DlGvDfkJE8
U/l76RWIdQboEuysRl75IXK+i9PgP8Zt9bAkyDb+qKpUyPligJsqDqNPx7e/PF2l
tVedDivUo7wAJUMC8FckiOGpKjp5mLIilRMIJFcY2KMuiq6rlc+7ETHi8Iuzca41
D/yNJ5ZhqqfsdZp0S6dANuN+S0oBpVtq6IHpyhGks3H1HCrjqmK+bk50pZ5vyn+8
ulyd8Fdt7PWaTlU30XQ6xiGPlr4ykdKXDkduJzCNJYvEwMxGBNkVgVcCAwEAAaCC
AdQwGgYKKwYBBAGCNw0CAzEMFgo2LjEuNzYwMC4yMGMGCSsGAQQBgjcVFDFWMFQC
AQUMF3BvcnRsYW5kLnZpcnR1YWxsLmxvY2FsDBJWSVJUVUFMTFxQT1JUTEFORCQM
Ik1pY3Jvc29mdC5FeGNoYW5nZS5TZXJ2aWNlSG9zdC5leGUwcgYKKwYBBAGCNw0C
AjFkMGICAQEeWgBNAGkAYwByAG8AcwBvAGYAdAAgAFIAUwBBACAAUwBDAGgAYQBu
AG4AZQBsACAAQwByAHkAcAB0AG8AZwByAGEAcABoAGkAYwAgAFAAcgBvAHYAaQBk
AGUAcgMBADCB3AYJKoZIhvcNAQkOMYHOMIHLMA4GA1UdDwEB/wQEAwIFoDCBiwYD
VR0RBIGDMIGAghdwb3J0bGFuZC52aXJ0dWFsbC5sb2NhbIIZY2luY2luYXR0aS52
aXJ0dWFsbC5sb2NhbIITd2VibWFpbC52aXJ0dWFsbC5ubIIbYXV0b2Rpc2NvdmVy
LnZpcnR1YWxsLmxvY2FsghhhdXRvZGlzY292ZXIudmlydHVhbGwubmwwDAYDVR0T
AQH/BAIwADAdBgNVHQ4EFgQUgz09LrIIAbvKfxqUz4qVCMvWkXMwDQYJKoZIhvcN
AQEFBQADggEBADypoODwhHiijP/QdkvRPt4LrZz+9U95ccK46i+5eHmvhWDpA/kK
yt3Dv3PTnZqWGC7wsI36U8+HXDzaymyvcSdgvHzJ6WLMofVP5ZVwhue/dhU8JAaJ
iO6x6kYRsCI1vyamEPEzSi62D2BwjcYq3OxRdKPOPV22gtJXtZThhy9NP8ue0eae
8zyZ90rg+x99KHdWvFeCjG3pPr3KVUvxXmQ8FJ7lYlihUjMk/ub68k6Zfk2bKkuz
ssTtvEVTWY8GF/+Im3WY2QRGQhx4UVkREcbfbIcSvU4jGImi4I1gV4vtuIC1ygfy
rArWAKrprVvJq8d9z3xkUtsfi7DhUkBLfXI=

-----END NEW CERTIFICATE REQUEST-----

Problemen bij het aanvragen van een certificaat

Nu wordt het req bestand zoals het door de Exchange 2010 wizard gegenereerd wordt helaas niet door alle instanties, die certificaten uitgeven, geaccepteerd. Het eerste probleem zit in de witregel voor ----END NEW CERTIFICATE REQUEST---- Sommige instanties controleren hierop en tijdens de aanvraag krijg je de melding dat er een fout in de SAN options zit. Helaas wordt je niet verteld dat dit vanwege de witregel in het req bestand is. De oplossing voor dit probleem is erg eenvoudig: haal de witregel weg :-D

Een tweede punt waarop een certificaat aanvraag kan mislopen is dat zowel bij de optie ‘CN’ als bij ‘DomainName’ een zelfde FQDN staat. Wanneer we even terug kijken naar het Exchange Management Shell commando dan staat er CN=webmail.virtuall.nl’. de FQDN webmail.virtuall.nl zie je echter ook terug achter DomainName. Hier vallen sommige instanties over en ook nu wordt tijdens de aanvraag de melding gegeven dat er een fout in de SAN options zit. Nu is dit geen Exchange 2010 probleem maar een probleem van de instantie waar het certificaat wordt aangevraagd. Als je perse bij deze instantie een certificaat wil aanvragen dan moet je de Exchange Management Shell gebruiken voor het aanmaken van een CSR. Hierbij haal je de FQDN die achter de optie CN staat weg bij de optie DomainName. Om e.e.a. te verduidelijken hier het commando:

New-ExchangeCertificate -FriendlyName 'Test' -GenerateRequest -PrivateKeyExportable $true -KeySize '2048' -SubjectName 'C=NL,S="Utrecht",L="De Meern",O="Virtuall",OU="Systeembeheer",CN=webmail.virtuall.nl' -DomainName ‘server1.virtuall.local','server2.virtuall.local', ’autodiscover.virtuall.local','autodiscover.virtuall.nl' -Server 'server1'

Het request dat door bovenstaand commando wordt gegenereerd wordt wel geaccepteerd. Zo zie je maar weer dat de we soms niet om de EMS heen kunnen.

Geplaatst op 1-3-2010 11:14 door Peter Noorderijk Wanneer je een (langdurige) transitie ingaat van Microsoft Exchange 2003 naar Microsoft Exchange 2010 dan wil je dit het liefst doen met zo weinig mogelijk hinder voor je eindgebruikers. Wanneer we bijvoorbeeld kijken naar de toegang tot webmail dan is het meest ideale scenario dat je voor al je eindgebruikers (gemigreerd naar Exchange 2010 of niet) dezelfde URL kunt aanbieden. In een transitie van Exchange 2003 naar Exchange 2010 is dit mogelijk door een zogenaamde ‘legacy’ redirect die Exchange 2010 uitvoert.

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:

De client gaat vanuit zijn browser dus naar https://webmail.virtuall.nl/. Op de externe interface van de ISA server luistert de weblistener naar dit verzoek en stuurt dit verzoek door naar de Exchange 2010 CAS server. Echter heeft de gebruiker nog een mailbox op de Exchange 2003 server. De Exchange 2010 server zal dus een redirection uitvoeren naar legacy.virtuall.nl. Deze URL wordt middels de ISA server weer teruggegeven aan de client. Op de client vind in de browser een redirection plaats naar de legacy url.

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!

Geplaatst op 17-2-2010 10:19 door NGN 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. Geplaatst op 1-2-2010 14:31 door Johan Veldhuis Je hebt de berichten vast weleens gelezen in kranten of op websites: E-mail blijft het grootste digitale middel om bedrijfsgeheimen mee te lekken. Bij 43 procent van de Amerikaanse bedrijven ontstond daardoor een lek in het afgelopen jaar. Daardoor ontsloegen 31 procent van de bedrijven een werknemer. (Bron: nuzakelijk.nl)
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

Met IRM wordt het mogelijk om informatie te beveiligen zodat het lekken van informatie moeilijker wordt gemaakt.  Het lekken van informatie kan ernstige gevolgen hebben voor een bedrijf, denk hierbij aan:

• 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.

IRM bestaat uit een server deel en een client deel. Het server gedeelte is in Windows 2008 een server rol welke geïnstalleerd kan worden op een server. De rol is terug te vinden onder de naam Active Directory Rights Management System en maakt o.a. gebruik van IIS en .NET.
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

Je kan bijvoorbeeld instellen dat een gebruiker alleen maar een document kan printen maar niet kan bewerken. Of zelfs alleen een document kan openen om te lezen maar dit niet kan printen.

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.

Om Exchange te configureren voor het gebruik van IRM dienen we voor een groot gedeelte gebruik te maken van de Exchange Management Shell. Hierin zijn o.a. de volgende commando’s beschikbaar:

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: Disabled, schakelt decryptie van berichten uit. Mandatory, berichten die niet gedecrypt kunnen worden worden verwijdert. Optional, er wordt geprobeerd het bericht te decrypten, lukt dit niet dan wordt het bericht alsnog afgeleverd.
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.

Geplaatst op 27-1-2010 09:26 door Kay Sellenrode 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. Geplaatst op 22-1-2010 12:18 door Sander van den Burg Met de recente release van Exchange 2010 heeft Microsoft ook een aantal nieuwe features geïntroduceerd. De bekendste en meest in het oogspringende veranderingen zijn natuurlijk Database Availability Groups (DAG), de volledige Outlook Web Access (OWA) versies voor third-party browsers en de nieuwe archiving mogelijkheden.
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

Net als bij deze 2 technologieën geldt ook voor archiving dat de huidige Microsoft oplossing op dit moment nog niet kan concurreren met de huidige third-party oplossingen.
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

(Hierbij geldt natuurlijk dat de ondersteuning van Outlook 2007 ook geïmplementeerd moet worden in Outlook zelf, een verantwoordelijkheid van het Outlook team. Het officiële statement van het Outlook team op dit moment is: "currently under review")

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.
Geplaatst op 19-1-2010 14:12 door Jaap Wesselius In Exchange Server 2003 is het Sender ID voor het eerst beschikbaar in de continue strijd tegen spam. Met Exchange Server 2007 werden de anti-spam mogelijkheden sterk verbeterd en die lijn is doorgetrokken met Exchange Server 2010.

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:

1. Een gebruiker stuurt van Server A een mailtje naar een gebruiker op Server B;
2. Server B ontvangt het mailtje van Server A;
3. 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.

Geplaatst op 14-12-2009 10:13 door Jetze Mellema Een paar jaar geleden ging mijn huisarts met pensioen en kwam ik voor het eerst bij zijn opvolger, een jonge vent die net zijn eigen praktijk geopend had. Nog voordat ik iets over mijn klacht kon vertellen informeerde hij naar mijn werk, hoe lang ik al in deze plaats woonde en hoe het met mijn vrouw en kinderen gesteld was. Terwijl ik hier wat over vertelde keek hij in de computer en zag welke medicijnen ik gebruikte en de uitslag van mijn laatste bloedonderzoek. Gecombineerd met mijn verhaal gaf dit een indruk van de persoon die tegenover hem zat, wat hem beter in staat stelt om mijn verhaal aan te horen en daar op de juiste manier op te reageren.
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.

Geplaatst op 8-12-2009 12:04 door Michel de Rooij 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.

Rechten in Exchange 2007 worden gemanaged via de Exchange Management Console of via de cmdlets Add-ExchangeAdministrator, Get-ExchangeAdministrator en Remove-ExchangeAdministrator. Recipient Administrators krijgen standaard rechten op alle recipients binnen de Exchange organisatie. Domein of OU delegaties zijn mogelijk maar hiervoor moet de trukendoos open.

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.


Geplaatst op 13-11-2009 10:38 door Michel de Rooij 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). Geplaatst op 12-11-2009 10:34 door Jetze Mellema 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!

Geplaatst op 5-11-2009 11:16 door Johan Veldhuis Zoals je misschien al weet bestaat een storage group van Exchange naast de database file uit:

• 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.

Voordat de data in de database terecht komt worden eerst een aantal stappen doorlopen zoals in onderstaand schematisch overzicht:

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.

Zoals in een eerder blog in het NGN Exchange Thema blog besproken, is het mogelijk in te stellen hoeveel log bestanden er “verloren” mogen gaan met de AutoDatabaseMountDial parameter:

• 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

De werking van LLR wordt beïnvloed door de ingestelde LLR diepte. De LLR diepte is de waarde van de AutoDatabaseMountDial parameter + 1.  Wanneer er gebruik wordt gemaakt van een CCR in Exchange 2007 SP1 dan is de LLR diepte hard gecodeerd met de waarde 10. De waarde van de AutoDatabaseMountDial parameter wordt in dit geval genegeerd. De hard gecodeerde waarde voor niet CCR omgevingen is  1, dit geld zowel voor Exchange 2007 RTM als SP1.

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:

1. Pauzeer de replicatie tijdelijk
2. Schakel circular logging in/uit
3. Dismount de database en mount deze vervolgens weer
4. 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 ;-) Geplaatst op 29-10-2009 10:30 door Jetze Mellema 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. Geplaatst op 28-10-2009 10:11 door Jetze Mellema 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

(*) Aanbevolen wordt om databases aan te houden die kleiner zijn dan 2 TB.

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:

Exchange Client Access License (CAL)	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

(**) Updates voor Outlook Mobile op Windows Mobile 6.1 en hoger.
(***) 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!
Geplaatst op 3-10-2009 14:41 door Jaap Wesselius

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: of via de Exchange Management Console -> server configuration -> mailbox en hier de database te selecteren en vervolgens de optie mount te selecteren.

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 |fl te draaien. Dit geeft onderstaande output:

 
Wanneer we nu de AutoDatabaseMountDial parameter willen wijzigen dienen we dit via het commando set-mailboxserver -AutoDatabaseMountDial: uit te voeren.
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 -ForcedDatabaseMountAfter: uit te voeren.

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.

Geplaatst op 4-9-2009 11:55 door Jaap Wesselius

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

Geplaatst op 16-7-2009 13:11 door Ed Wens

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 Technical Consultant 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 Dimension Data, 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.

Peter Noorderijk

Peter Noorderijk is als Infrastructuur Consultant werkzaam bij PQR, een organisatie die als Microsoft Gold Partner, Citrix Platinum Solution Advisor, VMware Premier en Gold Authorized Consultant Partner in Nederland vooraan loopt bij het ontwerpen, implementeren en migreren van geavanceerde ICT-Infrastructuren. Peter houdt zich bezig met “Back-end”  virtualisatie, Microsoft UM oplossingen, Microsoft Active Directory en de System Center producten.

Uitgebreidere bio's staan hier

Jetze Mellema is Infrastructure Consultant bij PQR en is ook MVP Exchange Server. Hij richt zich op het ontwerpen en bouwen van Microsoft-omgevingen.

Peter Noorderijk is Infrastructuur Consultant bij PQR en houdt zich bezig met back-end virtualisatie en Unified Messaging.

Johan Veldhuis is Technical Consultant bij Communicativ, hierbij is hij bezig met Microsoft-, Lefthand- en Citrixoplossingen. Ook Johan is MVP Exchange Server.

Michel de Rooij is Technical Consultant bij Dimension Data*. Michel zijn aandachtsgebied is, maar is niet beperkt tot, het ontwerpen en bouwen van MS omgevingen.

Kay Sellenrode is technical consultant bij Platani en is MCM Exchange. Hij heeft zich gespecialiseerd in Messaging en Security.