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のキューイング期間
  • 1週間…キリがいい
  • 無期限…再起動されたり、フェールオーバーすると消える
  • 特に決まってない…容量だけ決まってて自動的に上書きされる

blog引っ越しました

最近のITブロガーの方々のビッグウェーブに乗るべく、長年慣れ親しんだ wordpress.com をやめてSAKURAインターネットに移行してみました。

コンテンツもかなりやっつけで移行したので、もし不具合とかありましたら教えていただければと思います。(すいません、IE8で画像の縮小が効いていない点は諦めてください…)

一般ユーザーのセルフパスワードリセット(詳細)

前回の投稿では、一般ユーザーのセルフパスワードリセットの概要を紹介させて頂きました。

追加とおさらいとして。一般ユーザーのセルフパスワードリセットを利用する場合、Azure ADの管理画面から有効化を行います。

有効化を行わないデフォルトの状態だと当然セルフパスワードリセットは利用できないのですが、何もしていないテナントでも、少し挙動が変わりました。今までは、[管理者に連絡]というボタンから管理者宛に飛んでいたパスワードのリセット要求のメールの中に

ユーザーが自分でパスワードをリセットできるようにしますか? ほんの数回のクリックで組織のユーザーのパスワードのリセットを有効にする方法をご確認ください。

という様な機能説明のページへのリンクが併記されるようになりました。このメールが来て、初めてこの機能の実装に気がつく管理者の方も多いかも知れませんね。
スクリーンショット (135) スクリーンショット (136) スクリーンショット (138)

それでは、詳細設定の方に入っていきたいと思います。まずはセルフサービスができるユーザーの限定。通常社内にいるようなユーザーやパートナー社員に対してはこの機能を解放しないというようなケースで利用できます。

[パスワードリセットへのアクセスの制限]を[はい]に設定することにより、この機能が有効化されます。[SSPR セキュリティ グループ ユーザー]という名前の空のグループが新規で作成されますので、こちらにパスワードリセットをさせるユーザーを適宜追加して利用します。【本機能はプレビュー中の為変更になる可能性が有ります】
スクリーンショット (133) スクリーンショット (134)

また、前回の投稿では、ユーザーに登録用のリンクを送って自身で登録して貰う方法を紹介しましたが、管理メニューの[○○(テナント名)のユーザーを今すぐ編集します]というリンクから辿れるユーザー管理画面の[勤務先]から、電話番号と電子メールアドレスは入力することができます。

ちなみに、ユーザーが使用できる認証方法との対応は、認証用電話が[携帯電話]、別の認証電話番号が[会社電話]、認証用メールが[連絡用電子メール アドレス]になります。
スクリーンショット (129) スクリーンショット (130)

続いては、[秘密の質問]です。インターネットサイトなどでよく見かける物ですが、管理者側としては[①登録する必要がある質問の数]と[②リセットに必要な質問の数] [③秘密の質問]を設定する必要があります。【本機能はプレビュー中の為変更になる可能性が有ります】

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

数は、その性質上③≧①≧②にする必要があります。①②は3-5が設定できる範囲になります。ここでは試しに①=②=③=5個にしてますが、悪い見本ですね。

  1. (後述しますが)回答の最低文字数は3文字なのに姓を答えさせるって1文字とか2文字の人はどうするの?
  2. ペット飼ったこと無い人は回答できないし
  3. 回答できない質問があるくせに、実質全部の質問に何らかの回答を設定しなくてはいけない

普通に企業IDとしてやるなら、③10個>①5個>②3個くらいですかね? まあ、ここではサンプルなので仮に入力して進めてみます。

ユーザー自身で http://go.microsoft.com/fwlink/p/?LinkId=524980 にアクセスし、答えられる質問を選び、それに3文字以上で回答を設定します。(全角、半角どちらも1文字としてカウントされます。)
スクリーンショット (141) スクリーンショット (144)

そうするとパスワードリセット画面の項目の中に、[セキュリティの質問に回答する]が現れます。ここに、設定した回答と同じ物を入力すると、パスワードリセットを行う事ができます。(パスワード強度を表示する部分が文字化けしているのは、まあ愛嬌って事で)
スクリーンショット (146) スクリーンショット (147) スクリーンショット (156) e382b9e382afe383aae383bce383b3e382b7e383a7e38383e38388-148

セキュリティを強化させるため、認証に必要とされる数を、デフォルトの1から2に変更することもできます。従来の管理者アカウントのパスワードリセットには電子メールと携帯電話の両方が必要だったので、そちらと同じレベルと考えると良いかと思います。

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

