Exchange 2013 のリリース ノート

  • [アーティクル]

製品: Exchange Server 2013

Microsoft Exchange Server 2013 へようこそ! このトピックでは、Exchange 2013 を正常に展開するために知っておくべき重要な情報について説明します。 デプロイを開始する前に、このトピックを完全にお読みください。

このトピックは、以下のセクションで構成されています。

  • セットアップと展開

  • Exchange 管理シェル

  • Mailbox

  • パブリック フォルダー

  • メール フロー

  • クライアント接続

  • Exchange 2010 の共存

セットアップと展開

  • msExchProductId には、インストールされている Exchange 2013 のリリース バージョンが反映されていません Exchange が Active Directory スキーマを拡張し、Active Directory for Exchange を準備すると、準備が完了したことを示すいくつかのプロパティが更新されます。 これらのプロパティの 1 つは、名前付けコンテキストのコンテナーの CN=<your organization>, CN=Microsoft Exchange, CN=Services, CN=Configuration, DC=<domain>ConfigurationmsExchangeProductId です。 インストールしている Exchange 2013 のリリースで Active Directory スキーマの変更が導入されていない場合、このプロパティは更新されないか、予期しない値が表示される可能性があります。 この値がインストールされている Exchange 2013 のバージョンと一致しない場合、混乱を招く可能性があります。

    msExchProductId の値には、インストールされている Exchange 2013 のバージョンが反映されていないため、この動作が予想されます。 このプロパティは、最後に Active Directory スキーマに変更を加えた Exchange 2013 のバージョンを反映しています。 混乱を避けるために、「Active Directory とドメインの準備」の「この機能を確認する方法」セクションの手順に従って、Active Directory が更新され、インストールしている Exchange 2013 のリリースの準備ができていることを確認することをお勧めします。

  • セットアップが正しく要求.NET Framework 4.0: コンピューターに.NET Frameworkインストールせずに Exchange 2013 をインストールしようとすると、実際 .NET Frameworkには 4.5 以降が必要な場合にセットアップ.NET Framework 4.0 をインストールするように誤って要求します。

    この問題を回避するには、.NET Framework 4.5 以降をインストールします。 .NET Framework 4.0 をインストールする必要はありません。 前提条件の完全な一覧については、「 Exchange 2013 の前提条件」を参照してください。

  • Exchange XML アプリケーション構成ファイルは、累積的な更新プログラムのインストール中に上書きされます。Exchange XML アプリケーション構成ファイル (たとえば、クライアント アクセス サーバー上のファイルやメールボックス サーバー上の web.configEdgeTransport.exe.config ファイルなど) で行ったカスタマイズされた Exchange またはインターネットインフォメーション サーバーの設定は、Exchange 累積的な更新プログラムまたは Service Pack をインストールすると上書きされます。 インストール後にサーバーを簡単に再構成できるよう、必ずこの情報を保存しておいてください。 Exchange 累積的な更新プログラムまたは Service Pack をインストールした後、これらの設定を再構成する必要があります。

  • 代理管理者のアクセス許可を使用して Exchange をインストールするとセットアップに失敗する委任セットアップ役割グループのみのメンバーであるユーザーが事前に準備されたサーバーに Exchange をインストールしようとすると、セットアップに失敗します。 この失敗は、委任セットアップ役割グループに、Active Directory 内で特定のオブジェクトを作成および構成するために必要なアクセス許可がないために起こります。

    この問題を回避するには、次のいずれかの操作を行います。

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

    • 組織の管理役割グループのメンバーであるユーザーを使用して、Exchange をインストールします。

Exchange 2013 のインストール方法の詳細については、「 計画と展開」を参照してください。

Exchange 管理シェル

  • シェルが 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 の構成またはサーバーを管理できないため、特定のタスクを実行できない場合があります。

    Exchange 2013 CU11 以降では、この動作は設計上の動作です。 シェルが Exchange 2013 コマンドレットを読み込むかどうかを確認するには、ログオンしているユーザーのメールボックスを Exchange 2013 に移動します。 ログオンしているユーザーにメールボックスがない場合は、SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c} 仲裁メールボックスを Exchange 2013 サーバーに移動します。

    仲裁メールボックスを移動する方法の詳細と情報については、Exchange チームブログの 「Exchange 管理シェルとメールボックス のアンカー」 を参照してください。

