Exchange 2013 のリリース ノートRelease notes for Exchange 2013

に適用されます: Exchange Server 2013Applies to: Exchange Server 2013

Microsoft Exchange Server 2013 へようこそ!このトピックには、Exchange 2013 の展開を成功させるために必要な重要な情報が含まれています。展開を開始する前にこのトピックを完全に参照してください。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

  • Exchange 管理シェルExchange Management Shell

  • MailboxMailbox

  • パブリック フォルダーPublic folders

  • メール フローMail flow

  • クライアント接続Client connectivity

  • Exchange 2010 の共存Exchange 2010 coexistence

セットアップと展開Setup and deployment

  • msExchProductId がインストールされている Exchange 2013 のリリース バージョンに反映されません。 Exchange は、Active Directory スキーマを拡張し、Exchange の Active Directory を準備、準備が完了したことを表示するのにはいくつかのプロパティが更新されます。の下のmsExchangeProductIdは、これらのプロパティのいずれか、CN=<your organization>, CN=Microsoft Exchange, CN=Services, CN=Configuration, DC=<domain>のコンテナー、Configurationの名前付けコンテキストです。インストールしている Exchange 2013 のリリースでは、Active Directory スキーマの変更は発生しない、このプロパティは更新されませんまたは、予期しない値を表示することがあります。値がインストールされている Exchange 2013 のバージョンと一致しない場合、混乱が生じます。msExchProductId doesn't reflect release version of Exchange 2013 installed After Exchange extends your Active Directory schema and prepares Active Directory for Exchange, several properties are updated to show that preparation is complete. One of these properties is msExchangeProductId under the CN=<your organization>, CN=Microsoft Exchange, CN=Services, CN=Configuration, DC=<domain> container in the Configuration naming context. If no Active Directory schema changes are introduced in the release of Exchange 2013 you're installing, this property won't be updated or may show an unexpected value. This could cause confusion if the value doesn't match the version of Exchange 2013 being installed.

    MsExchProductIdの値は、Exchange 2013 のインストール中のバージョンを反映しないと、この動作が必要です。このプロパティは、Active Directory スキーマに変更を行った最後の Exchange 2013 のバージョンを表します。混乱を避けるためには、推奨の手順に従うこと、を知るこの方法ですか?Active Directory の準備とドメインを確認する、Active Directory が更新されており、Exchange 2013 のリリースの準備をしています。インストールします。This behavior is expected as the value of msExchProductId doesn't reflect the version of Exchange 2013 being installed. This property reflects the version of Exchange 2013 that last made changes to the Active Directory schema. To avoid confusion, we recommend that you follow the steps in the How do you know this worked? section of Prepare Active Directory and domains to verify that your Active Directory has been updated and is ready for the release of Exchange 2013 you're installing.

  • セットアップによって.NET Framework 4.0 が正しくない要求 .NET Framework をコンピューターにインストールせずに Exchange 2013 をインストールしようとすると、セットアップ正しく要求されません、実際には、4.5 またはそれ以降の.NET Framework が必要な場合は、.NET Framework 4.0 をインストールすることです。Setup incorrectly requests .NET Framework 4.0 If you try 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 or later is required.

    この問題を回避するには、4.5 またはそれ以降の.NET Framework をインストールします。.NET Framework 4.0 をインストールする必要はありません。前提条件の一覧については、 Exchange 2013 の必須コンポーネントを参照してください。To work around this issue, install .NET Framework 4.5 or later. You don’t need to install .NET Framework 4.0. For a complete list of prerequisites, see Exchange 2013 prerequisites.

  • Exchange XML アプリケーション構成ファイルは累積的な更新プログラムのインストール中に上書きされます。 カスタマイズされた Exchange やインターネット インフォメーション サービス サーバーごとの設定した値 Exchange クライアント アクセス サーバー上の web.config ファイルまたはメールボックス サーバー上の EdgeTransport.exe.config ファイルなどの XML アプリケーション構成ファイルになりますExchange の累積的な更新プログラムまたは Service Pack をインストールするときに上書きします。構成できるように簡単に再度、サーバーのインストール後は、この情報を保存することを確認します。Exchange の累積的な更新プログラムまたは Service Pack をインストールした後に再度、これらの設定を構成する必要があります。Exchange XML application configuration files are overwritten during cumulative update installation Any customized Exchange or Internet Information Server 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.

  • 代理管理者のアクセス許可を使用して Exchange をインストールするとセットアップに失敗する委任セットアップ役割グループのみのメンバーであるユーザーが事前に準備されたサーバーに Exchange をインストールしようとすると、セットアップに失敗します。この失敗は、委任セットアップ役割グループに、Active Directory 内で特定のオブジェクトを作成および構成するために必要なアクセス許可がないために起こります。Installing Exchange using Delegate Admin permissions causes Setup to fail When a user who's a member of only the Delegated Setup role group attempts to install Exchange on a pre-provisioned server, Setup will fail. This happens because the Delegated Setup group lacks the permissions required to create and configure certain objects in Active Directory.

    この問題を回避するには、次のいずれかの操作を行います。To work around this issue, do one of the following:

    • Exchange をインストールするユーザーを、Active Directory セキュリティ グループの Domain Admins に追加します。Add the user installing Exchange to the Domain Admins Active Directory security group.

    • 組織の管理役割グループのメンバーであるユーザーを使用して、Exchange をインストールします。Install Exchange using a user that's a member of the Organization Management role group.

Exchange 2013 をインストールする方法の詳細については、計画と展開を参照してください。For more information about how to install Exchange 2013, see Planning and deployment.

Exchange 管理シェルExchange Management Shell

  • Exchange 2007 または Exchange 2010 コマンドレットをシェルが予期せずロード以前は、Exchange 2013 サーバー上のシェルを開くになるローカル サーバーまたは Exchange 2013 を実行している別のサーバーへの接続を開くときのシェルです。接続が確立されると、Exchange 2013 コマンドレットが読み込まれます。Exchange 2013 CU11 から始めて、シェルは、ログオンしたユーザーのメールボックスが配置されている Exchange サーバーに接続します。ログオン中のユーザーがメールボックスを持っていない場合、シェルは SystemMailbox {bb558c35-97f1-4cb9-8ff7-d53741dc928c} の調停メールボックスが格納されているサーバーに接続します。ターゲット サーバーは、Exchange のすべてのサポートされているバージョンにできます。これは、Exchange 2010 サーバーにログオンしたユーザーのメールボックス (またはユーザーがメールボックスを持っていない場合は、調停メールボックス) がある場合、シェルはそのサーバーに接続し、Exchange 2010 コマンドレットを読み込むことを意味します。Exchange 2010 コマンドレットは、Exchange 2013 の構成やサーバーを管理できないために、特定のタスクを実行できない場合があります。The Shell unexpectedly loads Exchange 2007 or Exchange 2010 cmdlets Previously, opening the Shell on an Exchange 2013 server would result in the Shell opening a connection to the local server or another server running Exchange 2013. When the connection is made, Exchange 2013 cmdlets are loaded. Starting with Exchange 2013 CU11, the Shell will connect to the Exchange server where the logged on user's mailbox is located. If the logged on user doesn't have a mailbox, the Shell will connect to the server where the SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c} arbitration mailbox is located. The target server can be any supported version of Exchange. This means if the logged on user's mailbox (or the arbitration mailbox if the user has no mailbox) is located on an Exchange 2010 server, the Shell will connect to that server and load Exchange 2010 cmdlets. This may prevent you from performing certain tasks because Exchange 2010 cmdlets can't manage Exchange 2013 configuration or servers.

    Exchange 2013 CU11 以降、この動作は仕様です。シェルが Exchange 2013 コマンドレットを読み込むようにするには、ログオンするユーザーのメールボックスを Exchange 2013 に移動します。ログオンするユーザーがメールボックスを持っていない場合は、SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c} 調停メールボックスを Exchange 2013 サーバーにします。 Starting with Exchange 2013 CU11, this behavior is by design. To make sure the Shell loads Exchange 2013 cmdlets, move the logged on user's mailbox to Exchange 2013. If the logged on user doesn't have a mailbox, move the SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c} arbitration mailbox to an Exchange 2013 server.

    詳細および調停メールボックスを移動する方法については、Exchange チームのブログでExchange 管理シェルとアンカーのメールボックスを参照してください。For details and information on how to move the arbitration mailbox, see Exchange Management Shell and Mailbox Anchoring on the Exchange Team blog.

