マルチドメインでのExchange 2010のインストール/構成/ホスティングの実装

複数のドメインにExchangeを設定するときに管理者が遭遇する可能性のある困難について説明したいと思います。 これらの問題の解決については詳しく説明しませんが、さまざまな問題の解決策が詳細に説明されているリソース（MicrosoftまたはExchangeスペシャリストのブログ）へのリンクを提供する方法を一般的な方法で説明します。

私は可能な限り多くの「微妙さ」を把握しようとしますが、何かを忘れることができます:)



誰が気にする-猫の下。 注意：たくさんの手紙！



まず、トピックで説明されている構成でExchangeを実装するときに発生する問題に言及する価値があります。

• オブジェクトの準備と作成。 最も重要なポイントの1つ。 オブジェクトが適切な場所に適切な属性で正しく作成されていることを確認する必要があります。これにより、Exchange環境が適切に機能しやすくなります。

• 各ドメイン/クライアントのセキュリティ。 これにはさまざまな機能と設定が含まれますが、簡単に言えば、ある組織のユーザーが別の組織のユーザー/データを表示しないようにする必要があります。 ADインフラストラクチャ（たとえば、OU階層とそれらへの権限）を作成するときは、すぐにこのことを考慮する必要があります。

• システム設定とポリシー。 Exchangeには、ユーザーと管理者が使用できる多くの機能があり、これらの機能はさまざまな方法で制御できます。 一部の設定は個々のユーザーに影響を与え、一部はデータベースに影響を与え、一部はExchange組織全体に影響を与えます。

• 輸送。 すべてのユーザーに影響を与える設定の次の項目は、トランスポートです。 Exchangeが、同じ組織内にあるかのようにモードで2つのドメイン間でメールをルーティングし、1つのADドメインのユーザーに提供する必要があるすべての豊富な機能を提供しようとするときの問題について話します。

• システムの設計とアーキテクチャ。 ここでは、OWAなどのサービスの名前について説明しようとしています。 Outlookを使用してクライアントに提供されるURL。 AutoDiscoverやOutlook Anywhereなどのサービスのエンドポイント。 これらの/ホスト名アドレスはすべてのクライアントに表示され、さらなる問題を避けるためにそれらのいずれにも結び付けてはなりません（ブランド化されていない）。

• スケーラビリティ。 もう1つの重要な属性はスケーラビリティです。 これは、ドメイン/ユーザーの最大数だけでなく、負荷を計算し、成長を予測し、問題を回避する方法を理解するために弱点を特定することでもあります。



次に、特に各項目について説明しようとします。

AD構造。 従うべきいくつかのルールがあります。

1）各ドメインは個別のOUです。

2）各ドメインのすべてのユーザー-acc。 このドメインのグループ。

3） Active Directoryリストオブジェクトモードの使用 。 各OUのセキュリティ（詳細）設定でリストオブジェクトモードを有効にすると、リストに権限を設定できます。 これは、2番目の段落のグループが必要な場所です。このドメインのユーザーのみが、特定のドメインのリストOUを許可できます。 これにより、オブジェクトの可視性を区別できます。



各ドメイン/クライアントのセキュリティ。 これについては、前の段落ですでに説明し始めました。

1）ADリストオブジェクトモードの使用。

2）変更されたグローバルアドレス一覧と各ドメインのオフラインアドレス帳を使用します。 これを行うには、アドレス帳ポリシーを作成します（Exchange 2010 SP2でのみ使用可能になりました）。 ミハイルトカレフのブログでは、このプロセスについて詳しく説明しています。

3）各ドメインの管理者用の管理ポータル。 特定のユーザーが（ECPを介して）Exchangeユーザーの特定のグループを管理するために、Microsoftは役割グループメカニズムを作成しました。 役割グループ（管理者用の一連の権限を作成する場所）を作成する方法は、 ここに記載されています 。 ただし、これらのロールを作成するときは、スコープ（ロールが適用されるゾーン）を指定する必要があります。 「ゾーン」としてOUを使用することをお勧めします（各クライアント-独自）。 PowerShellおよびNew-ManagementScopeコマンドレットを使用したこのような管理スコープの作成については、 こちらをご覧ください 。

4）メッセージ追跡ログ（配信確認）を表示する権限を与えることはお勧めしません。 組織全体に適用され、管理者にはすべてのメールが表示されます。

5）カレンダーの権利の変更。 デフォルトでは、すべてのExchangeユーザーには、他のすべてのExchangeユーザーの空き時間情報が表示されます。 Set-MailboxFolderPermissionコマンドレットまたはExFoldersなどのユーティリティを使用して、ユーザーの「デフォルト」アクセスを選択しますが、このドメインのユーザーに必要な権限を付与します。

6） オプション：顧客への請求。 残念ながら、Exchangeにはビルトインの請求メカニズムがありませんが、Excelに基づいて独自のメカニズムを作成することもできます。 メールボックスの統計を取得するには、 Get-MailboxStatisticsおよびGet-ActivesyncDeviceStatisticsコマンドレットをよく理解することをお勧めします（PowerShellを使用してクライアント/ドメインごとに統計をフィルター処理できます）。統計を取得し、CSV / XLSにアップロードできます。

7）Outlook保護ルールを含めることはお勧めしません。 Outlook Advanced Loggingが有効になっている場合、すべてのクライアントのSMTPドメインのデータが利用可能になります。

