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:
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 $trueNew-Mailbox -Name PFProxyMailbox1 -Database PFProxyDatabase -UserPrincipalName PFProxyMailbox1@domain.localSet-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:
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:
- Exchange 2016: Die Basiskonfiguration
- Exchange 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 Assistant” erledigt werden: