Exchange 2013 发行说明

适用于:Exchange Server 2013

欢迎使用 Microsoft Exchange Server 2013! 本主题包含成功部署 Exchange 2013 所需的重要信息。 请在开始部署之前,完整阅读本主题。

本主题包含以下各部分:

  • 安装和部署

  • Exchange 命令行管理程序

  • 邮箱

  • 公用文件夹

  • 邮件流

  • 客户端连接

  • Exchange 2010 共存

安装和部署

  • msExchProductId 不反映已安装的 Exchange 2013 的版本 Exchange 扩展 Active Directory 架构并为 Exchange 准备 Active Directory 后,将更新多个属性以显示准备工作已完成。 其中一个属性是命名上下文中Configuration容器下的 CN=<your organization>, CN=Microsoft Exchange, CN=Services, CN=Configuration, DC=<domain>msExchangeProductId。 如果在要安装的 Exchange 2013 版本中未引入任何 Active Directory 架构更改,则此属性不会更新,也可能显示意外值。 如果值与安装的 Exchange 2013 版本不匹配,这可能会导致混淆。

    此行为是预期行为,因为 msExchProductId 的值不反映安装的 Exchange 2013 版本。 此属性反映上次对 Active Directory 架构进行更改的 Exchange 2013 版本。 为了避免混淆,我们建议你按照准备 Active Directory 和域“如何知道这有效?”部分中的步骤来验证 Active Directory 是否已更新并准备好发布要安装的 Exchange 2013。

  • 安装程序错误地请求 .NET Framework 4.0:如果尝试安装 Exchange 2013 而不在计算机上安装.NET Framework,安装程序会错误地请求安装 .NET Framework 4.0,而实际上需要.NET Framework 4.5 或更高版本。

    若要解决此问题,请安装 .NET Framework 4.5 或更高版本。 无需安装 .NET Framework 4.0。 有关先决条件的完整列表,请参阅 Exchange 2013 先决条件

  • 在累积更新安装过程中将覆盖 Exchange XML 应用程序配置文件:在 Exchange XML 应用程序配置文件中所做的任何自定义 Exchange 或 Internet Information Server 每服务器设置(例如,客户端访问服务器上的web.config文件或邮箱服务器上的EdgeTransport.exe.config文件)将在安装 Exchange 累积更新或 Service Pack 时被覆盖。 请务必保存此类信息,以便在安装累积更新后,您可以轻松地重新配置服务器。 安装 Exchange 累积更新或 Service Pack 后,必须重新配置这些设置。

  • 使用委派管理权限安装 Exchange 会导致安装程序失败 仅当委派安装角色组成员的用户尝试在预先设置的服务器上安装 Exchange 时,安装程序失败。 之所以发生这种情况,是因为委派安装组缺少在 Active Directory 中创建和配置特定对象所需的权限。

    若要解决此问题,请执行下列操作之一:

    • 将安装 Exchange 的用户添加到 Domain Admins Active Directory 安全组。

    • 通过属于组织管理角色组成员的用户安装 Exchange。

有关如何安装 Exchange 2013 的详细信息,请参阅 规划和部署

Exchange 命令行管理程序

  • Shell 意外加载 Exchange 2007 或 Exchange 2010 cmdlet 以前,在 Exchange 2013 服务器上打开 Shell 会导致 Shell 与本地服务器或运行 Exchange 2013 的另一台服务器建立连接。 建立连接后,将加载 Exchange 2013 cmdlet。 从 Exchange 2013 CU11 开始,Shell 将连接到登录用户的邮箱所在的 Exchange 服务器。 如果登录用户没有邮箱,Shell 将连接到 SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c} 仲裁邮箱所在的服务器。 目标服务器可以是任何受支持的 Exchange 版本。 这意味着,如果登录用户的邮箱 (或仲裁邮箱(如果用户没有邮箱) 位于 Exchange 2010 服务器上),Shell 将连接到该服务器并加载 Exchange 2010 cmdlet。 这可能会阻止你执行某些任务,因为 Exchange 2010 cmdlet 无法管理 Exchange 2013 配置或服务器。

    从 Exchange 2013 CU11 开始,此行为是设计而来的。 若要确保 Shell 加载 Exchange 2013 cmdlet,请将登录用户的邮箱移动到 Exchange 2013。 如果登录用户没有邮箱,请将 SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c} 仲裁邮箱移动到 Exchange 2013 服务器。

    有关如何移动仲裁邮箱的详细信息和信息,请参阅 Exchange Team 博客上的 Exchange 命令行管理程序和邮箱定位