2に変更すると、認証画面が[確認ステップ1]と[確認ステップ2]に分かれます。ちなみに、当然と言えば当然ですが[携帯電話にSMS送信]と[携帯電話に発信]で2個とはカウントしてくれません。片方で認証が取れると選択肢から消えます。
スクリーンショット (150) スクリーンショット (154)

その他の機能です。
スクリーンショット (156)

ユーザーがAzureのアクセスパネルにアクセスした際に以下の様な表示を出して情報の入力を促すことができます。(ただ、Office 365の一般ユーザーはあまりアクセスパネルにログインする機会自体が無いかも知れませんので、その場合はリンクを各ユーザーに伝えて入力する形になります。)
スクリーンショット (127)

また、連絡先データの再確認を行う間隔を設定できます。デフォルトは180日です。0日に設定すると、再確認は発生しません。

認証情報が分からなくなったユーザーが管理者に連絡する手段として[管理者に連絡]のリンクが設定されていますが、これをURLやメールアドレスに変更することもできます。
スクリーンショット (157)

ディレクトリ同期環境の場合、[パスワードの書き戻し]機能を有効化するようにとの記載がありますが、残念ながらこちらについては引き続きAzure AD Premiumのサブスクリプションが必要になります。

想定していないパスワードリセットを検知するために、通知機能がデフォルトで有効化されています。複数管理者がいる場合など、対応依頼が来たメールに対して対応済みかどうかを知るために、他の管理者にパスワードリセットするオプションも設定できます。

 

うまく使いこなせば、セキュリティレベルをそれほど下げないで管理者の負荷を軽減できる物になりますので、是非、色々と使い方を研究してみてください。

関連記事:一般ユーザーのセルフパスワードリセット

一般ユーザーのセルフパスワードリセット

Office 365では、以前より管理者アカウントに対してセルフパスワードリセットの機能が提供されていました。

これは、特に中小企業などで社内に全体管理者のユーザーが1名しかいない状況でも、パスワード忘れや退職等に対応できるようにするというのが主たる目的でした。

ただ、それ以外の一般ユーザーのパスワード忘れへの対応というのは、管理者の稼働の多くを必要とする物の一つであり、機能の一般ユーザーへの提供が望まれていました。Azure AD Premiumのサブスクリプションを購入すれば従来から利用はできていたのですが、今回、Office 365のサブスクリプションを有しているユーザーは、この機能が無償で提供されるようになりました。

この機能を有効化するには、Azure ADの管理画面にログインした後、[ユーザーパスワードのリセットポリシー][パスワードのリセットが有効になっているユーザー]を[はい]に変更します。
スクリーンショット (50) スクリーンショット (51)

これで、管理者側の設定は完了です。

次に、機能の利用対象である全ユーザーに対して以下のURLを通知し、携帯電話やメールの情報を登録して貰います。

http://go.microsoft.com/fwlink/p/?LinkId=524980

ユーザーがこの画面にアクセスすると、このような画面が表示されて情報の入力を促されます。
スクリーンショット (42)

