none
Migration Exchange 2010 zu 2016 / Fehler bei der internen Outlook Verbindung RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    Hallo liebe community,

    ich habe ein Problem während einer Migration von einem Exchange 2010 zu einem Exchange 2016 Server. 

    Die Migration habe ich nach folgender Anleitung von frankysweb.de begonnen: https://www.frankysweb.de/migration-von-exchange-2010-zu-exchange-2016-teil-1/

    Meine Umgebung:
    EX2010: 192.168.1.146
    EX2016: 192.168.1.108
    Split-DNS: remote.fqdn.de -> 192.168.1.108; autodiscover.fqdn.de -> 192.168.1.108; SRV-Record (_TCP, Port 443) -> 192.168.1.108; Externe öffentliche IP -> DNS autodiscover.fqdn.de

    Bei der Authentifizierung für Outlook Anywhere am Exchange 2010 ist nicht NTLM sondern Einfach gewählt gewesen, das habe ich beim Exchange 2016 ebenfalls eingestellt. SSL-Abladung zulassen war am Exchange 2010 nicht angehakt unter Outlook Anywhere, auf dem Exchange Server 2016 ist dieser Punkt angehakt. Der interne Hostname bei Outlook Anywhere auf dem Exchange 2010 war leer, das habe ich ergänzt durch remote.fqdn.de.

    Danach habe ich eine Migration eines Postfaches durchgeführt. Outlook meldete, dass der Administrator Änderungen durchgeführt hat und Outlook neu gestartet werden muss. Danach erhalte ich eine Endlosschleife mit Benutzeranmeldedaten in Outlook. Das Postfach öffnet sich nicht.

    Erst wenn ich auf dem Exchange Server 2016 folgenden Befehl für das betroffene Postfach ausführe, erhalte ich über RPC/HTTP Zugriff auf das Postfach: 

    Set-CasMailbox <user or mailbox id> -MapiHttpEnabled $False

    Wenn ich von Extern über Outlook eine Verbindung zu dem Postfach herstelle, funktioniert diese ohne Probleme. Ebenso die Neueinrichtung von extern funktioniert tadellos.

    Wenn ich dann mit RPC/HTTP mit dem Postfach verbunden bin und einen Autoverbindungstest mache, erhalte ich folgende Ergebnisse:


    Was kann ich tun, um die Ursache des Fehlers zu beheben?

    Grüße
    Mario

    • Bearbeitet MarioHeiss Dienstag, 17. November 2020 23:31 Ergänzungen
    Dienstag, 17. November 2020 23:07
    |

Antworten

  • Question
    Anmelden
    0
    Anmelden

    Hallo liebe community,

    das Problem konnte ich lösen und möchte Euch gerne an der Lösung teilhaben lassen.

    Folgendes Powershell Skript, das alle SPN's im AD aufzeigt, brachte die ursächliche Problematik zu Tage:

    #Set Search
 cls
 $search = New-Object  DirectoryServices.DirectorySearcher([ADSI]“”)
 $search.filter = “(servicePrincipalName=*)”
 $results = $search.Findall()

#list results
 foreach($result in $results)
 {
        $userEntry  = $result.GetDirectoryEntry()
        Write-host "Object Name = " $userEntry.name -backgroundcolor "yellow" -foregroundcolor "black"
        Write-host "DN      =      "  $userEntry.distinguishedName
        Write-host "Object Cat. = "  $userEntry.objectCategory
        Write-host "servicePrincipalNames"
        $i=1
        foreach($SPN in $userEntry.servicePrincipalName)
        {
            Write-host  "SPN(" $i ")   =      " $SPN       $i+=1
        }
        Write-host ""
}

    Das Ergebnis war, dass in einem Benutzerobjekt der SPN host/remote.fqdn.de stand.

    Die Lösung war, diesen Eintrag zu entfernen. Hierzu öffnete ich ADSIEDIT.MSC, begab mich in den Standardmäßigen Namenskontext und öffnete die Eigenschaften des entsprechenden Benutzerobjektes. Unter der Eigenschaft des Objektes "servicePrincipalName" konnte ich den SPN entfernen.

    Grüße
    Mario

    • Als Antwort markiert MarioHeiss Dienstag, 24. November 2020 22:11
    Dienstag, 24. November 2020 22:10
    |

Alle Antworten

  • Question
    Anmelden
    0
    Anmelden

    Hallo Mario,

    Hier eine Idee:

    https://support.microsoft.com/de-de/help/3097392/outlook-logon-fails-after-mailbox-moves-from-exchange-2010-to-exchange

    Grüße,

    Yavor
    Mittwoch, 18. November 2020 18:59
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Yavor,

    vielen Dank für Deine Nachricht und Deinen Tipp.

    Diese Möglichkeit hatte ich bereits getestet, leider ohne Erfolg. Gemäß einer Empfehlung aus einem anderen Forum, habe ich das Wiederverwendungsintervall auf 5 Minuten gestellt. Diese Einstellung soll nach Abschluss der Migration wieder zurückgestellt werden.

    Grüße

    Mario

    Donnerstag, 19. November 2020 10:32
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo liebe community,

    das Problem konnte ich lösen und möchte Euch gerne an der Lösung teilhaben lassen.

    Folgendes Powershell Skript, das alle SPN's im AD aufzeigt, brachte die ursächliche Problematik zu Tage:

    #Set Search
 cls
 $search = New-Object  DirectoryServices.DirectorySearcher([ADSI]“”)
 $search.filter = “(servicePrincipalName=*)”
 $results = $search.Findall()

#list results
 foreach($result in $results)
 {
        $userEntry  = $result.GetDirectoryEntry()
        Write-host "Object Name = " $userEntry.name -backgroundcolor "yellow" -foregroundcolor "black"
        Write-host "DN      =      "  $userEntry.distinguishedName
        Write-host "Object Cat. = "  $userEntry.objectCategory
        Write-host "servicePrincipalNames"
        $i=1
        foreach($SPN in $userEntry.servicePrincipalName)
        {
            Write-host  "SPN(" $i ")   =      " $SPN       $i+=1
        }
        Write-host ""
}

    Das Ergebnis war, dass in einem Benutzerobjekt der SPN host/remote.fqdn.de stand.

    Die Lösung war, diesen Eintrag zu entfernen. Hierzu öffnete ich ADSIEDIT.MSC, begab mich in den Standardmäßigen Namenskontext und öffnete die Eigenschaften des entsprechenden Benutzerobjektes. Unter der Eigenschaft des Objektes "servicePrincipalName" konnte ich den SPN entfernen.

    Grüße
    Mario

    • Als Antwort markiert MarioHeiss Dienstag, 24. November 2020 22:11
    Dienstag, 24. November 2020 22:10
    |