Mailbox verhuizen met EMS & EMC

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.