Exchange Migration: Häufige Ursachen für Probleme

Im Januar hatte ich bereits einen Artikel zu Problemen mit der Outlook Verbindung zu Exchange während der Migration geschrieben. In diesem neuen Artikel möchte ich nun noch ein paar weitere häufige Ursachen für Probleme nennen.

DNS Server ist kein DC

Während der Koexistenz der Exchange Server kann es vorkommen, dass Benutzer Mails nicht zwischen den beiden Exchange Version versenden können. Wenn ein Benutzer mit Exchange 2010/2013 Postfach beispielsweise keine Mails an Benutzer mit Exchange 2016 Postfach senden kann, kann die Ursache in den DNS Einstellungen der Exchange Server liegen.

In den Exchange Warteschlangen findet sich dann meist der folgende Fehler:

Hub version 15 – smtp-relay in active directory – Fehler: 451 – 4.4.0 DNS query failed. The error was: SMTPSEND.DNS.NonExistendDomain, nonexistend domain

Die Ursache für dieses Problem liegt meist darin, dass für die Exchange Server DNS Server konfiguriert wurden, die keine Domain Controller sind. Häufig können andere DNS Server wie Router nicht die Underscore-Zonen (bspw. _msdcs) auflösen. In diesem Beispiel wurde als alternativer DNS Server der Router angegeben (blau), der bevorzugte DNS Server ist ein Domain Controller:

Migration: DNS Server ist kein DC

In diesem Fall kommt es zu dem oben beschriebenen Problem. Entweder muss der Router so konfiguriert werden, dass auch die Underscore-Zonen aufgelöst werden können, oder es werden nur DNS Server eingetragen, die auch Domain Controller sind und somit die Underscore Zonen auflösen können.

Public Folder Proxy auf falschem Server

Ohne Public Folder Proxy Mailbox können Benutzer dessen Postfächer auf neuere Exchange Server verschoben wurden, nicht mehr auf die Öffentlichen Ordner der Exchange 2010 Server zugreifen. Um den Zugriff während der Migration zu ermöglichen können eine oder mehrere Public Folder Proxy Mailboxen genutzt werden. Ich habe allerdings schon häufiger gesehen, dass die Proxy Datenbank auf falschen Server bereitgestellt wird. Die Proxy Datenbank und die Public Folder Proxy Mailboxen müssen auf den Exchange 2010 Servern angelegt werden, nicht auf Exchange 2013 oder Exchange 2016 Servern.

Die folgenden Befehle zum Erstellen der Proxy Datenbank und einer Public Folder Proxy Mailbox muss auf einem Exchange 2010 Server ausgeführt werden:

1
2
3
New-MailboxDatabase -Server Exchange2010Server -Name PFProxyDatabase -IsExcludedFromProvisioning $true
New-Mailbox -Name PFProxyMailbox1 -Database PFProxyDatabase -UserPrincipalName PFProxyMailbox1@domain.local
Set-Mailbox -Identity PFProxyMailbox1 -HiddenFromAddressListsEnabled $true

Der nächste Befehl zum Zuweisen der Proxy Mailbox muss auf einem Exchange 2013 / Exchange 2016 Server ausgeführt werden:

1
Set-OrganizationConfig -PublicFoldersEnabled Remote -RemotePublicFolderMailboxes PFProxyMailbox1

Wenn Outlook dann immer noch keine Öffentlichen Ordner anzeigen will, hilft es die Proxy Datenbank als Public Folder Datenbank der Exchange 2016 Datenbank einzutragen. Dafür kann dieser Befehl in der Exchange 2013 / 2016 Shell ausgeführt werden:

1
Get-MailboxDatabase | Set-MailboxDatabase -PublicFolderDatabase "PFProxyDatabase"

Zusätzlich kann die Proxy Mailbox auch den migrierten Postfächern zugewiesen werden:

1
Set-Mailbox Exchange2016Postfach -DefaultPublicFolderMailbox "PFProxyMailbox1"

Nachdem diese Einstellungen geändert wurden, muss der Dienst “Microsoft Exchange-RPC-Clientzugriffsdienst” neu gestartet werden.

Authentifizierungseinstellungen unterschiedlich

Unterschiedliche Authentifizierungseinstellungen zwischen den Exchange Server Versionen sorgen auch immer wieder für Probleme mit der Outlook Verbindung. Insbesondere die Einstellungen für Outlook Anywhere sollten in beiden Exchange Welten gleich eingestellt werden. Ist auf den Exchange 2010 Servern für Outlook Anywhere beispielsweise NTLM konfiguriert, dann sollte auch NTLM auf Exchange 2013/2016 Servern eingestellt werden.

Hier ein Bespiel für eine entsprechende Konfiguration:

Authentifizierungseinstellungen unterschiedlich

Authentifizierungseinstellungen unterschiedlich

Zertifikate

Das Zertifikat für die Exchange Server sollte direkt nach der Installation und Basiskonfiguration konfiguriert werden. Zertifikatsfehler nerven nicht nur die Benutzer, sondern können auch für Probleme bei der Verbindung von Outlook zu Exchange sorgen.

Wenn die Exchange URLs während der Migration beibehalten werden, kann das Zertifikat der “alten” Exchange Server auch für die neuen Exchange Server weiterverwendet werden. Wie dies funktioniert habe ich hier beschrieben:

Ein neues Zertifikat stellt natürlich auch kein Problem dar, solange es gültig ist und von den Clients als vertrauenswürdig eingestuft wird. Die folgenden drei Artikel können dabei helfen ein entsprechendes Zertifikat zu konfigurieren:

Dank der kostenfreien Zertifizierungsstelle Let’s Encrypt, lässt sich das Zertifikat auch automatisiert beantragen und einspielen, dies kann beispielsweise mit meinem “Certificate Assistant” erledigt werden:

5 Kommentare zu “Exchange Migration: Häufige Ursachen für Probleme”

  1. Hallo Frank,

    vielen Dank für diesen hilfreichen Beitrag!
    Gibt es denn eine bevorzugte Authentifizierungsmethode der Clients gegenüber dem Exchange Server (z.B. bei Outlook anywhere)? Oder ist es hier egal, welche man nimmt?

    Danke nochmal.
    Gruß, Christoph.

    1. Hallo Frank,

      ergänzend zu Deinem Artikel: Ich erlebe es immer noch sehr häufig, dass der LegacyExchangeDN vergessen wird und sich dann nach einer Migration Beschwerden über NDRs häufen…

      Grüße
      Roland

  2. Hi Frank,

    ist es noch aktuell, dass Microsoft mit Exchange 2016 und 2019 die User von den öffentlichen Ordnern wegbringen will oder wurde das mittlerweile zurückgenommen?

    Gruß,

    Stefan

    1. Hallo Stefan,

      es war von Seitens Microsoft geplant öffentliche Ordner ab Exchange 2013 komplett abzuschaffen.
      Wegen dem großen Protest vieler Unternehmen hat Microsoft die öffentlichen Ordner in ein eigenes Postfach migriert und schleift diesen Balast ohne große Weiterentwicklung mit sich weiter.

      Ich finde sowohl öffentliche Ordner als auch Funktionspostfächer haben beide Ihre Vor- und Nachteile.
      Vorteile öffentliche Ordner:
      – keine Aufwand für die Einrichtung von neuen Postfächern/Kalender nötig (Postfach in Outlook hinzufügen usw.)
      – Übersichtlicher wenn nur eine Funktion eines Postfachs gebraucht wird für z.B. einen gemeinsamen Kalender

      Vorteile Funktionspostfach:
      – ActiveSync wird unterstützt
      – Gelesene Elemente Zähler funktioniert
      – Geringerer Aufwand bei Migration

      In meinem Unternehmen gehen wir immer weiter weg von öffentlichen Ordner, da Microsoft darin wohl keine Zukunft sieht. In neuen Umgebungen arbeiten wir komplett ohne öffentliche Ordner.

      @Frank: Korrigiere mich, falls nötig

      VG
      Pascal

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.