Onderhoud aan een Exchange 2010 DAG member

Bij een slim ontworpen Exchange 2010 omgeving kun je onderhoud plegen aan de servers zonder de productie in gevaar te brengen, dus zonder dat de gebruikers er iets van merken. Voor de Hub Transport en Client Access rollen zorgen we dat deze verwijderd zijn uit de actieve pool van servers in de load balancer. Voor de mailbox rol betekent dit dat hij tijdelijk geen actieve kopieën van de databases mag hosten. In dit artikeltje beschrijf ik op welke manier we dit kunnen bereiken.

Client Access en Hub Transport

Wanneer de DAG member naast de Mailbox rol ook de Client Access en Hub Transport rol heeft dan moeten we zorgen dat de load balancer geen verbindingen meer gaat maken met deze server. In dit voorbeeld gebruik ik een KEMP LoadMaster load balancer maar het principe is vergelijkbaar bij andere load balancers. Om een server uit de roulatie te halen gaan we in de webinterface naar Real Servers, door op Disable te klikken nemen we een server tijdelijk uit gebruik:

De load balancer zal nu geen nieuwe verbindingen meer opzetten naar deze server. Bestaande verbindingen blijven gewoon actief totdat de ingestelde tijd voor dit weglekken (drainen) van de connecties verlopen is. Op dat moment worden de laatste connecties verbroken en is de server definitief uit de pool verwijderd. Bij een KEMP LoadMaster kunnen we het aantal connecties monitoren door naar Statistics te gaan in het hoofdmenu.

In de kolom Active Conns zien we hier bijvoorbeeld 200 connecties staan voor de real server met het IP-adres wat op .113 eindigt. We zien nu dat dit aantal afneemt omdat er geen nieuwe connecties meer opgezet worden naar deze real server.

Mailbox

Voor de mailboxrol is het onder andere van belang dat de server geen actieve mailboxdatabases meer host, en dat er tijdens het onderhoud ook geen databases actief worden gemaakt. In Exchange 2010 SP1 en hoger kunnen we hiervoor het StartDagServerMaintenance.ps1 script gebruiken. Dit script doet onder andere het volgende:

• Actieve database kopieën worden verplaatst naar een andere node
• De core cluster resources worden verplaatst naar een andere node, indien deze server Primary Active Manager (PAM) was
• De node wordt gepauzeerd in failover clustering om te voorkomen dat hij tijdens het onderhoud PAM wordt
• Er wordt voorkomen dat er databases actief kunnen worden gemaakt tijdens het onderhoud
• De replicatie van de passieve mailbox kopieën wordt gepauzeerd

We starten het script als volgt:

cd $exscripts
.\StartDagServerMaintenance.ps1 -ServerName ServerNaam

Om de server weer in gebruik te nemen gebruiken we het StopDagServerMaintenance.ps1 script, deze maakt bovenstaande wijzigingen weer ongedaan. Het enige wat dit script niet doet is de databases op deze server weer actief maken, indien je dit wilt zoal je dat handmatig moeten doen. Het script roepen we aan op de zelfde manier:

.\StopDagServerMaintenance.ps1 -ServerName ServerNaam

Wanneer er na het uit gebruik nemen van een DAG member minder dan twee kopieën van een database over zouden blijven dan geeft het script een foutmelding. We kunnen deze controle uitschakelen door StartDagServerMaintenance.ps1 met de -OverrideMinimumTwoCopies switch te starten.

Onderhoud

Wanneer je een server op deze manier uit gebruik neemt kun je vervolgens onderhoud plegen. Houd er wel rekening mee dat je voor sommige updates extra instructies hebt, zoals bijvoorbeeld het uitschakelen van services voor antivirus en monitoring. Lees daarom altijd het bijbehorende knowledge base artikel, met name bij Update Rollups en Service Packs.

Exchange cross-forest migratie met ADMT: distributielijsten

