エンジニアから見たMTAとしてのExchange

Office365を導入する目的として最も多い要因は、メールシステムの更改かと思います。

各種ドキュメント、書籍や事例などによってかなり多くの情報が得られるようになってきましたが、Office365のExchange Onlineのベースとしているソフトウェア「Exchange Server」は、インターネット上で利用されてきているSendmailやPostfixなどのMTA(メール転送エージェント)と比較して、特徴的な実装となっているところがあります。

ここでは、Office365を導入する前に有益な情報となるよう、一般的なメールシステムと比較してのExchangeの特徴についていくつか記載をさせて頂きたいと思います。

①From詐称ができない

  • Exchangeでは、各ユーザーは標準で「自身のプライマリアドレスでメールを送信する権限」を有しています
  • 1つのユーザーに対しては、1つの「プライマリメールアドレス」と複数の「セカンダリメールアドレス」を割り当て、メールを受信することができます
  • この為、他のユーザーや配布グループなどのアドレスをFromアドレスとしてメールを送信しようとすると、「権限がない」と弾かれます
  • 送信者アクセス権(SendAs)という権限を割り当てる事により、Fromアドレスを変更してメールが送信できます。(内部では、そのFromのアドレスのメールボックス経由でメールが送信されるように処理がされます。)
  • SendAsは、SMTPプロトコルを使ってメールを送信する場合には利用できません。

②MessageIDが重複するメールは1通しかメールボックスに届かない

  • Exchangeでは、短時間(1時間以内)に同一MessageIDであるメールが同じメールボックスに到着した場合、後から到着したメールを重複として破棄します。
  • これにより、Toを本人としCcをメーリングリストとして送信されたメールは、Toで直接配送されてきたメールのみ受信され、Ccで展開された後のメールは受信されません。
  • メーリングリストでSubjectに通番を付けているような場合、その番号のメールのみ欠落して見えるなどの症状となります。

③メールアドレスの表示名がサーバ側で自動的に書き換えられる

  • Exchangeでは、FromやToなどの欄に表示される名前をグローバルアドレス帳の情報によって解決します。
  • この為、従来は自身でアドレス帳登録した名前、”舞黒 部長”<maikuro@contoso.com>などを宛先として送付できたのが、自動的に舞黒太郎<maikuro@contoso.com>などの全社的なグローバルアドレス帳に登録されている名前(通常、フルネームをベースとしている値)に自動的に書き換えられて送信されます。
  • デフォルトの設定だと、日本語の表記のまま海外のユーザーにも配送されてしまいます。特定ドメイン、もしくは全体に対して明示的に表示名をアルファベット表記に変更できます。変更方法はこちら
  • この処理は、SMTPプロトコルを使ってメールを送信する場合には該当しません。

④MIMEエンコードはExchange外部に出る際に実施される

  • Exchange内部では、SMTPで通常利用されるエンコードではなく独自の形式でメールが送受信されます。
  • SMTP送信時に必要となるMIMEエンコードなどはクライアントでは必要なく、OutlookやOWAはエンコード処理を行いません。
  • エンコードのオーバーヘッド(約3-40%)が必要無い分、SMTPよりネットワークトラフィックは軽くなります。
  • Office365は25MBのメールサイズが上限ですが、これはエンコード前の値を仕様として表記した物であり、内部では35MBの容量が設定されています。この為、30MBの添付ファイルはOutlookでは送信できるが、Thunderbirdでは送信できないという事象が発生します。(勿論、外部に送信する際にはエンコードされるので35MBの上限値に引っかかりますが)
  • MIMEエンコードされるのは、Exchangeから外部に送信される際に相手先のサーバを自動判定してエンコードが実施されます。
  • 外部サーバがExchangeと判定された場合、TNEF形式でメールがエンコードされます。外部連絡先に登録したユーザーにwinmail.datの添付ファイルだけ付いた空メールが届くという事象のはこの自動判定に起因する物です。
  • この処理は、SMTPプロトコルを使ってメールを送信する場合には該当しません。

⑤Exchange内部ではMXレコードを参照せずに配信する

  • Exchange内部では、他のMTAで権限のあるドメイン(MyDestination)と設定した場合と同様、内部ドメインはDNSを参照しません。
  • DNSの代わりに、ActiveDirectoryの中のProxyAddressesの値(プライマリメールアドレス、セカンダリメールアドレス)で一致する物を検索し、有った場合はそのユーザーのメールボックスへの配送を行います。
  • 内部ドメインであるが、そのアドレスがADに無かった場合の挙動は、そのドメインの種別によって異なります
    • 「ホスト」 宛先不明としてメールを破棄し、配送不能メール(NDR)を送信元に送ります
    • 「中継」 FOPEからMXレコードを参照して外部に配送します

⑥キャッチオールアドレスは作成できない

  • 存在しない宛先宛てのメールを全て特定の受信者(例えば管理者)に送信することはできません。
  • オンプレミスのExchange 2010 Serverであれば、キャッチオールメールボックスという物を作成することによって近い機能を実装できますが、Office365では提供されていません。

⑦配布グループは通常メール以外は受け取れない

  • 配布グループは仕様上通常配送のメールのみ受け取ることができ、NDRなどは展開することができません。
  • この為、配布グループ宛に送信したメールが展開された後に、例えばメンバーの退職、メールボックス溢れなどが有った場合のエラーメールなどは「破棄する」「配布グループの代表所有者に返信」「送信元に返信」の3つの処理しかできず、通常のメーリングリストなどで良く見られる「管理者グループ宛に返信する」という形式は利用できません。(管理者グループを作成したとしても、エラーメールを展開できないからです)

⑧メール以外の情報もメールボックスに格納されている

  • 例えば、主要な機能である予定表、タスク、個人の連絡先などはメールボックスの中の特殊フォルダとして管理されています。
  • その他、受信トレイルールや宛先情報のキャッシュなど、細かい設定情報などもメールボックス上に存在します。
  • これらの情報は、通常のPOP/IMAPなどのクライアントからはアクセスできない為、それらのクライアントでは機能自体を利用する事ができません。
  • 「迷惑メール」フォルダに関しては通常メールボックスとしてIMAPからアクセスできますが、POPは受信トレイにしかアクセスできません。この為、POPを常用する場合は定期的にOWAでアクセスして、迷惑メールフォルダの内容を確認(間違えてspamと判定されている物は無いかなど)するという運用が必要になります。

⑨メール送信処理はサーバー(メールボックス)で実施され、送信履歴も残る

  • メールをクライアントが送信しようとした場合、その処理は直接送信ではなく「送信フォルダに送信したいメッセージを作成する」という処理になります。
  • サーバ側では、定期的に各送信フォルダからメールをピックアップし、送信処理を行います。送信が完了すると、そのアイテムを送信済みフォルダに移動します。
  • この為、Exchangeでは受信メールだけではなく、受信メールに関しても全てExchangeサーバ側で保管されています。この仕組みをベースとして訴訟ホールドなどの機能で監査対応などを実施します。
  • この処理は、SMTPプロトコルを使ってメールを送信する場合には該当しません。この為、Outlook/OWA以外を利用する場合、一部(内→外)のメールの監査ができない可能性がございます。

⑩送ったメールのリボーク(取り消し)ができる

  • 送信済みメールを取り消したり置き換えたりすることができます。
  • 例えば、送り先を間違えた場合や添付ファイルを忘れた場合など、あわてずにOutlookクライアントから送信済みアイテムを開き、「メッセージの取り消し」を行うと、自動的にアイテムを削除したり置き換えたりしてくれます。
  • 相手先が未開封(もしくはPOPなどの場合は未ダウンロード)だった場合に限ります。

いかがでしたでしょうか?

知らない機能であったり、移行してみて少し挙動が変だなと思うことがあるような要因になるようなものを集めてみましたが、他にも「こんな事あるよ」とか「こうなってるのはどうなの?」とか有りましたら教えて頂けると幸いです。

広告

Windows Azure Active DirectoryでのSSO

Office365は、プランE・プランP共にディレクトリデータベースとしてWindows Azure Active Directoryを利用しています。Azure側は特に両者の区別はなく展開されており、利用するサービスが違うという扱いです。

この為、Windows Azure Active Directoryのポータルにサインオンすると、プランPとしてはサポートされていない(メニューに出てこない)シングルサインオンなどのメニューもプランE同様に表示されます。ここでは、Windows Azure Active Directoryを利用してADFSによるシングルサインオンをセットアップする手順を紹介致します。

ポータルにOffice365のアカウントを利用してサインインします。ポータルが表示された後は、メニューから独自ドメインを追加します。

手順はOffice365と同じです。ドメイン名を入力後に表示される ms=MSxxxxxxxx という値をそのドメインのTXTレコードに追加して、確認を行います。

追加後はそのドメインの用途を選択する画面になりますので、必要なサービスを選択します。続いてその独自ドメインをOffice365で利用する際に必要なDNSレコードが表示されます。後から再度表示させることもできますので、ここではDNSの設定はせずに先に進みたいと思います。

続いて、新たなメニュー「統合」を開き、「ディレクトリ同期」のメニューを開きます。ADFSの展開前に、まず最初に時間のかかる(経験上、数時間以上掛かる場合もあります)「アクティブ化」を選択します。選択後はバックグラウンドで処理が行われていますので、シングルサインオンの設定に進みたいと思います。

まず、ADFS2.0 RTWをダウンロードし、インストールします。ついでにADFS 2.0 RU2(KB2681514)もインストールしておきます。

ADFSの設定ウィザードに行く前に、準備(①必要な証明書をIISにインストールする ②ADFSの実行用アカウントを作成する)をしておきます。ウィザードは特に上記2つの設定が出るくらいです。デフォルトWebサイトを先に作成している場合、デフォルトWebサイトの構成で警告が出ますが、特に問題は無いので先に進みます。

続いて、ドメインでシングルサインオンを有効化します。前項でドメインを既に追加している場合は、Convert-MsolDomainToFederatedコマンドレットを、新規で追加したドメインをシングルサインオンとして構成する場合はNew-MsolFederatedDomainコマンドレットを使用します。ここでは、新規追加の場合を例に挙げておきます。

事前準備として、サインインアシスタントとWindows PowerShell用Microsoft Online Servicesモジュールをインストールしておきます。

Connect-MsolService
New-MsolFederatedDomain -DomainName contoso.com
New-MsolFederatedDomain -DomainName contoso.com

1回目のNew-MsolFederatedDomainコマンドの後に、所有確認用のDNSレコードが表示されますので、追加後に再度同じコマンドを実行します。このコマンド終了後、今回は同じマシンにディレクトリ同期もインストールしようと思っており、これが残っているとディレクトリ同期のインストールに失敗するのでサインインアシスタントを一回アンインストールします。

次に、ディレクトリ同期のインストールです。10/23現在、Windows Azure Active Directoryポータルからダウンロード可能なディレクトリ同期ツールは、残念ながら今年いっぱいでサポート終了が決まっている32bit版なので、64bit版をOffice365からダウンロードするのが良いと思います。

ディレクトリ同期ツールは、インストールに比較的時間はかかるものの、特に選択肢は無くそのまま終了します。また、ここでサインインアシスタントが同時にインストールされてます。同梱されているバージョンが単体で入手できる物より少し古いので、気になる方はWindowsUpdateでバージョンアップすると良いと思います。

一旦Office365のポータルに戻って、ディレクトリ同期が有効化されたことを確認してからディレクトリ同期の設定に入ります。

必要な情報は、Office365のインポート/エクスポートに利用するOffice365の管理者アカウントと、ADからの同期用アカウント(MSOL_AD_SYNC)の設定を行うのに必要なADの管理者アカウントの情報です。

と、ここまでの工程を実施すると、

プランP1のテナントでもディレクトリ同期やシングルサインオンができるようになります。
ちなみに、Windows Azure Active Directoryポータルを経由しなくても、直接PowerShellコマンドレット(Set-MsolDirSyncEnabled  -EnableDirSync $true)とかでも有効化できます。

ただし、プランP1のサポートはコミュニティサポートのみであり、コミュニティでは基本的にシングルサインオンなどは対象外となっているようなので、お試しの際はあくまで自己責任で実施されるようお願い致します。

Exchangeエンジニアから見たExchange Online比較

Exchange Onlineは、Exchange Server 2010をベースに構成されております。この為、基本的な機能はオンプレミスのExchangeと同じですが、細かい使い勝手で差分があります。

クラウドサービスであるOffice365を使う上では、導入前にその差分について十分検討し、Fit&Gapを行っていくことが重要です。機能一覧上は一見オンプレミスと同じだし、価格も安いので…というだけで導入を決めてしまうとあまり良い結果を生まないと思います。