邮箱

  • 可以将运行不同 Exchange 版本的邮箱服务器添加到同一数据库可用性组Add-DatabaseAvailabilityGroupServer cmdlet 和 Exchange 管理中心错误地允许将 Exchange 2013 服务器添加到基于 Exchange 2016 的数据库可用性组 (DAG) ,反之亦然。 Exchange 仅支持将运行相同版本的邮箱服务器(例如 Exchange 2013 与 Exchange 2016)添加到 DAG。 此外,Exchange 管理员中心会在可添加到 DAG 的服务器列表中同时显示 Exchange 2013 和 Exchange 2016。 这将允许管理员无意中将运行不兼容版本的 Exchange 的服务器添加到 DAG(例如,将 Exchange 2013 服务器添加到基于 Exchange 2016 的DAG)。

    There is currently no workaround for this issue. Administrators must be diligent when adding a Mailbox server to a DAG. Add only Exchange 2013 servers to Exchange 2013-based DAGs, and only Exchange 2016 servers to Exchange 2016-based DAGs. You can differentiate each version of Exchange by looking at the Version column in the list of servers in the Exchange admin center. The following are the server versions for Exchange 2013 and Exchange 2016:

    • Exchange 2013 15.0(生成号 xxx.xx)

    • Exchange 2016 15.1(生成号 xxx.xx)

  • 从以前的 Exchange 版本迁移时邮箱大小会增加:将邮箱从 Exchange 的早期版本移动到 Exchange 2013 时,报告的邮箱大小可能会增加 30% 到 40%。 邮箱数据库使用的磁盘空间没有增加,只有每个邮箱使用的空间属性已增加。 邮箱大小的增加是由于将所有项目属性包含在配额计算中,从而可以更准确地计算其邮箱中的项目占用的空间。 此增加可能会导致某些用户在将邮箱移动到 Exchange 2013 时超过其邮箱大小配额。

    若要防止用户超过其邮箱大小配额,请增加数据库或邮箱配额值以适应新的配额计算。 若要配置数据库或邮箱配额值,请分别对 Set-MailboxDatabaseSet-Mailbox cmdlet 使用 IssueWarningQuotaProhibitSendQuotaProhibitSendReceiveQuota 参数。

  • Outlook 2007 和 Outlook 2010 客户端可能无法下载脱机通讯簿:如果无法从 Internet 访问脱机通讯簿 (OAB) 内部 URL,则 Outlook 2007 和 Outlook 2010 客户端可能无法下载 OAB。

    若要为 Outlook 2007 和 Outlook 2010 客户端解决此问题,请使 OAB 内部 URL 可从 Internet 访问。 此问题不会影响 Outlook 2013。

  • 在现有 Exchange 组织中安装 Exchange 2013 可能会导致所有客户端下载 OAB:将第一台 Exchange 2013 服务器安装到现有 Exchange 2007 或 Exchange 2010 组织中可能会导致组织中的所有客户端下载 OAB 的新副本,从而导致网络饱和和服务器性能问题。 出现此问题的原因是 Exchange 2013 在取代 Exchange 2007 或 Exchange 2010 OAB 的组织中创建了一个新的默认 OAB。 未分配特定 OAB 或位于未分配特定 OAB 的邮箱数据库中的邮箱将下载新的默认 OAB。

    若要防止客户端在安装 Exchange 2013 时下载 OAB 的新副本,请将 OAB 分配给每个邮箱或邮箱所在的邮箱数据库。 必须在组织中安装 Exchange 2013 之前完成此操作。

  • 用户可能被路由到对所请求的 OAB 不负责的 OAB 生成邮箱:Exchange 2013 CU5 及更高版本的 CU 已更改 OAB 与 OAB 生成邮箱的链接方式。 通过此更改,可以将用户路由到对用户请求的 OAB 不负责的 OAB 生成邮箱。 如果以下所有条件都成立,则可能会发生这种情况:

    • 组织中有多个 OAB 生成邮箱。

    • 在升级客户端访问服务器之前,请升级托管 OAB 生成邮箱的邮箱服务器。

    • 你要将 Exchange 2013 服务器从 CU5 之前的版本升级到更高版本 (例如从 Exchange 2013 CU3 升级到 Exchange 2013 CU6) 。

    • 客户端访问服务器运行 CU5 之前的版本。

    若要解决此问题,请确保在升级邮箱服务器之前将客户端访问服务器升级到 Exchange 2013 CU6 或更高版本。 这将确保客户端访问服务器知道如何将请求代理到负责生成用户的 OAB 生成邮箱的请求。

    若要详细了解 Exchange 2013 CU5 中的 OAB 更改,请参阅 Exchange 2013 累积更新 5 中的 OAB 改进