Bij een cross-forest migratie naar Exchange 2010 gebruiken we tools en een aantal scripts om de juiste eigenschappen van de mailboxen over te krijgen naar de nieuwe omgeving. Bijvoorbeeld door het AD object te kopiëren met ADMT, converteren naar Mail-enabled User in de Exchange Management Shell, overhalen van de overige eigenschappen met Prepare-MoveRequest.ps1 en tenslotte het aanmaken van een remote move request. In dit artikel beschrijf ik hoe je iets vergelijkbaars kunt doen om distributielijsten te migreren.

AD object kopiëren

Om te beginnen migreren we de distributielijsten gewoon als groep met de ADMT tool, als je dit artikel leest dan ga ik ervan uit dat je weet hoe dit in zijn werk gaat. Wanneer we dit met de standaard instellingen uitvoeren dan verschijnen de groepen direct na het kopiëren in de Exchange Management Console onder Recipient Configuration, Distribution Group. Alleen missen de e-mailadressen, die komen niet mee omdat ADMT standaard alle mail-gerelateerde attributen filtert en dus niet kopieert. Een simpele oplossing zou zijn om het volgende uit te voeren:
Get-DistributionGroup | Update-Recipient

Exchange zal nu voor iedere DL de ontbrekende eigenschappen aanvullen, waaronder het aanmaken van een mailadres op basis van de Email Address Policy. Alleen is de kans groot dat je in de bronomgeving andere of meerdere adressen in gebruik had. Om deze mee te migreren kunnen we ADMT zo aanpassen dat hij het mail en proxyAddresses attribuut ook mee kopieert. Dit doen we met een klein stukje vbscript waarmee we de ingebouwde exclusions list van ADMT leeg maken:

Set objMig = CreateObject(“ADMT.Migration”)
ObjMig.SystemPropertiesToExclude = “”

Dit script voeren we uit op de ADMT server, op een x64 server als volgt: C:\Windows\SysWoW64\>cscript ADMTExclusionsWeg.vbs

Wanneer we de groepen nu opnieuw kopiëren zien we dat de mailadressen mee zijn gekomen.

X500 adressen

De gekopieerde DL’s zijn nu beschikbaar in de nieuwe omgeving en zijn te mailen op basis van hun SMTP-adres. Toch kunnen gebruikers melden dat ze de volgende NDR krijgen als ze de DL proberen te mailen:

IMCEAEX-_O=Omgeving_ou=Exchange+20Administrative+20Group+20+28FYDIBOHF23SPDLT+29_cn=Recipients_cn=DL+5FSysteembeheerders3ad@domein.nl
#550 5.1.1 RESOLVER.ADR.ExRecipNotFound; not found ##

De oorzaak is dat Outlook ‘onder de motorkap’ niet aan het SMTP-adres mailt maar naar de legacyExchangeDN waarde van een mailbox of DL. Wanneer de gebruiker nu een ontvanger selecteert uit zijn Outlook cache (.nk2) bijvoorbeeld zal Exchange het bericht sturen aan de legacyExchangeDN waarde zoals Outlook hem kent uit de oude omgeving. Probleem is dat het object in de nieuwe omgeving een nieuwe legacyExchangeDN  waarde heeft gekregen die anders is dan in de oude omgeving, daarom krijgt de verzender bovenstaande NDR.

Dit probleem kunnen we oplossen door de oude waarde van het legacyExchangeDN attribuut als X500 adres toe te voegen in de nieuwe omgeving. Bij de migratie van de mailboxen is dit iets wat het Prepare-MoveRequest.ps1 script gedaan heeft, in het geval van DL’s moeten we dat zelf doen. Nou ja, zelf doen? Daar gebruiken we natuurlijk PowerShell voor.

In de bronomgeving exporteren we de naam en de legacyExchangeDN waardes van de DL’s naar een csv-bestand:

Get-DistributionGroup | select name,legacyexchangedn | Export-Csv .\dls.csv –NoTypeInformation

Dit bestand kopiëren we naar de doelomgeving waar we hiermee de waarde van het legacyExchangeDN atribuut gaan toevoegen als X500 adres:

Import-CSV .\dls.csv | foreach {
$Tijdelijk = (Get-DistributionGroup $_.name).EmailAddresses
$Tijdelijk += [Microsoft.Exchange.Data.CustomProxyAddress]("X500:"+$_.LegacyExchangeDN)
Set-DistributionGroup $_.name -EmailAddresses $Tijdelijk
}

