• 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.
  
  
• Setup help contains unsupported Uninstall mode parameter   The Setup command line help indicates that you can use the Roles parameter when you uninstall Exchange 2013 using the Uninstall Setup mode. This is incorrect. The Roles parameter isn’t supported when using the Uninstall Setup mode. When you uninstall Exchange 2013, all server roles are uninstalled from the computer. Uninstalling individual roles isn’t supported.
  
  

For more information about how to install Exchange 2013, see Planning and Deployment.

• Coexistence with Exchange 2007 and Exchange 2010   Exchange 2013 can't be installed in the same Active Directory forest as Exchange 2007 or Exchange 2010. Use an Active Directory forest with no prior installations of Exchange 2007 or Exchange 2010. Coexistence with Exchange 2007 and Exchange 2010 will be available at a later date.
  
  

  Caution:
  You can't install Exchange 2007 or Exchange 2010 in a forest that's been prepared for Exchange 2013 but hasn't been prepared for Exchange 2007 or Exchange 2010. If you want to install Exchange 2007 or Exchange 2010 in a forest, do not prepare that forest for Exchange 2013.

• 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.
  
  
• Room mailboxes and lists are visible to all users regardless of the Address Book Policies that are applied   In organizations that use Address Book Policies (ABPs), room mailboxes and lists appear to all users, regardless of the ABP that’s been applied to their mailboxes, when using the Outlook Address Book scheduling assistant. This happens because the Outlook Web App scheduling assistant doesn’t correctly respect the ABP when retrieving the list of available room mailboxes or lists.
  
  There is currently no workaround for this issue.
  
  
• 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.
  
  

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

  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.

  1. Open a new Windows PowerShell window.
     
     
  2. Run the following command.
     
     

     	Copy Code
     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.
     
     

• Unsupported attachment types in transport rules   In Exchange 2013, the Transport Rules agent treats .png and .gif files as supported file types. However, even though they’re treated as supported file types, the Transport Rules agent doesn’t properly extract metadata from these file types. Because they're considered supported file types, transport rules that contain the AttachmentIsUnsupported predicate don’t act on .png or .gif file types.
  
  If you’ve configured a transport rule with the AttachmentIsUnsupported predicate, it won’t run when files with .png or .gif extensions are encountered. If you want a transport rule to also run when these file types are encountered, you need to create another rule for .png and .gif files that triggers your desired policy or action. To do this, you need to use the AttachmentExtensionMatchesWords condition.
  
  For example, if your policy is to reject all unprocessed attachment types, you may have a rule with the following settings:
  
  
  • AttachmentIsUnsupported: True
    
    
  • RejectMessageEnhancedStatusCode: 5.7.1
    
    
  • RejectMessageReasonText: This message contains unsupported attachment types.
    
    
  However, the transport rule won’t run for .png or .gif file types. To apply a similar policy to .png or .gif file types, you need to add another rule that matches these attachment types using the parameter AttachmentExtensionMatchesWords with the values "GIF,PNG". The command below is an example of how to create such a rule:
  
  

  	Copy Code
  New-TransportRule "Process GIF and PNG files" -AttachmentExtensionMatchesWords GIF,PNG -RejectMessageEnhancedStatusCode 5.7.1 -RejectMessageReasonText "This message contains unsupported attachment types."

  For a full list of file types supported in transport rules, see File Types That Are Supported In Transport Rules.
  
  
• DLP policy creation could fail because of invalid characters   When creating data loss prevention (DLP) policies from templates in some locales, the creation fails because of invalid characters in the localized data. Also, some non-English locales may contain English language text for DLP policy templates or descriptions.
  
  To work around this issue, download updated DLP policy templates from Microsoft and install them. For more information, see Microsoft Knowledge Base article 2769370, You cannot create a DLP policy in an Exchange Server 2013 environment.
  
  
• 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.
  
  
• Start and end dates are always interpreted as MM/DD/YYYY in legal discovery search   When you perform a legal discovery search using the Microsoft SharePoint federated e-discovery console, the start and end dates are always interpreted using the MM/DD/YYYY date format. This date format is used regardless of the local computer’s regional settings. This issue also occurs when using the SearchMailboxes Exchange Web Services application programming interface (API) provided by Exchange 2013.
  
  When you perform a legal discovery search, use the MM/DD/YYY date format for the start and end dates.