Release Notes for Exchange 2013
Applies to: Exchange Server 2013
Topic Last Modified: 2013-04-02
Welcome to Microsoft Exchange Server 2013! This topic contains important information that you need to know to successfully deploy Cumulative Update 1 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.
- 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 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 service pack.
To work around this issue, do the following on each Exchange 2010 SP3 Client Access server:
Open Internet Information Services (IIS) Manager.
Navigate to Sites\Default Web Site\ECP\14.3.123.<x>
Select Windows Authentication, and then click Disable in the Actions pane.
- A user with an Exchange 2013 mailbox tries to open an Exchange 2010 mailbox using one of the following methods:
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.
- Trying to copy data from a recovery database fails with an error When you try to use the New-MailboxRestoreRequest cmdlet to copy the contents of a mailbox in a recovery database to a mailbox in a production mailbox database, you’ll receive the following error:
The call to 'net.tcp://serverName/Microsoft.Exchange.MailboxReplicationService serverName (15.0.620.29 caps:3F)' failed. Error details: must be logging in with GUIDs, not legDN Parameter name: owner.
-SkipMerging StorageProviderForSourceto your original command and run it again.
New-MailboxRestoreRequest < parameters you originally specified> -SkipMerging StorageProviderForSource
- Client Access server doesn’t support NTLM authentication The Client Access server doesn’t advertise support for NTLM authentication when SMTP clients and servers connect to the server. SMTP clients and servers that require NTLM won’t be able to send mail to the Client Access server.
To work around this issue, you must configure SMTP clients and servers to use another authentication mechanism, such as Basic Authentication, when connecting to the Client Access server.
- 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.
- Transport rules and DLP policies may not detect contents of subjects in attached messages Sensitive words in the subject line of an attached message may go undetected even if those words match the Attachment contains words condition on Exchange transport rules or data loss prevention (DLP) policies. If this happens, the actions defined on the transport rules or DLP policies won’t be applied to the message or its attachments.
There is no workaround at this time.