ExchangeからEOPのSMTP配信速度のチューニング

Office 365のサービスの一つであるEOP(Exchange Online Protection)を利用すると、ハイブリッド構成時に受信時だけではなく送信時についてもspam判定を行うように構成をすることができます。

今回は、Exchangeハイブリッド構成時にOffice 365への通常のメール送信速度を理論上数倍にする方法をご紹介します。
20150226_01

Exchange Serverからの送信時のメールフローは、これにするかEdgeから直接出すかというほぼ2択になりますが、送受信でメールフローが同じでありシンプルだということもあり、この構成を取っている方も多いかと思います。

EOP を介した基本的なメール フローの設定に必要なコネクタを作成する などの記事を参照にこちらのEDGEサーバからExchange Online Protectionへの送信コネクタを作成します。サーバからEOPに円滑かつ継続的にメールを送信する為の注意点として、以下の記載が有ります。

  1. 1 接続当たりの送信電子メール数が 50 通以下
  2. 使用する同時接続数が 50 未満

今回は、この値を守りつつ、少しでもパフォーマンスを上げられるようにしていきたいと思います。

まず、1番です。こちらは送信コネクタのパラメータにSmtpMaxMessagesPerConnectionという値が有り、20に設定されています。

SMTP接続時のネゴシエーションに時間がかかるようであればこの値を大きくするのですが、インターネットを経由して送信していることもあってか、プロトコルログを確認する限りEdgeからEOPへの送信は、実際のメール送信に殆どの時間を費やしているのでこれを50などに増やしてもあまりパフォーマンスは向上しなさそうです。

次に2番。前提として、こちらの「同時接続数」の判定ですが、受信コネクタのMaxInboundConnectionPerSource の設定と同じように制御された場合、IPアドレスをベースにEOPに判定されてしまう可能性があります。複数台のEdgeサーバが同一のグローバルIPでNAPTして送信される場合は、50を台数で割った数字になるように調整しましょう。

この値は、Set-TransportService(Exchange 2010の場合はSet-TransportServer)のMaxPerDomainOutboundConnectionsで指定できます。デフォルト値は20になります。これだけ見ると、単一のスマートホスト先であるEOPへは、デフォルト設定でも20平行なのでそれなりにパフォーマンスが確保できるように見えますね。

が、実際に比較的メール流量が多い環境で利用すると、かなりEdge→EOPのパフォーマンスは低く、メールが滞留するポイントになりがちです。

なぜかというと、MaxPerDomainOutboundConnectionsというのはあくまで制限値であり、Exchangeがそこまで利用しようとするかとすると必ずしもそうではないからです。Edgeサーバ上でGet-Message -Queue [EOPへのキュー]などで挙動を観察してみると、キューの数が20までは1つのセッションで送信しようとして、それを越えると1つSMTPセッションを張るという挙動に見えます。
20150227_01

つまり デフォルトの制限値である20同時セッションになるにはキューが400通溜まる状態に、50同時セッションなら1000通までにならないといけない ことになります。そんな状態になったら、メールの配信遅延が顕在化してしまっている頃ですよね。

という訳で、ここをチューニングしてみたいと思います。

ここの数値ですが、コマンドの設定で変えられる設定は見つかりません。

色々と調べた結果、EdgeTransport.config にSmtpConnectorQueueMessageCountThresholdForConcurrentConnections パラメータを設定することにより、こちらをチューニングすることができました。

C:\Program Files\Microsoft\Exchange Server\V15\Bin\EdgeTransport.exe.config の<app Settings> </app Settings>の間に以下の値を入れます

<add key="SmtpConnectorQueueMessageCountThresholdForConcurrentConnections" value="新たにセッションを張る閾値"/>

例えば、デフォルトは20になりますので、値を5にした場合は理論上4倍の速度でセッションが張られて処理速度が向上することになります。
20150227_02

どんな値を設定したほうが良いかは、利用するリソースやメールサイズ等の特性によりケースバイケースだと思いますので、定期的にキューの状態やプロトコルログなどを確認していただいてチューニングするのがよろしいかと思います。

重複メッセージの除去(Exchange Online)