Mailbox

  • 異なるバージョンの 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 に追加するなど) 可能性があります。

    この問題に対する回避策はありません。 管理者は、メールボックス サーバーを 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-MailboxDatabase コマンドレットと Set-Mailbox コマンドレットの IssueWarningQuota、ProhibitSendQuota、および ProhibitSendReceiveQuota パラメーターをそれぞれ使用します。

  • Outlook 2007 および Outlook 2010 クライアントは、オフライン アドレス帳をダウンロードできない場合があります。オフライン アドレス帳 (OAB) の内部 URL にインターネットからアクセスできない場合、Outlook 2007 および Outlook 2010 クライアントは OAB をダウンロードできない可能性があります。

    Outlook 2007 および Outlook 2010 クライアントでこの問題を回避するには、インターネットから OAB 内部 URL にアクセスできるようにします。 Outlook 2013 はこの問題の影響を受けません。

  • Exchange 2013 を既存の Exchange 組織にインストールすると、すべてのクライアントが 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 の生成を担当する OAB 生成メールボックスに要求をプロキシする方法を認識します。

    Exchange 2013 CU5 の OAB の変更の詳細については、「 Exchange 2013 累積的な更新プログラム 5 の OAB の機能強化」を参照してください。

パブリック フォルダー

  • 未承認の送信者は、メールが有効なパブリック フォルダーにメッセージを送信できなくなりました。Exchange 2013 CU6 より前のバージョンでは、未承認の送信者はメールが有効なパブリック フォルダーにメッセージを送信できます。 これにより、外部の送信者が、パブリック フォルダーに設定されているアクセス許可に関係なく、メールが有効なパブリック フォルダーにメールを送信する可能性が可能になりました。

    Exchange 2013 CU6 以降では、外部の送信者がメールが有効なパブリック フォルダーにメールを送信する場合は、 匿名 ユーザーに少なくとも アイテムの作成 アクセス許可を付与する必要があります。 メールが有効なパブリック フォルダーを設定し、これを行っていない場合、外部の送信者は配信エラー通知を受け取り、メッセージはメールが有効なパブリック フォルダーに配信されません。

    匿名ユーザーのアクセス許可を設定するには、シェルや Outlook を使用できます。 匿名ユーザーにアクセス許可を設定する方法について詳しくは、「パブリック フォルダーのメールの有効化またはメールの無効化」を参照してください。

  • 従来の Exchange サーバーから Exchange 2013 に移行できるパブリック フォルダーの最大数は 500,000 です。 パブリック フォルダーの移行の詳細については、「 バッチ移行を使用して、以前のバージョンのパブリック フォルダーを Exchange 2013 に移行する」を参照してください。

メール フロー

  • クライアント アクセス サーバー上の TransportAgent コマンドレットにはローカル Windows PowerShellが必要です。 *-TransportAgent コマンドレットに問題があります。このコマンドレットでは、Exchange 管理シェルを使用してクライアント アクセス サーバーにトランスポート エージェントをインストール、アンインストール、管理できません。 クライアント アクセス サーバーにトランスポート エージェントをインストール、アンインストール、管理するには、Exchange Windows PowerShell スナップインを手動で読み込み、*-TransportAgent コマンドレットを実行する必要があります。 Exchange 管理シェルを使用してトランスポート エージェントをインストール、アンインストール、または管理しようとすると、接続先の Exchange 2013 メールボックス サーバーに変更が適用されます。

    クライアント アクセス サーバーにトランスポート エージェントをインストール、アンインストール、または管理するには、管理するクライアント アクセス サーバーで次の操作を行います。

    警告

    Microsoft.Exchange.Management.PowerShell.SnapIn Windows PowerShell スナップインを読み込み、-TransportAgent コマンドレット以外のコマンドレットを実行することはサポートされていないため、Exchange の展開に回復不可能な損傷を与える可能性があります。

    トランスポート エージェントをインストール、アンインストール、または管理するクライアント アクセス サーバーのローカル管理者である必要があります。 Exchange ファイル、ディレクトリ、または Active Directory オブジェクトのアクセス制御リスト (ACL) の変更はサポートされていません。

    重要

    クライアント アクセス サーバーでのみ、次の手順を実行します。 メールボックス サーバーでトランスポート エージェントを管理する場合は、Exchange Windows PowerShell スナップインを読み込む必要はありません。

    1. 新しいWindows PowerShell ウィンドウを開きます。

    2. 次のコマンドを実行します。

      Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn

    3. トランスポート エージェント管理タスクを通常どおりに実行します。

    4. 管理する各クライアント アクセス サーバーで、この手順を繰り返します。

