DuplicateDeliverによる配信不可

Exchange Serverでは、以前のバージョンより同じメールが複数届いた場合に最初の1通のみ受信し、残りのメールを重複として削除するシングルインスタンス機能が備わっています。Exchange Server 2013においても同機能が備わっております。

重複と検出判断されたメールは、メッセージ追跡ログを見ると、2通目以降のメールには Source STOREDRIVER EventId DUPLICATEDELIVER が記録され、メールボックスには最初の1通だけ配送されます。
20150311_01

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

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

参照:How does duplicate detection work? / Exchange 2007 で重複するメッセージを検出する方法

この機能自体は、ユーザー側のメールを読む負荷を軽減すると共に、メールのループ防止などの意味で重要な役割を担っているのですが、一定のケースで2通目以降のメールを受け取りたい場合があります。例えば、

  1. ウィルスが誤検知されて添付ファイルが削除されたメールをアンチウィルスソフトから再送する場合
  2. ユーザが誤って削除して復元できなくなったメールをジャーナルアーカイブから再送する場合
  3. システム上の制約で同じMessageIDで送信してくるメールを受信する場合
  4. Toに自身のアドレスが、Ccにメーリングリストが入っていて、メーリングリスト毎にフォルダ分けしている場合

などです。Exchange Server 2007/2010では、デフォルトで1時間の間このメッセージの重複を検知します。また、情報自体は7日間保存しております。この時間を変更する際には、レジストリの HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<Server_Name>\Private-<GUID>\ 配下のDeliveredTo Expiration in Hours や DeliveredTo Cleanup Interval in Seconds を変更する事により変更することが可能でした。

ところが、Exchange Server 2013においては、検証する限りでこの設定が変更になっているようで、今までデフォルトでは1時間待てば配送されていた物が、7日間配送されないようになっておりました。また、今まで設定していたレジストリを設定してみても動作は変わりません

Microsoftのサポートに問い合わせて調査したところ、Exchange Server 2013 CU7現在、上記設定は7日にハードコーディングされており変更できなくなっているとのことでした。

Exchange Serverは、基本的にExchange Onlineと同じコードがベースになっているという話を聞いたことがあるので、Online側でカスタマイズ不可としてハードコーディングされているのであれば、それも考えられるかなとは思う反面、今までとデフォルト値を変更した上に設定変更も不可…というのはちょっと厳しいかなとも感じております。

最近、Exchange Onlineの挙動を見る限りでは、重複検出期間が24時間に仕様が変更になったっぽいので、オンプレも今後のCU8やそれ以降で挙動が変更にならないかどうか注視していきたいと思います。

関連記事: 重複メッセージの除去(Exchange Online)

メールヘッダでExchange Onlineの構成を推測

注:この投稿は検証結果を元にした推測の部分を多大に含みます 今回は、Exchange Onlineのサーバ構成について考えてみたいと思います。

メールのヘッダには、様々な情報が付与されています。これを読み解くことによって、メールの送信遅延がどこで発生しているのか、どういうサーバを経由して届いたのかを調べることができます。

例えば、以前の記事 重複メッセージの除去(Exchange Online) で送信したテストメールを見ると、以下の様なReceivedヘッダが付与されています。

Received: from SG2PR03MB0537.apcprd03.prod.outlook.com (25.160.235.149) by
 SIXPR03MB0541.apcprd03.prod.outlook.com (25.160.173.25) with Microsoft SMTP
 Server (TLS) id 15.1.99.14 via Mailbox Transport; Sun, 8 Mar 2015 13:39:47
 +0000

Received: from SIXPR03CA012.apcprd03.prod.outlook.com (10.141.119.22) by
 SG2PR03MB0537.apcprd03.prod.outlook.com (25.160.235.149) with Microsoft SMTP
 Server (TLS) id 15.1.106.15; Sun, 8 Mar 2015 13:39:46 +0000

Received: from DB3FFO11FD006.protection.gbl (2a01:111:f400:7e04::167) by
 SIXPR03CA012.outlook.office365.com (2a01:111:e400:a82b::22) with Microsoft
 SMTP Server (TLS) id 15.1.106.15 via Frontend Transport; Sun, 8 Mar 2015
 13:39:46 +0000

Received: from xxxx.localdomain (xx.xx.xx.xx) by
 DB3FFO11FD006.mail.protection.outlook.com (10.47.216.95) with Microsoft SMTP
 Server id 15.1.112.13 via Frontend Transport; Sun, 8 Mar 2015 13:39:43 +0000

Receivedヘッダは、リレーされる度に下から上にだんだんと追加されていきます。Office 365の中では、主に以下の様な流れで記録されています。
20150309_02

まず、①では外部からMXレコードを引いた値でEOPに送信されます。これは、APACには限定されず、世界中のEOPで受信する形になるようです。今回はDB3~というホスト名で受信していますので、恐らくヨーロッパリージョンのダブリンのEOPで受け取ってからAPACに転送されているのだと思います。