Exchangeは同じメッセージと思われる物を短期間に同じメールボックスで複数受信した場合、2通目以降のメールは重複としてドロップされ、メールボックスに配信されません。

何らかの事情で同じメールを複数回受信する必要がある場合(例えば、Exchange外でメールアーカイブを利用していて、誤ってExchangeで消してしまったメールをアーカイブから再送する場合など)には2通目のメールが受け取れない事があるので注意が必要です。

同じメッセージと見なされる条件は以下の通りです。

  • 同一のMessageIDヘッダであること
  • 同一のDateヘッダであること
  • 同一のメールボックスへの配送であること

これは、Exchange Onlineにおいても同じ動作をします。例えばTo:に直接自分のアドレス、Cc:にメーリングリスト(配布グループ)を指定して送ったような場合は、1通しか届きません。

外部のメーリングリストを利用していて、付与されたサブジェクトや、Reply-Toを元にメーリングリスト毎にフォルダ分けをしていた場合など、自分がToに入っている物は通常そちらが先に届いてしまって、そのフォルダに欠番がでてしまう様な形になり、影響を受けます。

また、これらの情報がキャッシュされている期間について、Exchange Server 2010まではデフォルトで1時間で、その時間はレジストリによりチューニング可能でしたが、クラウドサービスであるExchange Onlineについては当然そんなチューニングはできません。

というわけで、デフォルト値を調べてみたいと思います。まずは、適当にスクリプトを作って5分に1回同じMessage IDとDateヘッダのメールを流し続けます。PowerShellで組むの面倒だったので、適当にbashから以下を無限ループで実行し続けます。

while :
do
cat <<EOM | sendmail test@example.com
From: test@example.com
To:test@example.com
Date: Wed, 25 Feb 2015 00:00:00 +0900
Message-ID: <201502250000.00000@localhost.localdomain>
Subject:`date`: test mail
This is test. 

.
EOM
sleep 300
done

20150225_01

すぐに最初のメールが届きます。(2/25 00:28:58)
20150225_02

さて、何時間待ったら次のメールが届くでしょうか?1時間待っても届きません。

現在。8時間待っても届いてません。(メッセージ追跡を見るとPendingになってます)
20150225_00

皆さんは何時間だと思います? いくつか選択肢を。

  • 1日…キリがいい 2/26配信されませんでした
  • 2日…Exchangeのキューイング期間 2/27配信されませんでした
  • 5日…一般的な MTAのキューイング期間 3/2まだ配信されません
  • 1週間…キリがいい
  • 無期限…再起動されたり、フェールオーバーすると消える
  • 特に決まってない…容量だけ決まってて自動的に上書きされる

(3/4 追記)
3/4 16:07:39 7日+16時間で来ました。

20150304_02

ちょっと半端な時間ですね…。比較的長い時間が設定されていて、ある程度流れるとローテーションされるということなのですかね?

(3/5 追記)
3/5 16:08:08 ちょうど24時間で届きました。

ということは、昨日新しいモジュールが展開されて仕様が24時間に変わったということでしょうか!?

続きはこちらの記事

他人のスケジュールを作成する

急な休暇が入った場合や会議室だけおさえて欲しいと頼まれた場合など、他の人や会議室メールボックスのカレンダーに予定を書きたいケースがあります。

こういったケースでは色々と皆さん工夫されて運用されているようなのですが、今回は私がやってる方法について書きたいと思います。

 

編集者の権限を他のユーザーに一般的に与えているような組織であれば勿論問題無いですが、デフォルト設定だと直接のカレンダーアイテムの作成はできません。
スクリーンショット (53)

仕方ないので、会議開催通知をとして自分を含めた会議を作成します。

スクリーンショット (54)

ただ、こうすると自分にも予定が入ってしまいます。とはいえ、自分の予定を削除しようとすると、相手先にも会議のキャンセル通知が行ってしまい、最終的な予定表の見た目はCanceled: と入ってしまいます。これだと折角入れたのにあまり意味が無いですよね。
スクリーンショット (55) スクリーンショット (56) スクリーンショット (57)

 

そもそも、これは「会議」という予定表アイテムの以下の様な特性によります。

  • 会議にはそれぞれ開催者が設定される
  • 開催者以外の参加者は会議アイテムのコピーのみを保持する
  • 開催者以外の参加者は仮の予定として予定が作成され、「承諾→正規の予定に」「辞退→削除」となる。
  • 会議室はデフォルトでは当該時間に予定が入っていない場合、自動的に承諾処理が実施される
  • 開催者は予定時間や場所を変更したり、参加者を変更、会議の削除をしたりできる
  • 開催者が会議を削除した場合、参加者全員の予定がキャンセルされる
  • それぞれの開催通知、変更通知、キャンセル通知はメールとして流れる

今回は、この辺のところを上手く悪用利用して、相手だけに予定を入れてみたいと思います。

まず、これを実施するには自分の他に1人協力者が必要です。今回は、例えばユーザーBの予定を入れる際に、隣の席のCさんに手伝って貰うことを想定します。
スクリーンショット (58)

まずは、先ほどのようにサッカー観戦で休んでるユーザーBに会議開催通知を送って仮の予定を作成します。
スクリーンショット (67)

その後、ユーザーCに一時的にすべてのアイテムに対しての削除権限を付与します。
スクリーンショット (68)

そして、ユーザーCに頼んで自分の入れたその予定を削除して貰います。Outlook 2010だと右クリックで削除ができた記憶があるのですが、2013だと右クリックからは会議キャンセル通知の(代理送信の)作成に推移してしまうため、Shift+DELキーを押してアイテムを完全削除します。これで、ユーザーAの予定表アイテムが削除されました。
スクリーンショット (69) スクリーンショット (70)

ユーザーAのOutlookに戻って予定表を見てみると、ユーザーBの予定は残っているのに、ユーザーAの予定表からはアイテムが削除されているのが分かると思います。
スクリーンショット (72)

簡単な流れは以下の通りです。(確認ができたら、付与した削除権限は元に戻しておきましょう。)
スクリーンショット (73)

 

感覚的に正規な動作では無い気がするので、Outlookへの更新プログラムの適用などで将来的に出来なくなってしまうかもしれませんが、比較的リーズナブルな手順なのでよろしければお試し頂ければと思います。

Exchange Online上のデータ暗号化

導入するユーザーの要件によっては、どうしてもオンプレミスのExchange Serverで立てないといけないケースもあるので、Exchange Onlineの仕様は定期的にチェックしてます。

ご存じかと思いますが、Exchange Onlineを初めとするOffice365のサービス仕様は昨年からファイル(.docxや.pdf)ではなくTechnet上でのオンラインベースでの公開に変更されています。

Exchange Online サービスの説明

2014-04-21版をチェックしていたところ、2013-09-09と比較して色々と変更が加わってました。今回はその中から1つ紹介します。

保存中のデータの暗号化 (BitLocker)

Exchange Server 2013 ○(管理者が有効にする必要がある旨の注記有り)
Exchange Online(全てのプラン) 

この項目、悪い言い方ですがRFPでOffice365外しをする際に利用される、かなりメジャーな仕様でした。今回こちらが実装されたようですが、ユーザーから見てあまり機能面で響く物では無いので特にアナウンスとしては無かったのでしょうか。

例えば他にも以下の様な「オンプレではできるがOffice365では出来ない物」が有りましたが、いずれも実装されていっており、機能要件としてマルバツ表作ってもほぼ差が出ない状態になってきています。

  • アドレス帳の分割(→アドレス帳ポリシーの機能実装)
  • パブリックフォルダ(→Onlineでも利用可能に。しかも無料)
  • 階層型アドレス帳(→Onlineでも有効化可能に)

 

が、いざ実際に導入フェーズになってみると、色々と機能一覧では出てこない非機能要件の面で差異が出てきて、時には問題になったりもします。

 

というわけで、来月のSQLWorldさんの勉強会ではその辺りの事を踏まえた上で、運用を踏まえたスムーズなOffice 365導入についてお話ししたいと思います。

SQLWorld★大阪#24 開催情報

