Applies to: Exchange Server 2013
Topic Last Modified: 2013-02-25
Welcome to Microsoft Exchange Server 2013! This topic contains important information that you need to know to successfully deploy Exchange 2013. Please read this topic completely before beginning your deployment.
This topic contains the following sections:
Setup and deployment
- 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
- 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
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
- Open a new Windows PowerShell window.
- 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
AttachmentIsUnsupportedpredicate don’t act on .png or .gif file types.
If you’ve configured a transport rule with the
AttachmentIsUnsupportedpredicate, 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
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
AttachmentExtensionMatchesWordswith the values "GIF,PNG". The command below is an example of how to create such a rule:
New-TransportRule "Process GIF and PNG files" -AttachmentExtensionMatchesWords GIF,PNG -RejectMessageEnhancedStatusCode 5.7.1 -RejectMessageReasonText "This message contains unsupported attachment types."
- AttachmentIsUnsupported: True
- 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
When you perform a legal discovery search, use the MM/DD/YYY date format for the start and end dates.