公用文件夹

  • 未经授权的发件人无法再将邮件发送到已启用邮件的公用文件夹:在 Exchange 2013 CU6 之前,未经授权的发件人可以将邮件发送到已启用邮件的公用文件夹。 这允许外部发件人将邮件发送到已启用邮件的公用文件夹,而不考虑对公用文件夹设置的权限。

    从 Exchange 2013 CU6 开始,如果希望外部发件人将邮件发送到已启用邮件的公用文件夹,则至少需要向 匿名 用户授予 “创建项目” 权限。 如果已设置启用邮件的公用文件夹但尚未执行此操作,外部发件人将收到传递失败通知,并且邮件不会传递到已启用邮件的公用文件夹。

    可以使用命令行管理程序或 Outlook 设置匿名用户的权限。 要了解如何设置匿名用户的权限,请参阅对公用文件夹启用或禁用邮件

  • 可从旧 Exchange 服务器迁移到 Exchange 2013 的公用文件夹的最大数目为 500,000。 有关公用文件夹迁移的详细信息,请参阅 使用批量迁移将公用文件夹从早期版本迁移到 Exchange 2013

邮件流

  • 客户端访问服务器上的 TransportAgent cmdlet 需要本地Windows PowerShell*-TransportAgent cmdlet 存在一个问题,它阻止这些 cmdlet 使用 Exchange 命令行管理程序在客户端访问服务器上安装、卸载和管理传输代理。 若要在客户端访问服务器上安装、卸载和管理传输代理,必须手动加载 Exchange Windows PowerShell管理单元,然后运行 *-TransportAgent cmdlet。 如果尝试使用 Exchange 命令行管理程序安装、卸载或管理传输代理,所做的更改将应用于连接到的 Exchange 2013 邮箱服务器。

    若要在客户端访问服务器上安装、卸载或管理传输代理,请在要管理的客户端访问服务器上执行以下操作:

    警告

    Microsoft.Exchange.Management.PowerShell.SnapIn 不支持加载Windows PowerShell管理单元和运行 -TransportAgent cmdlet 以外的 cmdlet,并且可能会导致 Exchange 部署遭受无法修复的损害。

    必须是要在其中安装、卸载或管理传输代理的客户端访问服务器上的本地管理员。 我们不支持修改对 Exchange 文件、目录或 Active Directory 对象 (ACL) 访问控制列表。

    重要

    仅在客户端访问服务器上执行以下过程。 如果要管理邮箱服务器上的传输代理,则无需加载 Exchange Windows PowerShell管理单元。

    1. 打开新的Windows PowerShell窗口。

    2. 运行以下命令:

      Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn
      
    3. 像平常一样执行传输代理管理任务。

    4. 在要管理的每台客户端访问服务器上重复此过程。