MailboxMailbox

  • バージョンが異なる Exchange を実行しているメールボックス サーバーを、同一のデータベース可用性グループに追加できる Add-DatabaseAvailabilityGroupServer コマンドレットと Exchange 管理センターにより、Exchange 2013 サーバーを Exchange 2016 ベースのデータベース可用性グループ (DAG) に追加する操作、またはその反対の操作が誤って許可されています。Exchange では、同じバージョン (Exchange 2013 や Exchange 2016 など) を実行しているメールボックス サーバーを DAG に追加する操作のみをサポートしています。一方、Exchange 管理センターでは、Exchange 2013 サーバーと Exchange 2016 サーバーの両方が、DAG に追加できるサーバーの一覧に表示されます。この結果、互換性のないバージョンの Exchange を実行するサーバーを、管理者が誤って DAG に追加する (Exchange 2013 サーバーを Exchange 2016 ベースの DAG に追加するなど) 可能性があります。Mailbox servers running different versions of Exchange can be added to the same database availability group The Add-DatabaseAvailabilityGroupServer cmdlet and the Exchange Admin Center incorrectly allow an Exchange 2013 server to be added to an Exchange 2016-based database availability group (DAG), and vice versa. Exchange supports adding only Mailbox servers running the same version (Exchange 2013 versus Exchange 2016, for example) to a DAG. Additionally, the Exchange Admin Center displays both Exchange 2013 and Exchange 2016 servers in the list of servers available to add to a DAG. This could allow an administrator to inadvertently add a server running an incompatible version of Exchange to a DAG (for example, adding an Exchange 2013 server to an Exchange 2016-based DAG).

    この問題に対する回避策はありません。管理者は、メールボックス サーバーを DAG に追加するときに十分に注意して行う必要があります。Exchange 2013 のサーバーは Exchange 2013 ベースの DAG にのみ、Exchange 2016 のサーバーは Exchange 2016 ベースの DAG にのみ追加します。Exchange 管理センターで、サーバーの一覧の [バージョン] 列を確認することにより、Exchange の各バージョンを区別できます。Exchange 2013 および Exchange 2016 のサーバーのバージョンを次に示します。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 2013 15.0 (Build xxx.xx)

    • Exchange 2016 15.1 (ビルド xxx.xx)Exchange 2016 15.1 (Build xxx.xx)

  • Exchange の以前のバージョンから移行するとメールボックスのサイズが増加 以前のバージョンの Exchange を Exchange 2013 メールボックスを移動すると、報告されたメールボックスのサイズが 40% を 30% に向上します。メールボックス データベースによって使用されるディスク領域は増加しませんが、各メールボックスによって使用される領域の属性のみが増加します。メールボックス サイズの拡大は、自分のメールボックス内のアイテムによって消費される領域のより正確な計算を提供する、クォータの計算にすべてのアイテムのプロパティを含めることが原因です。この増加は、一部のユーザーに自分のメールボックスが 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.

    ユーザーのメールボックス サイズがクォータを超えないようにするため、新しいクォータ計算に対応できるよう、データベースやメールボックスのクォータ値を増やします。データベースやメールボックスのクォータ値を構成するには、IssueWarningQuota パラメーター、ProhibitSendQuota パラメーター、ProhibitSendReceiveQuota パラメーターをそれぞれ Set-MailboxDatabase コマンドレットと Set-Mailbox コマンドレットで使用します。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 および Outlook 2010 クライアントがオフライン アドレス帳をダウンロードできない可能性があります。 オフライン アドレス帳 (OAB) の内部 URL がインターネットからアクセス可能でない場合 Outlook 2007 および Outlook 2010 クライアントが OAB をダウンロードすることがない場合があります。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.

    Outlook 2007 および Outlook 2010 クライアントでこの問題を回避するのには、インターネットからアクセス可能な OAB の内部 URL を確認します。Outlook 2013 は、この問題の影響を受けません。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.

  • 既存の Exchange 組織で Exchange 2013 をインストールする場合、OAB をダウンロードするすべてのクライアントがあります。 最初の Exchange 2013 サーバーを既存の Exchange 2007 または Exchange 2010 組織にインストールするネットワークの飽和状態とサーバー パフォーマンスの問題の結果として、OAB の新しいコピーをダウンロードするのには組織内のすべてのクライアントあります。この問題は、Exchange 2013 は、Exchange 2007 または Exchange 2010 の OAB を優先する組織に新しい既定の OAB を作成するために発生します。割り当てられている特定の OAB を必要はありませんまたは割り当てられている、特定の OAB を設定していないメールボックス データベース上にあるメールボックスでは、新しい既定の OAB をダウンロードします。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.

    クライアントが Exchange 2013 がインストールされている場合、OAB の新しいコピーをダウンロードするを防ぐ、またはメールボックス データベースにメールボックスがあるすべてのメールボックスに OAB を割り当てます。組織にインストールされている Exchange 2013 の前にこれを行う必要があります。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.

  • 要求された OAB の原因では、OAB の生成のメールボックスにユーザーをルーティングすることがあります。 Exchange 2013 CU5 と CUs の後では、OAB の生成のメールボックスに Oab をリンクする方法に変更しました。この変更により、ユーザーは、ユーザーが要求している OAB の担当ではない OAB 生成、メールボックスにルーティングされます。これは、次のすべてに該当する場合に発生することができます。Users may be routed to an OAB generation mailbox that's not responsible for the requested OAB Exchange 2013 CU5 and later CUs have changed how OABs are linked to OAB generation mailboxes. This change makes it possible for a user to be routed to an OAB generation mailbox that isn't responsible for the OAB that the user is requesting. This can happen if all of the following are true:

    • 組織内に複数の OAB 生成メールボックスが存在する。You have more than one OAB generation mailbox in your organization.

    • クライアント アクセス サーバーをアップグレードする前に、OAB 生成メールボックスをホストするメールボックス サーバーをアップグレードする。You upgrade the Mailbox servers that host OAB generation mailboxes before you upgrade your Client Access servers.

    • アップグレードする、Exchange 2013 サーバー CU5 より前のリリース以降のリリース (たとえば、Exchange 2013 CU3 から Exchange 2013 CU6 へのアップグレードなど) にします。You're upgrading your Exchange 2013 servers from a release prior to CU5 to a later release (for example, upgrading from Exchange 2013 CU3 to Exchange 2013 CU6).

    • クライアント アクセス サーバーが CU5 より前のリリースを実行している。Your Client Access servers are running a release prior to CU5.

    この問題を回避するには、メールボックス サーバーをアップグレードする前に、Exchange 2013 CU6 またはそれ以降のクライアント アクセス サーバーをアップグレードすることを確認します。これにより、クライアント アクセス サーバーが知っていることを確認して、どのプロキシに OAB の生成のメールボックスへの要求はユーザーの OAB を生成します。To work around this issue, make sure that you upgrade your Client Access servers to Exchange 2013 CU6 or later before you upgrade your Mailbox servers. This will make sure the Client Access servers know how to proxy the requests to the OAB generation mailbox that is responsible for generating the user’s OAB.

    OAB の詳細が変更された Exchange 2013 CU5 を読み取り、 OAB の強化 Exchange 2013 の累積更新プログラムの 5を参照してください。To read more about the OAB changes in Exchange 2013 CU5, see OAB Improvements in Exchange 2013 Cumulative Update 5.

パブリック フォルダーPublic folders

  • 許可されていない送信者がメールが有効なパブリック フォルダーにメッセージを送信できなくなった  Exchange 2013 CU6 より前には、許可されていない送信者が電子メールが有効なパブリック フォルダーにメッセージを送信できました。これにより、パブリック フォルダーに設定された許可には関係なく、外部の送信者がメールが有効なパブリック フォルダーにメールを送信することが可能でした。Unauthorized senders can no longer send messages to mail-enabled public folders Prior to Exchange 2013 CU6, unauthorized senders could send messages to mail-enabled public folders. This allowed the possibility for external senders to send mail to mail-enabled public folders regardless of the permissions set on the public folder.

    Exchange 2013 CU6 以降、外部の送信者がメールが有効なパブリック フォルダーにメールを送信する場合、[匿名] ユーザーに [アイテムの作成] 以上のアクセス許可が付与されている必要があります。メールが有効なパブリック フォルダーをセットアップしていて、このアクセス許可の付与を行っていない場合、外部のユーザーは配信失敗の通知を受け取り、メッセージはメールが有効なパブリック フォルダーに配信されません。Starting with Exchange 2013 CU6, if you want external senders to send mail to a mail-enabled public folders, the Anonymous user needs to be granted at least the Create Items permission. If you've set up mail-enabled public folders and haven't done this, external senders will receive a delivery failure notification and the messages won't be delivered to the mail-enabled public folder.

    匿名ユーザーのアクセス許可を設定するには、シェルや Outlook を使用できます。匿名ユーザーにアクセス許可を設定する方法について詳しくは、「パブリック フォルダーのメールの有効化またはメールの無効化」を参照してください。You can use the Shell or Outlook to set the permissions on the Anonymous user. To read more about how to set permissions on the Anonymous user, see Mail-enable or mail-disable a public folder.

  • 従来の Exchange サーバーから Exchange 2013 に移行できるパブリック フォルダーの最大数は、500,000 です。パブリック フォルダーの移行については、「Use batch migration to migrate public folders to Exchange 2013 from previous versions」をご覧ください。The maximum number of public folders that can be migrated to Exchange 2013 from legacy Exchange servers is 500,000. For more information about public folder migration, see Use batch migration to migrate public folders to Exchange 2013 from previous versions.