向く組織、向かない組織、導入が決まったのであれば変えていくべきポイントなど、具体例含めて紹介したいと考えています。

Office365で階層型アドレス帳が利用可能に②

前回の投稿では、Office365で利用可能になった階層化アドレス帳のさわりをご紹介しました。

今回は、実際に利用していく上でいくつか考えていく必要のあることを中心にお話したいと思います。

1.階層として利用できるグループの種類について

Office365では、①メールが有効なセキュリティグループ ②配布グループ ③動的配布グループ という3つの種類のグループを利用する事ができます。

 

20140325_01

テストというグループの下にそれぞれの種類のグループを入れて、アドレス帳に表示しないオプションを入れてない物-1(デフォルト値)と入れていない物-2を作成しました。

動的配布グループはアドレス帳に表示しないオプションの選択や階層化アドレス帳として利用する為に必要な Set-Group -IsHierarchicalGroup $true 自体が入れられませんでしたが、とりあえずはグループメンバーに入れたままテストしてみます。
20140325_03

結論)階層化アドレス帳の階層グループには「メールが有効なセキュリティグループ」「配布グループ」が利用できる。利用する場合はPowerShellのSet-Groupコマンドレットで -IsHierarchicalGroup を $true に設定し、アドレス帳非表示の属性は有効化してはいけない。

2.複数組織にまたがるユーザー(兼務者)の扱いについて

階層化アドレス帳はグループ内のメンバーであるユーザーを再帰的な展開はせずにそのまま表示します。この為、例えば「Contosoグループ会長 兼 Fabrikam株式会社社長」などのユーザーを表現したい場合は、「Contosoグループ」「Fabrikam株式会社」の両方のグループのメンバとして登録すれば両方に表示されます。
20140325_04

ただし、注意が必要なのは右側の一覧画面の中で表示される「役職」についてはグループの情報では無く、各ユーザーに静的に設定された値が表示されますので、一般的には本務の方を役職欄に入れる形が多いかと思います。

3.同一グループ内の並び順について

ここが階層化アドレス帳の最大の特徴にして、日本から要望が上がって機能化したんだなとしみじみ思う点の1つです。日本人は、社員の一覧を表示する際に50音順では無く役職順に並ぶ事を美学としています。

この為、
20140325_05
こーんな並び方をしてた日には、酒井総務課長からけしからんというメールを頂く事にもなりかねません。

このため、階層化アドレス帳で表示させるユーザーやグループには、SeniorityIndex というパラメータを設定して明示的に偉さの順番を表現することができます。

例えば、社長440 常務430 部長320 課長 310 係長220 社員210 などと定めて、それを各社員にSet-User -SeniorityIndex で設定をしておけば、
20140325_06

といった表示となり、酒井総務課長も満足してくれます。また、複数の同一階層の組織の並び順(例えば営業部が前なのか総務部が前なのかなど)を行う際にも利用できます。

元から会社の人事システムなどでコードがあればそれで良いですし、なければ後から間に役職を足せるように適宜間を開けた数を振りましょう。(え?担当部長代理と担当課長とどっちが偉いかって? そんな事は人事の人にでも聞いて下さいw)

4.同一階層内での並び順について

同一階層で、同一SeniorityIndexの場合、もしくはその設定が無い場合、並び順はフリガナが設定してあればその順に、無ければASCIIコード順になります。

こちらもASCIIコード順だと特に日本語の環境の場合は視認性が悪くなりますので、フリガナを設定しておきましょう。コマンドはSet-User [ユーザー名] -PhoneticDisplayName [フリガナ]です。

