2013 年 6 月 20 日以降は、Microsoft ではこのブログに新しいコンテンツを投稿しません (ただし、既存の投稿のアーカイブは引き続きお読みいただけます)。今後は、以下の場所で、Microsoft Exchange Server の最新の IT プロフェッショナル向け情報を提供します。
原文の記事の投稿日: 2013 年 3 月 29 日 (金曜日)
私は CSS のサポート エンジニアで、特定のドメイン (たとえば contoso.com) でメール ループ エラーに遭遇したお客様のサポートをしていました。このエラーは大容量のメールでのみ発生するという実に不可解なエラーですが、とうとう、送信コネクターのサイズ制限がループ エラーの原因になっていることを突き止めました。珍しいケースなので共有しておく必要があると考えました。
最初私は、エッジ サーバーが外部の DNS サーバー (外部ホストを解決する DNS サーバー) を使用するように構成されているのが原因ではないかと考えました。通常、エッジ トランスポート サーバーが外部 DNS を使用するように構成されている場合は、ドメイン ネームを、Active Directory サイトのハブ トランスポート サーバーではなく、パブリック IP アドレスに解決します (一般に、サーバー自身、外部ファイアウォール、またはサービス プロバイダーをポイントします)。これがメール ループの原因になるのです。
問題を再現しているうちに、エッジ トランスポート サーバーが外部 DNS サーバーを使用するように構成されていないことに気がつきました。問題再現のために私がセットアップした環境は、下図のとおりです。
このシナリオは、次のように進みます。インターネットの送信者から 20 MB のメールを受け取ったエッジ トランスポート サーバーは、それを受理します。エッジ トランスポート サーバーには、そのアドレス スペースに一致するコネクタが 2 つあります。Active Directory サイトへのアドレス スペース contoso.com 用のコネクタと、アドレス スペース * 用のコネクタです。使用できるすべてのコネクタを基にルーティングを決定する場合、エッジからハブまでのコネクタは、サイズ制限のために考慮の対象になりません (10 MB のサイズ制限があります)。この条件に最もよく適合するのはエッジからインターネットまでの * コネクタ (「メッセージ ルーティングについて」に記載されているコネクタ選択アルゴリズムを参照) で、このメッセージ サイズ制限は 30 MB です。
最終結果: メッセージはインターネットに戻され、インターネットとエッジ サーバーの間でメッセージ ループが発生します。
インターネットへの送信コネクタが、送信メールの配信に DNS を使用するように構成されているか、スマート ホストを使用するように構成されているかによって、次の NDR のどちらかを受け取ることになります。
DNS を使用する場合:
#554 5.4.4 SMTPSEND.DNS.MxLoopback; DNS records for this domain are configured in a loop ##
スマート ホストを使用する場合:
5.4.6 smtp;554 5.4.6 Hop count exceeded - possible mail loop> #SMTP#
この動作は意図されたものなので、コネクタ上でメッセージ サイズの制限を変更することにより、簡単に修正できます。必要に応じて、次のオプションのどちらかを選択してください。
これで解決です。このブログ執筆に協力してくれた Arindam Thokder と Scott Landry に感謝します。
これはローカライズされたブログ投稿です。原文の記事は、「Mysterious mail loop on Edge Transport server: Check your size limits!」をご覧ください。
原文の記事の投稿日: 2013 年 3 月 12 日 (火曜日)
2012 年 11 月の MCA ベータ クライアントの発表以降、MCA クライアントから利用できるテスト オプションの改善に取り組んできました。ここで、1.0 リリースの内容をご紹介します。
Microsoft 接続アナライザー 1.0 がリリースされたことをお知らせします。このツールは、Microsoft リモート接続アナライザー Web サイトと対になるものです。MCA ツールを使用すると、管理者やエンド ユーザーは一般的な接続の問題 5 つに関する接続診断をローカル コンピューターから直接実行できます。ユーザーは接続をテストし、結果を HTML 形式で保存できます。管理者はこの結果をリモート接続アナライザー Web サイトで表示し、判定できます。
MCA 1.0 ツールはこちらからインストールできます。 https://testconnectivity.microsoft.com/?tabid=client
紹介ビデオを見る
Microsoft Lync 接続アナライザー ツール: クライアント ページには、Lync 接続アナライザー ツールもあります。近い将来に MCA と MLCA を統合しようと取りくんでいますが、クライアント診断オプションを改善するために、今すぐこれらの優れたツールの両方をお客様が利用できるようにしたいと考えました。MLCA の詳細については、こちらを参照してください。
フィードバック: すべてのフィードバックは MCA フィードバック エイリアス宛てにお送りください。ツールについてのご感想、および接続のトラブルシューティングにこのツールが役立つかどうかをお知らせください。また、今後追加を希望するテストについてのフィードバックもお寄せください。
Microsoft リモート接続アナライザー Web サイト 2.1 がリリースされたことをお知らせします。このツールを使用すると、管理者���よびエンド ユーザーはマイクロソフトのサーバーとの接続診断を実行して Exchange、Lync、および Office 365 の一般的な問題をテストできます。Office 365 ドメイン ネーム サーバー テストを新しく追加し、既存のテストを強化して、サイト全体の操作性を向上させました。
Web サイトの更新は、こちらで確認してください。 https://testconnectivity.microsoft.com
バージョン 2.1 (2013 年 3 月)
どうぞご利用ください。
お読みいただき、ありがとうございました。
(MCA/RCA チーム代表)
Twitter でチームをフォローしてください - @ExRCA
これはローカライズされたブログ投稿です。原文の記事は、「Announcing Microsoft Connectivity Analyzer (MCA) 1.0 and Microsoft Remote Connectivity Analyzer (RCA) 2.1」をご覧ください。
原文の記事の投稿日: 2013 年 2 月 21 日 (木曜日)
リクエストの多かった Exchange Server 2013 用ホスティングおよびマルチテナント ガイダンス のドキュメントが利用可能になったことをお知らせします。こちらからダウンロードしてください。
お気づきのとおり、これは Exchange Server 2010 用のガイダンスとほぼ同じです。ただしそれは、このガイダンスが検索、コピー、置換だけで作成されたからではなく、Exchange 2010 のときに採用した方針が Exchange 2013 でも変わっていないためです。そういうわけなので、ソリューションの構成には組み込みのツールやコマンドレット、インターフェイスだけを使用し、どんな場合でも、必要な構成に合わせるために AD 内のオブジェクトを直接操作するようなことはしないでください。
すべての機能が、マルチテナントに似た構成で期待されるように動作するとは限らないという考え方も、これまでと同じです。たとえば、メール ヒントは標準的な社内展開の場合とまったく同じように動作します。通常はその結果、公開されているテナント間で不要なデータが生じる可能性があります。このドキュメントでは、Exchange Server をマルチテナント用に構成した場合に期待どおりに動作しない可能性がある機能を中心に説明し、構成や、必要に応じて機能を無効にする方法についてアドバイスします。
ソリューションの重要なディレクトリ セグメンテーション エレメントの中心となるのが、アドレス帳ポリシー機能です。トランスポート エージェントの最近のお知らせ (英語) はこのアドレス帳ポリシーの利用について説明したもので、これを読めば、Exchange Server 2013 用ソリューションの作成と保守がさらに簡単になったことがわかります。
Exchange Server 2013 には重要な変更点がいくつかあるので、ガイダンスを熟読してからソリューションの計画と作成に取りかかり、問題が生じたら必要に応じてガイダンスに戻って該当箇所を読み直すことをお勧めします。
Exchange Server 2010 の場合と同様、ドキュメント内のガイドラインに従って作成されるパートナー ソリューションがあります。サイトには、現時点で検証済みのソリューションもリストアップされています。このリストは今後も増えていくので、使用したいソリューションが現在はリストにない場合でも、時々チェックしてください。あるいは、ベンダーに検証計画について問い合わせてください。
「Scale Guidance for Exchange 2013」についてはアップデート版 (マルチテナントまたはホスティング用に構成されたもの) のリリースを予定しています。このドキュメントが利用可能になれば、ソリューション サイトを更新します。
このドキュメントがお客様の役に立つことを願っています。ぜひフィードバックをお寄せください。
主席 プログラム マネージャー リード
Exchange カスタマー エクスペリエンス
これはローカライズされたブログ投稿です。原文の記事は、「Hosting and Multi-Tenancy Guidance for Exchange Server 2013 Now Available」をご覧ください。
原文の記事の投稿日: 2013 年 1 月 15 日 (火曜日)
Exchange チームのブログ記事「Exchange Server 2013 の OAB」では、Exchange Server 2013 のオフライン アドレス帳 (OAB) の生成と配布の新しいアーキテクチャを紹介しました。この記事をまだご覧になっていない方や、内容をよく覚えていない方は、先に進む前にこの記事をご覧ください。
Exchange 2013 ではアーキテクチャが変更されたため、OAB の管理方法が従来のバージョンとは異なります。さらに、新しい Exchange 管理センターには、現在、OAB を管理するためのオプションがありません。したがって、現時点では、OAB 関連のタスクには Exchange 管理シェルを使用する必要があります。
この記事では、OAB の管理に関する一般的なタスクの手順と、それらのタスクの理解に役立つ現実的なシナリオを紹介します。
メモ: マルチフォレストの Active Directory ドメイン環境をお使いの場合は、シェル セッションで ViewEntireForest が有効になっていることを確認してください。これが有効になっていないと、この記事の一部のコマンドで結果が返されません。
ViewEntireForest を有効にするコマンド:
Set-ADServerSettings -ViewEntireForest $true
Exchange 2013 では、新しい OAB を作成する際に -Server パラメーターを使用する必要はなくなりました。必要なアドレス一覧を指定するだけで作成できます。
次の例では、"Global Address List FAB" というアドレス一覧の OAB を作成しています。
New-OfflineAddressBook -Name OAB-FAB -AddressLists "Global Address List FAB"
Exchange Server 2013 の調停メールボックスには、その調停メールボックスの目的や機能を定義する特定の "永続機能" が割り当てられます。
永続機能 "OrganizationCapabilityOABGen" を持つ調停メールボックスは、OAB の生成に使用されます。ここでは、このメールボックスを、全体を通じて "組織メールボックス" と呼びます。
組織メールボックスをホストする Exchange Server 2013 メールボックス サーバーは、環境内で定義されているすべての OAB を生成します。
非 DAG 環境で OAB 生成サーバーを特定するには、次のコマンドを使用します。
Get-Mailbox -Arbitration | where {$_.PersistedCapabilities -like "*oab*"} | ft name,servername
DAG 環境で OAB 生成サーバーを特定するには、次の 2 つの手順を実行します。
手順 1: OABGen 機能を持つ組織メールボックスをホストしているメールボックス データベースを特定する
次のコマンドを使用して、OABGen 永続機能を持つ調停メールボックスと、そのメールボックスをホストしているデータベースを特定します。
Get-Mailbox -Arbitration | where {$_.PersistedCapabilities -like "*oab*"} | ft name,database
手順 2: 組織メールボックスをホストしているデータベースがマウントされているメールボックス サーバーを特定する
次のコマンドを使用して、メールボックス データベースのアクティブなコピーを特定します。
Get-MailboxDatabaseCopyStatus db1
データベースのステータスが "mounted" になっているサーバーが、現在の OAB 生成サーバーです。
OAB 生成サーバーを変更するには 2 つの方法があります。
新たに OAB 生成サーバーにするサーバーのメールボックス データベースに組織メールボックスを移動します。
例:
サーバー Exch1 にある単一コピーのデータベース DB1 で組織メールボックスがホストされています。メールボックス データベース DB2 は Exch2 にあります。
組織メールボックスを DB2 に移動して Exch2 を OAB 生成サーバーにするには、次のコマンドを使用します。
Get-Mailbox -Arbitration -database db1| where {$_.PersistedCapabilities –like “*oab*”} | New-MoveRequest -TargetDatabase db2
この方法は、組織メールボックスをホストするメールボックス データベースのコピーが 1 つしかない環境に適しています。
この方法は、組織メールボックスをホストするメールボックス データベースのコピーが複数ある環境に適しています。
例:
組織メールボックスをホストする DB1 には、サーバー Exch1 と Exch2 に 2 つのコピーがあります。現在は、Exch1 でアクティブになっています。
DB1 を Exch2 でアクティブにして、Exch2 を OAB 生成サーバーにするには、次のコマンドを使用します。
Move-ActiveMailboxDatabase DB1 -ActivateOnServer Exch2
メモ: OAB 生成サーバーを変更する前に、この後の「組織メールボックスの配置」のガイドラインを確認してください。
フォールト トレランスや、地理的に分散した Exchange 展開のユーザーのために、追加の組織メールボックスを作成することができます。
新しい組織メールボックスを作成するには、次の 2 つの手順を実行します。
手順 1: 新しい調停メールボックスを作成する
New-Mailbox -Arbitration -Name "OAB Seattle" -Database DB2Seattle -UserPrincipalName oabs@contoso.com –DisplayName “OAB Mailbox for Seattle”
手順 2: OABGen 機能を有効にする
Set-Mailbox -Arbitration oabs -OABGen $true
メモ: 追加の組織メールボックスを作成する前に、この後の「組織メールボックスの配置」のガイドラインを確認してください。
Exchange Server 2010 までは、OAB のプロパティで設定された "スケジュール" に基づいて OAB が生成されていました。Exchange 2013 でも、OAB のプロパティを表示すると "スケジュール" が定義されていることがありますが、Exchange 2013 の OAB は、OAB のプロパティで定義されている "スケジュール" では生成されません。
Exchange Server 2013 では、メールボックス サーバーで構成される OABGeneratorWorkCycle プロパティと OABGeneratorWorkCycleCheckpoint プロパティに従って OAB が生成されます。
例:
上のスクリーンショットの値は、OAB が 1 日に 1 回生成されることを表しています。
Exchange Server 2013 の CAS ロールは、OAB ダウンロード要求を適切なメールボックス ロール サーバーにプロキシします。CAS ロールが処理した要求は、%ExchangeInstallPath%\Logging\HttpProxy\OAB\ フォルダーにあるログ ファイルに記録されます。
これらのログ ファイルは、CAS によって選択されて要求を処理したメールボックス サーバーを特定するのに便利です。
このログ ファイルの重要なフィールドを以下に示します。
| フィールド | 説明 |
|---|---|
| UrlStem | ダウンロードされた OAB と、完全ダウンロードまたは増分ダウンロードのどちらが実行されたかを特定できます。 |
| AuthenticatedUser | OAB を要求したユーザーの名前です。 |
| AnchorMailbox | OAB 要求に最も近いと判定された組織メールボックスの DN です。 |
| ServerHostName | 要求を処理した CAS サーバーの名前です。 |
| HttpStatus | プロキシ操作の状態コードです。 |
| ProxyAction | 要求に対して CAS サーバーが実行した操作です。Exchange 2013 の OAB の場合、通常は "Proxy" になります。 |
| TargetServer | 要求がプロキシされたメールボックス ロール サーバーの名前です。 |
このログ ファイルは、見やすくするために Excel にインポートできます。
例:
Exchange Server 2013 で OAB の生成を強制的に開始するには、2 つの方法があります。
次のコマンドを実行すると、すべての組織メールボックスで "Default Offline Address Book" という OAB が強制的に生成されます。
Update-OfflineAddressBook "default offline address book"
メモ: このコマンドは、アクティブな組織メールボックスをホストしている各メールボックス サーバーに対する RPC 要求を開始します。
OAB の生成は、メールボックス ロールの Microsoft Exchange メールボックス アシスタント サービスによって行われます。このサービスを再起動すると、特定のメールボックス サーバーで、環境で定義されているすべての OAB が生成されます (そのメールボックス サーバーがアクティブな組織メールボックスをホストしている場合)。
Exchange Server 2013 の CAS ロールは、アクティブな組織メールボックスをホストしている "最も近い" メールボックス サーバーに OAB ダウンロード要求をプロキシします。同じ AD サイトでアクティブな組織メールボックスが複数検出された場合は、要求がラウンドロビン方式でプロキシされます。この場合、OAB の完全ダウンロードが頻繁に発生する可能性があります。
そのため、現在は、1 つの AD サイトでアクティブになる組織メールボックスが 1 つになるように組織メールボックスの配置を計画することをお勧めします。これは、新しい組織メールボックスを作成するときにも、組織メールボックスをホストするメールボックス データベースのコピーを作成するときにも当てはまります。
以下のシナリオでは、OAB の新しい管理方法を実際の状況でどのように使用するのかを説明します。
Contoso では、Exchange Server 2013 のメールボックス ロール サーバーと CAS ロール サーバーをダラスとシアトルのサイトに展開しています。Contoso で Exchange を管理している John は、CAS サーバーの http プロキシのログ ファイルを分析して、シアトルのユーザーの OAB ダウンロード要求がダラスのサーバーに送られていることを見つけました。さらなる調査の結果、組織メールボックスがダラスに 1 つしかないために、すべてのユーザーの OAB ダウンロード要求がダラスのサーバーに送られていることがわかりました。
John は、次のコマンドを使用して、シアトルのサイトに新しい組織メールボックスを作成することにしました。
手順 1: 新しい調停メールボックスを作成する
New-Mailbox -Arbitration -Name "OAB Seattle" -Database DB2Seattle -UserPrincipalName oabs@contoso.com –DisplayName “OAB Mailbox for Seattle”
手順 2: 調停メールボックスで OABGen 機能を有効にする
Set-Mailbox -Arbitration oabs -OABGen $true
Tail Spin Toys で Exchange 2013 を管理している Ben は、既定の OAB 生成スケジュールを変更して、OAB を 4 時間ごとに生成したいと考えています。
この場合は、次のコマンドを使用して、組織メールボックスをホストするメールボックス サーバーのプロパティを変更します。
Set-MailboxServer Exch1 -OABGeneratorWorkCycle 01.00:00:00 -OABGeneratorWorkCycleCheckpoint 04:00:00
数日経ったら、アプリケーション ログでイベント ID 17002 を分析して、OAB が 4 時間ごとに生成されていることを確認します。
この投稿が皆さんのお役に立つことを願っています。フィードバックをお待ちしております。
これはローカライズされたブログ投稿です。原文の記事は、「Managing OAB in Exchange Server 2013」をご覧ください。