Release Notes for Exchange 2013
Applies to: Exchange Server 2013
Topic Last Modified: 2013-11-12
Welcome to Microsoft Exchange Server 2013! This topic contains important information that you need to know to successfully deploy Cumulative Update 3 for Exchange 2013. Please read this topic completely before beginning your deployment.
This topic contains the following sections:
- Setup incorrectly requests .NET Framework 4.0 If you attempt to install Exchange 2013 without .NET Framework installed on the computer, Setup incorrectly requests that you install .NET Framework 4.0 when, in fact, .NET Framework 4.5 is required.
To work around this issue, install .NET Framework 4.5. You don’t need to install .NET Framework 4.0. For a complete list of prerequisites, see Exchange 2013 Prerequisites.
- Exchange XML application configuration files are overwritten during cumulative update installation Any customized per-server settings you make in Exchange XML application configuration files, for example, web.config files on Client Access servers or the EdgeTransport.exe.config file on Mailbox servers, will be overwritten when you install an Exchange Cumulative Update (CU). Make sure that you save this information so you can easily re-configure your server after the install. You must re-configure these settings after you install an Exchange CU.
For more information about how to install Exchange 2013, see Planning and Deployment.
- Mailbox size increase when migrating from previous Exchange versions When you move a mailbox from a previous version of Exchange to Exchange 2013, the mailbox size reported may increase 30 percent to 40 percent. Disk space used by the mailbox database has not increased, only the attribution of space used by each mailbox has increased. The increase in mailbox size is due to the inclusion of all item properties into quota calculations, providing a more accurate computation of space consumed by items within their mailbox. This increase may cause some users to exceed their mailbox size quotas when their mailbox is moved to Exchange 2013.
To prevent users from exceeding their mailbox size quotas, increase the database or mailbox quota values to accommodate the new quota calculation. To configure database or mailbox quota values, use the IssueWarningQuota, ProhibitSendQuota, and ProhibitSendReceiveQuota parameters on the Set-MailboxDatabase and Set-Mailbox cmdlets, respectively.
- Outlook 2007 and Outlook 2010 clients may be unable to download the Offline Address Book If the Offline Address Book (OAB) internal URL isn’t accessible from the Internet, Outlook 2007 and Outlook 2010 clients may be unable to download the OAB.
To work around this issue for Outlook 2007 and Outlook 2010 clients, make the OAB internal URL accessible from the Internet. Outlook 2013 isn’t affected by this issue.
- Installing Exchange 2013 in an existing Exchange organization may cause all clients to download the OAB Installing the first Exchange 2013 server into an existing Exchange 2007 or Exchange 2010 organization may cause all clients in the organization to download a new copy of the OAB, resulting in network saturation and server performance issues. This issue occurs because Exchange 2013 creates a new default OAB in the organization that supersedes the Exchange 2007 or Exchange 2010 OAB. Mailboxes that don’t have a specific OAB assigned, or that are located on a mailbox database that doesn’t have a specific OAB assigned, will download the new default OAB.
To prevent clients from downloading a new copy of the OAB when Exchange 2013 is installed, assign an OAB to every mailbox or to the mailbox database the mailboxes are located on. This must be done prior to Exchange 2013 being installed in the organization.
- Public folder permissions might be lost after public folder mailboxes are moved In an Exchange 2013 organization that uses Modern Public Folders and that has Exchange 2013 CU2 build 15.00.0712.022 installed, if you move a public folder mailbox the permissions structure on some public folders might be lost. Permissions might be lost in the following situations:
If you move (via New-MoveRequest) a secondary public folder mailbox, the permissions on any public folder (including well known folders) not stored in the secondary public folder mailbox would be lost from the secondary public folder mailbox and replaced by the default access control list (ACL). The original ACLs can be restored via a full synchronization event by running the following command:
Update-PublicFolderMailbox -InvokeSynchronizer <Public Folder Mailbox> -FullSync
If you move (via New-MoveRequest) the primary public folder mailbox, the permissions on any public folder (including well known folders) not stored in that public folder mailbox are lost and replaced by the default ACL.
To work around this issue, install Exchange 2013 CU2 build 15.00.712.024 or later. For information on how to download the latest cumulative update, see Cumulative Updates for Exchange 2013.
For more information on this issue, including answers to common questions, see the following posts on the Exchange Team Blog:
- If you move (via New-MoveRequest) a secondary public folder mailbox, the permissions on any public folder (including well known folders) not stored in the secondary public folder mailbox would be lost from the secondary public folder mailbox and replaced by the default access control list (ACL). The original ACLs can be restored via a full synchronization event by running the following command:
- TransportAgent cmdlets on Client Access servers require local Windows PowerShell An issue exists with the *-TransportAgent cmdlets that prevents those cmdlets from installing, uninstalling, and managing transport agents on Client Access servers using the Exchange Management Shell. To install, uninstall, and manage transport agents on Client Access servers, you must manually load the Exchange Windows PowerShell snap-in and then run the *-TransportAgent cmdlets. If you attempt to install, uninstall, or manage transport agents using the Exchange Management Shell, your changes will be applied to the Exchange 2013 Mailbox server you’re connected to.
To install, uninstall, or manage transport agents on Client Access servers, do the following on the Client Access server you want to manage:
Caution: Loading the
Microsoft.Exchange.Management.PowerShell.SnapInWindows PowerShell snap-in and running cmdlets other than the *-TransportAgent cmdlets is not supported and may result in irreparable damage to your Exchange deployment.
You must be a local Administrator on the Client Access server where you want to install, uninstall, or manage transport agents. We do not support the modification of access control lists (ACLs) on Exchange files, directories, or Active Directory objects.
Important: Perform the following procedure on Client Access servers only. You don’t need to load the Exchange Windows PowerShell snap-in if you want to manage transport agents on Mailbox servers.
Open a new Windows PowerShell window.
Run the following command.
Perform transport agent management tasks as normal.
Repeat this procedure on each Client Access server you want to manage.
- Open a new Windows PowerShell window.
- NTLM authentication fails for non-domain joined clients Authentication between a client, such as Windows Live Mail, and Exchange 2013 may fail when the following conditions are true:
Then authentication method the client uses is NTLM.
The computer isn't joined to the domain.
Join the computer the client is running on to the domain.
Change the authentication type the client uses from NTLM to Basic Auth over TLS.
- Then authentication method the client uses is NTLM.
- GSSAPI authentication fails when used with the Send-MailMessage cmdlet Generic Security Service Application Program Interface (GSSAPI) authentication may fail when the Send-MailMessage cmdlet, which is included with default installs of Windows PowerShell, is used to send authenticated mail to Exchange 2013. When this happens, you'll see an entry in the Application event log on the Exchange 2013 Client Access server that received the connection with the following information:
- Source MSExchangeFrontEndTransport
- Event ID 1035
- Description Inbound authentication failed with error
IllegalMessagefor Receive connector Client Frontend <server name>. The authentication mechanism is Gssapi. The source IP address of the client who tried to authenticate to Microsoft Exchange is [<client IP address>].
Integratedauthentication method from the client receive connector on your Exchange 2013 Client Access servers. To remove the
Integratedauthentication method from a client receive connector, run the following command on each Exchange 2013 Client Access server that could receive connections from computers running the Send-MailMessage cmdlet:
Set-ReceiveConnector "<server name>\Client Frontend <server name>" -AuthMechanism Tls, BasicAuth, BasicAuthRequireTLS
- Source MSExchangeFrontEndTransport
- Requests to access Exchange 2010 mailboxes may not work when proxied through Exchange 2013 Client Access servers In some situations, the proxy request between the Exchange 2013 and Exchange 2010 Service Pack 3 (SP3) Client Access servers without any update rollups installed may not work correctly and an error appears. This can happen if all of the following conditions are true:
A user with an Exchange 2013 mailbox tries to open an Exchange 2010 mailbox using one of the following methods:
The Open Another Mailbox option in Outlook Web App -OR-
The Another user option in the Exchange admin center
- The Open Another Mailbox option in Outlook Web App -OR-
The Client Access server the user connected to is running Exchange 2013.
The Exchange 2010 Client Access server was upgraded to Exchange 2010 SP3 from the release to manufacturing (RTM) version of Exchange 2010 or a previous Exchange 2010 service pack.
To work around this issue, install Exchange 2010 SP3 Update Rollup 1 or later on each Exchange 2010 server.
- A user with an Exchange 2013 mailbox tries to open an Exchange 2010 mailbox using one of the following methods: