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

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

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セッションを張るという挙動に見えます。

つまり デフォルトの制限値である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倍の速度でセッションが張られて処理速度が向上することになります。

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

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 から切り替わっています。）

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

皆さんこんにちは。

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

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などの向上のお役に立てればと思います。

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) のアップグレード

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

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

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

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

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

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

先日、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接続すべき（したい）シーンというのは、かなり限定されるのではと個人的に感じます。

おかげさまで、MicrosoftのMVPアワードをOffice Servers and Servicesの分野で受賞しました。
2012年にOffice 365で初受賞して以来、5年連続での受賞となります。

これも偏にblogやコミュニティ運営などでご協力を頂いている皆さまの応援のおかげと感謝しております。

これからもよろしくお願い致します。

今週の土曜日に品川の日本Microsoftで開催される第17回Office 365勉強会に登壇させて頂きます。

今回は、既に導入がかなり進んでいるということもあって、なかなか改めて話題に上がることも少ないExchange Onlineにスポットを当ててみようということで、Exchange Online特集になっております。

私のセッションでは、
「意外と知らない最近のExchange Online」
ということで、ここ数年で追加された、もしくは追加予定のExchange Onlineの新機能や仕様変更についてお話ししたいと思います。

お時間のある方は是非ご参加頂けると幸いです。

この投稿は Office 365 Advent Calendar 2016 に参加しています。

先日開催された第17回Office 365勉強会のセッション中においても少しお話をさせて頂いたのですが、Microsoftのパートナーの立場から言うと、既にOffice 365は機能やサービス内容の説明だけでは新規ユーザーがゲットできなくなってきました。（逆に言うと、それだけ導入が進んだ）

普段このblogでは技術的なことばかりを書かせて頂いておりますが、今回は少し趣向を変えて、どうやっていけば、これからもOffice 365でご飯を食べられるエンジニアでいられるのかを書いてみたいと思います。

一言でいうと、

Office 365を通じてお客様のワークスタイルを変え、生産性を向上させ続けられるエンジニア

かなと自分では思っています。ちょっと漠然としていますが、広い意味での「導入支援」ですね。ただ、単に技術的な要件に留まらず、これまでの経緯や周辺領域の動きと合わせて今後Microsoftがどういう方向にこの機能（サービス）を持って行こうとしているのか、どう使ったら生産性が上がると思って設計しているかなどを含め、自分の言葉で語れる人物。

例えば、思いつくままに書いてみますが、お客様への導入の中で出てくる以下の様なことが常に鮮度の高い情報を持って答えられる人かなと思っています。

• SharePoint/Groups/Exchange/Teams/Yammer/Skype for Businessなど、いっぱい有るけどどうやって使い分ければ良いの？
• サービスを導入したらインターネット接続環境はどういった物を用意すれば良いの？（帯域、セッション数、冗長性など）
• サービスに接続するクライアントは何を使えば良いの？シーンによって使い分けるとしたらどういう使い分け？
• アクセス制御はするべき？するならどこまですれば良い？
• うちの現在定めているセキュリティポリシーとの整合性はどう取っていけば良い？
• 監査はどういったことを何処までやれば良いの？事前に利用する社員と合意しておくべき項目はある？
• BYODを認める場合、その条件や取り交わすべき誓約書など、社内規程の整備はどう進めれば良い？
• 365日24時間仕事ができるようになってしまうが、業務時間外のメール等の確認に対して労使でどう合意すれば良い？
• 他の同業他社はどこまでOffice365を使いこなしてどう業務に活かしているの？
• セキュリティにはどこまでお金をかけてどのレベルまで取り組めば良いの？
• 社内で自立的に対応していけるようにする運用体制はどう作っていったら良い？

書いていてなんですが、自分も全然できていないので、もう少しアンテナ高くして頑張って精進していきたいです。

この投稿は PowerShell Advent Calendar 2016 に参加しています。

Facebookでリスクエストを貰ったので、PowerShellから全社員のメールボックスに創立記念日の予定を入れるPowerShellを作ってみたいと思います。

Exchangeでは、各種管理用のPowerShellコマンドレットが用意されておりますが、各ユーザーのメールボックスのアイテムを直接操作するコマンドは基本的には有りません。