クライアント接続

  • ドメインに参加していないクライアントに対して NTLM 認証が失敗する: Windows Live メールなどのクライアントと Exchange 2013 の間の認証は、次の条件に該当する場合に失敗する可能性があります。

    • 次に、クライアントが使用する認証方法は NTLM です。

    • コンピューターがドメインに参加していません。

    この問題を回避するには、次のいずれかの操作を行います。

    • クライアントが実行しているコンピューターをドメインに参加させます。

    • クライアントが使用する認証の種類を NTLM から TLS 経由の基本認証に変更します。

  • GSSAPI 認証は、Send-MailMessage コマンドレットと共に使用すると失敗します。認証されたメールを Exchange 2013 に送信するために、Windows PowerShellの既定のインストールに含まれる Send-MailMessage コマンドレットを使用すると、汎用セキュリティ サービス アプリケーション プログラム インターフェイス (GSSAPI) 認証が失敗する可能性があります。 この場合、次の情報を含む接続を受信した Exchange 2013 クライアント アクセス サーバーの アプリケーション イベント ログにエントリが表示されます。

    • ソース: MSExchangeFrontEndTransport

    • イベント ID: 1035

    • 説明: 受信コネクタクライアント フロントエンド <サーバー名>のエラーIllegalMessageで受信認証が失敗しました。 認証メカニズムは Gssapi です。 Exchange に対して認証を試みたクライアントの送信元 IP アドレスは [<クライアント IP アドレス>] です。

    この問題を回避するには、Exchange 2013 クライアント アクセス サーバーのクライアント受信コネクタから認証方法を削除 Integrated する必要があります。 クライアント受信コネクタから認証方法を Integrated 削除するには、 Send-MailMessage コマンドレットを実行しているコンピューターから接続を受信できる各 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 が無効になっている場合、クライアントは代わりに 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 2010 メールボックスへのアクセス要求は、Exchange 2013 クライアント アクセス サーバーを介してプロキシされた場合に機能しない場合があります。状況によっては、更新プログラムのロールアップがインストールされていない Exchange 2013 Service Pack 3 (SP3) クライアント アクセス サーバー間のプロキシ要求が正しく機能せず、エラーが表示されることがあります。 これは、次のすべての条件が満たされている場合に発生する可能性があります。

    • Exchange 2013 メールボックスを持つユーザーは、次のいずれかの方法で Exchange 2010 メールボックスを開こうとします。

      • Outlook Web Appの [別のメールボックスを開く] オプション -OR-

      • Exchange 管理センターの [別のユーザー ] オプション

      • ユーザーが接続したクライアント アクセス サーバーが Exchange 2013 を実行しています。

      • Exchange 2010 クライアント アクセス サーバーは、リリースから製造 (RTM) バージョンの Exchange 2010 または以前の Exchange 2010 Service Pack に Exchange 2010 SP3 にアップグレードされました。

    上記のすべての条件が満たされている場合、ユーザーは他のユーザーの Exchange 2010 Outlook Web App オプションにアクセスできず、空白のページが表示されることがあります。

    この問題を回避するには、各 Exchange 2010 サーバーに Exchange 2010 SP3 更新プログラムロールアップ 1 以降をインストールします。