Migration von Exchange 2010 auf 2013 / Troubleshoot

In der letzten Woche habe ich meine erste Live Migration von Exchange 2010 auf Exchange 2013 durchgeführt. Vorweg ich habe es geschafft 🙂

Da es im Internet schon genügend How-To`s und Step by Step Anleitung gibt, habe ich mich entschlossen hier mal die Probleme aufzulisten die ich in dieser Woche zu lösen hatte.

Kurz zu meinem Szenario:

2x Windows Server 2012
2x Exchange 2013 CU2 V2 mit CAS/Mailbox Rolle + DAG
2x KEMP LoadMaster 2200 (Hardware)
200 Clients Windows 7 und Windows XP

 

1. Einrichtung DAG bei Exchange 2013

Um auf dem Exchange 2013 eine DAG einzurichten sind einige manuelle Arbeiten von Nöten.
Alles scheint erst einmal zu funktionieren bis man den ersten Mailbox Server zum DAG hinzufügen möchte.

Problem 1: Keine Berechtigung einen Mailboxserver hinzuzufügen.

Problem 2: Der DNS Name kann nicht gefunden werden.

Problem 3: Das DAG Computerobjekt ist nicht deaktiviert.

Beim Anlegen einer DAG erstellt Exchange ein Computerobjekt im ActiveDirectory, dies aber leider nicht korrekt. Somit ist es einfacher vorher manuell ein Computerobjekt zu erstellen.

Folgende Schritte sind durchzuführen:

–          Computerobjekt mit dem Namen der DAG erstellen

–          Der Gruppe Exchange Trusted Subsystem „Full Control“ erteilen

–          Das Attribut „dNSHostName“ mit dem FQDN der DAG ausfüllen.

–          Das Objekt deaktivieren

Jetzt kann man die Mailboxserver hinzufügen.

Quelle: http://buenoflex.com/archives/211
http://technet.microsoft.com/en-us/library/dd298065.aspx

 

2. Postfachmigration rückgängig machen

Nachdem ich die Exchange Umgebung installiert hatte und der Mailverkehr über die beiden KEMPs Richtung Ex2013 lief habe ich mein erstes Postfach verschoben. Um sicher zu gehen verschob ich das Postfach mal direkt wieder zurück. Und siehe da ein Fehler.

…Tombstone hasn’t been cleaned up from the destination database…

Nach ein wenig Recherche hatte ich nicht wirklich eine Lösung. Dann fiel mir ein, dass ich gar nicht die alte Exchange 2010 Umgebung auf Updates geprüft hatte und Tatsächlich war hier nicht das Service Pack2 Rollup 2 Version 2 installiert. Nach der Installation funktionierte das Zurückverschieben auf die alte Datenbank ohne Probleme.

Daher immer die aktuelle Exchange Version auf Updates Prüfen.

 

3. Outlook Anywhere und Windows XP

Ab 2013 unterhalten sich Outlook und Exchange 2013 nur noch über HTTPS.

Besser gesagt alle Clients egal ob Extern oder Intern nutzen das Feature Outlook Anywhere (RPC over HTTPS). Als ich die ersten Postfächer der Windows XP Anwender verschob, konnten diese sich anschließend nicht mehr mit Exchange verbinden. Zudem tauchte immer ein Pop-Up Fenster auf und fragte nach den Anmeldedaten des Benutzers. Anmelden war aber nicht möglich. Outlook Web App funktionierte aber ohne Probleme, daher war das Problem am Client anzusiedeln.

Nach einem halben Tag Analyse und Testen hatte ich dann den Fehler gefunden. Die Umgebung benutzt ein Offizielles SAN Zertifikat mit einer externen Adresse (webmail.xyz.de) und eine interne Adresse (mail.xyz.de). So auch in den Outlook Anywhere Einstellungen auf beiden Servern hinterlegt:

Server -> Server -> Einstellungen -> Outlook Anywhere

Es scheint nun so als ob Windows XP nicht korrekt mit SAN-Zertifikaten umgehen kann und lediglich den CN Eintrag lesen kann, wo webmail.xyz.de drin steht. Somit findet er den Eintrag mail.xyz.de nicht im Zertifikat und markiert es als Ungültig. Dies verursacht dann die Verbindungsprobleme. Windows 7 ist in der Lage den SAN Teil des Zertifikates zu lesen und findet den Eintrag mail.xyz.de auch.

Die Lösung war für mich den Eintrag webmai.xyz.de auch von intern Erreichbar zu machen und die Outlook-Anywhere Einstellungen abzugleichen. Sprich beide Hostnames sowohl intern als auch extern auf webmail.xyz.de zu stellen.

Weiter sollte man noch den Outlook Provider kontrollieren. Dies geht wie folgt:

Get-OutlookProvider EXPR | fl Name, CertPrincipalName

Hier sollte die gleiche Adresse stehen wie in den Outlook Anywhere Einstellungen. Wenn nicht bitte den Eintrag anpassen:

Set-OutlookProvider EXPR –CertPrincipalName msstd:webmail.xyz.de

Natürlich auf beiden Servern und danach muss ein IIS Reset durchgeführt werden.

Bitte die Datenbanken vorher jeweils verschieben. Danach sollte sich das Outlook auf dem Windows XP auch wieder verbinden. Ich musste bei ein paar Benutzern allerdings das Profil neu erstellen.

 

4. Löschen des CAS Arrays nach der Migration

Auf Rat meines Kollegen wollte ich das 2010er CAS Array, was nun nicht mehr benötigt wird, erst ganz zum Schluss löschen. Nach der Deinstallation der beiden alten Exchange 2010 Server versuchte ich das wie üblich mit:

Remove-ClientAccess Array

Leider steht dieser befehl unter Exchange 2013 nicht mehr zur Verfügung.

Das Array lässt sich aber über ADSI Edit herauslöschen. Dazu öffnet mit ADSI Edit die Konfiguration und öffnet folgenden Pfad:

CN=Configuration,DC=DOMAIN,DC=LOCAL
CN=Services
CN=Microsoft Exchange
CN=EXCHANGE_ORG
CN=Administrative Groups
CN=Exchange Administrative Group (FYDIBOHF23SPDLT)
CN=Array

Dort den Eintrag komplett löschen und die AD Replikation abwarten.

Quelle: http://blog.dargel.at/2013/09/18/remove-cas-array-with-adsi-edit/

Ich hoffe ich konnte euch hiermit helfen 😉

Greetz

Stephan

Advertisements

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

%d Bloggern gefällt das: