Archiv für die Kategorie » Migration «

16 | 12 | 2016

Quest Migration Manager for Exchange: Nun auch nach Exchange 2010 mit MAgE!

Geschrieben von um 19:36 Uhr

Still und heimlich hat Quest, noch unter der Marke „DELL Software“, ein Update-Paket für den Migration Manager 8.13 rausgebracht. Neben den üblichen Bugfixes gibt es eine tolle Neuerung: Der „neue“ Migration Agent fpr Exchhange (MAgE) kann nun auch nach Exchange 2010 migrieren. Das ermöglicht gleich zwei Dinge, die bis dato nicht gingen:

  • Migration von Exchange 2013 nach 2010 (der „alte“ Mail Source Agent konnte und kann nicht mit Exchange 2013 sprechen)
  • Migration in bestehende Postfächer (rettet mit gerade ziemlich den Abend, der alte Agent musste sie selber neu anlegen, bevor er bereit war, per MAPI da hinein zu schreiben)

Drei Dinge sind beim Einsatz des MAgE zu beachten:

  • Die SQL-Datenbank wird richtig groß (1.036 Bytes pro synchronisiertes Element) – das ist generell so bei MAgE, nicht nur mit Exchange 2010
  • Wenn die Synchronisierung eines Postfachs mit dem alten MSA/MTA begonnen wurde, kann man nicht auf MAgE umstellen, ohne dass es massenhaft Dubletten gibt
  • Man muss zwingend CPUU ab 5.6.4 einsetzen, um Profile zu migrieren.

Danke Quest, das war lange fällig! Und ja, es wird noch nach Exchange 2010 migriert 🙂

Tags » , , , , «

+

07 | 10 | 2016

MAP in einer Workgroup-Umgebung

Geschrieben von um 22:30 Uhr

Heute mal etwas leichtere Kost, eher als Reminder gedacht.

Das Microsoft Assesment & Planning Toolkit ist ja ein bewährtes Mittel zur systemübergreifenden Performance-Analyse. Zum Beispiel, um eine Konsolidierung von Servern von Physik und „wilder Virtualisierung“ auf geordnete virtuelle Plattformen oder in die Cloud zu modellieren. So auch heute. Die Herausforderung jedoch war, dass nur einer der zu betrachtenden Server tatsächlich Domänen-Mitglied ist – und zwar in einer Domäne, in die der MAP-Server natürlich nicht aufgenommen werden durfte! Alle anderen Server gehören keiner Domäne an, und die meisten von ihnen haben nur den Default-„Administrator“ an Konten eingerichtet. Das Kennwort von diesem Administrator ist zwar nicht überall unterschiedlich, aber auch nicht überall gleich – ca. die Hälfte der Server hatte „Kennwort1“, und der Rest teilte sich in etwa gleichmäßig in „Kennwort2“ und „Kennwort3“.

Landet man in einer solchen Situation, so muss man folgendes berücksichtigen:

  • „.\Administrator“ kann MAP nicht erfassen, nur „Administrator“ oder „<COMPUTER>\Administrator“
  • Jedes Account kann in der exakten Schreibweise nur einmal vorkommen, das Erfassen von „Administrator“ mit unteschiedlichen Passwörtern ist also nicht ohne weiteres möglich
  • Im Inventory-Teil kann man jedem Eintrag, wenn man ihn manuell eingibt, oder jeder Liste, wenn man sie aus Dateien einliest, ein eigenes Konto zuweisen.
  • Im Performance-Sammlungs-Teil gibt es diese Funktion aber nicht – da kann man NUR eine Liste von Accounts zum Durchprobieren erfassen!
  • Die Schreibweise „<COMPUTER>\Administrator“ wird im Performance-Sammlungs-Teil nur für den Computer akzeptiert, der auch tatsächlich da steht. Somit mussten wir die Durchprobier-Liste in Form „Administrator – Kennwort1″,“DomainUser – DomainKennwort“, „SERVER2A\Administrator – Kennwort2“, „SERVER2B\Administrator – Kennwort2″,…“SERVER2Z\Administrator – Kennwort2″,“SERVER3A\Administrator – Kennwort3“,… erfassen. Alles andere hat nicht funktioniert.
  • Im Inventory-Teil (WMI) wird hingegen auch ein „fremder“ Computername angenommen, wenn nur der Benutzername und das Kennwort passen.