メール フローMail flow

  • クライアント アクセス サーバー上の TransportAgent コマンドレットは、ローカルの Windows PowerShell を必要とします。 問題が存在する、 ** *TransportAgent -** これらのコマンドレットをインストール、アンインストール、および Exchange 管理シェルを使用してクライアント アクセス サーバー上のトランスポート エージェントを管理するを防止するためのコマンドレットです。インストール、アンインストール、およびクライアント アクセス サーバー上のトランスポート エージェントの管理、する必要があります手動でロードする Exchange Windows PowerShell スナップインとその後の実行、 ** *TransportAgent -** コマンドレットです。インストール、アンインストール、または Exchange 管理シェルを使用してトランスポート エージェントを管理しようとする場合、変更内容を接続している Exchange 2013 メールボックス サーバーに適用されます。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:

    警告

    ロード、Microsoft.Exchange.Management.PowerShell.SnapIn以外の Windows PowerShell スナップインで、実行中のコマンドレットの*-TransportAgentコマンドレットは、サポートされていないと、Exchange の展開が回復不可能な破損ことがあります。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.
    インストール、アンインストール、またはトランスポート エージェントを管理するクライアント アクセス サーバー上のローカル管理者でなければなりません。Exchange ファイル、ディレクトリ、または Active Directory オブジェクトのアクセス制御リスト (Acl) の変更をサポートはしていません。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.

    重要

    クライアント アクセス サーバーだけでは、次の手順を実行します。交換をロードする必要はありません Windows PowerShell スナップインで、メールボックス サーバー上のトランスポート エージェントを管理する場合。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. 新しい Windows PowerShell のウィンドウを開きます。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.

