Mailboxen verhuizen is een van die taken die geregeld gedaan worden binnen een Exchange organisatie, maar hoe werkt het precies in Exchange 2007?

In tegenstelling tot Exchange 2003 hebben we nu de mogelijkheid om naast de GUI ook gebruik te maken van een commandline interface, in de vorm van het Move-Mailbox cmdlet. Dit stelt ons in staat op basis van filters source en destination te bepalen. Een leuk voorbeeld is het volgende:

$db = (Get-ExchangeServer | get-MailboxStatistics | Sort-Object Count | Select-Object Name)[0]
Get-User | ?{$_.City -eq "Zoetermeer"} | Move-Mailbox -TargetDatabase $db

Deze regels code verplaatsen alle mailboxen van gebruikers uit Zoetermeer naar de database met de minste mailboxen.

Naast de toevoeging van de shell heeft de move mailbox wizzard in de console een opknapbeurt gekregen. Het schijnt ook dat de achterliggende code beter geintegreerd is met de servercode, dus laten we dat maar aannemen. Wat in ieder geval wel aantoonbaar gewijzigd is zijn de pre-move checks. Voordat een mailbox verhuist wordt werden zaken als rechten en het mailboxtype (wel of geen system mailbox) in Exchange 2000+ ook al gechecked. Wat er nu ook nog gechecked wordt is of de properties van de mailbox ook nog kloppen. Dit zijn checks waar ik eerder ook al aandacht aan heb besteed. De methode Validate() op het mailboxobject wordt aangeroepen en checkt of bijv. de alias geen spaties bevat en of het mail attribute hetzelfde is als het primary proxy address. Voldoet de mailbox niet, vindt er geen move plaats.
Voldoet hij wel, wordt er een MAPI sessie opgezet naar zowel de source als de destination server. De source mailbox wordt getagged met een PR_IN_TRANSIT flag, waarna op de destination server de nieuwe mailbox aangemaakt wordt, ook getagged met de PR_IN_TRANSIT tag. De PR_IN_TRANSIT flag zorgt ervoor dat de mailbox in een soort read-only status terecht komt, wat clients en Exchange weerhoudt wijzigingen te maken op de mailbox. Client wijzigingen worden in het geheugen gemaakt en nieuwe email wordt gequeued. De move vindt plaats door de mailbox als 1 stream te verplaatsen. Tijdens de move worden MAPI berichten gecontroleerd op corruptie en een counter bijgehouden. Het move-process zal proberen corrupte items te repareren, maar zal nooit een corrupt item opslaan in de target mailbox. Vandaar dat het moven van een mailbox dus soms problemen met rules en dergelijke op kan lossen. Of een item wel of niet corrupt is wordt bepaald door de aanwezige MAPI attributen op het bericht te controleren. Voor een move kan je zelf aangeven hoeveel items maximaal corrupt mogen zijn. Als deze waarde overschreden wordt, zal de move ongedaan worden gemaakt. Als de mailbox eenmaal over is, worden de msExchHomeServerName, HomeMDB en HomeMTA properties aangepast op het user object. Het is aan te bevelen de wijzigingen te laten uitvoeren op een GC in de site waar de target Exchange server zich bevindt. De source Exchange server weet van de move en zal MAPI connecties voor de betreffende mailbox doorzetten naar de target Exchange server. Deze zal in AD controleren of de MAPI connectie voor hem bestemt is. Op deze manier zouden mailbox moves bijna seamless moeten zijn. Je kan door blijven werken met Outlook. Het kan echter zijn dat de Outlook vraagt de client te herstarten. Dit is meestal wanneer de client ook doorverwezen wordt naar een nieuwe default Public folder store.
Nu dat de mailbox over is en de AD attributen zijn aangepast zal de source server de mailbox verwijderen en de target server de PR_IN_TRANSIT flag van de mailbox halen. De move is nu voltooit.

Het is dan eindelijk zover... SP1 is vanaf morgen hier vrij verkrijgbaar.

De hightlights voor deze aanvulling zijn:

• Ondersteuning voor Windows Server 2008
• Uitgebreide ActiveSync policies
• High availability opties als "Standby Continuous Replication" en cross-site resilience.
• Uitbreiding op GUI voor bijvoorbeeld Public Folders en connector configuratie.

