Thursday, July 12, 2012

Import-CSV en non-ASCII karakters

Wanneer je een CSV bestand importeert met daarin een waarde met hoge ASCII karakters dan zul je zien dat dit karakter wordt weergegeven als een vraagteken. Mooie namen als Düker en Çobanlar zijn in de output van Import-CSV verminkt tot D?ker en ?obanlar. Wanneer je deze output wilt gebruiken om bijvoorbeeld een mailbox of AD account te bewerken dan zal dit mislukken, waar Düker misschien de naam van een object is kan D?ker niet gevonden worden.

De oorzaak hiervan is dat Import-CSV standaard ASCII encoding verwacht, in tegenstelling tot bijvoorbeeld Get-Content die UTF8 ondersteunt. Een work-around kan zijn om het CSV bestand eerst te converteren naar UTF8 als volgt:

cat bestand.csv > bestand2.csv # make utf8

Wanneer we bestand2.csv nu als invoer gebruiken voor Import-CSV zien we dat de karakters juist weergegeven worden.

Wednesday, July 11, 2012

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:

image

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.

image

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.

Monday, July 9, 2012

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.