ただし、EWS(Exchange Web Services)というAPIが用意されておりますので、そちらを利用する事によりメールボックスにアプローチできます。また、その際にアプリケーション偽装(ApplicationImpersonation)権限を利用する事により、「そのユーザーに成り代わって」そのアイテムを利用できます。

今回は、目的が明確ですので一番近いサンプルスクリプトとして以下のstack overflowに回答例として提示されているスクリプトを元に、作成用のコマンドを作ってみます。

How to import meetings into office365 (EWS and Powershell?)

変更している所は赤字で記載します。

function Create-Appointment
{
    [CmdletBinding()]
    param(
        [Parameter(Position=0, Mandatory=$true)] [string]$MailboxName,
        [Parameter(Position=1, Mandatory=$true)] [string]$Subject,
        [Parameter(Position=2, Mandatory=$true)] [DateTime]$Start,
        [Parameter(Position=3, Mandatory=$true)] [DateTime]$End,
        [Parameter(Position=4, Mandatory=$true)] [AllowEmptyString()] [string]$Location,
        [Parameter(Position=5, Mandatory=$true)] [AllowEmptyString()] [string]$Body,
        [Parameter(Position=6, Mandatory=$true)] [Boolean]$IsAllDayEvent,
        [Parameter(Position=7, Mandatory=$true)] [PSCredential]$Credentials
    )
    Begin
    {
        $EWSDLL = (($(Get-ItemProperty -ErrorAction SilentlyContinue -Path Registry::$(Get-ChildItem -ErrorAction SilentlyContinue -Path 'Registry::HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange\Web Services'|Sort-Object Name -Descending| Select-Object -First 1 -ExpandProperty Name)).'Install Directory') + "Microsoft.Exchange.WebServices.dll")
        if (Test-Path $EWSDLL)
        {
            Import-Module $EWSDLL
        }
        else
        {
            "$(get-date -format yyyyMMddHHmmss):"
            "This script requires the EWS Managed API 1.2 or later."
            "Please download and install the current version of the EWS Managed API from"
            "http://go.microsoft.com/fwlink/?LinkId=255472"
            ""
            "Exiting Script."
            exit
        }

        $ExchangeVersion = [Microsoft.Exchange.WebServices.Data.ExchangeVersion]::Exchange2010_SP2
        $service = New-Object Microsoft.Exchange.WebServices.Data.ExchangeService($ExchangeVersion)
        $creds = New-Object System.Net.NetworkCredential($Credentials.UserName.ToString(),$Credentials.GetNetworkCredential().password.ToString())
        $service.Credentials = $creds
        $Provider=New-Object Microsoft.CSharp.CSharpCodeProvider
        $Compiler=$Provider.CreateCompiler()
        $Params=New-Object System.CodeDom.Compiler.CompilerParameters
        $Params.GenerateExecutable=$False
        $Params.GenerateInMemory=$True
        $Params.IncludeDebugInformation=$False
        $Params.ReferencedAssemblies.Add("System.DLL") | Out-Null
$TASource=@'
  namespace Local.ToolkitExtensions.Net.CertificatePolicy{
    public class TrustAll : System.Net.ICertificatePolicy {
      public TrustAll() { 
      }
      public bool CheckValidationResult(System.Net.ServicePoint sp,
        System.Security.Cryptography.X509Certificates.X509Certificate cert, 
        System.Net.WebRequest req, int problem) {
        return true;
      }
    }
  }
'@ 
        $TAResults=$Provider.CompileAssemblyFromSource($Params,$TASource)
        $TAAssembly=$TAResults.CompiledAssembly
        $TrustAll=$TAAssembly.CreateInstance("Local.ToolkitExtensions.Net.CertificatePolicy.TrustAll")
        [System.Net.ServicePointManager]::CertificatePolicy=$TrustAll
        $service.AutodiscoverUrl($MailboxName,{$true})
        #"Using CAS Server : " + $Service.url
        $service.ImpersonatedUserId = new-object Microsoft.Exchange.WebServices.Data.ImpersonatedUserId([Microsoft.Exchange.WebServices.Data.ConnectingIdType]::SmtpAddress, $MailboxName)
        $folderid= new-object Microsoft.Exchange.WebServices.Data.FolderId([Microsoft.Exchange.WebServices.Data.WellKnownFolderName]::Calendar,$MailboxName)
        $Calendar = [Microsoft.Exchange.WebServices.Data.Folder]::Bind($service,$folderid)
        $Appointment = New-Object Microsoft.Exchange.WebServices.Data.Appointment -ArgumentList $service
        $Appointment.Start = $Start
        $Appointment.End = $End
        $Appointment.Subject = $Subject
        $Appointment.Location = $Location
        $Appointment.Body = $Body
        $Appointment.IsAllDayEvent = $IsAllDayEvent
        $Appointment.Save($Calendar.Id,[Microsoft.Exchange.WebServices.Data.SendInvitationsMode]::SendToNone)
    }
}