クライアント接続Client connectivity

  • 非ドメイン参加していないクライアントの NTLM 認証が失敗します。 など Windows Live メール、および Exchange 2013 のクライアント間の認証は、次の条件に該当する場合に失敗します。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:

    • クライアントの使用する認証方法が NTLM である。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.

    • クライアントが使用する認証の種類を、NTLM から TLS 上の基本認証に変更します。Change the authentication type the client uses from NTLM to Basic Auth over TLS.

  • GSSAPI 認証は、送信メッセージのコマンドレットを使用すると失敗した場合。 汎用的なセキュリティ サービス アプリケーション プログラム インターフェイス (GSSAPI) の Windows PowerShell では、既定で含まれており、送信メッセージコマンドレットをインストールするときに、認証が失敗する可能性がありますを使用して、Exchange 2013 に認証済みのメールを送信します。このような場合は、次の情報との接続を受信する Exchange 2013 のクライアント アクセス サーバーのアプリケーションイベント ログにエントリが表示されます。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:

    • ソース MSExchangeFrontEndTransportSource MSExchangeFrontEndTransport

    • イベント ID   1035Event ID 1035

    • 説明 エラーのため、受信の認証に失敗しましたIllegalMessage受信コネクタ クライアントのフロント エンドの<サーバー名>。認証メカニズムは、Gssapi です。交換を認証しようとしたクライアントの発信元 IP アドレス[ <クライアントの IP アドレス>]。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 Exchange is [<client IP address>].

    この問題を回避するには、削除する必要があります、Integratedクライアントからの認証方法は、Exchange 2013 のクライアント アクセス サーバー上のコネクタを受信します。削除するのには、 Integrated 、クライアントからの認証方法は、受信コネクタを送信メッセージのコマンドレットを実行しているコンピューターから接続を受け取る可能性がある各 Exchange 2013 のクライアント アクセス サーバー上で次のコマンドを実行します。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
    
  • HTTP 経由で MAPI Exchange 2013 SP1 にアップグレードするときのパフォーマンスが低下が発生する可能性があります。 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 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 or later server.

    注意

    これは、クライアント アクセス サーバー上で MAPI over HTTP プロトコルが有効になっている場合にのみ発生する問題です。このプロトコルは既定で無効になっています。MAPI over HTTP が無効になっている場合、クライアントでは代わりに RPC over HTTP プロトコルを使用します。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. クライアント アクセス サーバーの役割を実行しているサーバーでは、Windows のコマンド プロンプトで次のコマンドを実行します。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%\Microsoft\Exchange Server\V15
    
          %AppCmdLocation%\appcmd.exe SET AppPool "MSExchangeMapiFrontEndAppPool" /CLRConfigFile:"%ExchangeLocation%\bin\MSExchangeMapiFrontEndAppPool_CLRConfig.config"
          %AppCmdLocation%\appcmd.exe RECYCLE AppPool "MSExchangeMapiFrontEndAppPool"
    
    1. メールボックス サーバーの役割を実行しているサーバーでは、Windows のコマンド プロンプトで次のコマンドを実行します。On servers running the Mailbox server role, run the following commands in a Windows Command Prompt:
          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 2010 coexistence

  • Exchange 2013 のクライアント アクセス サーバーからプロキシとは、Exchange 2010 のメールボックスにアクセスする要求が機能しません。 状況によっては、インストールされている更新プログラムのロールアップしなくても Exchange 2013 および Exchange 2010 Service Pack 3 (SP3) クライアント アクセス サーバー間でプロキシ要求が正常に動作しない可能性があり、エラーが表示されます。これは、すべての次の条件に該当する場合に発生することができます。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:

    • Exchange 2013 メールボックスを持つユーザーは、次の方法のいずれかを使用して、Exchange 2010 のメールボックスを開こうとするとします。A user with an Exchange 2013 mailbox tries to open an Exchange 2010 mailbox using one of the following methods:

      • Outlook Web App で別のメールボックスを開くオプションOR-The Open Another Mailbox option in Outlook Web App -OR-

      • Exchange 管理センターで他のユーザーオプションThe Another user option in the Exchange admin center

    • クライアント アクセス サーバー、ユーザーは、Exchange 2013 を実行しているに接続されています。The Client Access server the user connected to is running Exchange 2013.

    • Exchange 2010 クライアント アクセス サーバーは、Exchange 2010 または Exchange 2010 の以前のサービス パックの製品 (RTM) 版のリリースから、Exchange 2010 の SP3 にアップグレードされました。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.

    上のすべての条件に当てはまる場合ユーザーは他のユーザーの Exchange 2010 の Outlook Web App のオプションにアクセスすることができませんし、空白のページが表示される場合があります。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.

    この問題を回避するのには、Exchange 2010 SP3 の更新プログラム ロールアップ 1年または後での各 Exchange 2010 サーバーをインストールします。To work around this issue, install Exchange 2010 SP3 Update Rollup 1 or later on each Exchange 2010 server.