Op deze manier voegen we bij iedere met ADMT gekopieerde DL een X500 adres toe wat gelijk is aan de legacyExchangeDN waarde in de oude omgeving.

Samenvattend

Om distributiegroepen te migreren zorgen we dus eerst dat ADMT de SMTP adressen mee kopieert. Vervolgens voegen we de oude legacyExchangeDN waarde toe als een X500 adres waardoor de groepen ook weer gemaild kunnen worden vanuit de Outlook cache.

Server 2012 Hyper-V gebruiken in VMware Workstation

Windows Server 2012 is de nieuwste versie van Microsofts serverbesturingssysteem. Windows Server 2012 is veel meer dan alleen de nieuwste versie, het is misschien wel de eerste versie sinds Windows 2000 Server die zoveel nieuws brengt dat het niet de vraag is óf je gaat upgraden, maar wanneer. Naar verwachting wordt Windows Server 2012 later dit jaar uitgebracht maar je kunt de Windows Server 2012 Release Candidate (RC) nu al downloaden en uitproberen.

Eén van de gebieden waar veel ontwikkeling zit is Hyper-V en ik kan me voorstellen dat veel mensen de nieuwe mogelijkheden willen verkennen in een lab, bijvoorbeeld in VMware Workstation 8. In dit artikel beschrijf ik op welke manier je Hyper-V kunt gebruiken in een VM op VMware Workstation.

Het probleem

Wanneer je Hyper-V wilt inschakelen in een VM kun je tegen de volgende foutmelding aanlopen:

Install-WindowsFeature : A prerequisite check for the Hyper-V feature failed.
1. Hyper-V cannot be installed: A hypervisor is already running.

De oorzaak is dat we al in een hypervisor werken, namelijk in VMware Workstation.

De oplossing

Hyper-V is een hypervisor die hardware-asisted virtualisatie vereist, dat wil zeggen dat Hyper-V niet kan werken zonder dat het AMD-V of Intel-VT kan gebruiken. Daarom moeten we VMware Workstation vertellen dat het de nodige CPU features beschikbaar maakt voor onze VM. Ten eerste schakelen we Intel VT aan in de eigenschappen van de virtuele cpu:

De tweede aanpassing doen we in het configuratiebestand <naam VM>.vmx, deze vinden we in de werkdirectory waar de bestanden van deze VM staan. Wanneer je die lokatie niet kent kun je deze vinden op het tabblad Options van de VM eigenschappen:

In deze directory openen we het .vmx bestand met een text editor. In dit bestand voegen we de volgende regel toe: hypervisor.cpuid.v0 = "FALSE"

De exacte plek in het bestand maakt niet uit, de regel mag gewoon onderaan toegevoegd worden. Uiteraard slaan we het bestand op na het toevoegen van deze regel.

Hyper-V inschakelen

We kunnen onze VM nu starten en Hyper-V installeren via Server Manager of in PowerShell. Omdat ik op een server werk zonder GUI start ik PowerShell, in tegenstelling tot oudere versies zijn de verschillende modules al geladen dus kan ik direct het Install-WindowsFeature cmdlet gebruiken.

We zien dat we de Hyper-V role nu succesvol hebben ingeschakeld op een virtual machine in VMware Workstation 8.

En Hyper-V in Windows 8 dan?

Het zelfde verhaal geldt ook voor het inschakelen van Hyper-V in een VM met Windows 8, waarvan de Release Preview inmiddels beschikbaar is. Met die aantekening dat er nog een tweede regel benodigd is in het .vmx bestand: mce.enable = "TRUE".

Tot besluit

Ik hoop dat dit artikel je helpt om Hyper-V te gebruiken in een VM op VMware Workstation 8. Meer informatie over Hyper-V in de Windows Server 2012 Release Candidate kun je hier vinden: http://www.microsoft.com/en-us/server-cloud/windows-server/2012-overview.aspx Veel plezier gewenst!

Exchange 2010 en statische poorten voor load balancing