ここでは、構築運用実績のあるExchangeエンジニアの立場として、オンプレミスのExchange 2010と比較した場合のクラウド(Office 365)のExchange Onlineについて、いくつかのポイントに絞って考えてみたいと思います。

詳細はExchange Onlineサービス詳細の巻末の機能比較表をご覧下さい。

①インターネット上にあるパブリッククラウドサービスである

    • インターネット接続が必要
      • クライアントから直接インターネット上の名前解決が必要
      • クライアントからインターネットへのIPルーティングが必要
    • 内部にメールサーバを置く場合に比べ、回線の帯域がより多く必要
      • 内部メールの送受信も経由する為
      • 1通のメールに複数の宛先や配布グループが含まれている場合の、展開後の個々での受信処理
    • 通常はPIPからGIPへのNAT(NAPT)が必要
    • URLは他のテナントと共有
      • 他テナントのExchange Onlineとドメイン上は区別が付かない。「インターネット上のWebメールサービスは利用不可」などのコンテンツフィルタルール不可

②シェアドサービスであり、設定変更(カスタマイズ)できる範囲に制限がある

    • アドレス帳のカスタマイズ
      • 階層型アドレス帳の利用不可
      • 分割やフィルタ不可(部門毎のアドレス帳の作成や、グループ企業利用の際の公開範囲を自社のみへの限定など)
    • 送受信コネクタのカスタマイズ
      • 匿名アクセスを許可した受信コネクタ(認証無しのSMTP接続が可能)の作成不可
      • システムメールの送信は認証無しでは不可(内部向けのみの場合は送信先をFOPEのアドレスにして外部メール扱いで対処するなど可能)
    • パブリックフォルダ
      • パブリックフォルダ利用不可
      • Outlook2003からのMAPI接続不可(予定表などの機能利用不可)
    • 閾値制御
      • 公平制御の為、送信速度や宛先数などに上限値の制限が掛かっている(一部SRにて緩和可能)
      • NW帯域がLANに比べると遅い。特にGB単位のデータ移行やコピーは経験上2GB/時間程度を目安にして、気長にやった方がいい。
    • ログファイル
      • メッセージ追跡ログやパフォーマンスモニタなど、サーバの生ログデータを利用した、メール関連の統計情報(送受信通数、サイズ、トラフィック量、内・外区分など)が取得できない
      • メッセージ追跡ログの取得期間の延長ができない
    • セキュリティ
      • 送信元のIPベースの制限不可
      • 別AD組織なので、シングルサインオンするにはADFSが必要
      • 証明書ベースの認証不可

③クラウドサービスであり、オンライン側で運用され、随時更新され

    • メジャーバージョン含めて、バージョンアップされる
      • メンテナンス事前告知は原則有る。仕様変更は全テナント完了後の場合が多い
      • バージョンアップなので基本的に改善
      • 変更したくない場合でも原則実施される
      • 要件に合わせてクライアントも随時バージョンアップする必要がある。場合によっては新規購入を含めた処理が必要。
    • コミュニケーション
      • メンテナンスは基本的に一方的な通知によって行われる。サービス断がある場合でも自社で定めたメンテナンスウィンドウなどの考慮は行われない
      • 故障発生時も同じく基本的にポータルにて通知される。故障問い合わせは受け付けて貰えるが、実際のデータセンタでの対応状況などの確認は困難
      • 電話での受付はあるが、オンサイトでの対応は原則不可
    • 随時サービス仕様が変わる
      • 接続先サーバーのURL、IPアドレスなどは仕様変更や収容変更、増設などによって随時変更される
      • IP情報は公開される。比較的頻繁に追加され、IPベースのフィルタ制御は推奨されていない

簡単に並べるとこんな所でしょうか?

これだけ書くと、デメリットばかり並べているように見えますが、これだけ多くのお客様がOffice365を導入しているという事例などを見ますと、代替案などを検討して上手く落としどころを作ったり、サービスの方に合わせて自社の運用を変えたり、割り切ったり…という決断をされたお客様は結構多いということなのではないでしょうか。

ディレクトリ同期ツールのアップグレード

