Release notes for Exchange 2016
Applies to: Exchange Server 2016
Topic Last Modified: 2016-06-09
|Coming from the Exchange Deployment Assistant? Click Release notes for Exchange 2013.|
Welcome to Microsoft Exchange Server 2016! This topic contains important information that you need to know to successfully deploy Exchange 2016. Please read this topic completely before beginning your deployment.
This topic contains the following sections:
Slow installation on Windows Server 2012 R2 On computers running Windows Server 2012 R2 with Windows update KB3097966 installed, it can take up to 50% longer for Setup to complete.
To work around this issue, do the following on each server where you'll install Exchange 2016 before you run Setup. You only have to do this once on each server.
Open an elevated command prompt.
Run the following command.
Important: This command can generate many warnings or errors. This is expected and doesn't mean the command has failed.
Run the following command. If the number returned is 0, the
ngen.execommand completed successfully.
Installing Exchange using Delegate Admin permissions causes Setup to fail When a user who's a member of only the Delegated Setup role group attempts to install Exchange on a pre-provisioned server, Setup will fail. This happens because the Delegated Setup group lacks the permissions required to create and configure certain objects in Active Directory.
To work around this issue, do one of the following:
Add the user installing Exchange to the Domain Admins Active Directory security group.
Install Exchange using a user that's a member of the Organization Management role group.
Mailbox servers running different versions of Exchange can be added to the same database availability group The Add-DatabaseAvailabilityGroupServer cmdlet and the Exchange Admin Center incorrectly allow an Exchange 2013 server to be added to an Exchange 2016-based database availability group (DAG), and vice versa. Exchange supports adding only Mailbox servers running the same version (Exchange 2013 versus Exchange 2016, for example) to a DAG. Additionally, the Exchange Admin Center displays both Exchange 2013 and Exchange 2016 servers in the list of servers available to add to a DAG. This could allow an administrator to inadvertently add a server running an incompatible version of Exchange to a DAG (for example, adding an Exchange 2013 server to an Exchange 2016-based DAG).
There is currently no workaround for this issue. Administrators must be diligent when adding a Mailbox server to a DAG. Add only Exchange 2013 servers to Exchange 2013-based DAGs, and only Exchange 2016 servers to Exchange 2016-based DAGs. You can differentiate each version of Exchange by looking at the Version column in the list of servers in the Exchange Admin Center. The following are the server versions for Exchange 2013 and Exchange 2016:
Exchange 2013 15.0 (Build xxx.xx)
Exchange 2016 15.1 (Build xxx.xx)
Can't connect to archive mailbox when using MAPI over HTTP In Exchange 2016, MAPI over HTTP can be enabled per-mailbox. An issue exists that prevents users from accessing their archive mailbox, if one is configured, when the following are true:
MAPI over HTTP is enabled on the user's mailbox.
MAPI over HTTP is disabled at the organization level.
When these conditions are true, the user won't be able to open their archive mailbox and they'll get the error The set of folders cannot be opened. The attempt to log on to Microsoft Exchange has failed.
To work around the issue, do one of the following
Open the archive mailbox using Outlook on the web.
Disable MAPI over HTTP on the mailbox by running the following command.
Set-CasMailbox <email address> -MapiHttpEnabled $False
Notifications Broker service stops after 30 seconds When you start your Exchange server, you might notice the Notifications Broker service start and then stop after approximately 30 seconds. If you attempt to start the service manually, it will successfully start and then stop, again after approximately 30 seconds. No errors or warnings are included in the Event log.
This behavior is expected in on-premises deployments of Exchange 2016. The Notifications Broker service performs a configuration check on each time the server starts. If there is nothing for the Notifications Broker service to do, it stops automatically until the next time the server is restarted.
Edge Transport servers can reject mail sent to valid recipients Exchange 2016 Edge Transport servers may reject messages sent to valid internal recipients when the following are true:
Exchange 2016 Cumulative Update 1 (CU1) is installed on the server.
Recipient validation is enabled on the server.
When an Edge Transport rejects a message because of this issue, the sender will receive a non-delivery report (NDR) with the status code 5.1.10, and the error Recipient not found by SMTP address lookup. The recipient won't receive the message.
To work around the issue, do one of the following:
Disable recipient validation on the affected Edge Transport server(s) by running the following command.
Set-RecipientFilterConfig -RecipientValidationEnabled $False
Disable the recipient validation cache on the affected Edge Transport server(s) by running the following command.
Get-TransportService | Set-TransportService -RecipientValidationCacheEnabled $False
Caution: Disabling the recipient validation cache causes Exchange to verify that recipients on inbound messages are valid by querying the local instance of Active Directory Lightweight Directory Services. This can significantly increase the resources Exchange needs to process messages. Before you disable the recipient validation cache, verify that your server has sufficient capacity to handle the additional demand.
Configure your firewall or external mail exchanger (MX) DNS record to send mail to an Edge Transport server that doesn't have Exchange 2016 Cumulative Update 1 installed. You might need to configure your firewall to allow TCP port 25 to connect to the new Internet-facing server.
Configure your firewall or external MX DNS record to send mail to an Exchange 2016 Mailbox server. You might need to configure your firewall to allow TCP port 25 to connect to the new Internet-facing server.