Er wordt wel eens gezegd dat je voor Exchange 2003 een storage specialist moest zijn, voor Exchange 2007 een specialist in certificaten en voor Exchange 2010 een specialist in load balancing. En eerlijk gezegd zit daar wel wat in, want hoge beschikbaarheid en load balancing is nog nooit zo belangrijk geweest.

Van alle Exchange 2010 protocollen die je kunt load balancen is MAPI wel de meest bijzondere. De reden is dat MAPI verkeer standaard gebruik maakt van dynamische hoge poorten voor de RPC Client Access en Address Book services, dat betekent dat je nooit vooraf weet welke poorten je moet load balancen. Dit kunnen we oplossen door Exchange zo te configureren dat deze vaste poortnummers gebruikt voor deze twee services.

Om te beginnen moeten we deze poortnummers bepalen. Hoewel in principe ieder hoog nummer wat niet in gebruik is voldoet, raadt Microsoft aan om een poort te kiezen binnen de range 59531 tot 60554. In dit voorbeeld ga ik uit van poort 60000 en 60001, omdat ze makkelijk te onthouden zijn als ik zo meteen de load balancing rules ga aanmaken. En het spreekt voor zich dat we de zelfde waardes gebruiken voor iedere Client Access server in deze site.

We kunnen Exchange configureren met behulp van twee registry keys. Om fouten te voorkomen raad ik aan om dit in te stellen met de volgende vier eenvoudige PowerShell regels:

New-Item HKLM:\SYSTEM\CurrentControlSet\services\MSExchangeAB\Parameters
Set-ItemProperty HKLM:\SYSTEM\CurrentControlSet\services\MSExchangeAB\Parameters RpcTcpPort 60001 -type string
New-Item HKLM:\SYSTEM\CurrentControlSet\services\MSExchangeRPC\ParametersSystem
Set-ItemProperty HKLM:\SYSTEM\CurrentControlSet\services\MSExchangeRPC\ParametersSystem "TCP/IP Port" 60000 -type dword

Vervolgens moeten we deze twee services opnieuw starten zodat we kunnen controleren of we het goed gedaan hebben:

Restart-Service MSExchangeAB
Restart-Service MSExchangeRPC

Nu controleren we of de server op de nieuwe poorten luistert:

netstat -ano | findstr 60000
netstat -ano | findstr 60001

We hebben ons werk goed gedaan, er luistert nu een proces op beide poorten. Dat betekent dat we nu de load balancer kunnen configureren voor poort 135, 60000 en 60001, maar dat valt buiten de scope van dit artikeltje.

Exchange 2010: Mailboxen exporteren naar PST

Een server met Exchange 2010 biedt de mogelijkheid om de inhoud van een mailbox of archief te exporteren naar een PST bestand. Dit kan handig zijn als backup voordat je mailboxen verwijdert, of wanneer je een kopie van de mailboxitems wilt bewaren tijdens troubleshooten of iets dergelijks.
In Exchange 2010 worden exports, imports en verplaatsingen van mailboxen uitgevoerd door de Mailbox Replication Service (MRS). In de praktijk betekent dit dat we een verzoek voor een bepaalde actie klaarzetten en dat de MRS het verzoek af gaat handelen. De MRS doet dit asynchroon, dat wil zeggen dat ze de verzoeken die wij klaarzetten oppakt en uit gaat voeren en niet per sé direct nadat wij opdracht geven. Het voordeel hiervan is dat het proces gewoon weer verder gaat als de server tussendoor een reboot gekregen heeft.
Eerst moeten we zorgen dat het account waarmee wij werken de juiste rechten heeft, in dit voorbeeld doe ik dit door de RBAC rol “Mailbox Import Export” toe te kennen aan de groep Organization Management:
New-ManagementRoleAssignment -SecurityGroup "organization management" -Role "mailbox import export"
Om een mailbox te im- of exporteren maken we een request met New-MailboxImportRequest of New-MailboxExportRequest, als je deze cmdlets nog niet kunt gebruiken nadat je bovenstaande aanpassing gedaan hebt dan moet je de EMS even opnieuw openen. Je zult zien dat de extra cmdlets nu tot je beschikking zijn. Een voorbeeldje nu:
$lijst = Get-Mailbox -OrganizationalUnit _users
$lijst | % { $_ | New-MailboxExportRequest -FilePath "\\ex01\c$\pst\$($_.alias).pst" }

In de eerste regel vullen we de variable $lijst met alle mailboxen van de gebruikers in de OU _users. In de tweede regel beginnen we met het aanroepen van de zojuist gevulde variabele, waarna we voor elk van deze mailboxen een MailboxExportRequest aanmaken. Belangrijk is dat we het FilePatch in UNC formaat moeten opgeven, maar als de beheershare c$ gebruikt dan is het een koud kunstje om naar een lokale folder te verwijzen. Verder gebruik ik de Alias-eigenschap van de mailboxen om de bestandsnaam mee op te bouwen.
Direct na het klaarzetten van de verzoeken is de status Queued, zoals te zien is in de meest rechtse kolom van het screenshot hierboven. We kunnen de status van de verzoeken op elk moment opvragen met Get-MailboxExportRequest.

We zien hier niet alleen de 4 verzoeken die we net klaar hadden gezet, maar ook nog enkele oudere. Als de status van deze verzoeken niet meer belangrijk is dan kunnen we die verwijderen met Remove-MailboxExportRequest.
De beloning van onze noeste arbeid, met hulp van de MRS, vinden we in de opgegeven directory:

Leuk detail is misschien dat mijn mailbox (jetze.pst) aanzienlijk groter is dan ik hier zie staan. Dit komt omdat ik in het screenshot hierboven alle Move Requests verwijderd heb, inclusief eentje die nog als status InProgress had. Hiermee heb ik onbedoeld het exporteren afgebroken, hebben we die vraag ook meteen beantwoord.

Snel testgebruikers aanmaken in Exchange 2010

Zo af en toe is het handig om snel een paar testmailboxen aan te maken in Exchange 2010. Vaak is testgebruiker1 tot en met testgebruiker10 al voldoende. We kunnen dit in de Exchange Management Shell (EMS) eenvoudig doen door een oplopende nummers te produceren en deze nummers vervolgens te gebruiken bij het maken van mailboxen.

Als eerste zetten we een wachtwoord in een secure string:

$password = Read-Host “Geef het wachtwoord” -AsSecureString

Vervolgens maken we onze 10 testgebruikers aan als volgt:

1..10 | ForEach-Object { New-Mailbox -Name TestGebruiker$_ -UserPrincipalName testgebruiker$_@domaina.local -Password $password }

In bovenstaande regel staat $_ voor de waarde die we aan de linkerkant van de pijp hebben gegenereerd. Er wordt dus 10 keer een regel uitgevoerd waarbij $_ de eerste keer voor 1 staat, de tweede keer voor 2, enzovoort.

En als je je nu afvraagt of het ook werkt als je 1..10000 gebruikt of 29..34? Probeer het maar.

Actuele issues met Exchange ActiveSync devices

Exchange ActiveSync is een protocol van Exchange Server waardoor je je e-mail, agenda en andere items kunt synchroniseren naar je mobile. Die mobile kan een telefoon zijn maar ook bijvoorbeeld een tablet met een ingebouwde ActiveSync client. Exchange ActiveSync biedt veel meer functionaliteit dan synchroniseren via IMAP en SMTP, zowel voor de eindgebruiker als voor beheerders. De afgelopen jaren is er veel veranderd door de opkomst van smartphones en tablets. Eén van de ontwikkelingen is dat vrijwel alle fabrikanten het ActiveSync protocol zijn gaan ondersteunen, zo ook Apple bijvoorbeeld sinds versie 2.0 van de iPhone software.

Twee dingen zijn belangrijk om te weten. Ten eerste hebben niet alle fabrikanten de zelfde functionaliteit van het protocol in hun oplossing geïmplementeerd en evenzo bieden nieuwere versies van Exchange Server meer mogelijkheden dan de oudere voorgangers. Voor een uitgebreid overzicht verwijs ik naar dit Wikipedia artikel: Comparison of Exchange ActiveSync clients. Het tweede is dat deze grote verscheidenheid aan ActiveSync clients voor beheerders en helpdesk ook betekent dat zij vaker met issues geconfronteerd worden.