Last but not least: Die eingegebenen Accounts werden bei Abmeldung „vergessen“ und stehen beim nächsten Aufruf von MAP nicht zur Auswahl.

In einer Domänen-Umgebung wäre das alles überhaupt kein Problem…

 

Tags » , , «

+

16 | 01 | 2016

Exchange: Kein Drag & Drop in Outlook – Ursache und Lösung

Geschrieben von um 0:00 Uhr

Nach einer Migration von Exchange 2010 auf Exchange 2013, die mit dem DELL Migration Manager for Exchange durchgeführt wurde, haben sich Nutzer beschwert, dass sie in Outlook keine Elemente per Drag & Drop in einen bestimmten Unterordner des Posteingangs und dessen Unterordner verschieben können. Da dieser Ordner der e-Mail-Archivierung im Unternehmen diente, betraf es alle Nutzer und war auch beliebig reproduzierbar. Eine weitere Untersuchung ergab, dass:

  • auch keine neuen Elemente in diesen Ordnern erstellt werden können,
  • das Verschieben per Rechtsklick –> Verschieben nach… funktioniert
  • in OWA auch Drag & Drop funktioniert
  • nur diese archivierungsbezogenen Ordner betroffen sind
  • es keine Unterschiede in den Zugriffsrechten zwischen funktionierenden und nicht funktionierenden Ordnern gibt.

Der Blick auf die MAPI-Properties der Ordner per MFCMAPI ergab folgendes Bild, das auch schnell zur Lösung führte:

  • in Exchange 2010 fehlt in den betroffenen Ordner die Property PR_CONTAINER_CLASS komplett
  • in Exchange 2013 haben die „defekten“ Ordner zwar diese Property, sie ist aber leer
  • in beiden Systemen haben die Default-Ordner und solche, die von Hand angelegt wurden (und wo Drag & Drop ausnahmslos funktioniert) die Property auf den korrekten Wert „IPF.Note“ gesetzt.

Der Versuch, manuell den Wert für PR_CONTAINER_CLASS auf IPF.Note in einem der „defekten“ Ordner zu setzen, brachte sofort die Linderung für den betreffenden Ordner. Da 1.200 Postfächer betroffen waren und die Unterordner-Strukturen überall unterschiedlich waren, habe ich das folgende Skript geschrieben, das die Angelegenheit global heilt:


$ex_ps_url = "http://EXCHANGE01/PowerShell/"
$ex_ews_path = “C:\Program Files\Microsoft\Exchange\Web Services\2.2\Microsoft.Exchange.WebServices.dll”
$log_file = "C:\temp\folder_class.log"
$res_file = "C:\temp\folder_class_set.log"

################################################################
#                 F U N C T I O N S
################################################################

Function WriteLog ($text, $uname) {
    if ($uname) {
        $xname = $uname + " | "
    } else {
        $xname = "######## | "
    }
    ((Get-Date -Format "dd.MM.yyyy hh:mm:ss").ToString() + " | " + $xname + $text) | Out-File -FilePath $log_file -Append
}

Function DoSubFolder ($folder, $path) {
    $folderView = new-object Microsoft.Exchange.WebServices.Data.FolderView(2147483647)
    $subfolders = $folder.FindFolders($folderView)
    if (!$path) { $path = $folder.DisplayName }
    foreach ($subfolder in $subfolders) {
        if ($subfolder.SearchParameters -ne $null) {
            # If it's a search folder, just skip it
            continue
        }
        $xpath = $path + "\" + $subfolder.DisplayName
        if (!($subfolder.folderClass)) {
            WriteLog ($xpath + " has no FolderClass set! Setting FolderClass to IPF.Note") $name
            ($name + " --> " + $xpath) | Out-File -FilePath $res_file -Append
            $subfolder.FolderClass = "IPF.Note"
            $subfolder.Update()
        } else {
            WriteLog ($xpath + " has FolderClass property of " + $subfolder.folderClass) $name
        }
        DoSubfolder $subfolder $xpath
    }
}

################################################################
#                         S T A R T
################################################################

Add-Type -Path $ex_ews_path
$ExchangeVersion = [Microsoft.Exchange.WebServices.Data.ExchangeVersion]::Exchange2013
$Service = New-Object Microsoft.Exchange.WebServices.Data.ExchangeService($ExchangeVersion)