Helaas hebben we voor dit servicepack een schema uitbreiding nodig. 

Enjoy!

Voor Exchange 2007 kan je een leuke architectuur plaat downloaden.
Deze vind je op de Microsoft Site.

We hadden al architectuurplaten voor de transport rollen (Edge en Hub). Deze waren hier te vinden.

Enjoy! :)

Tijdens een pilotfase van een project ben ik weer drie nieuwe 'features' tegengekomen. De een iets ernstiger dan de ander, maar in ieder geval erg vervelend. Helaas is dit niet de eerste keer aangezien ik al eerder wat strubbelingen had:

http://www.spurius.nl/?p=46
http://www.spurius.nl/?p=55

Bug1#
Als je een mailbox moved dan verdwijnen de linefeeds (enters) uit je Out of Office message. Dit gebeurt echter alleen bij moves van Exchange 2003 naar Exchange 2007.

Bug2#
Wanneer je in Exchange 2007 een account aanmaakt (of moved vanuit 2003) dan wordt de address policy applied en krijgt het account een proxyaddress en wordt het 'mail' attribute (WindowsEmailAddress) gevuld. Wanneer je nu via de Exchange console het primary proxy address aanpast en je verwijdert het adres wat in de policy als primary was aangeduid, dan zal je NDR's krijgen wanneer je emails stuurt vanuit Exchange 2003 naar dit account. Dit komt omdat Exchange 2003 het 'mail' attribuut als TO: address gebruikt, en de Exchange 2007 management tools dit veld NIET meewijzigen als je het primary proxy address wijzigt. Omdat je het adres heb weggegooid, krijg je dus een NDR.
Nu zal je vast denken.... Dan gooi je het adres toch niet weg??.... Leuk bedacht, maar dat is niet de oplossing. Een ander probleem met dit is dat als je dat doet, je OAB generation problemen niet verhelpt. Het OAB generation process EIST namelijk dat het 'mail' attribuut gelijk is aan het primary proxy address. De enige oplossing is dus om het mail attribuut gelijk te trekken. Dit kan met de ADUC, native tools of Set-Mailbox met de -WindowsEmailAdress parameter.

Bug3#
Als je vanuit Exchange 2007 een email stuurt aan een mailenabled security group (dus niet Distributiegroep) dan kan je in je ontvangen email niet meer de Groep expanden. Je krijgt dan de melding:

"Cannot perform the requested operation. The command selected is not valid for this recipient. Could not complete the operation. One or more parameter values are not valid."

Na wat onderzoek bleek dat het met Distributiegroepen wel werkte. 1 van de properties op een groep is het msExchRecipientDisplayType attribuut. Dit attribuut wordt gebruikt om in de tooling een recipient op een bepaalde manier weer te geven. De waardes zijn als volgt:

Object Type	Decimal Value
Universal Distribution Group	1
Universal Security Group	1073741833
Dynamic Distribution Group	3
Linked Mailbox, Shared Mailbox, or User Mailbox	1073741824
Room Mailbox	7
Equipment Mailbox	8
Mail User, Mail Contact	6
Public Folder	2
N/A (this represents a special "Organization" object to Outlook, but does not map to a specific exchange object type)	4
N/A (this represents a special "Private Distribution List" object to Outlook, but does not map to a specific exchange object type)	5

Blijkbaar doet het toch meer dan dat! Want... Als ik de waarde van de securitygroups naar 1 zet, werkt het wel! het lijkt erop dat de transport stack van Exchange 2007 iets wijzigt, waardoor de Outlook client de groep ziet als een contact of user ipv een group. Wanneer je namelijk op de naam klikt in het ipm.note form, zie je de properties die je normaal op een contact ziet, ipv diegene die je ziet op een group, zoals het member tabblad.

Wat er precies gebeurt is onduidelijk; dit ligt momenteel bij Microsoft...

Altijd al willen weten wat je server nou allemaal aan het babbelen is met zijn DC? Sysinternals heeft AD Insight for Active Directory 1.0 gelanceerd. Een must-have tool al zeg ik het zelf.