Naast het actief ondersteunen van fabrikanten die moeite hebben om problemen in hun software op te lossen, heeft Microsoft het volgende KB-artikel beschikbaar gemaakt: Current issues with Microsoft Exchange ActiveSync and third-party devices. Voor beheerders en helpdesk is het aan te bevelen om dit artikel af en toe door te nemen om te kijken of er oplossingen beschikbaar zijn voor issues.

Nieuw Exchange 2010 Language Pack lost problemen op

Eerder schreef ik al over een vertaalfoutje in OWA na installatie van SP2 op de CAS servers. Na enige tijd bracht Microsoft een Language Pack Bundle uit die dit probleem herstelt, zie het artikel “Exchange 2010 SP2 toont Globale adreslijst in plaats van Berichten: opgelost”. Na installatie van dit Language Pack toont OWA nu E-mail in plaats van Globale Adreslijst:

Beheerders die deze update installeerden op een server met meerdere rollen, dus niet alleen Client Access, zagen nu een nieuwe error verschijnen in het Application Log:

Log Name: Application
Source: MSExchangeIS
Date: 23.03.2012 15:55:35
Event ID:10013
Task Category: General
Level: Error
Keywords: Classic
User: N / A
Computer: Server
Description:
The Active Directory entry for mailbox CN contains an invalid locale for attribute MsExchUserCulture: nl-NL

Inmiddels heeft Microsoft een nieuwe versie van de Bundle klaargezet die ook dit probleem oplost. Downloaden doe je hier.

Office 365: Migraties en performance

Iedereen die wel eens een mailmigratie heeft uitgevoerd weet dat de doorlooptijd een belangrijke factor is. Vaak is het lastig om te bepalen waar nu precies de bottleneck zit, is het de bronserver, het migratiestation of toch misschien de internetverbinding? En hoe zit dat met throttling in Exchange Online?

Microsoft heeft hier een mooi document voor uitgebracht: Microsoft Exchange Online Migration Performance Guide

Dit document behandelt niet alleen de standaard Office 365 migratiemethoden maar gaat ook in op third party tools als die van Quest, MigrationWiz en Binary Tree. De schrijvers gaan uitvoerig in op de hele keten van factoren, van bronserver tot Exchange Online. Absolute aanrader voor iedereen die een migratie naar Exchange Online wil voorbereiden.

Verlopen van het wachtwoord aan- of uitschakelen in Office 365

Wanneer je geen gebruik maakt van single sign-on in Office 365, hebben je gebruikers te maken met het standaard wachtwoordbeleid. Wat dit beleid precies inhoudt kunnen we lezen in de Office 365 Service Descriptions: Identity Service Description. Hierin vinden we de volgende tabel:

We zien hier dat de een wachtwoord maximaal 90 dagen oud mag worden, dan moet het echt aangepast worden. Wanneer het wachtwoord bijna verlopen is en je de Microsoft Online Services Sign-in Assistant geïnstalleerd hebt zie je onderstaande melding verschijnen:

In bepaalde gevallen zou je die termijn misschien aan willen passen maar dit is helaas niet mogelijk. Wat wel kan is om het verlopen van wachtwoorden helemaal uit te schakelen, dit is een instelling die je per gebruiker kunt zetten. Dit kun je eenvoudig doen in de Microsoft Online Services Module for Windows PowerShell, namelijk door de parameter -PasswordNeverExpires voor een gebruiker op $true te zetten. En wel  als volgt:

1. Open de Microsoft Online Services Module for Windows PowerShell of start een normale PowerShell sessie en importeer de MSonline module (import-module msonline)
2. Maak verbinding met de Office 365 tenant: Connect-MsolService
3. Pas de waarde voor -PasswordNeverExpires aan voor een gebruiker: Set-MsolUser -UserPrincipalName user@domain.com -PasswordNeverExpires:$True

Het spreekt voor zich dat we dit ook in één keer kunnen instellen voor al onze gebruikers:

Op deze manier kunnen we het verlopen van wachtwoorden in Office 365 uitschakelen.