New-ManagementRoleAssignment –Name:EWSCalendarApplication -Role:ApplicationImpersonation –User:ews_user

続いて、PowerShellを実行するコンピュータにEWS Managed APIをインストールします。

PowerShellを開き、上記コードを実行し、Create-AppointmentのFunctionを登録します。

最後に、以下のコマンドを実行します。最初の行では実行アカウントのID/PASSを入力します。

$LiveCred = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $LiveCred -Authentication Basic -AllowRedirection
Import-PSSession $Session -AllowClobber

$results = Get-Mailbox -RecipientTypeDetails UserMailbox -ResultSize Unlimited | select WindowsEmailAddress

foreach ($result in $results){
    Create-Appointment -MailboxName $result.WindowsEmailAddress -Subject "創立記念日" -Start "2017/07/01" -End "2017/07/01" -Body $null -Location $null -IsAllDayEvent $true -Credential $LiveCred
}

これで、来年の7/1に終日イベントとして[創立記念日]が全ユーザーMBXに作成されます。

他にも、これを応用すれば会議室の利用状況を集計したり、役員の今日の予定の印刷用の元データを抜いたりできます。

また、このコマンドを行うには対象となるメールボックスが先に作成されている必要があります。メールボックスはNew-Mailboxコマンドなどで作成した時点では実体は作成されていません。ユーザー自身のログイン以外にも、以下の様な動作を行う事により作成されますので、エラーが出て登録出来ないメールボックスには試してみると良いでしょう。

1. メールの受信（例えば、メールの開通通知などの名目でテストメールを送る）
2. 受信トレイルールの作成（管理者がNew-InboxRuleコマンドレットで作成できます。ダミーのルールを作成し、すぐに消せば影響は無いと思います）

ディレクトリ同期ツールをAAD Connectにインプレースアップグレードする際、以下のような画面が出てアップグレードに失敗することがあります。

参照されるログファイルを確認すると、以下のエラーが記録されています。

[11:27:39.819] [ 18] [ERROR] PerformConfigurationPageViewModel: Caught exception while installing synchronization service.
Exception Data (Raw): System.Exception: Synchronization Service をインストールできません。詳細については、イベント ログを参照してください。 ---> System.DirectoryServices.AccountManagement.NoMatchingPrincipalException: Group 'FIMSyncAdmins' was not found.
 場所 Microsoft.Azure.ActiveDirectory.Synchronization.Framework.AccountManagementAdapter.GetGroupBySamAccountName(String groupSamAccountName)

FIMSyncAdminsグループが見つからないというエラーです。確かに、FIMSyncAdminsグループができたのはパスワード同期が実施できるようになった辺りのバージョンなので、ローカルには存在していませんでした。

グループが無いのがエラーの原因と記載されていますので、単純にメンバーは空で良いのでグループを作ってみます。（説明はMIISAdminから適当にコピーしましたが、無くても問題ないです）

これでインストールを行ったところ、問題なく実施ができるようになります。

ちなみに、FIMSyncAdminsグループにはオンプレミスのADとディレクトリ情報をやり取りするアカウント AAD_<nnnnnnnnnnnn>とAAD Connectのインストールに利用したアカウントがデフォルトでメンバーとして登録されます。

また、Microsoftから提示されている標準手順のうち、並列デプロイの方式を利用してもアップグレードは可能ですので、オブジェクトの数や作業の手間などを考えて、どうアップグレードするか決めるといいと思います。