Exchange 2013 发行说明

适用于: Exchange Server 2013

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

本主题包含以下各部分:

  • 安装和部署

  • Exchange 命令行管理程序

  • 邮箱

  • 公用文件夹

  • 邮件流

  • 客户端连接

  • Exchange 2010 共存

安装和部署

  • msExchProductId 不反映已安装的 Exchange 2013 版本 Exchange 扩展 Active Directory 架构并准备适用于 Exchange 的 Active Directory 后,会更新多个属性,以显示准备已完成。 其中一个属性是命名上下文中容器下的 CN=<your organization>, CN=Microsoft Exchange, CN=Services, CN=Configuration, DC=<domain> Configuration 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.5 或更高版本时安装.NET Framework 4.0。

    若要解决此问题,请安装.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 的用户添加到“域管理员 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 Management Shell 和邮箱定位

邮箱

  • 运行不同版本 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)。

    此问题暂无解决办法。向 DAG 添加邮箱服务器时,管理员必须非常用心。仅将 Exchange 2013 服务器添加到基于 Exchange 2013 的 DAG,仅将 Exchange 2016 服务器添加到基于 Exchange 2016 的 DAG。若要区分各个 Exchange 版本,可以查看 Exchange 管理中心内服务器列表中的“版本”列。下面列出了 Exchange 2013 和 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 在组织中创建了一个新的默认 OAB,用于取代 Exchange 2007 或 Exchange 2010 OAB。 未分配特定 OAB 或位于未分配特定 OAB 的邮箱数据库中的邮箱将下载新的默认 OAB。

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

  • 用户可能被路由到 OAB 代邮箱,而该邮箱不负责请求的 OAB:Exchange 2013 CU5 和更高版本的 CU 更改了 OAB 链接到 OAB 代邮箱的操作方式。 此更改使用户可以路由到不负责用户请求的 OAB 的 OAB 代邮箱。 如果以下所有内容均为 true,则可能会发生这种情况:

    • 组织中有多个 OAB 代邮箱。

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

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

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

    若要解决此问题,请确保在升级邮箱服务器之前将客户端访问服务器升级到 Exchange 2013 CU6 或更高版本。 这将确保客户端访问服务器知道如何将请求代理到负责生成用户 OAB 的 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 Management Shell 在客户端访问服务器上安装、卸载和管理传输代理。 若要在客户端访问服务器上安装、卸载和管理传输代理,必须手动加载 Exchange Windows PowerShell管理单元,然后运行 *-TransportAgent cmdlet。 如果尝试使用 Exchange Management Shell 安装、卸载或管理传输代理,则更改将应用于连接到的 Exchange 2013 邮箱服务器。

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

    警告

    Microsoft.Exchange.Management.PowerShell.SnapIn 不支持加载Windows PowerShell管理单元和运行 -TransportAgent cmdlet 以外的 cmdlet,并且可能会对 Exchange 部署造成无法弥补的损害。

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

    重要

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

    1. 打开新的Windows PowerShell窗口。

    2. 运行以下命令。

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

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

客户端连接

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

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

    • 计算机未加入域。

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

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

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

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

    • 来源:MSExchangeFrontEndTransport

    • 事件 ID:1035

    • 说明:入站身份验证失败,接收连接器客户端前端<server name>出现错误IllegalMessage。 身份验证机制为 Gssapi。 尝试向 Exchange 进行身份验证的客户端的源 IP 地址为 [<client IP address>]。

    若要解决此问题,需要从 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 协议时,才会出现此问题。 默认情况下已禁用。 如果禁用了通过 HTTP 的 MAPI,则客户端将改为通过 HTTP 协议使用 RPC。

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

    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) 客户端访问服务器(未安装任何更新汇总)可能无法正常工作,并出现错误。 如果以下所有条件均为 true,则可能会发生这种情况:

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

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

      • Exchange 管理中心中 的另一个用户 选项

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

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

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

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