In January I had already an article about problems with the Outlook connection to Exchange during the migration. In this new article, I would now like to mention a few more common causes of problems.
DNS server is not a DC
During the coexistence of the Exchange servers, users may not be able to send emails between the two Exchange versions. For example, if a user with an Exchange 2010/2013 mailbox cannot send mails to users with an Exchange 2016 mailbox, the cause may lie in the DNS settings of the Exchange servers.
The following error is then usually found in the Exchange queues:
Hub version 15 - smtp-relay in active directory - Error: 451 - 4.4.0 DNS query failed. The error was: SMTPSEND.DNS.NonExistendDomain, nonexistend domain
The cause of this problem is usually that DNS servers that are not domain controllers have been configured for the Exchange servers. Often other DNS servers such as routers cannot resolve the underscore zones (e.g. _msdcs). In this example, the router was specified as the alternative DNS server (blue), the preferred DNS server is a domain controller:
In this case, the problem described above occurs. Either the router must be configured so that the underscore zones can also be resolved, or only DNS servers that are also domain controllers and can therefore resolve the underscore zones are entered.
Public Folder Proxy on wrong server
Without a public folder proxy mailbox, users whose mailboxes have been moved to newer Exchange servers can no longer access the public folders of the Exchange 2010 servers. To enable access during the migration, one or more public folder proxy mailboxes can be used. However, I have often seen that the proxy database is deployed on the wrong server. The proxy database and the public folder proxy mailboxes must be created on the Exchange 2010 servers, not on Exchange 2013 or Exchange 2016 servers.
The following commands for creating the proxy database and a public folder proxy mailbox must be executed on an Exchange 2010 server:
|
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 |
The next command for assigning the proxy mailbox must be executed on an Exchange 2013 / Exchange 2016 server:
|
1
|
Set-OrganizationConfig -PublicFoldersEnabled Remote -RemotePublicFolderMailboxes PFProxyMailbox1 |
If Outlook still does not want to display public folders, it helps to enter the proxy database as the public folder database of the Exchange 2016 database. This command can be executed in the Exchange 2013 / 2016 shell:
|
1
|
Get-MailboxDatabase | Set-MailboxDatabase -PublicFolderDatabase "PFProxyDatabase" |
In addition, the proxy mailbox can also be assigned to the migrated mailboxes:
|
1
|
Set mailbox Exchange2016Mailbox -DefaultPublicFolderMailbox "PFProxyMailbox1" |
After these settings have been changed, the "Microsoft Exchange RPC Client Access Service" service must be restarted.
Different authentication settings
Different authentication settings between the Exchange Server versions also repeatedly cause problems with the Outlook connection. In particular, the settings for Outlook Anywhere should be set the same in both Exchange worlds. For example, if NTLM is configured for Outlook Anywhere on the Exchange 2010 servers, then NTLM should also be configured on Exchange 2013/2016 servers.
Here is an example of a corresponding configuration:
Certificates
The certificate for the Exchange server should be configured directly after installation and basic configuration. Certificate errors not only annoy users, but can also cause problems when connecting Outlook to Exchange.
If the Exchange URLs are retained during the migration, the certificate of the "old" Exchange servers can continue to be used for the new Exchange servers. I have described how this works here:
Of course, a new certificate is not a problem as long as it is valid and is classified as trustworthy by the clients. The following three articles can help you to configure an appropriate certificate:
- Exchange 2016: The basic configuration
- Exchange 2013: Create certificate request for public CA
- Exchange 2013: SAN certificate and internal certification authority (CA)
Thanks to the free certification authority Let's EncryptThe certificate can also be requested and imported automatically, for example with my "Certificate Assistant":