客户端连接

  • 对于未加入域的客户端,NTLM 身份验证失败:如果满足以下条件,则客户端(如 Windows Live Mail 和 Exchange 2013)之间的身份验证可能会失败:

    • 然后,客户端使用的身份验证方法是 NTLM。

    • 计算机未加入域。

    若要解决此问题,可以执行下列操作之一:

    • 将运行客户端的计算机加入域。

    • 将客户端使用的身份验证类型从 NTLM 更改为基于 TLS 的基本身份验证。

  • 与 Send-MailMessage cmdlet 一起使用时,GSSAPI 身份验证失败:当 Send-MailMessage cmdlet(默认安装包含Windows PowerShell)用于将经过身份验证的邮件发送到 Exchange 2013 时,通用安全服务应用程序接口 (GSSAPI) 身份验证可能会失败。 发生这种情况时,你将在 Exchange 2013 客户端访问服务器上的 应用程序 事件日志中看到一个条目,该条目接收了连接,其中包含以下信息:

    • :MSExchangeFrontEndTransport

    • 事件 ID:1035

    • 说明:入站身份验证失败,并显示“接收连接器客户端前端<服务器名称>”错误IllegalMessage。 身份验证机制为 Gssapi。 尝试向 Exchange 进行身份验证的客户端的源 IP 地址是 [<客户端 IP 地址>]。

    若要解决此问题,需要从 Exchange 2013 客户端访问服务器上的客户端接收连接器中删除 Integrated 身份验证方法。 若要从客户端接收连接器中删除 Integrated 身份验证方法,请在可从运行 Send-MailMessage cmdlet 的计算机接收连接的每台 Exchange 2013 客户端访问服务器上运行以下命令:

    Set-ReceiveConnector "<server name>\Client Frontend <server name>" -AuthMechanism Tls, BasicAuth, BasicAuthRequireTLS
    
  • 升级到 Exchange 2013 SP1 时,通过 HTTP 的 MAPI 可能会遇到性能不佳的问题:如果从 Exchange 2013 累积更新升级到 Exchange 2013 SP1 并通过 HTTP 启用 MAPI,则使用协议连接到 Exchange 2013 SP1 服务器的客户端可能会遇到性能不佳的问题。 这是因为在从累积更新升级到 Exchange 2013 SP1 期间未配置所需的设置。 如果从 Exchange 2013 RTM 升级到 Exchange 2013 SP1,或者安装了新的 Exchange 2013 SP1 或更高版本的服务器,则不会出现此问题。

    注意

    仅当客户端访问服务器上启用了 MAPI over HTTP 协议时,才会出现问题。 默认情况下,它处于禁用状态。 如果禁用了 MAPI over HTTP,客户端将改用 RPC over HTTP 协议。

    若要解决此问题,请执行以下操作:

    1. 在运行客户端访问服务器角色的服务器上,在 Windows 命令提示符中运行以下命令:

      set AppCmdLocation=%windir%\System32\inetsrv
      set ExchangeLocation=%ProgramFiles%\Microsoft\Exchange Server\V15
      
      %AppCmdLocation%\appcmd.exe SET AppPool "MSExchangeMapiFrontEndAppPool" /CLRConfigFile:"%ExchangeLocation%\bin\MSExchangeMapiFrontEndAppPool_CLRConfig.config"
      %AppCmdLocation%\appcmd.exe RECYCLE AppPool "MSExchangeMapiFrontEndAppPool"
      
    2. 在运行邮箱服务器角色的服务器上,在 Windows 命令提示符中运行以下命令:

      set AppCmdLocation=%windir%\System32\inetsrv
      set ExchangeLocation=%ProgramFiles%\Microsoft\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"
      

Exchange 2010 共存

  • 通过 Exchange 2013 客户端访问服务器代理时,访问 Exchange 2010 邮箱的请求可能不起作用:在某些情况下,Exchange 2013 和 Exchange 2010 Service Pack 3 之间的代理请求 (SP3) 客户端访问服务器(未安装任何更新汇总)可能无法正常工作,并出现错误。 如果满足以下所有条件,则可能会发生这种情况:

    • 具有 Exchange 2013 邮箱的用户尝试使用以下方法之一打开 Exchange 2010 邮箱:

      • Outlook Web App -OR- 中的“打开另一个邮箱”选项

      • Exchange 管理中心中的 “其他用户 ”选项

      • 用户连接到的客户端访问服务器正在运行 Exchange 2013。

      • Exchange 2010 客户端访问服务器已从版本升级到 Exchange 2010 SP3,以制造 (RTM) Exchange 2010 版本或以前的 Exchange 2010 Service Pack。

    如果上述所有条件都为 true,则用户将无法访问其他用户的 Exchange 2010 Outlook Web App选项,并且可能会出现空白页面。

    若要解决此问题,请在每台 Exchange 2010 服务器上安装 Exchange 2010 SP3 更新汇总 1 或更高版本。