5.その他

  • Outlook Web App(OWA) からは利用できません。Outlook 2010/2013のみです。OWAからも利用したい場合は、BBSさんのAddressLookなどのアドインを活用しましょう。
  • 階層型アドレス帳関連の設定は基本的にPowerShellからコマンドラインベースで行います。組織改編や人事異動は気合いで乗り切りましょう。(昔は管理ツールとかも出てたのですが
  • アドレス帳ポリシー(ABP)と併用することはサポートされていません(参考)。(※試した限りでは上手く階層が作れれば動きます。アドレス帳非表示設定になってると階層型アドレス帳に表示されないのと同じ理屈で、トップから表示させたい各階層のグループ&メンバーまで上手くアドレス帳ポリシーに則って分割できれば…。)

 

Office365で階層型アドレス帳が利用可能に①

Office365(Exchange Online)は、新機能の追加に加え、「パブリックフォルダ」「アドレス帳の分割」など、発表以降オンプレミスのExchange Serverでしかできない機能制約がどんどん解消されています。

今回、その中で特に日本のユーザーにとって要望が多かった階層型アドレス帳(HAB)がOffice365でも利用できるようになりました。

階層型アドレス帳というのは、階層構造の組織をそのままアドレス帳として表示させる物です。(特に日本の企業であればなじみやすいかと思います。)
スクリーンショット (38)

階層型アドレス帳を利用する手順は、大きく以下の2つになります。(その後、必要に応じて並び順などのカスタマイズを行いますが、これは次回の投稿で書きたいと思います)

  1. 階層構造として表示したいアドレスをグループとそのメンバーとして表現し、そのグループのIsHierarchicalGroupの属性をTrueにする
  2. Set-OrganizationConfigで階層構造の最上位となるグループを指定する

会社組織の場合は最上位は「全社」、企業グループの場合は「○○グループ」になります。今回は、Contoso株式会社とFabrikam株式会社から構成されるContosoグループでアドレス帳を作ってみます。

階層用のグループは専用で作成しても良いですし、既存で利用している組織グループがあればそれでも構いません。グループを作成してメンバーを構成したら、各グループにIsHierarchicalGroupのフラグをセットします。

Set-Group -identity [グループ名] -IsHierarchicalGroup $true

そして、最後に最上位のグループを指定します。(Enable-OrganizationCustomizationが必要とエラーメッセージが出た場合、事前に実行します。)

Set-OrganizationConfig -HierarchicalAddressBookRoot [最上位グループ名]

これで、Outlookからアドレス帳を開くと(OWAからは階層化アドレス帳は利用できません。Outlook専用です)、新たに「組織」というタブが表示されるようになります。

(設定前)
スクリーンショット (39)

(設定後)
スクリーンショット (36)  スクリーンショット (37)

次回は、階層化アドレス帳を実際に利用していく上でのTIPSをいくつか紹介したいと思います。

それにしてもどんどん便利になっていきますね。

ADFS環境でOWAからログアウトできない

新しいOffice365になって、ADFSまわりで微妙に挙動が変わった部分があるのでそちらを紹介させて頂きます。

内容は、OWAのバニティURLからログインした場合にOWAからログアウトできないという物です。具体的にどういうことかというと、ADFSの場合は、通常

【ログイン】
20130924-000503 20130924-000443 20130924-000451

【ログアウト】
20130924-000455 20130924-000459 20130924-000503

こんな感じで画面が推移してそれぞれシングルサインオン、サインアウトして最初のサインインの画面に戻るというフローになります。(ちなみにサインアウト画面が出るのはWindows Server 2012 R2のADFSの場合のみです) 各アプリケーションのサインアウト画面からは、アプリケーション毎に少し違っていて、SharePoint Onlineからの場合はサインアウト後専用の画面で止まります。

OWA
20130924-002356 20130924-000459 20130924-000503

SharePoint Online
20130924-002018 20130924-000459 20130924-002027

ただし、新しいOffice365へのアップグレード後、「OWAに直接バニティURLを利用して入った場合、OWAからサインアウトできない」という事象が発生しました。このバニティURLというのは、例えば https://outlook.com/owa/contoso.com のようなURLで、ポータルのサインイン画面でのID入力を飛ばしてOWAに入れるURLです。これを利用していた環境でサインアウトをしようとすると、

20130924-000700 20130924-000459

一旦はサインアウトされるのですが、なぜか再度数回リダイレクトを繰り返した後に元の画面に戻ってきてしまいます。
20130924-000710 20130924-000712

以前一度だけあった事象は、「SharePoint Onlineで*.sharepoint.comを信頼済みサイトに入れていない場合にリダイレクト処理の関係でサインアウトが上手くいかない」というのは有りましたが、今回はちゃんと設定してあります。う~ん、謎な挙動です。

とりあえずFiddlerでポータルから入った場合とバニティURLから入った場合の挙動をトレースしてみます。
20130924-003935

一箇所怪しいところを見つけました。

ポータルから:    https://sts.w15jp.info/adfs/ls/?nossl=1&wreply=https://login.microsoftonline.com/login.srf%3Flc%3D1041%26ct%3D1379942681%26rver%3D6.1.6206.0%26id%3D260563%26wa%3Dwsignoutcleanup1.0%26nossl%3D1%26wreply%3Dhttps:%252F%252Foutlook.com:443%252Fowa%252F%253Fexch%253D1&wa=wsignout1.0
バニティURLから: https://sts.w15jp.info/adfs/ls/?nossl=1&wreply=https://login.microsoftonline.com/login.srf%3Flc%3D1041%26ct%3D1379924091%26rver%3D6.1.6206.0%26id%3D260563%26wa%3Dwsignoutcleanup1.0%26nossl%3D1%26wreply%3Dhttps:%252F%252Fpod51054.outlook.com:443%252Fowa%252F%253Fexch%253D1&wa=wsignout1.0

ポータルから入った場合はサインアウトした後に戻るURLの更にリダイレクト先がoutlook.comになっているのに対して、バニティURLから入った場合はそのメールボックスが収容されているpod51054.outlook.comになっています。

この差が最終的にリダイレクトされた後にポータルに飛ぶか、再度SSOの画面に飛ぶかの判定に繋がっているようです。(ちなみにバージョンアップ前のOffice365の場合はsixprd0210.outlook.comなどの実際にMBXサーバがあるところのFQDNでした。この場合もサインアウト後の戻り先はポータル) 最初は無理矢理web.configに

<RewriterConfig>
   <Rules>
      <RewriterRule>
         <LookFor>~/adfs/ls/?nossl=1&wreply=https://login.microsoftonline.com/login.srf%3Flc%3D(d{4})%26ct%3D(d{10})%26rver%3D6.1.(d{4}).(d)%26id%3D(d{6})%26wa%3Dwsignoutcleanup1.0%26nossl%3D1%26wreply%3Dhttps:%252F%252Fpod51054.outlook.com:443%252Fowa%252F%253Fexch%253D1&wa=wsignout1.0</LookFor>
         <SendTo>~/adfs/ls/?nossl=1&wreply=https://login.microsoftonline.com/login.srf%3Flc%3D(d{4})%26ct%3D(d{10})%26rver%3D6.1.(d{4}).(d)%26id%3D(d{6})%26wa%3Dwsignoutcleanup1.0%26nossl%3D1%26wreply%3Dhttps:%252F%252Foutlook.com:443%252Fowa%252F%253Fexch%253D1&wa=wsignout1.0</SendTo>
      </RewriterRule>
   </Rules>
</RewriterConfig>

とかのrewriteルールを無理矢理書いて対応しようかと考えたのですが、そもそもWindows Server 2012 R2からはADFSがIISを利用していないのでweb.configが利用できません。

SRで上げても再度ログインしてしまうのは新バージョンからの仕様と言われてしまったので手詰まりかと思ったのですが、ある時ふとOutlookのプロファイルを見たところ、バニティURLが https://outlook.office365.com/owa/contoso.com に変わっていることに気がつきました。(今まではpod510xx.outlook.com/owa/contoso.com)

というわけで、この新しいバニティURLからサインインして、サインアウトを試してみると…おぉ、できました! よく見ると、サインイン後のOWAのURLもpod51054.outlook.comではなくoutlook.office365.comになっています。

20130924-010348 20130924-010428

20130924-010433 20130924-000459 20130924-000503

という訳で、アップグレードに伴って古いバニティURLを利用されている方でサインアウトの問題がでている方は、 https://outlook.office365.com/owa/contoso.com に変更してみて解消するかどうかお試し頂く事をお勧めさせて頂きます。

Office365のADFSでの最近の変更点

Office365のアクセス制御の実装方式としまして、一番一般的なのはADFSを利用したクレームルールによるアクセス制御になります。クレームにはExchangeにアクセスしてくるクライアントのIPやプロトコルなどの情報がOffice365側で付与されて伝送されてきますので、それとユーザーの所属するグループなどの情報を合わせてアクセス制御を実装します。

ここ1~2年の間で、(非常に細かいことですが)少しここの仕組みでOffice365側で変更になった部分があるので紹介します。

まず、従来のアクセス方式について説明します。Office365のExchange Onlineは、メールボックスがシンガポールか香港のどちらかがプライマリとして設定されています。また、ユーザーがアクセスするCASサーバはどちらのデータセンタも同じURLでのアクセスとなるため、1/2の確立で自分のメールボックスが無いCASにアクセスされます。

この際、Outlook(Outlook Anywhere)やActiveSyncなど、HTTPSによる通信でリダイレクトがサポートされているプロトコルについては、メールボックスがこのサイトに無い旨クライアント側に通知され、メールボックスの存在するサイト(下の図で言えばシンガポール)のCASサーバにリダイレクトされます。

この結果、ADFS(ADFS Proxy経由)に渡されてくる送信元IPは、元のグローバルIP:Aが渡されてきます。

20130723_01

次に、POPやIMAPなど、プロトコル的に「リダイレクト」の処理がサポートされていない場合です。この場合、CASサーバは適切なサイトへの接続(下の図で言うと香港→シンガポール)を「Proxy」処理します。

これが行われると、ADFSには送信元IPとしてグローバルIP:AならびにグローバルIP:Cの両方が渡されます。

20130723_02

この原理により、POP/IMAPのプロトコルをADFSで送信元IP制限を掛ける場合、Exchange OnlineのIP帯についても許可IPリストに入れておく必要がありました。

変更点

①クライアントのIPアドレスとしてIPv6がサポートされました。

Exchange Onlineの接続ポイントとしてIPv6がサポートされました。合わせて、クライアントのIPv6アドレスについても問題なくADFSサーバ側に情報として渡されるようになりました。
20130527_02

ADFSのクレームルールでは、文字列の正規表現でのマッチングで判定をします。「IPv6でもアクセスできるように許可する」「既存の許可ルールが、別のIPv6アドレスにマッチングしないようにする」などの確認が必要になります。

②MicrosoftデータセンタのIP帯のアドレスがマスクされてADFS側に渡されなくなりました。

これは、上記POP/IMAPアクセスの際に従来「グローバルIP:AならびにグローバルIP:C」が渡されてきた物から香港DCのIP帯であるCの方がマスクされて「グローバルIP:A」のみADFSに渡されてくる形になります。

http://community.office365.com/ja-jp/wikis/sso/927.aspx にも、以下のように記載があります。

・クライアント IP アドレスおよび要求を渡した各プロキシのアドレスを示す複数の IP アドレスは、
コンマで区切って指定されます。
・Exchange Online インフラストラクチャに関連する IP アドレスは一覧に表示されません。

これにより、ADFSのクレームルールを作成する場合に、プロトコルの挙動(リダイレクトかProxyか)の差について作成者は意識せずに作れるようになりました。

ただし、現時点で1つ問題点というか、制限事項が確認されています。このマスクされるIPアドレスについては別途Microsoft側で定められているようなのですが、それにシンガポールDC、香港DCなど【同一DCで動作しているWindows AzureサービスのIP帯】も一部含まれているようです。

この為、Windows Azure上で展開されているExchange Online対応のサービスについて、適切なIPアドレスが渡されてこない可能性があります。IntuneのクライアントアクセスのIPアドレス帯については未確認ですが、同じ原理でいけば可能性はあると思います。

いずれIPアドレスのリストなどが精査されて直ることを期待してますが、動作原理を知っているのといないのでは有事の際に対応にも差が出るかと思いますので、細かいことですがここでご紹介させて頂きました。

なお、この記事は一部検証結果に基づいた個人的な推察を交えて記載しておりますので、もし事実に反することや、既に解消されたということが書かれていた場合は訂正させて頂きますので、連絡を頂ければと思います。

最初の管理者がExchange管理センターに入れない

Office365にサインアップを行う際、最初に作成されるアカウントは(その時点で)唯一の全体管理者として作成されます。

通常は、このアカウントを利用して色々Exchange OnlineやSharePoint Onlineの設定を行うことができるのですが、テナントによっては希に以下の様な事象になり、Exchangeの管理ができなくなることがあります。

①管理者メニューのExchangeを開くと、組織では無く個人のExchangeの設定が出てしまう。
20130721_01

②Office365管理センターのサービス設定からExchange関係の設定をしようとすると403アクセス拒否のエラーが出る
20130721_02 20130721_03

どういうメカニズムで発生しているのか、少し中を見てみたいと思います。まず、新しい全体管理者のアカウント(今回はadmin02という名前)を作成します。この新規で作成したユーザーはExchangeの管理画面(Exchange管理センター)に接続できるので、接続後に[アクセス許可][管理者の役割]を見てみます。

TenantAdmins_xxxxxという名前のグループがありますが、ここに通常は全体管理者のユーザーがコピーされてきます。このグループがOrganization Managementのメンバーなので、全体管理者がExchangeの管理権限を持つという仕組みです。ここで、メンバーがadmin02という新規で作ったユーザーしかいないことが分かります。
20130721_04

よって、この事象は恐らく全体管理者のメンバー情報がOffice365ポータルからExchangeにコピーされる際に、タイミングや不可の問題等で欠落してしまったと推測されます。また、最初のユーザーでのみ発生することから、テナントのプロビジョニングの問題と考えられます。

よって、最初のユーザーから一回全体管理者の管理権限を外し、再度付け直すことによって解決を試みます。
20130721_05

反映までに若干時間が掛かりましたが、これでTenantAdmins_xxxxxのメンバーに最初の管理者が追加されました。後は、必要に応じて一時的に作成した全体管理者アカウントを削除するなりすれば問題なく利用できます。
20130721_06

Office365バージョンアップで実行されるコマンドと注意点

先月より本格的に日本でも開始されたOffice365のバージョンアップですが、その裏側でどんなことが行われているかについて少し調べてみたいと思います。

ご存じの通り、Exchangeは管理者のコマンド(参照以外)実施は「管理者監査ログ」を見ることにより調べることができますので、早速バージョンアップしたテナントの管理者監査ログを取り寄せてみます。

管理者監査ログは、Exchange管理センターの[コンプライアンス管理][監査]のメニューから[管理者監査ログのエクスポート]を選択します。アップグレードを含む適切な期間と、結果を受領するメールボックスを選択して[エクスポートを]選択します。通常、数時間待つとメールで管理者監査ログが届きます。

20130720_01
20130720_02

管理者監査ログは、XMLファイルの形式です。1つ1つのイベントは、<Event Caller=…>で始まり、</Event>で終わります。

アップグレードが実施された時間帯を元に探すと、”NT AUTHORITYSYSTEM (Microsoft.Exchange.ServiceHost)”からの命令で実施されている一連のコマンドが表示されます。ほとんどが、Set-MailboxPlan、Set-CASMailboxPlanなどのユーザーに開放されていないコマンドレットやInstall-GlobalSettingsContainer、Install-DataClassificationConfigなどのアップグレード用に作成されたであろう特別なコマンドレットになっています。

ここで、以前の投稿で紹介したアップグレードコマンドの実行により一部の設定がデフォルト値に戻ってしまうという現象が再現していないかについて検証してみたいと思います。以前の物はマイナーバージョンアップによる物で、その後の更新によりこちらは設定が保持されるようになりました。が、今回は残念ながら以前紹介した3つのパラメータ

Set-RemoteDomain AutoForwardEnabled True
AutoReplyEnabled True
Set-OrganizationConfig MailTipsLargeAudienceThreshold 25

については元に戻ってしまうようです。
20130720_03

また、当然と言えば当然なのですが、このタイミングでSet-OwaMailboxPolicyでPublicFoldersEnabledがTrueになってたりなどもしてます。

Exchangeをお分かりの方で、何かUpgrade後に挙動がおかしいと思った場合には管理者監査ログを調べられるのも良いかもしれませんね。