Microsoftからアナウンスが有りましたが、ディレクトリ同期ツールの32bit版がサポート切れになるとのこと。年内に64bit版にアップグレードする必要が出て参りましたので、ここでは、簡単にディレクトリ同期ツールのアップグレードについてお話をさせて頂きたいと思います。

まず、基本的な説明から。ディレクトリ同期の32bit版を利用されている場合は、通常Windows Server 2008を利用されており、64bit版の導入に当たってはWindows Server 2008R2になる形となるかと思いますので、基本的にはOSごと入れ替えるという形になります。

詳細は以下の図で軽く説明をしておりますが、この入れ替えに際して、旧サーバで最後に行った同期から、新しいサーバで最初に同期を実施するまでの間にActive Directory上でオブジェクトの「削除」が行われると、Office365(Windows Azure Active Directory)上にゴミのオブジェクトが残ってしまいます。このオブジェクトはディレクトリ同期されている物と認識されてますので、ポータル等から削除できないオブジェクトとして残ってしまって消すのは結構大変です。※1

そこで、このリスクの生じる時間に関してはなるべく短くなるように計画し、かつドメインコントローラー間の同期間隔を考慮して、その周辺の時間はメンテナンス時間として確保してActive Directoryへの変更は行われないように運用対処するのが望ましいと思われます。

作業自体は簡単で、新規でのインストールとあまり変わりません。移行先として別の筐体という前提で簡単に手順を書きますと、

  1. 新しいWindows Server 2008R2の環境上でディレクトリ同期ツールをインストール
  2. 古いディレクトリ同期ツールが前回参照したドメインコントローラに、他のドメインコントローラの情報を手動同期
  3. 古いディレクトリ同期ツールで最後の手動同期を実行
  4. 新しいディレクトリ同期ツールで構成ウィザードを走らせ、初回の同期を実施する
  5. 旧サーバを撤去(必要に応じてディレクトリ同期ツールのアンインストールを行う)する

この工程の中で、ディレクトリ同期で利用する「MSOL_AD_Sync」アカウントのリセットが行われ、AD内でディレクトリ同期を行うことができるサーバが新サーバに切り替わります。また、終了後に再度Active DirectoryのオブジェクトとOffice365のオブジェクトのマッチングが実施されます。マッチングは、基本的には既に同期済みであり、キーとなるSourceAnchorが設定されていますので、特にこの間に変更が行われていない限りはハードマッチして元の状態になります。

同じ筐体を利用するということであれば、3番の後にOSをクリーンインストールして、ディレクトリ同期ツールをインストールするという形になるかと思います。

また、前に紹介したようなディレクトリ同期対象のフィルタなど、個別のカスタマイズ設定や、ローカルのMIIS_Adminsグループに追加したユーザは、当然新しいサーバになると全てクリアされますので、再設定が必要な場合は忘れずに実施するようにしましょう。

 

※1 ゴミが残ってしまった場合、放置しておくとそのオブジェクトで利用していたUPN、Emailアドレスなどの属性が再利用できなくなってしまうなどの弊害が残りますので、以下のいずれかの方法で削除する形となります。

  1. Active Directoryゴミ箱などから削除したオブジェクトが復活できる場合は、一度復活させて同期を行った後に、再度削除した後に再同期する(このタイミングでOffice365側からも削除される)
  2. そのテナントのディレクトリ同期を無効化する。この時点でオブジェクトの操作ができるようになるのでOffice365に残ったオブジェクトを削除し、Office365の削除済みユーザーからも削除する。その後、ディレクトリ同期を再度有効化する。ただし、この方法は有効化~無効化で2-3日以上掛かる場合が有り、かつその間にオブジェクトが更に削除された場合、今度はそのオブジェクトがゴミとして残ってしまう形となるので注意が必要。

【参考】
サービスに関する通知:【重要】32 ビットのディレクトリ同期ツールは 2013 年 1 月 1 日までに 64 ビット版に切り替えてください
ディレクトリ同期ツールをアップグレードする

Microsoft MVP(Office365)受賞しました

10/1に通知があり、Microsoft MVPをOffice365のカテゴリで受賞させて頂いたとのこと。

これも、いつもblogを見に来て下さっている皆様や、勉強会などの場を提供頂いている方々のおかげだと感謝しております。今後も、blogにコミュニティに、皆様に役立つ情報を発信していきたいと思いますので、よろしくお願い致します。


2012.10~