Exchangeでは、外部からのメールはCAS(クライアントアクセスサーバ)で動作しているフロントエンドトランスポートが受ける形になります。直近数百通のメールを見る限りで、後述するDAGより大きな単位で束ねられたシンガポール・香港のCASサーバ群に負荷分散されて到着しているようです。ここはロードバランサーにより行われていると推測します。

次に、メールボックスの存在するDAG(データベース可用性グループ)に対してルーティングされます。DAGは、Exchange Server 2013と基本的なアーキテクチャが同じという前提であれば、最大16台のメールボックスサーバで構成されるクラスタサーバ群になります。同じく直近のメールのヘッダを追う限りでは香港①/香港②/シンガポール①/シンガポール②でそれぞれ4台ずつ構成されている様です。

最後にメールボックストランスポートから実際のメールボックスに対してメールが配信されます。メールボックスデータベースは、1つのActiveと複数のPassiveによって構成されていますが、メールボックストランスポートからは現在Activeとなっているメールボックスサーバにメールが配送されます。

これらをまとめると、以下の様なメールフローになります。CASのサーバ名は非常に数が多かったのでサンプルを、メールボックスサーバの中で実際に見つからなかったが、名前付けルールから推測したものを( )で表示しています。(※たまたま通らなかっただけかもしれませんし、故障やメンテナンスで切り離されていたのかもしれません。)
20150309_01

次に、 重複メッセージの除去(Exchange Online) で紹介している過去一定期間に受信したメールの重複チェック用のデータですが、これは各メールボックスストアごとに保存されており、メンテナンスや故障対応などのためにデータベースのActiveが別のサーバに切り替わるとリセットされます。

以下、3/4以降のメールについて、最後のReceivedヘッダの記録されているサーバ(つまり、メールボックスのストアされているサーバ)と時刻のリストです。24時間ではない間隔で来ているメールはそれぞれ短時間(数十分)の間SG2~→SIX~に切り替わり、切り戻りが発生しており、メンテナンスで同一データセンター内でActiveが切り替わったと推測されます。

  • Mar 4 16:07:39 JST 2015: SG2PR03MB0539.apcprd03.prod.outlook.com
  • Mar 5 16:08:08 JST 2015: SG2PR03MB0539.apcprd03.prod.outlook.com
  • Mar 6 16:08:36 JST 2015: SG2PR03MB0539.apcprd03.prod.outlook.com
  • Mar 7 01:23:47 JST 2015: SIXPR03MB0541.apcprd03.prod.outlook.com
  • Mar 7 01:58:48 JST 2015: SG2PR03MB0539.apcprd03.prod.outlook.com
  • Mar 8 01:54:17 JST 2015: SG2PR03MB0539.apcprd03.prod.outlook.com
  • Mar 8 22:39:42 JST 2015: SIXPR03MB0541.apcprd03.prod.outlook.com
  • Mar 8 22:54:42 JST 2015: SG2PR03MB0539.apcprd03.prod.outlook.com

Activeが切り替わった場合でも、OutlookからExchange Onlineへの接続は透過的に行われていますので、ユーザーが気づくことは少ないかと思われます。

サイト障害を考えると、シンガポール、香港ともに2つずつはメールボックスDBを配置するのが必要だと思いますので、HK2~、HKX~のどれかにもPassiveが存在しており、最低、平常時は1 Active – 3 Passive以上の冗長性は確保されているものと思われます。更に運用によって(すぐにオンラインに戻す必要はないと前提で運用設計する場合)はDC内に2つ以上のPassiveを構成している可能性もありますね。

 

また、これらのユーザーの所属するサーバ群はたまに変わるようです。 (私のメールボックスは、2/6のAM6:00-7:00頃に HK2PR03MB0833 から切り替わっています。)

これは、オンプレミスで利用するのと同じで、それぞれのユーザーの利用量や負荷についてはバラツキがあり、これを解消する為のリバランス処理や障害対応(主に、検索インデックス関係)が多いと思われます。

Outlookを便利にするアドイン紹介③

今回は、利用者側が便利、というよりは管理者よりの便利機能になりますが、誤送信対策を提供するアドインの紹介です。

そもそも、Exchange/Outlookは標準で誤送信対策に役立つ機能がいくつか備わってますが、それでは万全ではないと考える組織向けになります。欧米では免責事項を文末に付けておけば十分とされている部分も多大にありますが、日本は少し厳しめですね。

Office 365 に標準装備されている電子メールの誤送信防止機能 5 点 

いくつか出てますが、今回は試用版がVectorからダウンロードできるWISE Alertを紹介します。

インストール自体は、インストーラーを実行すると簡単に完了します。
スクリーンショット (161) スクリーンショット (162) スクリーンショット (163) スクリーンショット (164) スクリーンショット (165)

 

なお、Chromeからダウンロードしようとすると警告メッセージがでてしまうので、IEからダウンロードした方が良いかもしれません。
スクリーンショット (166)

 

