Export (0) Print
Expand All
34 out of 45 rated this helpful - Rate this topic

Release Notes for Exchange 2013

 

Applies to: Exchange Server 2013

Topic Last Modified: 2014-02-26

Welcome to Microsoft Exchange Server 2013! This topic contains important information that you need to know to successfully deploy Exchange 2013 Service Pack 1 (SP1). 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 or Service Pack. 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 Cumulative Update or Service Pack.

  • MAPI virtual directory isn't created during server recovery   When you run Setup.exe with the RecoverServer switch on a server that has the Client Access server role installed, the MAPI virtual directory isn't created. If the MAPI virtual directory doesn't exist, clients that use the MAPI over HTTP protocol to connect to the Exchange server, such as Outlook, won't be able to connect.

    NoteNote:
    This is only an issue if the MAPI over HTTP protocol is enabled on your Client Access servers. It's disabled by default. If MAPI over HTTP is disabled, clients use the RPC over HTTP protocol instead.

    To resolve this issue, follow the steps in Knowledge Base article KB2931223 (MAPI virtual directory is missing from default Web Site node).

  • Mail flow stops after Exchange 2013 SP1 is installed   After you upgrade to Exchange 2013 SP1 from a previous version of Exchange 2013, mail flow might stop working on servers that have the Client Access server role installed. This happens because, even though the Microsoft Exchange Frontend Transport service starts after Setup completes, it doesn't correctly detect that it can start sending mail again. This issue doesn't occur on new installations of Exchange 2013 SP1.

    To work around the issue, restart the server after Setup completes.

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.

    The default ACL gives Author permissions to Default authenticated users.

     

    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 Updates for Exchange 2013.

     

    For more information on this issue, including answers to common questions, see the following posts on the Exchange Team Blog:

  • Unauthorized senders can send messages to public folders   Public Folders located on servers running Exchange 2013 SP1 accept messages from senders external to the Exchange organization, regardless of the configuration of the public folder. This issue may allow public folders to receive spam and other unwanted messages.

    There's currently no workaround for this issue.

  • Legacy public folders can't be accessed via Exchange Web Services   Public folders that are located on Exchange 2007 or Exchange 2010 servers can't be accessed by clients that connect to Exchange 2013 using Exchange Web Services (EWS). Clients that use EWS include Mac Outlook and Outlook Web App. If an EWS client attempts to access a legacy public folder, they'll receive an error.

    The only workaround at this time is to migrate legacy public folders to Exchange 2013. However, there are some issues that must be considered before you migrate your public folders. For more information, see Public Folders.

  • 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:

    CautionCaution:
    Loading the Microsoft.Exchange.Management.PowerShell.SnapIn Windows 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.
    ImportantImportant:
    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.
    1. Open a new Windows PowerShell window.

    2. Run the following command.

      Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn
      
    3. Perform transport agent management tasks as normal.

    4. Repeat this procedure on each Client Access server you want to manage.

  • 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.

    To work around this issue, you can do one of the following:

    • 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.

  • 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 IllegalMessage for 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>].

    To work around this issue, you need to remove the Integrated authentication method from the client receive connector on your Exchange 2013 Client Access servers. To remove the Integrated authentication 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
    
  • MAPI over HTTP may experience poor performance when you upgrade to Exchange 2013 SP1   If you upgrade from an Exchange 2013 cumulative update to Exchange 2013 SP1 and enable MAPI over HTTP, clients that connect to an Exchange 2013 SP1 server using the protocol may experience poor performance. This is because required settings aren't configured during an upgrade from a cumulative update to Exchange 2013 SP1. This issue doesn't occur if you upgrade to Exchange 2013 SP1 from Exchange 2013 RTM or if you install a new Exchange 2013 SP1 server.

    NoteNote:
    This is only an issue if the MAPI over HTTP protocol is enabled on your Client Access servers. It's disabled by default. If MAPI over HTTP is disabled, clients use the RPC over HTTP protocol instead.

    To work around this issue, do the following:

    1. On servers running the Client Access server role, run the following commands in a Windows Command Prompt:

      set AppCmdLocation=%windir%\System32\inetsrv
      set ExchangeLocation=%ProgramFiles%\Exchange Server\V15
      
      %AppCmdLocation%\appcmd.exe SET AppPool "MSExchangeMapiFrontEndAppPool" /CLRConfigFile:"%ExchangeLocation%\bin\MSExchangeMapiFrontEndAppPool_CLRConfig.config"
      %AppCmdLocation%\appcmd.exe RECYCLE AppPool "MSExchangeMapiFrontEndAppPool"
      
      
    2. On servers running the Mailbox server role, run the following commands in a Windows Command Prompt:

      set AppCmdLocation=%windir%\System32\inetsrv
      set ExchangeLocation=%ProgramFiles%\Exchange Server\V15
      
      %AppCmdLocation%\appcmd.exe SET AppPool "MSExchangeMapiMailboxAppPool" /CLRConfigFile:"%ExchangeLocation%\bin\MSExchangeMapiMailboxAppPool_CLRConfig.config"
      %AppCmdLocation%\appcmd.exe RECYCLE AppPool "MSExchangeMapiMailboxAppPool"
      
      %AppCmdLocation%\appcmd.exe SET AppPool "MSExchangeMapiAddressBookAppPool" /CLRConfigFile:"%ExchangeLocation%\bin\MSExchangeMapiAddressBookAppPool_CLRConfig.config"
      %AppCmdLocation%\appcmd.exe RECYCLE AppPool "MSExchangeMapiAddressBookAppPool"
      
      
  • 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 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.

    If all the conditions above are true, the user won’t be able to access the other user’s Exchange 2010 Outlook Web App options and a blank page may appear.

    To work around this issue, install Exchange 2010 SP3 Update Rollup 1 or later on each Exchange 2010 server.

 
Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft. All rights reserved.