Exchange 2010 Senden Als Funktioniert Nicht

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 dice 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 agile 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, dice 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 Substitution 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 Binder Proxy Mailboxen genutzt werden. Ich habe allerdings schon häufiger gesehen, dass dice Proxy Datenbank auf falschen Server bereitgestellt wird. Die Proxy Datenbank und die Public Binder Proxy Mailboxen müssen auf den Exchange 2010 Servern angelegt werden, nicht auf Substitution 2013 oder Exchange 2016 Servern.

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

iii

                      New-MailboxDatabase                      -Server                      Exchange2010Server                      -Proper noun                      PFProxyDatabase                      -IsExcludedFromProvisioning                      $true                    
                      New-Mailbox                      -Name                      PFProxyMailbox1                      -Database                      PFProxyDatabase                      -UserPrincipalName                      PFProxyMailbox1                      @domain                      .local                    
                      Set-Mailbox                      -Identity                      PFProxyMailbox1                      -HiddenFromAddressListsEnabled                      $truthful                    

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

1	`Ready-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 Beat out ausgeführt werden:

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

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

one	`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 Substitution 2013/2016 Servern eingestellt werden.

Hier ein Bespiel für eine entsprechende Konfiguration:

Authentifizierungseinstellungen unterschiedlich

Zertifikate

Das Zertifikat für dice 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 Substitution 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:

Howto: Migration von Substitution 2010 zu Exchange 2016

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:

Substitution 2016: Die Basiskonfiguration
Substitution 2013: Zertifikatsanforderung für öffentliche CA erstellen
Exchange 2013: SAN Zertifikat und interne Zertifizierungsstelle (CA)

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

Exchange Certificate Assistant: Neue Version