Wise Alertの基本機能は、①メール送信時の確認画面のポップアップ ②自動メール遅延送信の2つです。メールを送信すると、自分が送信しようとしたメールの宛先や添付ファイルに誤りが無いかどうかを確認する画面がポップアップします。
20150305_02

この画面の表示条件は設定により変更することができます。添付ファイルが有る場合、外部ユーザーが存在する場合など、比較的よく利用するパターンで条件付けをすることが可能です。
20150305_03 20150305_04

デフォルトでは10分の送信待ち時間が設定されていますが、その場合10分間はOutlookの「送信トレイ」に残っている状態になりますので、そこから削除や編集などをして取り消しすることができます。
スクリーンショット (168)

 

他にも、有名どころではCipher Craft/Mail(Outlookアドインタイプ) などがありますが、企業情報を登録しないと試用版をお出しできないということで、こちらはまた機会があれば紹介させて頂きます。

 

Outlookを便利にするアドイン紹介②

前回の投稿に引き続き、Outlookを便利にするアドインを紹介させて頂きます。

Exchange Onlineは、マルチドメイン/マルチアドレスに対応しており、一人で複数のサブアドレスを持つことができます。ただし、これらは基本的に受信専用のアドレスであり、送信時に利用されるのはプライマリアドレスと呼ばれる代表アドレスのみになります。

これらを回避するため、配布グループや共有メールボックスなどを作成し、送信者アクセス権を割り当てることにより任意のアドレスから送信できるよう運用対処することがあるのですが、…正直面倒ですよね。

という訳で、それを解消するのがこのProxy Managerです。$29.99と有償の英語のソフトウェアですが直感的なインターフェイスですので恐らく誰でも利用できると思います。インストールはダウンロードしてきた.msiファイルを実行するのみで完了します。
20150303_13 20150303_14 20150303_15 20150303_16 20150303_17 20150303_18 20150303_19 20150303_20

インストール完了後にOutlookwp起動すると、 [Send Using Proxy Addresses]というプルダウンメニューが表示され、サブアドレス含めたアドレス一覧が表示されますので、ここで送信元として利用したいアドレスを選択します。
20150303_21 20150303_22

初回のみID/PASSを設定する画面が表示されますので、こちらにOffice365のID/PASSを入力します。また、Emailアドレスの前の表示名も変更したい場合はこちらの画面で[Names]を変更します。
20150303_23

到着したメールは、以下の様に送信者の部分に先ほどの電子メールアドレスと表示名が記載されています。また、購入前の場合はフッタに購入情報が記載されます。表示や操作について問題無いと確認してから、購入すれば良いと思います。
20150303_24

 

購入はメールのリンクから実施します。ライセンスキーが発行されたら、[Proxy Manager Options]の左下の[Register]ボタンから入力して完了です。
20150303_25 20150303_26

 

複数のユーザーやプロダクトを兼任している窓口業務などの返信用にお勧めいたします。

 

Outlookを便利にするアドイン紹介①

Office365を利用する場合、メールクライアントはOutlookを利用されることが多いと思います。今回は、私が今利用させて頂いている便利なOutlook2013用のアドインを2つ紹介させて頂きます。

まずは、Office365勉強会で紹介を頂いたのですが、二宮さんの作成されたOutlook添付ファイルツールです。

仕事柄、スクリーンショットやログを取得して、それを添付ファイルとして送信する事が多いのですが、そのたびにペイントやメモ帳を開いて、クリップボードから貼り付けて、名前を付けて保存して、パスワード付きZIPにして送付とかしていたのですが、この作業をOutlookのウィンドウを閉じることなくその上でやってしまおうというのがこのツールです。

インストールすると、メールの作成画面の中に添付ツールのタブが現れます。
20150303_01

ここで、[保存]をクリックすると、ファイル名を入力するとクリップボード上の情報がファイルとして保存されます。クリップボード上の情報のタイプによって、ファイルフォーマットは.txtや.pngと自動で識別されます。芸が細かい!
20150303_02  20150303_03 20150303_04

[圧縮して追加]とすると、名前を付けたファイルをそのままZIP化した物を追加してくれます。パスワード無しで送る場合などはこれでそのまま送ってしまえば良いですね。
20150303_05 20150303_06 20150303_07

[添付を圧縮]で、複数の添付ファイルを圧縮したり、パスワード付きZIPにしたりできます。[パスワードメール作成]をクリックすると、先ほどの画面で入力したファイル名とパスワードを引用してそのままパスワード通知用のメールを生成してくれます。
20150303_08 20150303_09 20150303_10 20150303_11 20150303_12

取得した情報を送るまでの一連の流れを、Outlookのメール作成画面の中で完結できるのでとても作業効率が向上しますね。皆さんも是非お試し下さい。

Outlook添付ファイルツール – Vector

 

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時間に変わったということでしょうか!?

続きはこちらの記事

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

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