8）交換拠点。 Exchangeの使用経験のある人の多くは、各クライアントが独自のデータベースを作成し、同じドメインのすべてのメールボックスを別のデータベースに保存する方が「より便利」だと言うでしょう。 しかし、そうする正当な理由がない場合は、クライアントを拠点に分割しないでください。 実際、1つのデータベースに問題がある場合、すべてのドメインメールが利用できなくなりますが、これは受け入れられません。 複数のデータベースを作成し、自動メールボックス配布を使用して、メールボックスを配置するデータベースをExchangeに選択させます。 ここで、自動メールボックス配布の仕組みについて読むことができます 。



システム設定とポリシー。 この点は前の点と非常に「交差」しているので、ここで少しお話しします。

1）クライアントに直接アクセス（LDAP + MAPI）を提供する必要はありません。 これは悪い考えです。 多くのホスティング事業者がこれを行います（たとえば、Masterhost）が、そのようなソリューションの正確さに同意することはできません。 RPC over HTTPsのみ（特にExchangeの次のバージョンでは、そのようなアクセスのみがあります）。 このタイプのアクセスは、初期セットアップではもう少し難しいですが、将来の問題からあなたを救うことが保証されています。

2）ファイアウォールを追跡します。 可能性のあるブルートフォース攻撃のためのDDoS攻撃。 ネットワークセキュリティを後で使用しないでください。

3）パスワードを誤って入力した場合、アカウントの「自動ブロック」ポリシーを無効にすることをお勧めします（そうしないと、攻撃者がアカウントをブロックするのは非常に簡単になります）が、ユーザーからの複雑なパスワードを必要とするポリシーを必ず使用してください。



輸送

1）他のドメインから配布グループへの送信を禁止する必要があります。 これを行うには、DGへの送信を許可されている送信者を制限し、DGへの送信に認証を要求します。 これは、EMCまたはSet-DistributionGroupコマンドレットを使用して構成できます。

2）文字のサイズを制限する。 たとえば、エッジサーバー上の受信メッセージのサイズ制限は、内部メールに設定された制限以下にする必要があります。 逆は、エッジサーバーリソースの無駄になります。 ユーザー制限を使用すると、ユーザーまたはユーザーグループがExchange組織全体に設定された制限を超えることができることに注意してください。

3）外部リレーを介した「隣接」ドメインのメールルーティングを構成します。 これは、このExchangeのドメインからのメールを「隣接」ドメインに送信する場合に完全に「マスク」する場合に必要です。 もちろん、一部の情報はヘッダーに残りますが、メールがインターネットから受信されることを確認します。これにより、この送信者が内部的に解決されなくなります。

4）相互TLSを使用する場合（ ここで内容を確認できます ）、TLSRecieveDomainSecureListおよびTLSSendDomainSecureListの設定がExchange組織全体に対して構成されていることに注意してください。 また、この機能を顧客に提供する場合、顧客が受け取るいくつかの文字に「安全」フラグが表示される理由を顧客が理解していることを確認する必要があります。

5）ドメイン間のメールがチェックされるように、ハブサーバーでスパム対策エージェントを有効にすることをお勧めします。 これを行う方法はここに書かれています 。

6）ドメイン間の不在時の内部メッセージを無効にする必要があります。 実際、ユーザーが「組織内でのみOOFを送信する」ことを選択した場合、OOFレターはこのExchangeのユーザーに送信されますが、別のドメインから送信されます。 これを防ぐには、IPM.Note.Rules.Oof.Template.Microsoftクラス（このクラスにはOOFメッセージがある）のメッセージを同じドメイン間でのみ許可するいくつかのトランスポートルールを作成する必要があります（ドメインごとのルールによる）。

7）手紙を送るとき、いくつかの「ヒント」を無効にします。 マルチドメイン構造では、グループメンバーの表示や、受信者のOOF自動応答が有効になっているという警告など、一部の機能を犠牲にする必要があります。 これらの設定は、 Set-OrganizationConfigコマンドレットを使用して変更できます。



デザインとアーキテクチャ。

1）共有URLを使用します。 たとえば、ドメインexchsuperhost.ruを登録します。 ノードm.exchsuperhost.ruおよびm2.exchsuperhost.ru （フォールトトレラントEDGEの場合、これらは異なる優先順位のMX）、 mail.exchsuperhost.ru （クライアントアクセスおよびOutlookAnywhereの場合）、およびAutodiscoverのautodiscover.exchsuperhost.ruを作成します。 WebインターフェースにCNAMEを使用し、MXおよびSPFレコードにMXアドレスを顧客に使用させます。 これにより、メールの管理と追跡が大幅に簡素化されます。

2）ユーザーにPOPおよびIMAPアクセスを提供しないことをお勧めします。 これにより、ユーザーの作業中だけでなく、移行中にも問題が発生する可能性があります。

3）仮想化について考えます。 Microsoftは、特定のExchangeの役割を仮想化することに対して何もしません。 これにより、機器とライセンスのコストを削減できます。



スケーラビリティ。 それはすべて、顧客、機器などに依存します。 私がアドバイスできるのは、「古い」テクノロジー（パブリックフォルダーなど）を使用せず、「鉄」の容量とストレージスペースとディスクシェルフを計算し、動的配布グループを使用して作業を最大化することです-PowerShellスクリプト、トランスポートルール、 GAL、ネーミングおよびストレージポリシー。



私はあなたの質問に答えて、あなたのアドバイスを聞いてうれしいです:)ありがとう！