if (!(Get-Command "Get-ExchangeServer" -EA SilentlyContinue)) {
    WriteLog "Connecting to Exchange using $ex_ps_url"
    $ex_rem_session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri $ex_ps_url -Authentication Kerberos -EA SilentlyContinue -WA SilentlyContinue
    Import-PSSession $ex_rem_session -DisableNameChecking -EA SilentlyContinue -WA SilentlyContinue > $null
} else {
    WriteLog "Exchange environment already established"
}

$mbxs = @(Get-Mailbox -ResultSize Unlimited)
$nmbx = $mbxs.Count
WriteLog ($nmbx.ToString() + " mailboxes to process...")
$i = 0
foreach ($mbx in $mbxs) {
    $mail = $mbx.PrimarySMTPAddress
    $name = $mbx.SamAccountName
    $i++
    WriteLog "Processing mailbox $i of $nmbx ..." $name
    Write-Host ([math]::Round((($i / $nmbx) * 100),2)).ToString() " % $name"
    if ($mail) {
        WriteLog "Primary email address is: $mail" $name
        $Service.AutodiscoverUrl($mail,{$true})
        WriteLog ("Autodiscover URL: " + $Service.Url.OriginalString) $name
        $Service.ImpersonatedUserId = new-object Microsoft.Exchange.WebServices.Data.ImpersonatedUserId([Microsoft.Exchange.WebServices.Data.ConnectingIdType]::SmtpAddress, $mail)
        $fldInbox = [Microsoft.Exchange.WebServices.Data.Folder]::Bind($Service, [Microsoft.Exchange.WebServices.Data.WellKnownFolderName]::Inbox)
        WriteLog ("Default Inbox folder: " + $fldInbox.DisplayName + " contains " + $fldInbox.TotalCount + " item(s)") $name
        DoSubFolder $fldInbox
    } else {
        WriteLog "Primary email address NOT SPECIFIED! Skipping mailbox..." $name
    }
}

if ($ex_rem_session) {
    Remove-PSSession $ex_rem_session -EA SilentlyContinue -WA SilentlyContinue
}

Damit dieser Code ausgeführt werden kann, benötigt das ausführende User-Account mindestens das Recht, alle Postfächer aufzulisten und deren SAMAccountName und PrimarySMTPAddress zu lesen (also: Mitgliedschaft in irgendeiner Exchange-Administratorrolle) sowie die ApplicationImpersonation-Berechtigung. Da alle Postfächer zu bearbeiten waren, war das Zuweisen dieser Berechtigung denkbar einfach:

New-ManagementRoleAssignment –Name "adminuser_may_impersonate" –Role ApplicationImpersonation –User: "DOMAIN\adminuser"

Noch ein wenig Hinergrund: Die Unterordner im Quellsystem wurden mit einem Skript angelegt, welches EWS Managed API 2.0 und ebenfalls ApplicationImpersonation nutzt. Dabei wurde denkbar einfach vorgegangen:

$oFolder = new-object Microsoft.Exchange.WebServices.Data.Folder($exchService)
$oFolder.DisplayName = "Mailarchiv"
$oFolder.Save([Microsoft.Exchange.WebServices.Data.WellKnownFolderName]::inbox)

Die FolderClass-Eigenschaft wurde nicht explizit gesetzt. Offensichtlich erstellt dabei EWS Managed API auch keine Property PR_CONTAINER_CLASS. DELL Migrator hingegen erstellt diese Property offenbar standardmäßig, bestückt sie jedoch strikt mit dem Wert, den sie im Quellsystem hatte. In diesem Fall also: mit keinem.

Happy troubleshooting!

Tags » «

+

12 | 02 | 2015

DELL-Zertifizierung

Geschrieben von um 13:05 Uhr

Ich bin nun als Implementation Consultant für die DELL Software (ehem. QUEST) – Produkte

  • Migrator for Active Directory und
  • Migrator for Exchange

zertifiziert. Der Kurs und die Prüfungen, beides geleitet von Phil Welsh, haben großen Spaß gemacht – aber ich kann niemandem empfehlen, beide Prüfungen am selben Tag zu machen 😉

Tags » , , , , , , «

+