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

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

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

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

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

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

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

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

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

• 関連記事
  • Outlookを便利にするアドイン紹介③　【Wise Alert（誤送信対策）】
  • Outlookを便利にするアドイン紹介②　【Proxy Manager(送信元アドレス変更）】

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

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

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

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

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

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

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

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

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

• 関連記事
  • Outlookを便利にするアドイン紹介③　【Wise Alert（誤送信対策）】
  • Outlookを便利にするアドイン紹介①　【Outlook添付ファイルツール】

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

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

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

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

インストール自体は、インストーラーを実行すると簡単に完了します。

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

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

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

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

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

• 関連記事
  • Outlookを便利にするアドイン紹介②　【Proxy Manager(送信元アドレス変更）】
  • Outlookを便利にするアドイン紹介①　【Outlook添付ファイルツール】

注：この投稿は検証結果を元にした推測の部分を多大に含みます　今回は、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の中では、主に以下の様な流れで記録されています。

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

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

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

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

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

次に、 重複メッセージの除去（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 から切り替わっています。）

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

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

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

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

• 同一の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）

皆さんこんにちは。

年度が切り替わって、心機一転新しいことに取り組まれて頑張っている方も多いのではないかと思います。

Office 365も、常に進化するクラウドサービスですので今年度もどんどん新しくなっていきます。特に、今年はOSとOfficeの新しいバージョンが発表される年でも有り、大きな変化が予想されます。

今日は、Office 365の管理者の皆さまが2015年度に考えていくべき事について述べていきたいと思います。

①メジャーバージョンアップ（2013→2016）への対応

今までのOffice 365は、オンプレミスのプロダクト（Exchange/SharePoint/Lync）でいうと2013のバージョンでした。Microsoftも言っているとおり、「クラウドファースト」になりますので、今年はこれらのバージョンアップ（2016?）が予定されます。

既に一部発表されている通り、サーバーサイド（LyncはSkype for Businessに名称が変わりますが）もクライアントサイドのOfficeも2016ベースに切り替わります。Office Pro Plusで導入している場合、アップグレード猶予期間は1年間なので、計画的に進めていきましょう。

②更改の準備を進めましょう

Office 2010は2015/10/13にメインストリームサポートが終了します。終了後はアクセスはできますが、今でいうOffice 2007やIE9と同じような扱いになり、新しい機能の利用などへの制約事項が増えていきます。

Office 365 のシステム要件
Office 365 では、Office 2007 でのサービスの使用に関する問題を解決するコード修正は提供されません。ユーザー エクスペリエンスの質が次第に低下し、Office 365 の新しいエクスペリエンスの大部分がまったく機能しなくなります。

また、クライアントだけでは無く、サーバサイドでも既に延長サポート期間に入っているWindows Server 2008 R2やExchange Server 2010をオンプレミスで連携に利用している場合、今後のサポートのアナウンスに注意しましょう。

③日本リージョンへの移行

現在APACリージョン（シンガポール/香港）に展開されている日本のユーザーは、日本リージョン（東日本/西日本）に移行が実施されます。移行したくない場合は、移行の案内が来た場合にその旨を通知する必要があります。

また、移行は極力影響の無いように実施されるとの事ですが、実際やってみないと何が起きるか分からないという部分もあるかと思います。現在、先行ユーザーが実テナントで移行を試行して影響などを調査していますが、今後、例えば移行時期におけるサービスの一部制約等が発生する可能性もありますので、継続的に情報収集しましょう。

④単一プロダクトや社内の特定環境からだけ利用という考え方についてそろそろ再考を

Office 365の新しい機能（Delve、Group）や統合的な電子情報開示などを見ても分かる通り、段々とOffice 365は「Exchange(Messaging)」「SharePoint(Collaboration)」「Lync(Communication)」という個々のソフトウェアではなく、企業の生産性を向上(Productivity)させる製品群という考え方で全体で一体的に開発/向上させてます。

加えて、Office 365は「いつでも、どこでも、どんな端末からでも同じ情報にアクセス」できることをコンセプトに作られてます。最近、iOSやAndroid向けのモバイルアプリも多数開発されていっており、BYOD環境に適合できるようMDMの機能も取り入れていくと発表されてます。

エンドユーザーでも、そのMicrosoftの考え方を取り入れ、業務に導入し、結果的に生産性を向上させていっているという先行事例がどんどん出てきています。今までの使い方（というかポリシーのレベルかも知れません）を変えるというのは、非常に労力のかかることではありますが、折角クラウドを導入したのですから、競合他社に遅れを取らない為にもどんどん使いこなしていきましょう。

⑤為替レートの推移

Office 365は、昨年度円安の影響で日本市場で値上げが実施されました。ただ、値上げが発表された時期はまだ1$=\110程度の時期で、その先更に円安は進みました。

例えば、E3の値段($20)が\2,180に設定されているという事からも想像できる通り、現在の値段の想定円レートは現在の為替相場よりかなり円高になってます。このままの円安基調で推移した場合、更なる価格改定も考えられますので、2016年度の予算取りの時期が近づいてきたら円レートを少し気にするようにすると良いかもしれません。

という訳で、2015/05/16 Japan Office365 Users Group主催の第11回 Office 365勉強会で上記の事などを話したいと思います。

今回は新年度ということもあり、テーマは「Office365新任管理者さん　いらっしゃ～い」です。各分野の著名な方に喋って頂こうと思ってます。新しくOffice 365と付き合うことになった方にも、勿論昔からのユーザーの方にも為になる内容になるように、スピーカー一同頑張って内容を考えている所です。

お時間の許す方、是非ご参加下さい。

Office 365の導入を検討しているユーザーから良く聞かれることの一つに、「会社のネットワークの中からだけOffice 365が利用できるようにできるか」ということがあります。

Microsoftやベンダの立場としては「AD FSで制御できます」と答えるべき所だとは思うのですが、この時点でのこの回答は正しくも有り、そして間違ってもいます。私は、そういった場合「AD FSで認証に関する制御を行う事ができますが、それで要望されていることを満たすかどうかはお客様の要件次第です」と回答しています。

これは、AD FSを利用したOffice 365へのアクセスの仕組みが、「認証」「認可」に役割が分かれていることに関係します。AD FSは「認証」を行い、Office 365（の各アプリケーション：例えばOneDrive for Business）は「認可」を行います。

AD FSでは、認証を行う時にID/PASSが合っているということの他に、条件を付けることができます。例えば、今回のケースでは「アクセス元が社内ネットワークからである」というという条件を加えることができます。これにより、インターネットからのアクセスでは「認証」されることがないので、Office 365の利用を制御できることができます。

これなら要件が満たせるのでは？ということになりますが、これは1つ観点が抜けています。Office 365では、AD FSで認可を受けてきているということは認識してますが、それがどういった条件の下で認可を受けてきたかどうかは情報として要求しておらず（アカウント名とImmutableIDというユーザーを一意に識別する特別な符号のみ）、認識しません。この為、今アクセスしてきているユーザーのアクセス元が社内ネットワークからであるかどうかは分からないのです。

具体的に言うと、一度社内ネットワーク内でAD FSで認証し、Office 365にアクセスした後に、そのままの状態（例えば、ブラウザを開いたまま）でその端末を外に持ち出した場合、アクセスが一定期間継続できてしまうのです。

これでどの程度の期間アクセスが継続できるのか（再度認証が必要になるのはどういった条件か）というのはOffice 365側で決められているので、AD FS側で制御することができません。タイトルに戻るのですが、OneDrive for Businessのスマートフォン用アプリでは、私が試した限り一度AD FSで認証をかけるとその後AD FSに認証されるというケースはほぼ無いように見えます。（常時接続するので、アイドルタイムアウトしない為ではないかと思いますが）

従来の考え方ですと、そもそも社内端末を社外に持ち出して使うこと自体認められていないので問題ないという形になったのかもしれませんが、今後BYODやスマートフォンなどからの利用が進んでいくと、端末が社内NW、社外NWと行き来したりするというケースは普通に出てきます。

こういったケースが併用される環境では、IPアドレスをベースにしたアクセス制御よりはMDM（モバイルデバイス管理）などで端末単位での認証をしていく方が現実的になっていくのかもしれませんね。

全ユーザーの予定表の権限を変える場合、ユーザーの言語設定やOWAログオンの有無などによって、設定をするべきフォルダ名が username:\Calendar になったり username:\予定表 になったりします。

これって結構スクリプト化する上では悩みの種なんですよね。

仕方が無いので、[予定表]で設定できなければ[Calendar]だろうと決め打ちしてスクリプトを作ったりするケースがよく有ります。例えば、全ユーザーのCalendarもしくは予定表フォルダの権限をReviewerに変更する場合、

$mbxs = Get-Mailbox -RecipientTypeDetails UserMailbox -ResultSize Unlimited
foreach ($mbx in $mbxs){ 
  $alias = ${mbx}.alias
  try{ Set-MailboxFolderPermission -Identity "${alias}:\予定表" -User "default" -AccessRights Reviewer -ErrorAction Stop }
  catch { Set-MailboxFolderPermission -Identity "${alias}:\Calendar" -User "default" -AccessRights Reviewer -ErrorAction Stop }
}

とやったりしますが、微妙にこれでもエラーになってしまう場合が有って、例えば中国語など別の言語圏のフォルダ名になってしまっている場合や、フォルダ名の破損・重複などで[予定表1]などがデフォルトの予定表フォルダとして指定されてしまっている場合です。

中国語とかならともかく、[予定表1]とかはさすがに分からないですよね…。こういった場合、いくつか方法はありますが、私の場合は Get-MailboxFolderStatistics を利用します。これは、ルート以下のそれぞれのフォルダのアイテム数や格納サイズを出してくれる物ですが、この中に FolderType という属性があり、それが Calendar の物が予定表のフォルダ名です。

あとは、このIdentityの値が [ユーザ名\フォルダ名] の形式なので、Set-MailboxFolderPermissionの指定形式 [ユーザー名:\フォルダ名] に変換すれば大丈夫です。

$mbxs = Get-Mailbox -RecipientTypeDetails UserMailbox -ResultSize Unlimited
foreach ($mbx in $mbxs){
  $alias = ${mbx}.alias
  $path = (Get-MailboxFolderStatistics $alias | ? {$_.FolderType -eq "Calendar"}).Identity -replace "\\",":\"
  Set-MailboxFolderPermission -Identity $path -User "default" -AccessRights Reviewer
}

スクリプトを作っていく上では、「英語か日本語以外に設定している人がいないだろうから…」という思い込みで作るのでは無く、こうしたエラーを引き起こす原因となる例外の発生確率を少しでも減らす努力をしていくと、最終的に管理者の負担軽減に繋がるのではないかと思います。

Sonyから、待望のフラッグシップモデルのスマートフォンXperia Z4が発売されました。

今回は、スマートフォンを利用する上で一番よく利用すると思われるExchange Onlineの設定方法を紹介します。

Exchange Onlineに接続するには、標準の「Eメール」アプリケーションを利用します。[開始する]を選択すると、アカウントの設定画面が開きます。
 

ここで、Eメールアドレスとパスワードを入力します。

【注意】ここでは、[手動セットアップ]を選択します。

[次へ]を押して自動セットアップを行っても自動的にサーバ情報を取得してアカウントが設定できるのですが、IMAPを利用したプロファイルになってしまい、メールの送受信はできますが、それ以外の機能やサーバ側でのポリシー管理ができなくなってしまいます。

手動セットアップを選ぶと、アカウントの種類を選択する画面になります。ここれは、[Exchange ActiveSync]を選択します。

ドメイン\ユーザー名と表示されている部分は、\に続いて先ほど入力したメールアドレスの@の前の値が入っていますので、Office 365にログインする際に使っているUPN（ユーザー名＠ドメイン名）の形式のアカウント名を入れます。また、サーバは@の後の値が入っていますので、ここを手動で[outlook.office365.com]を入力します。入力が完了したら、[次へ]を押します。

スマートフォンの制御をアプリケーションに許可するので、[OK]をクリックします。

アカウントの基本設定を行います。プッシュ通知（常時接続）かつメモを除く全ての情報が同期されるように設定されてますので、必要に応じてこのデフォルトの値を変えます。

作成されたアカウントのプロファイルに識別用の名前を付けます。

最後に、Office 365のポリシーによって制御することのできる操作の権限の許可（いっぱい有ります）を確認して[有効にする]をクリックします。まあ、リモートワイプができるくらいなので基本は全ての制御権限をOffice 365に渡すと思った方が良いと思います。

これで設定は完了です。良いOffice 365ライフを！

Windows Server 2012 R2に搭載されているAD FS 3.0も、だいぶ導入が増えてきたように思えます。最初の方に導入された方は導入から1年経過してSSL証明書の更新などを迎えられているユーザーもいらっしゃるかと思います。

今回は、あまり公開されている情報も無く、トラブルも多く聞かれているので、AD FS 3.0のSSL証明書更新についてまとめていきたいと思います。（なお、こちら基本的には以前勉強会で実施したLT「ADFSの証明書入れ替えではまった話」をブラッシュアップした物になります）

まずは、AD FSならびにWeb Application Proxyの各サーバに新しい証明書をインポートします。Windows Server 2012 R2から、AD FSの動作にはIISは利用されなくなったので必要に応じて別の環境で作成してエクスポートした物を利用します。

基本的にはローカルコンピュータにインポートして、インポート先を自動的に証明書ストアを選択するとしておけば、MMCで確認すると[証明書（ローカルコンピュータ）]-[個人]-[証明書]に表示されると思います。

これで準備は完了です。

1.AD FS #1のSSL証明書更新（Set-AdfsSslCertificate）

AD FS#1（AD FSファームを構成しているプライマリ機をAD FS#1と便宜上表記します）において、PowerShellを起動します。

まず、新しい証明書のThumbprintを取得します。調査方法は色々ありますが、オフィシャルで案内されている証明書管理ツールからだとスペースが入ったりして面倒なので、dir（これはGet-ChileItemのエイリアスです）コマンドで表示してしまうのが一番楽です。有効期限や発行元などの情報を元に、新しい証明書を特定してThumbprintをメモ帳などにコピーします。

Get-ChildItem cert:\LocalMachine\My\ | FL

続いて、こちらの情報を指定してSet-AdfsSslCertificateコマンドレットを実行します。この瞬間、AD FS#1の通信は新しい証明書に切り替わりますので、テストクライアントにHostsを設定するなどして、切り替わり後の証明書に問題がないことはこのタイミングで見ておいた方が良いでしょう。

Set-AdfsSslCertificate -Thumbprint 新しい証明書のThumbprint

このコマンドは、主にAD FS管理ツールによって実施されない2つのことを実施しています。特に後者の方は手動でやると面倒なので、コマンド 1発で済ませられるのは便利ですね。

• SSL証明書のバインドの変更（手動の場合netshコマンドで変更する）
• SSL証明書の秘密鍵に対してAD FSサービスがアクセスできるよう権限設定を行う（手動の場合証明書管理ツールから変更する）

いきなり証明書を切り替えるのには若干違和感はありますが、1番の工程より先に3番の工程を実施した場合、セカンダリ側のAD FSで秘密鍵へのアクセス権限の問題でAD FSの133番のエラーが出ます。

2.AD FS#2以降のSSL証明書更新（Set-AdfsSslCertificate）

同様の操作を、AD FS#2（#3や#4などがある場合はそちらも）についても行います。

3.AD FS#1でAD FSのサービス通信証明書の変更（Set-AdfsCertificate -CertificateType Service-Communications）

続いて、AD FSのサービス通信証明書を変更します。従来でいうSSL証明書の入れ替えの作業の工程です。GUIから実施してもいいですが、せっかくWindows Server 2012 R2の環境なのでPowerShellから実施してみます。

Set-AdfsCertificate -CertificateType Service-Communications -Thumbprint 新しい証明書のThumbprint

ファーム内の各サーバでAD FSサービスを再起動するように指示がありますので、順に行います。

4.AD FS#1でAF FSサービスの再起動

最初にプライマリを実施します。

5.AD FS#2以降でAD FSサービスの再起動

続いてセカンダリ。セカンダリは5分おきにプライマリに設定変更をポーリングしてますので、念のため5分程度待ってから実施します。

これで基本的な項目は完了です。

6.全AD FSでKB2973873の再対応

Lync MobileなどからAD FS接続ができないという問題（KB2973873）のために、netshでSSL証明書のバインドを手動で修正している場合は、こちらの方はSet-AdfsSslCertificateコマンドレットでは差し替えてくれないので手動で差し替えます。

コマンドは最初に設定した際と同じくnetshコマンドで行いますが、上書きができないので削除～再指定を行います。AD FSのAppidは確認した限りでは固定の様ですが、エラーが出たら上記のKBをご確認いただき適宜修正下さい。

netsh
HTTP
DELETE SSLCert IPPORT=0.0.0.0:443
ADD SSLCert IPPORT=0.0.0.0:443 Certhash=新しい証明書のThumnbprint Appid={5d89a20c-beab-4389-9447-324788eb944a}

7.Web Application Proxy #1のSSL証明書更新（Set-WebApplicationProxySslCertificate）

続いて、WAP（旧AD FS Proxy）側に移ります。こちらもまずは各コンピュータのSSL証明書の差し替えから入ります。コマンドレット名が変わりますが基本的には同じです。

Set-WebApplicationProxySslCertificate -Thumbprint 新しい証明書のThumnbprint

8.Web Application Proxy #2以降のSSL証明書更新（Set-WebApplicationProxySslCertificate）

7番と同様です。

9.Web Application Proxy のアプリケーションの設定更新

Web Application Proxyで公開されているアプリケーション（通常はAD FSのみになりますが）について、外部証明書として設定されている証明書を差し替えます。Set-WebApplicationProxyApplicationに必要な引数はGUIDで入力が面倒なので、Get-WebApplicationProxyApplicationしたものをそのままパイプしてしまう方が楽ですね。

Get-WebApplicationProxyApplication | Set-WebApplicationProxyApplication -ExternalCertificateThumbprint 新しい証明書のThumnbprint

10.全Web Application ProxyでKB2973873の再対応

6番と同様の工程をWAP側でも実施します。

という訳で、今回はAD FS 3.0のSSL証明書の入れ替えについてご紹介しました。IISが無くなった分、AD FS 2.0と比較して少し面倒ですが、手順さえ確立できれば後は作業です。

それにしても、AD FSは証明書関係は色々ありますね…、鬼門でしょうか。

関連記事： ADFS証明書の更新について （2008 R2の際の記事になります）

複数台のAD FSにおいて冗長化を行う場合、AD FSファームを構成して冗長化を行います。

今回は、運用中においてサーバの障害やメンテナンスなどでAD FSファームのスイッチオーバーが必要になる際の手順などについて書きたいと思います。

まずは、おさらいとしてAD FSファームについて記載します。AD FSは、1台のプライマリAD FSサーバと複数台のセカンダリAD FSから構成されるAD FSファームを構成できます。

AD FSファームを構成すると、セカンダリは自身のデータベースに対する直接の書き込み（設定変更）を禁止し、指定したプライマリサーバからその情報を同期します。デフォルトでは、300秒（5分）に1度その設定をポーリングします。

Windows Server 2012 R2のAD FSファームは、証明書利用者信頼（Relying Party trusts）が5以下の場合は最大10台、それ以上の証明書利用者信頼の場合は最大5台のAD FSサーバでの構成がサポートされます。

Office 365のみを利用する環境であれば、「Device Registration Service」「Microsoft Office 365 Identity Platform」の2つが証明書利用者信頼として登録されることになりますので、10台で構成すれば10万を越えるような大規模な環境でも理論上は構成できることになります。（実際の環境では、DR環境にある別のデータセンタのAD FSサーバの台数も含めての台数になるので、もう少し収容ユーザー数は少なりますが）

また、構成可能なオブジェクト数は要求プロバイダー信頼と証明書利用者信頼で最大100がサポートされています。実環境としては使い切ることは無さそうですね。

さて、こんなケースを考えてみます。プライマリ AD FSのfs01が故障しました。復旧までにはかなり時間がかかる見込みです。この状態でも、ユーザーからfs02への認証要求は通常通り継続できますので問題は無いのですが、fs02はセカンダリなので設定変更などのオペレーションを実施することができません。

AD FSの設定変更を可能にするために、fs02をプライマリに昇格させようと思います。

fs02をプライマリに昇格させるには、fs02でPowerShellを起動して、以下のコマンドを実行します。

Set-AdfsSyncProperties -Role PrimaryComputer

前述の通り、クラスターなどとは違ってAD FSファームのプライマリやセカンダリはDBの同期のためだけに利用されている物になりますので、これだけで完了します。

続いて、fs03など更に別のセカンダリが存在している場合は、今までfs01に向けてポーリングしていた物をfs02からポーリングするように設定する必要があります。fs03などでプライマリのFQDNを指定した以下のコマンドを実行してポーリング先を変更します。

Set-AdfsSyncProperties -PrimaryComputerName fs02.contoso.com

これで、fs02へのプライマリの役割のスイッチオーバーが完了です。

さて、この状態でようやくfs01の故障対応が完了してサーバが立ち上がってきたとします。fs01の設定は以前のままになりますので、立ち上がってきた状態は以下の感じになります。

このままスイッチバックをすると、fs01は故障発生前の古い情報のままになってしまいますので、まずはfs02のセカンダリとして設定して情報が同期されるのを待ちます。

Set-AdfsSyncProperties -Role SecondaryComputer -PrimaryComputerName fs02.contoso.com

最後に、fs01に再度スイッチバックを行います。

<fs01>
Set-AdfsSyncProperties -Role PrimaryComputer

<fs02>
Set-AdfsSyncProperties -Role SecondaryComputer -PrimaryComputerName fs01.contoso.com

<fs03など>
Set-AdfsSyncProperties -PrimaryComputerName fs01.contoso.com

AD FSファームの仕組み（静的なDB同期）が分かってしまえば挙動については比較的単純なのでご理解頂けると思います。

Microsoft MVPアワードをOffice 365の技術分野において再受賞しました。

（MVPアワードについて知りたい方はこちら）

初受賞が2012年になりますので、4年連続で頂いた形となります。これも、Office 365勉強会に来てくれた参加者の方や本blogを読んで頂いた皆さま、Office 365コミュニティで情報交流をさせて頂いている皆さまのおかげだと感謝しております。

日本DCも開設され、Windows 10やOffice 2016、ExchangeやSharePointの新バージョンや周辺のオンラインサービスの拡充など、Office 365にとって更に重要な年になってくると思いますが、これからのOffice 365の普及やUsageなどの向上のお役に立てればと思います。

Exchange Server 2010で、ある日突然CASやメールボックスサーバがMSExchange ADAccessの2130,2102,2103など、いずれもドメインコントローラに接続できない旨のエラーが出てサービスが利用できなくなる事があります。

事象自体はOS再起動をすると治るのですが、たまに発生する割には、出る環境と出ない環境が決まっていて変だなと思って調査をしたのでそのメモを。

まず、この事象に陥ってもRDPでサーバに接続できます。でも、なぜかドメインコントローラに接続ができない、詳しく言うと、ドメインコントローラの名前解決のDNSに失敗します。nslookupでDNSサーバに接続しようとしても接続できません。

もっと調べると、この状態ですがTCPやICMPの通信には影響を及ぼさない（なのでRDP接続はできる）のですが、UDPでのみ通信ができないという状態だということが分かりました。

ここで、セッションの状態を見てみようとnetstat -anoを打ってみます。 

と、延々と続くUDPの待ち受けポート。どうやらこいつが原因のようです。TCPの動的ポート枯渇というのは497日問題で良く聞いた話ですが、UDPにも動的ポートがあります。どうやらこれが枯渇しているようです。

netstatの結果より調べたプロセスを特定します。タスクマネージャーを開き、必要に応じて更に列の選択でコマンドラインを表示させます。（w3wp.exeの場合、ワーカープロセスの特定に使います）

こちら場合によっていくつかケースがあるのですが、多くの場合はCASはOWAかExchangeServicesのIISのワーカープロセス、メールボックス（特にパブリックフォルダを有している）の場合はRPC Client Accessが多いです。

サービスの再起動か、ワーカープロセスの場合はIISマネージャーから、被疑アプリケーションプールのリサイクルを実施します。

これでしばらく待つとMSExchange ADAccessが自動的にドメインコントローラを見つけてくれ、動作が再開します。

そもそもの原因なのですが、どうやら上記を初めとする一部のExchangeアプリケーションが全ドメインコントローラに接続できないタイミングで、そのアプリケーションでリークが発生。UDPの動的ポートが掴みっぱなしになり、そのポートが徐々に溜まっていき、16000超の領域を全部埋め尽くすと、今回の様な事象になるようです。

確かに、検証環境でADが1台しかなかったり、複数台有ってもメンテナンスの時などに一定時間（例えば15分）とか開けずに1台目のドメインコントローラが上がってきたタイミングですぐに2台目を再起動するなどの運用をしている環境でたまに発生していました。

特に直す気配も無さそうなので、対策としては

1. 常時最低1台はMSExchange ADAccessからドメインコントローラに接続できているようにする
2. UDPの動的ポートの数を増やす
3. UDPのポート数を監視（1万くらいになったら対象プロセスを再起動）

とかになりますね。

昨年末ごろから、Exchange 2013の管理系の自作スクリプトが失敗する様になったという話を色々な所で耳にするようになりました。

Exchange Server 2013のコンソールからExchange管理シェルのプログラムを起動すると、黄色い字で「○○○（サーバ名）に接続しています／接続しました」と表示されます。

ただ、実際には別のサーバに接続しているケースがあります。例えば、下のスクリーンショットではmbxcas02ではなくmbxcas01に接続していることが、Get-ExchangeCertificateコマンドレットの実行結果からお分かり頂けると思います。

これは、Exchange Server 2013のCU 11から実装されたExchange管理シェル（EMS）の仕様変更に依るものです。

Exchange 管理シェルとメールボックスのアンカー設定

簡単に説明すると、今まではExchange管理シェルは接続した先のサーバにそのまま接続されていましたが、Exchange 2013 CU11からはCAS（クライアントアクセスサーバ）に接続した場合は自分のメールボックスの存在するメールボックスサーバ（メールボックスを持たないアカウントの場合は調停メールボックスの存在するサーバ）に接続するようになりました。

なので、ローカルサーバへのオペレーションだと思って実行しているコマンドは違うサーバに対して実行されてしまうことがあります。接続先のサーバが異なるADサイトに存在をしている場合、AD情報の同期タイミングも考慮しなければいけません。

なお、CASの役割がインストールされていないサーバ（メールボックスのみやエッジトランスポートサーバ）の場合は影響ありません。

基本的な対処策としては、例えば Get-ExchangeCertificate であればGet-ExchangeCertificate -Server (hostname)などとして、明示的に実行先のサーバを指定するようにするという形になります。

いままで通りでやりたい場合は、PowerShellを管理者権限で立ち上げたあと、

Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn

と実行すれば今までと同じ感覚で利用できますので、私なんかは.ps1スクリプトにしてデスクトップに置いておいてます。

先日の投稿の続編です。

Exchange Server 2013 CU11から、Exchange管理シェルの接続先が自身のメールボックスのサーバに変更になった旨告知がありました。

その後ですが、CU12の公開に合わせて以下のような告知がありました。

Exchange 2013 CU12 および Exchange 2016 でのリモート PowerShell のプロキシ転送時の処理

しかし、CU11 に実装された変更により、オンプレミス環境のリモート PowerShell では予想外の問題が複数発生しました。これらの問題について詳細にコードを見直した結果、CU11 に実装された変更を取り消し、Exchange 2013 CU12 のリリース時に従来のサーバー バージョンによるルーティングを使用するように戻すことになりました。

Oh, 色々とスクリプトを修正していたのですが…。

まあ、Microsoft側も速い判断で良かったと思います。ということで、CU12以降を入れれば元通りということになりました。

Office 365とオンプレミスのActive Directoryを同期させるツールは標準で「ディレクトリ同期（DirSync）」「Azure AD Sync（AADSync）」「Azure AD Connect（AADConnect）」の3つの種類があります。

予てよりAADConnectに統合する旨の情報は流れておりましたが、遂に今朝、古い同期ツールを利用しているユーザーに対して以下のようなメールが届きました。

利用の継続のためには、2017年4月13日まで（通知から1年）にAADConnectにアップグレードしろということです。

幸い、32bit版のサポート切れに伴う64bit版への移行の際と違い、Server OSの要件が変わらないのと、ディレクトリ同期ツール自体が3時間に1度しか同期せず、比較的サービス断を伴う作業がしやすいので、そこまで障壁は高くないですね。

公開情報は以下にありますが、こちらでも何か注意点など見つかったら報告します。

Azure AD Connect: Windows Azure Active Directory 同期 (DirSync) のアップグレード

Forefront TMGがサポート切れとなり、Microsoftが提供しているIISモジュールであるARR（Application Request Routing）を利用してExchange ServerのOWAやActiveSyncなどをインターネットに公開されている方も多いかと思います。

ある特定の環境下でARRを利用していると、ある時からARR上にSchannel 36871（内部エラー：10013）が記録され続け、そのままアクセスできない状態が続くことがあります。

10013のエラーコード自体は、サーバ側から返された利用可能な暗号化スイートの一覧にクライアント側で対応した物が無いという物なのですが、Schannelの設定はARRのクライアント側もExchangeのCASのサーバ側も同じに設定していますし、そもそも通常時は利用できているのでそういったことは無いのではと推測しました。

色々と検証したところ、以下のような事が分かって来ました。

• 発生する環境は、SSL3.0を無効化した環境
• 発生するタイミングは接続先のCASが起動してきたタイミング
• ヘルスチェックを有効化している環境もしくは、アクセスが多いタイミングで発生する可能性が高い
• 一度発生すると出続ける

以上のことから、Exchange Server側でIISが立ち上がりきる前にARRからアクセスし、TCPセッションの確立自体は成功したものの、その後のSSL通信の確立に失敗した為に発生。かつARRは都度セッションを張るのでは無く、一度張ったセッションを再利用し続ける仕様の為に発生している可能性が高いと思われます。

こちらを解消するためには、ARR側のOSを再起動しても勿論直りますが、一番簡単なのはARRのアプリケーションプールをリサイクルすることにより、完全に立ち上がったCASに対してセッションを張り直して貰うことです。

あとは、これを自動的に事象発生時に実行して貰うように、以下の様なスクリプトを作成してタスクスケジューラでイベントログをトリガーにして起動すれば自動的に復旧してくれます。

Import-Module WebAdministration
$SysDate = Get-Date -Format "yyyy/MM/dd HH:mm:ss"
$HostName = hostname

"$SysDate $HostName ARR Recovery Script Start" | Out-File C:\scripts\recovery_arr\recovery_arr.log -encoding default -append
$site = "Default Web Site"
$pool = (Get-Item "IIS:\Sites\$site"| Select-Object applicationPool).applicationPool
Restart-WebAppPool $pool
sleep 300

$SysDate=Get-Date -Format "yyyy/MM/dd HH:mm:ss"
"$SysDate $HostName ARR Recovery Script End" | Out-File C:\scripts\recovery_arr\recovery_arr.log -encoding default -append

このイベントログは発生すると大量に出続けるので、同時起動を無しに設定し、スクリプト中で5分間のwaitを入れていますが、この値は環境により調整して下さい。WebアプリケーションプールはDefault Web Siteのみの想定です。別の発生要因により直らなかった場合はアラートを出すなどの処理を加えても良いかもしれません。

既に満席になってしまっておりますが、6/1(水)の夜に株式会社ラック様の会議室をお借りしてOffice 365勉強会を開催します。

第15回 Office 365 勉強会 ～日本企業にとって必要なOffice 365のセキュリティ～

今回は動画配信は無しで、日本有数のセキュリティベンダであるラック様がパブリッククラウドであるOffice 365を利用するに至った経緯や苦労した点など、プレスリリースでは語れなかった深い部分まで聴かせて頂ければと思っております。

開催が迫ってまいりましたが、まだキャンセル待ちの方も多くいらっしゃいますので、参加ができなくなった方は忘れずキャンセルを入れて頂ければ幸いです。

以下の記事の対談をされていらっしゃるお二人に登壇をお願いしておりますので、事前に見られておくとスムーズに話が入ってくるかと思います。

【参考Web記事】
パブリック クラウドは危険? セキュリティのプロ、ラックの CTO に聞いてみた
【2分バージョン】セキュリティのプロはなぜパブリッククラウド Office 365 を選んだのか

6/25(土)に日本Microsoft品川本社で行われるInteract x Cloud Samurai 2016 Summerに登壇させて頂く事になりました。

タイトルは【オンプレミス x Exchange Server 2016 という選択肢】ということで、Exchange Onlineではなくサーバ製品であるExchange Server 2016について話をさせて頂きたいと思います。

Exchange Serverってそれなりにまだ出ているみたいだけど、普段なかなか勉強会で話を聴く機会がないよね…って話がありまして、誰も喋らないのであればじゃあ私が、ということで枠を頂きました。

内容としてはまだこれから考えていくのですが、なるべく具体的に、実際に役に立つ内容となるようにしたいと思ってます。今考えてる（というか、自分が聴きたい内容なのですが）トピックは、以下の感じです。全部喋れるかわかりませんが…。こういった事が聴きたいとかのリクエストもあれば是非御連絡下さい。

• Exchange Onlineとはどういった違いがあるの？
• 実際作るとどういったH/W構成になるの？
• 構築や運用で気をつけるべき所とかあるの？
• 価格はどれくらい？
• 2010とか2013とどう違うの？

お時間が許すようであればご参加頂ければ幸いです。

先日、Microsoftより以下のようなメッセージが示されました。

Azure ExpressRoute is not required or recommended for Office 365 except where mandated to use direct networking for regulatory purposes or where a network assessment for Skype for Business connectivity requires it

また、先日のde:codeのイベントのExpressRoute for Office 365関連の講演においても、しきりに「ExpressRouteはセキュリティ向上のためのソリューションではありません」というメッセージを出しており、少し自分的に違和感を覚えておりました。

今回はExpressRoute for Office 365と聴いてイメージする物と、実際のサービス導入後の構成のギャップについて少し整理したいと思います。

まず、標準のOffice 365の構成が下図の左側だとします。ExpressRouteでOffice 365に直接接続出来るようになると聴くと、何となく以下の問題が解決されるように思えます。（右側のイメージ）

1. インターネット上に機密情報を置くことへの不安
2. インターネットアクセスが急増することによる回線、NW機器やProxyサーバーなどのパフォーマンスの不安
3. インターネットアクセスのログのモニタリングやOffice365側のURL/IPアドレスの増減に対応する運用負荷に関する不安

確かにExpressRoute for Office 365を入れると、いくつかの問題点は解消されるのですが、実際にはいくつかの点でギャップが発生します。

簡単に纏めると以下の図上の3点になると思います。

まず、ExpressRoute for Office 365を利用しても、主にCDNから配信されてくるデータはインターネット経由でしか取得できないため、①ExpressRouteの他にもインターネット接続を必要とする という点がございます。これにより、インターネット接続経由でOffice 365の一部の通信は継続するため、その運用管理負荷は無くなりません。

また、ExpressRoute経由で接続するのはテナントではなくIPアドレス単位になる為、②他社テナントにもExpressRouteを経由して接続できてしまいます。構成によっては、自社の管理下にあるFirewallやProxyなどをバイパスして外部のクラウドに接続できてしまうことになります。

更に、ExpressRouteを契約しても接続元IPの制限ができるようになる訳では無いので、③ExpressRouteを経由しないインターネットからもこれまで通り利用できてしまいます。

勿論、②はSharePoint OnlineであればテナントごとにURL空間が異なるので、そこを意識して.pacファイルで制御するなどすれば、ある程度は制御できると思いますし、③はAD FSを入れれてクラウドIDの利用を制限すれば社外からの認証を抑制することもできます。

ただ、こう言ったFit & Gapを整理していくと、Azureとは違ってOffice 365にExpressRoute接続すべき（したい）シーンというのは、かなり限定されるのではと個人的に感じます。