電話番号の登録は、国番号と電話番号を入力してショートメールもしくは電話での認証となります。[電話する]ボタンを押すと、入力した電話番号に電話が掛かってきて、[確認を完了する為に#を押して下さい]と言われるので、[#]を押すと登録が完了します。
スクリーンショット (43) スクリーンショット (45)

 なお、前は+81の後に続けて入力する番号は先頭の0を除いた、例えば9012345678などの値を入力する必要がありましたが、この記事を書いている時点では09012345678と入力しても問題無く電話は掛かってきて認証できました。

続いて、メールアドレスの登録です。メールアドレスを入力した後に、[電子メールを送信する]をクリックするとメールが飛んできます。そのメールの値を入力します。

なお、勿論このメールはOffice 365のパスワードを忘れたときに送信されてくる物になりますので、Office 365のアドレスではなく、例えば携帯のアドレスやgma…、いや、Outlook.comのアドレスなどを設定する必要があります。
スクリーンショット (46) スクリーンショット (47) スクリーンショット (61)

これでクライアント側の設定は完了です。
スクリーンショット (49)

さて、実際の利用シーンです。セルフパスワードリセットを利用するには、サインイン画面の下に表示されている[アカウントにアクセスできない場合]をクリックします。
スクリーンショット (62)

登録してある情報のどれを利用して本人確認をするかの画面がでますので、ここで利用する情報を選択します。今回は電子メールで認証をしています。

携帯電話は、登録したときと同じようにショートメールか電話を選択できます。電子メールと違うのは、登録してある電話番号を認証用に入力する必要があるということです。これは、実際に個人の携帯などに電話が掛かってくるので、間違い電話防止などの意味もあるのでしょうね。
スクリーンショット (53) スクリーンショット (54)スクリーンショット (55)

認証が完了すると、リセットするパスワードの入力画面になりますので、新しいパスワードを入力します。上書きのリセットの扱いのようで、前回と同じパスワードを入力しても別にエラーにはなりませんでした。
スクリーンショット (57) スクリーンショット (58)

今回は、まずデフォルト状態でのセルフサービスパスワードリセットを紹介させて頂きました。

Azure AD側では、もう少しこの操作の詳細を設定できるオプションが用意されていますので、そちらは次の機会に紹介させて頂きます。

関連記事:一般ユーザーのセルフパスワードリセット(詳細)

Office 365 サインイン画面のカスタマイズ

Azure Active Directory Premiumで利用可能であった一部のオプションが、Office 365を利用しているユーザー向けに利用できるようになりましたので紹介します。

今回紹介するのは、サインイン画面のカスタマイズです。

設定するには、Office 365管理センターではなく、Microsoft Azureのポータルから設定をする必要があります。[サービス設定] – [パスワード]の下の方や、左のナビゲーションバーの管理者メニューの一番下の[Azure AD]にもリンクがありますが、Azure AD管理センターにアクセスします。
20150222_01

まだAzureにサインアップしていない場合、携帯の番号やクレジットカード番号を入力して無料評価版としてサインアップします。無料評価版のままでも試せますが、30日間の期限がありますので、期限が切れる前に従量課金制にアップグレードして利用しましょう。あくまで従量課金なので、有償のサービスを利用しないままであれば0円課金のまま継続利用できます。

ポータルのを開くと、最初は唯一利用中であるディレクトリ(Active Directory)のみ表示されます。ここの[構成]メニューを選択します。
20150222_05

 

[ブランドのカスタマイズ]を選択します。
20150222_06

 

バナー(画面右上部に表示される物)やサインインページの図(左側に表示される画像)やテキスト(画面下部に表示される)などを設定します。
20150222_07_2

下のチェックボタンを押してしばらく待つと完成です。ちなみに、サインインページの図は、最大サイズが500KBに制限されていますので、保存中にエラーが発生した場合はまずファイルサイズを確認してみて下さい。

いつものサインイン画面ですが、IDを入力すると…
20150222_10

先ほど指定した画面に飛ぶようになります。
20150222_11

コーポレートカラーや会社のロゴなどを表示したり、下の部分にカスタマイズしたテキストを表示させることができますので、未ログインの状態のユーザーに対して提示したい情報、例えばID/パスワードを忘れた場合の対応方法や利用開始の申請方法など入れておくと便利です。

ただし、こちらはIDや会社のメールドメインなどを入れただけでも他のユーザーにも表示されますので、社内向けヘルプデスクの電話番号などあまりオープンにすべきでない情報は載せない方が良いかもしれません。

無期限のパスワードポリシー

Office 365では、パスワード有効期限(14日~730日)や、その期限切れ通知を行う期間(1日~30日前)について、テナント単位で設定を行う事ができます。
20150222_01

この画面、最近ちょっと新しくなりました。

まず、パスワードセルフリセットに関する案内が記載されました。これは別の投稿で紹介させて頂きます。また、一番上に「パスワードの有効期限が切れることはありません」という項目が追加されました。

20150222_02

以前は、パスワードの無期限化を設定しようとした場合は、ユーザー単位でPowerShellを利用して設定しなければいけなかったのが、これを利用するとテナント全体でパスワードの無期限化を設定することができます。

勿論、パスワードは定期的に変えるのが運用上良いのですが、どうしても組織の運用と合わない場合などは利用すると良いと思います。

 

ちなみに、この設定は今のところGUIからしかできないようです。

PowerShellから見ると、2147483647(2^31-1)日と表示されますが、実際にPowerShellから同じ値で設定を入れてもGUIの表示でチェックは付かないので…。
20150222_03

 

Office 365の各種URL

遅くなってしまいまして申し訳ないですが、以前の投稿「祝!Office365日本リージョン」のフォローアップです。

あの投稿と平行しましてMicrosoft側にも調査をお願いしていたのですが、どうやら私の普段利用していたログインスクリプトの接続先URLが古く、そのURLを利用した場合に接続できないという事象だったとのこと。

確かに、いつの間にかTechnetなどの接続先が https://ps.outlook.com/powershell/ から https://outlook.office365.com/powershell-liveid/ に変わっていました。(2014/2/19の英語版の改定からそうなっていたようですね)

ただ、個人的に素晴らしいなと思うのは、「古いURLを使っているとつなげない」という問題に対して、単純にそれをKBとして公開して終わりではなく、それを使い続けている人がどういうシナリオで使っていて(例:スクリプトに埋め込んでいる)、その人達に対してどう伝えれば効果的(例えばCommunityの上の方に固定表示させる)なのかを色々と考えてくれるのだな、と感じました。

ただ、この投稿を書いている現在は問題であったDNSレコード pod51075psh.outlook.com のDNSが登録されたようで、古いURLからも接続できるようになっているようです。何か有った場合のサポートコストを考えると、新しいのにばっさり切り替えるよりは今までの互換性を担保できるようにした方が良いとの判断でしょうね。
20150124_01

私自身、ポータルのURLが変わるという情報は blog【重要】Office 365 にサインインするためのアドレスの変更について などで見ていたので気づいていましたが、PowerShellの接続先は見落としてました。

自身のリマインダも兼ねて、接続先URLを新旧対応含めいくつか記載しますね。

  • Office365 ポータル:https://portal.office.com (旧:https://portal.microsoftonline.com)
  • Outlook Web App:http://mail.office365.comまたはhttps://outlook.office365.com/owa/contoso.com(旧:https://outlook.com/owa/contoso.com)
  • Exchange管理Shell:https://outlook.office365.com/powershell-liveid/ (旧:https://ps.outlook.com/powershell/)

それぞれ、古いURLを使っていると一部挙動がおかしく(OWAからサインアウトできない)なったりすることもあるので、確かに全クライアントPCで変更するのは大変ですが、そろそろ新しいURLにブックマークやスクリプトなどは変えて行った方が良いかと思います。

MVP Community Camp 2015に登壇します

1/31(土)に全国8都市で実施されるMVP Communitu Camp 2015の東京会場(品川・Microsoft)で、1セッション担当させて頂くことになりました。

MVP Community Camp 2015
https://msevents.microsoft.com/cui/EventDetail.aspx?EventID=1032608669&culture=ja-JP

同一会場内だけで4セッションもあるので、1つくらいは若手/若年層向けではなくITPro向けの話でもいいかな、と思ってます。予定しているタイトルは以下の通りです。

Office 365 オンプレミス製品の共存/使い分け

Office365が出て、最近あまり話を聞く機会が無くなったExchange/SharePoint/Lyncのオンプレミス向けのServer製品について、Office365がでてきた今だからこその観点で話をしたいといます。

そんなのOffice365で良いじゃんと思われる方もいらっしゃると思いますが、実はオンプレミス製品も需要有るんですよというのを、なるべく実例を交えて話させて貰いたいと思いますので、お時間のある方は是非参加していただければと思います。

ちなみに、来週末ですが、スライドの進捗は…非常に悪いです(w

祝!Office365日本リージョン

12/16に、いよいよ待望のOffice 365の日本リージョンが開設されました。既存のAPACテナントに配置されているユーザーも移設されるようなので、楽しみですね。

というわけで、さっそくトライアルを申し込んで利用してみました。
Pingを打ってみると、既存テナントが80-100msecなのに対して、10-25msecとかなり近いです。(日本でも値にぶれがあるのは東日本<132.245.144.66>と西日本<132.245.131.50>の差ですかね?)
20141217_04

ホスト名の命名規則はkaw,ty1,os1,os2のようです。前2つが東日本、後ろ2つが西日本ですかね? ちなみに、前はsin,six,hkn,hkxのような感じ。
20141217_02

(注意)
この記事を書いている時点で、Exchange OnlineにPowerShellから接続しようとすると、pod51075psh.outlook.comの名前解決ができないというエラーがでます。しばらく待っても変わらないのでネガティブキャッシュでもなさそうです。

20141217_03

他のPODのDNSを参考にすると、pod51xxxpsh.outlook.comはpod51xxx.outlook.comのAlias(CNAME)なので、とりあえずpod51075.outlook.comを引いた物のうちの任意の1つをHostsに書いてあげれば接続できます。