バッチサーバー、Azure functions、LogicApps、Flowの違い

ひょんな事から kenakamuさんとお話しする機会があり、自分なりに整理できたのでメモ。

背景

Azure functionsにも慣れ「これがサーバーレスかー!おもろー!」とコードを書きまくって動かしていたところ、コードの行数が200行を超え、コードから呼び出すためにfunctionsにUPするモジュール(Azure Powershell)なども増え、コードとモジュールの管理が必要となる。「これってバッチサーバー上で動かしているのと、何が違うんだろう…?」と思ったのが、考えるきっかけです。

また、LogicAppsとFlowの違いを説明することが多いので、まとめようと思いました。

比較表

バッチサーバー Azure functions LogicApps Flow
料金 ○無料 ○無料 ×有料 ○無料
簡易さ ×コード ×コード ○GUI ○GUI
自由度 ◎自由 ○自由 △サービスの制約あり ×サービスの制約あり
時間制限 ○なし ×あり ○なし ○なし
基盤 ×IaaS ○PaaS ○PaaS ○PaaS
安定性 ○高 △中 ×低 ×低
権限 ○管理者 ○管理者 ○管理者 ×ユーザー

料金

LogicAppsはステップ毎に課金が発生。バッチサーバー、Azure functions、Flowはあえて”無料”と書かせていただきましたが、バッチサーバーはサーバー費用、Azure functionsは実行回数とCPU時間による課金、Flowは500回/日の回数制限があります。

ただ、ちょっと動かすだけならfunctionsとFlowは無料で使え、バッチサーバーも環境がある場合(ほとんどある)は、実質無料で使えます。

簡易さ / 自由度

LogicAppsとFlowはGUI、バッチサーバーとAzure functionsはコードで動かす必要がある。GUIの場合、設計書がなくてもある程度意味が分かるのが大きなメリット。つーかお客さんが設計書なしでもOKと言ってくれる。もちろん、作成の背景を記した要件定義書は残しておいた方がよいが…。一方、コードの場合、プログラムができない顧客に引き渡すとき & 自社管理用にプログラム設計書はほしい。GUIなら気軽に変更でき、それが設計書となることから、Logic Apps、Flowの方が、気軽にあれこれいじれるメリットはある。

その簡易さと引き換えにコードには自由度がある。バッチサーバーはIaaS環境を自分でいじれるので自由度◎、Logic AppsはAzure functionsと連携できるので自由度△としました。

時間制限

これはAzure Functionだけの制約で、1回の実行時間が5分(工夫すれば10分)となる。5分あればある程度の処理は出来るが…。一方他は実質時間制限なし。

基盤

バッチサーバーはIaaSとなり、基盤の再起動タイミングなどを考慮して設計することが必要。

安定性

LogicAppsやFlowは(実績ベースだと)起動に失敗し、うまく動かないことがある。一方、IaaS上でタスクスケジューラーやJP1で動かす場合、ほぼ確実にプログラムがキックする。…という意味で、こういう評価にさせてもらいました。Azure functionsの実績は手元にないので、とりあえず”中”にしました。

権限

Flowだけがユーザー権限であり、ユーザーが自分が出来る範囲のタスクをFlowで実装するもの。よってLogicAppsが元になっているとはいえ、自分ができないことはFlowにも出来ないです。(本当に抜け道がないか自分で確認したわけではないけど、設計思想はそう。)

なので「Flowでいろいろできちゃうかもしれないから、禁止しよう!」はナンセンス。まぁ中には、手動で私用のGmailにメールを送るのはいいが、自動転送はシステム的に禁止する、などのナンセンス運用の企業もあるが…。

管理者が実行するスクリプトのための比較表なので、〇管理者 / ×ユーザーとしてしまったけど、ユーザー権限だから逆にいいこともあり、一概には言えません。

ユースケース

Office 365 ライセンス付与、初期ユーザー設定バッチ

Office 365の運用ではほぼ確実に必要なバッチであり、サーバーレスの概念の登場前はバッチサーバーで動かしていたのがほとんどと思われる。これは引き続きバッチサーバーで動かした方がよいのではないか、と思えてきました。

まず、管理者業務なのでFlowは除外。1ユーザー毎に発行するコマンドが多く、LogicAppsで処理すると処理が長くなりそうな事。AzureADのユーザー属性によって処理内容を変化させる必要があり、分岐のパターンによってはコードで実装したほうがスマートであること。コマンドが通らなかった場合の、エラーハンドリングが必要なこと(例外処理が多い)など。

ログ監視バッチ

一定期間毎にクラウドサービスのログにアクセスしてデータをエクスポートする。これはコマンドは単純ですが、ログが大量の場合、APIからの戻り時間が不安なため、バッチサーバーで実行したほうがいいかもしれません。

使い分け基準

1. 管理者が実施するアクションか、ユーザーが実施するものか

これでFlowかそれ以外かを分けられます。

※ ただし、本来管理者が実施する業務だが、無料のFlowを使いたいため、システムアカウント権限でFlowを動かす方法はあり。”本来すべきではない”かもしれないけど。

2. タイマージョブか、そうではないか

もしタイマージョブ以外、例えばHTTPトリガーの場合、バッチサーバー上で動かすプログラムをHTTPトリガーで動かすのは面倒であるため、バッチサーバーは使わない方がよいと考える。

3. 短時間で終わるかどうか

もし5分以内に終わらない、あるいは終わらない可能性があれば、自動的にAzure functionsは候補から外れる。

4. ミッションクリティカルなアクションであるか

1度くらい失敗して、それに気づかなくてもよいかどうか。もしそれがNGなら安定性の高いバッチサーバー or Azure functionsで動作させるべきである。1回失敗しても、翌日に成功 or ユーザーリトライでOKだったらLogic Appsでよい。

5. Logic Appsの標準パーツで大半のフローを実現可能かどうか?

例えばExchange Onlineのユーザー設定は現状GraphAPIも用意されておらずPowerShellからしか行えないため、多数のコマンドを発行するならLogic Appsを使う意味は少ない。

6. 2~5で判断がつかない場合

タイマージョブで、そこそこ短時間で終わり、1回失敗しても翌日リトライすればOK、Logic Appsと2,3のAzure Functionsを組み合わせれば実現可能の場合。その場合にどの製品を使用するかは会社の開発ポリシーによります。例えば、Azure FunctionsはLogic Appsの部品としてのみ使用を許可、それ単体では動かさない、よって20行以上のコードを書くのは禁止する、など。

おそらく社内にコーディング規約的があるとすると1つの関数に実装する機能は1つまでなど、ある程度のポリシーがあるはずです。それと同じことをクラウド製品でも検討する必要があると思います。

まとめ

kenakamuさんがおっしゃっていたのは「なんでもできるからこそ、製品が生まれたニーズを知り、最適な使い方をする必要がある。」とのこと。

私自身、これだけサーバーレスだiPaaSだともてはやされていたとしても、コードを書いて、バッチサーバーで動かす方がいい場合もあると思いました。

Office 365 管理者アカウント 強制MFA機能(Baseline security policy)と対処法

最近がんばってるAzureADチームがナイスな新機能をリリースしてくれました。

Baseline security policy for Azure AD admin accounts in public preview! – Enterprise Mobility + Security

  • 全体管理者
  • SharePoint 管理者
  • Exchange 管理者
  • 条件付きアクセス管理者
  • セキュリティ管理者

上記権限を保有し、かつMFAが有効になっていないアカウントについて、強制的にMFAが有効になります。これらのアカウントをスクリプトで使用していたり、共用で使用している場合は、運用上支障が出ます。

対処法

その1. 機能を無効化する

この機能はプレビューであり、GAされた段階で強制MFAが発動します。それを防ぐためには以下画面で「ポリシーを使用しない」を選択します。

f:id:teraco:20180626231956p:plain

その2. MFAを有効にしないアカウントを選ぶ

MFAを使わないアカウントが整理できている場合、同じ画面から除外対象アカウントを指定できるので、MFAを有効にしないアカウントを指定します。

なお、他の選択肢として「全ての管理者アカウントでMFA有効化」がありますが、この設定を使用すると後述の通りスクリプトでの管理タスク実行に支障が出るため、現実的には「MFAを除外するアカウント指定」を使用するべきでしょう。MSも「全てのアカウントについてMFAを利用するのではなく、緊急用の管理者アカウントを1つはMFAをオフにする方法」を提示しています。

Manage emergency-access administrative accounts in Azure AD | Microsoft Docs

さらっとしか流し読みしてませんが、パスワード文字列を2つか3つに分けて、別々の人間が知るようにする、などが書かれています。

SIer的な立場として

こんなうざったい機能がリリースされたからオフにしちゃいましょうはアウトな気がします。今までは規定値がMFAオフだったので許されていたかもしれませんが、今後は規定値がオンなのをオフにするので…。

  1. SIerが明示的にMFAオフにする
  2. 結果、アカウントが乗っ取られる
  3. SIerが悪いんじゃね?

という話になりそうな気がします。最低限、説明責任を果たして、顧客の同意を取ってからオフにするべきでしょう。

推奨設定

といってもスクリプトで管理者アカウント使いたい!という人向けに推奨設定が出ていました。

Securely Administrate Exchange Online with Multi-Factor Authentication (MFA) – Microsoft Tech Community – 207160

対話的に使用する管理者アカウント

人間が非定形作業で使用するアカウントは(ちょっと面倒ですが)二要素認証を有効にします。Exchange Onlineの場合はこんな感じ

多要素認証を使用して Exchange Online PowerShell に接続する | Microsoft Docs

「俺はSecurePasswordでパスワードを暗号化してるんだ!」「パスワードも十分強力にしてるんだ!」「だから二要素認証なんて要らなんだ!」という方はご自由にどうぞ。

タスクスケジューラーなどで動かす管理者アカウント

夜間バッチなどに埋め込んでいるアカウントはMFAが使えません。つーかMFAオンにしているとバッチが動きません。なので仕方なくMFAをオフにするのですが、その場合は以下のように注意をしてください、とのこと。

  • RDPを禁止する
    • クラウドIDなら問題ないですね
  • 管理者作業に用途を限定し、メールなどは有効化しないようにする
    • 着信したマルウェアをクリックしちゃうと大変ですからね
  • 居力なパスワードをセットする
  • アカウントに対する監査ログを有効化し、定期的にチェックする
  • 社内IPからのアクセスに限定する
  • 管理役割を厳密に設計し、不要なコマンドレットの実行権限を外す
    • これはさすがにめんどくさい…。

将来的に

タスクスケジューラーで動かす管理者アカウントもセキュアに守りたいやん、ということで、Azure MSI(Managed Service Identity)という仕組みが勧められています。

What is Managed Service Identity (MSI) for Azure resources | Microsoft Docs

しかしながら現在はAzureの一部コマンドしか対応しておらず、Office 365的には使えないものになっています。なお私はAzure MSIの仕組みを詳しく理解していません。使わなきゃな。

余談:GraphAPI

同僚とこの件に会話していて「もしかしてGraphAPIで適切にアクセス権を振れば、MFA回避できるんじゃね?」という話題が出たので試しました。結果、GraphAPIでもMFAが効いたことをお知らせいたします(当然ですね)。一点注意として、強制MFA有効化前にトークンを取得していれば、継続してアクセスが可能であり、トークンの有効期限が切れた時点でMFAを求められ、スクリプトでのアクセスが不可になります。時限爆弾。

f:id:teraco:20180626232129j:plain

f:id:teraco:20180626232131j:plain

余談:MFAの実装方法とGA時期予想

KBの注意書きに、MFAが有効になった管理者アカウントは、POP/SMTP/レガシーのOutlookクライアントからもアクセスがブロックされるよと書かれていました。これは検証していないですが、この注意書きが正しいとすると、最近Azure AD Premiumのプレビュー機能として実装されたレガシーブロックの機能を利用していると考えられます(旧MFAはレガシーブロックできなかった…はず)。ということは、Azure AD Premiumのレガシーブロック機能がGAされるまで、Baseline security policyも有効にならないのかな?と思いました。

Azure AD スマートロックアウトのカスタマイズ機能について

こんなリリース(プレビュー)がありました。

cloudblogs.microsoft.com

機能としては3つで

  1. ロックアウト閾値の変更
  2. 禁止パスワードの定義
  3. オンプレADのパスワード保護

となります。1と2は以前からGraphAPI経由で変更できた機能です。

docs.microsoft.com

3は新しくリリースされました。

1. ロックアウト閾値の変更

Azure ADのロックアウト値は規定で

  • 10回連続でパスワードを間違えた場合
  • 60秒間ロックアウトがかかる

です。この値を変更できます。

この機能の何がうれしいの?ということですが…。

例えば、社内のセキュリティ部門が定めているポリシーでパスワードは3回連続間違えたら1時間ロックアウトすべし!と決まっていて、Azure ADが導入できない場合など。あるいは、外部からアタックされてもアカウントが即ロックしないように、100回連続でパスワードを間違えてもOKにしたい、など。前者はセキュリティ重視、後者は利便性重視ですね。

余談

MSとしてはAzure ADで提供している

  1. ブラックリストIP
  2. IPロックアウト
  3. スマートロックアウト

の3つの機能で、利益目的の攻撃者のアタックをほぼ防げる、と主張しています。1はそもそも怪しい所からのアクセスは禁止する、2はパスワードスプレー攻撃への対応、3はブルートフォース攻撃への対応です。そこらへんのロジックはMS本社のSIMONSさんの神エントリをご覧ください。

Azure AD and ADFS best practices: Defending against password spray attacks – Enterprise Mobility + Security

てことで、利便性重視の設定にしてしまって問題ないと思われます。

具体的には、NISTのガイドラインに従って、ロックアウト回数を100回にするのがよいです…ってMS日本のセキュリティの方が言ってました。

なお、上で提示したリンク(Azure AD Connect: Pass-through Authentication – Smart Lockout | Microsoft Docs)に、

  • The Azure AD lockout threshold is less than the Active Directory account lockout threshold. Set the values so that the Active Directory account lockout threshold is at least two or three times longer than the Azure AD lockout threshold.
  • The Azure AD lockout duration (represented in seconds) is longer than the Active Directory reset account lockout counter after duration (represented in minutes).

とあるんですが、パスハードハッシュ同期でAzure ADで認証している場合、この記載は無視してもらって大丈夫、のはずです。パススルー同期でオンプレADを認証基盤としている場合、外部からのアタックによってオンプレADのアカウントがロックアウトしてしまうので、上記のような施策でAzure AD 側を先にロックアウトさせ、オンプレADを継続できるようにする施策のようです。

…とはいえ、パススルー認証で外部からアタック受けた場合、Azure ADのパスワードロック閾値が動作するのか?てのは疑問です。パススルー認証導入したことないから分からんけど。

2. ロックアウト閾値の変更

これは単純で、登録した単語を含むパスワードの設定を禁止できる機能です。面白い所は、「よく置き換えられる文字を自動的に禁止する」こと。例えば

  • password

という単語を登録した場合

  • p@ssword
  • passw0rd
  • p@ssw0rd
  • p@$$w0rd

などなども、同時に禁止されるようです。

3. オンプレADのパスワード保護

オンプレADに、Azure AD password protection proxyってのをインストールする事で、オンプレADでAzure ADで禁止されているパスワードを使っているユーザーをあぶりだす事が出来るお楽しみ機能です。例えAADCでパスワード同期をしても、Ctrl+ Alt + DeleteでオンプレADに対してパスワード変更をすればAzure ADのパスワードポリシーは無視されるので、P@ssw0rdのような脆弱パスワードがインターネットにさらされることになり危険ですので、有効にしたほうがよい気がします。

この機能を有効にする際に”強制”と”監査”が設定でき、”監査”だと弱いパスワード設定しているユーザー一覧が出力され、”強制”で設定を強制できるようです。”強制”時の挙動は書かれてませんが、次回パスワード変更時までは今のパスワードが使えるのかな?

何にせよ、この機会に脆弱なパスワードを使っている意識低いユーザーを洗い出して、要注意ユーザーリストを作ってセキュリティ教育を強制させるとかの使い方も面白いかもしれません(どこか導入させてくれ~)

必要なライセンス

  • ブログ主のSIMONSさんは”全てのAzure ADで使える”と言っている
  • 日本のMSに確認した所、v2が必要です、と言われた
  • E1テナントだと設定自体が出来なかった
  • P1テナントだと設定が可能である

と、現状ではどのライセンスが必要なのかはっきりしません。システムがせいだとするなら、少なくともAADP1以上は必要のようです。

GraphAPIの時も”AADP1で設定は出来るけど、AADP2しか使っちゃいけない機能だから、設定するとライセンス違反”という罠があったので、MSから公式アナウンスが出るまでは触らない方がよさそうです。

2018/6/22 追記

ブログ更新されてました。

  • 全てのAzureADで使用可能
    • Custom smart lockout
  • P1以上が必要
    • Custom banned passwords
    • Password protection for Windows Server Active Directory

だそうです。

第22回 Office 365 勉強会

第22回だ!

第22回 Office 365 勉強会 – connpass

2018/6/16(土) 13:00-18:00。参加者は80名くらい(?)でした。以下、セッションとその他感想です。細かい感想は上記リンク先のtogatterまとめを見ればよい気がするので、このエントリでは私が単純に思ったことを書きます。

Office 365 ProPlus の 更新管理 と SCCM

「自宅ラック友の会」というパワーワードを引っ提げて、オンプレ・クライアントのカテゴリ感が強い、ProPlusとSCCMの話。O365利用のためには最新版のOfficeが必要で、事実上ProPlusの更新管理をする必要がある。SACのアップデートについていく必要があり、企業ユーザーには難関である。SCCM使えばそこは管理できる。

私は、SCCMないお客さんでIISServer + Office 展開ツール(ODT)で作れるconfig.xml使ってProPlusの更新運用を設計したことがあり、ひとまずそれはうまく回っている様子です。SCCMの事はよー分からん。しかしながらWin10デリバリチームに聞くと、Win10の管理にはSCCM必須やし結局2020年になればみんなWin10になるから勉強するしかないっすよ(しろよ)、との事らしい。

確かにお客さんの中にはWin10の運用上手く回してて、拠点にハブマシン作ってUpdate配布(※)とかやってる会社もあり、大規模環境 & 拠点数がたくさんあるなら、SCCM絡めたWin10 + Office ProPlusの更新管理をする必要があるんだろうな、って。

(※ Win10のWindowsUpdateには、拠点の代表クライアントPC1台に更新プログラムを配置して、LAN内の他のマシンはそのマシンにUpdateを取に行かせることでWAN回線を節約する機能がある。詳しくはde:code18のWin10更新管理のセッション参照)

欠点としては、このフローに乗らないソフトウェアもあって。例えばTeamsはOffice ProPlus製品じゃないからクライアントPCが個別にインターネットに更新プログラム取りに行って死ぬ、など。

MSさん内部でWin10チーム、Officeチーム、Teamsチームが離れててソフトウェア更新フローが統合されてないのかな?と勘繰っちゃいますが、Office 365 / Microsoft 365入れるお客さんは製品群をトータルで管理できる事を期待しているしSIerとしても期待しているので、MSさん推奨のSCCM構成組むから、全部そのフローに乗せて更新できるようにしてよ、とは言いたいです。

SIer視点だと、365の躍進でクラウドベースのエンジニアが重宝され、枯れた技術として軽視(?)されてきたオンプレAD・PCクライアント管理人が、逆にクラウドの方が枯れてきて今後は主役になりそうな気がするんですよね。その時にクラウドベースのエンジニアとオンプレエンジニアが協力してM365環境に一気通貫で対応出来れば、他社に比べて相当アドバンテージになりそうな気がするんだけどな。特にFlowがWin10のアクションを拾えるようになったりしたら、RPAもM365で作れるようになるかもだし、ハッカソン開いてM365で遊び倒すのも面白いかもしれない。

まずは最低限の要件としてWin10/O365のSACに乗れるレベルの更新運用勝ちパターンを構築する事でしょうか。それが出来ればお客さんもうれしい、ベンダーも(ビジネス的に)うれしい、1社のベストプラクティスが他社にも転用できるかも?なOffice 365 黄金郷が見えてくる気がします。

などなど。

Office 展開ツール(ODT)がGUIで作れるようになった、ってのがありがたい情報でした。

Office Deployment Scripts for IT Pros by OfficeDev

Office 365 を楽しもう!(家庭で Office 365 を使ってみたところから業務での利活用促進を考える)

アイディアがめっちゃ面白かったです!365の製品知っててアイディアがあれば、こんないろいろ出来るんだなって。Plannerを家族で共有、SharePoint Onlineはモバイルからたどり着き辛いから、ガワをPowerAppsで作るってアイディアが面白かったです。あとは目立たないけど失敗事例も。非ITの人に新しくアカウントを作ってもらったり、普段のソフトウェアを変更してもらうのは難しい。

Plannerの機能単体だと、TodolistやasanaなどのPJ管理ツールでもいいんだけど、他のサービスも使って、それらのサービスと1つのアカウントでSSO出来るって利便性が非ITの人向けにはいいなって思いました。エンジニアならTodo管理はasana、メモはgoogle keep…など、用途によって一番最適なツールを選ぶことが出来るけど、そうじゃない人には苦痛なだけなので。一通りなんでもそろってる365の強みかなと。

LT

助成金の話が面白かったです。正直、全然知らなかったので、こういう視点の発表もあるんだって驚きました。あ、あと自分も発表しました。終わった後でtwitter見ると好意的な反応が多くてうれしかったです。僕はSharePoint初心者なので、慣れているExchange Onlineを選びました。今となっては枯れたシステムですが、企業で一番利用されているOffice 365機能ってExchange Onlineじゃね?と思っているので、これからもネタがあれば発信します。

セキュアに使おう Microsoft Teams

これは圧巻でした。こういうストーリーを持ってお客さんに話せるとコロっといっちゃうのかな、と思いました。自分の話をすると、EM+S案件には2年前くらいから関わって、それ系のイベントも行っているのですが、イベントでEM+Sの機能が押されることはなく、まさに啓蒙活動が中心なイメージ。外部からの攻撃に対する製品だから当然なんですけど、セキュリティリスクはこんなんですよ、発生したら某社みたいになっちゃいましょ、みたいな。

セキュリティ施策ってどうしても”前例主義”で見直しが少ない、まさに「Teamsを危険と言いつつメールの添付ファイルな野放しな状況」が各社なのです。で、情シス担当者としては波風立てたくないし、上の人も危険性が分かっている人は少ない。

なので、EM+Sに関わらずセキュリティ製品を売る人は、そういった目に見えない危険性とかリスクをストーリー立ててしっかり説明する必要があるんだなぁ~とエンジニアの私は眺めてました。お仕事取ってきてくれてありがとうございます。

EM+Sに関しては、AIPとか条件付きアクセスがシナリオ通りにいかない所もあるんですけども。

おとなのたしなみ Microsoft Flow

Bot Service使ってPowerAppsに通知送るとかIFTTTと連携してGPS自動連動とか、Flowは知識増やしでアイディア練れば面白いネタがいくらでも埋まってそう。特に自分はPowerApps、Bot Serviceは全然わかっていないので、ちゃんと触って何が出来るか理解したい。特にPowerAppsは最近アツい。これを触ればOffice 365 のサービスは一通り触った事になるのかな?と思うので早めに取り組もう。

※ StuffHub?何それ?

まとめ

そんな感じで今回も非常に面白かったです。主催者のもくだいさん、お菓子係のみなさま、ありがとうございました。次回もぜひ参加できればと思います。

Monthly Office 365 Update (2018年3月分,4月分,5月分)

Office 365のアップデートを定期的にチェックして気になったものをピックアップするシリーズ。マンスリーなのに3か月分を一気に更新。

チェックソース

その前に。前回の更新のおさらい

MC128924 See Microsoft Planner tasks in iCalendar

こちら、リリースされました。予想通り、iCalをインターネットに公開する方式なので、情報漏れます。

Monthly Office 365 Update (2018年1月分,2月分) – 今日も元気にIT屋さん

しかしながらiCalに乗ってくる情報は…

  • 件名→連携される(漏れる)
  • 日付情報→連携される(漏れる)
  • チェックリスト→タスク総数と完了数だけ連携される

だけで、肝心の内容部分である…
– 説明欄→連携されない
– 添付ファイル→連携されない
– コメント→連携されない

は大丈夫。漏れるのはタスクの件名欄のみ。あんまり大騒ぎしなくていいかも。
予定表は、タスクの件名と日付の情報だけicsファイルに含まれ、本文にはPlannerへのリンクが表示される。
Exchange Onlineでいう「件名だけ公開」と同じような形です

またicsファイルの公開アドレスは簡単に推測できるものではないです。

https://tasks.office.com/[O365テナントID]/Calendar/Plan/[プラン名?グループ名?]?t=[乱数?_発行日付(ミリ秒単位?)]

外部のユーザーが総当たりで公開されているプランのカレンダーにアクセス成功する確率は低いです。

てことで、神経質にならなくてもいいかもですが、気持ち悪い場合、以下の手順でPlannerの共有をOFFにします。

組織のプランナーで Outlook 予定表の同期をオフにします。 – Office サポート

Office 365 メッセージセンター

MC133135 Office 365 Groups created from Microsoft Teams will be hidden from Outlook by default

Teamsでチームを作ると、それに紐づいで作成されるO365 GroupsがOutlook左ペインに自動的に追加される仕様だったが、表示されなくなる。Teamsをヘビーに使っている場合、いつの間にかTeamsとしてしか使っていないO365グループが左ペインにぽこぽこ追加されているためウザい。この判断はOKだと思います。

MC133236 We’re making changes to Office 365 IP Address range and URL publication

2018年10月2日に、従来のRSSでのOffice 365 IP アドレスと URLの配信が中止され、RESTベースのXML or csvでの配信になります。こちら、インフラエンジニア的にはそこそこ大きい変更でありまして…

  • 自作スクリプトでOffice 365 IP アドレスと URLを取得している場合、スクリプトの改修が必要
  • ネットワーク機器自身がOffice 365 IP アドレスと URLを更新するサービスを販売している事業者は、サービス継続のためにネットワーク機器に仕込んでいる仕組みの変更が必要

となります。たいへんたいへん。

しかしながら、従来のOffice 365 IP アドレスと URLでは、そのURLがExpress Routeを通るか通らないかの情報が取れませんでした。

MSがOffice 365に関わるPACファイルを作成してくれる件 – 今日も元気にIT屋さん

今回の変更で、Express Routeの有無も含む情報が取れるようになったので、まさに望んでいた情報が手に入ることとなります。FlowやLogicAppsでRESTの解析もできるからプログラム書く必要もないし、よい変更だと思います。

MC133271 Microsoft To-Do Steps

MC140111 Microsoft To-Do List Sharing

Microsoft To-Doでサブタスクを追加できたり、他人とTo-Doの共有ができるようになりました。最初のリリースの時に触って失望して、今はasanaでタスク管理しているのですが、ずっとTo-Doを使っている人が「そこそこ使えますよ」とか言っているので、勉強のために使ってみようかなと思うこの頃です。

MC134487 Groups in Outlook and Group-connected team sites are now private-by-default

Outlookなどで作成したO365 グループは、強制的にグループに紐づいたSharepointサイトができるのですが、その規定値が非公開になりますよ、という話。

MC136565 Updated: Microsoft Teams trial for commercial cloud customers

とある条件を満たしたテナントでは、Teamsのトライアルが使用できるようになり、ユーザー自身の意思でTeamsを使用開始できる、という話…っておい。この機能は対象のテナントにプレゼントされて規定で有効になるため、嫌ならOFFにしてね、とのことです。

Manage the Microsoft Teams Commercial Cloud Trial offer | Microsoft Docs

僕のテナントでは既にTeamsを使っているため対象のテナントではないのですが、これ、意識的にTeamsを使わせてないテナントとかで有効になってたら大変じゃないの?ちょっと動作確認が取れないので、どんなものかわからないのですが…。

MC136899 Updated feature: Email quarantine capabilities

Exchange Onlineの検疫管理(スパムマルウェアとして検知されたメールを隔離し、管理者が再配信できる管理画面)が、2018年10月に現在のExchange Online管理センターからセキュリティ&コンプライアンスセンターに代わるらしいです。機能も強化され、保管機能が増えたり選べるアクションが増えたりする様子。

MC137650 Updated feature: Group followers will no longer receive all Planner task email

今まで、O365グループに紐づいたPlannerのタスクに誰かがコメントしたら都度O365グループにメールが飛んで、O365グループの受信トレイをフォローしているユーザーにびしばしメールが飛んでいたのが、変更後は、自分が関係ないタスクのメールは、変わらずO365グループに飛ぶんだけど、関係ないユーザーには転送されない、という仕組みらしいです。

O365グループに着信したメールは問答無用で転送される仕様だと思ってたのですが、こんなコントロールもできるんですね…?翻訳間違ってるのかな。もし本当ならいい変更だと思います。

MC137770 Redesigned Message Trace in the Security & Compliance Center

検疫機能がセキュリティ&コンプライアンスセンターに代わるのと同じで、メッセージの検索も代わっていくようです。

MC139542 We are updating the details of Service Health Communications

O365管理センターのサービスの状態で、障害によって影響を受けているユーザー数が見れたのですが…。これが5月30日に廃止されるようです。なんてこったい。また、以前(2016年くらい)に、O365の管理センターが新しくなって、指定したユーザーのステータスが見れるようになるぜ!って言われてたのですが、リリースがキャンセルされたようです。(Office 365 ロードマップ キャンセル済み Feature ID: 15064 を参照)

原文ブログ(削除済み)

https://blogs.office.com/2016/09/27/office-365-administration-announcements-new-admin-center-reaches-general-availability-and-introducing-the-service-health-dashboard

日本語訳ブログ
Office 365 管理機能更新のお知らせ: 新しい管理センターの一般提供開始とサービス正常性ダッシュボードについて – Office Blogs
Office 365 管理機能更新のお知らせ: 新しい管理センターの一般提供開始とサービス正常性ダッシュボードについて – Office Blogs

その他ブログ情報

Outlook for iOSの新しい機能のリリース予告

www.microsoft.com

セキュリティ関係では

  1. プロキシを設定できるようになった
  2. 1つのO365アカウントにしか接続できないようになった

1について。WindowsPCではプロキシを踏ませて指定したサイト以外へのアクセスを遮断する、というのがセオリー。Outlook for iOSは、例えばOutlook for iOSから個人のGmailアカウントに対してのアクセスをブロックする、という使い方ができる。

2についてはそのままの意味で、「O365」というアカウント種別を1つしか設定できなくなるので、個人のO365アカウントへの接続を禁止することができる。

ただ、どちらも社外への情報漏えいを防ぐための機能だが、Intune配下のiOS/Androidなら元々(情報漏えいを防ぐことは)できていたことなので、今更Outlook for iOSに実装するメリットはないかも?

#decode18 に参加した感想

割と浅めの感想です。

2018/5/23(水),24(木)にマイクロソフト社のイベント「de:code」に参加しました。
米国Microsoft本社では

  • Build
  • Inspire
  • Ignite

ってイベントをやってて、それぞれが開発系・営業系・インフラ系のカテゴリとなります。今回の「de:code」は先日のBuildを受けた上での開発系エンジニアのためのイベントなので、インフラ系の私は適任ではない気がしたのですが…ってことで浅い感想です(予防線)

day1

DA03 スマート シティにおける AI カメラの活用例 ~街の人・モノをカウント~

日本システムウェアさんのCityVisionのご紹介。機械学習はクローズアップされているが欠点として

  • Deep Learning分かる人少ない
  • データ前処理の手間と時間
  • 学習コストヤバイ

というのがあります。タイムリーにこの前のrebuild.fmでもそんな話してました。

Rebuild: 208: Oculus Go On The Go (higepon)

その欠点を解消したのがCityVision。特徴として、裏側でAzureMLを利用しつつ、人と車を数えることだけに焦点を置いたものである。こちらですね。

NSWの画像AIを活用した人・モノカウントサービス、 日本マイクロソフト主催イベントde:code 2018に画像分析ソリューションとして提供 | 日本システムウエア株式会社

つまり、「人」と「車」のモデルがあらかじめ定義され済のものを提供してくれる、ということ。初期費用10万円、サービス継続料は月に2万円ということで、交通量調査する人を安いよりも安価でしょ、と。

人の待ち行列を数えたいときって結構あります。例えばdocomoショップの並びとか、ラーメン二郎の並びとか、ゲレンデのキッカー待ち人数とか。こういったものがインターネットから確認できるようになれば、利用者としてはいろいろ便利だな~。とはいえ、サービス提供側が、なんで行列を他人に公開せなあかんねん、という課題はあるので、実際の売り込み先は考えないといけないぽい。

AD10 Azure PaaSとOffice365で基幹システムを拡張 ~ERPのAPI化とノンコーディングモバイルアプリ開発 ~

レガシーの代表であるSAPを、今流行りのWeb化やモバイル化をどうやって進めるのか。SAPの中をカスタマイズしたりSAP用の3rdパーティー製アドオンもあるらしいが、品質やサービス継続性が不安だったりするので(それを言うならO365の周りで商売している3rdパーティーもそうだが…)

  • SAPはそのまま使う。その周りの周辺システムを整備する

という「Bolt Onの考え方」でやりましょう。

レガシー的なBolt Onの考え方でやると

  • アウトプットデータをExcelで見るので、ローカルのセットアップが必要
  • 各PCにセットアップしたツールの変更管理が大変
  • オンプレミスの中に閉じるのでスマホ対応できない

という課題があるので

  1. On-Premise Data Gatewayでデータに外からアクセスできるようにして
  2. Logic Appsでデータを使う

のストーリー。この流れでさらに

  1. 作成したLogic AppsをAPI化し、Azure API Managementに登録。
  2. Azure API ManagementでAPI管理が可能。

です。単一アプリなら3.4.をやらなくていいけど、業務アプリのデータを全社が使えるようにするなら必要かな。PowerAppsでAPI Managementで管理するAPIを参照出来る様子。

SAP経済圏の中でもスマホアプリ見れるソリューションとかありそうだから、世界を見渡した時にベストプラクティスかはわからないけど、MSワールドでやるならこの方法がクールだな、と思いました。

※ けど後で弊社のSAP担当に聞いたら、Concur(SAP経済圏のアプリ)でデータを引っ張らないとちゃんと取れない、という話もあり、On-Premise Data Gateway大丈夫かな…と

AD07 戦う情シス!全社 API で社内アプリ開発を加速させよう

花王さんの社内情シスの話。雰囲気、ばりばり社内で業務アプリケーション開発してそうでした。

人事情報を取るためにAzureADにアクセスするAPIを作って開放。csvで定期的にデータをエクスポートして渡すより、データは中に持ったまま都度渡す方がセキュアでよい。

  • API Management
  • Application Gateway
    • WAF
    • SSLオフロード、セッションアフィニティ

を使って制御。WebAppsが基盤なので、いろんな設定が簡単にできる。認証が簡単に選べる

難点として、社内のシステムはL4な考え方だが、PaaS,FaaSはL7なので、それをつなげるのが難しかった。

  • L7のサービス:固定IPが持てない
  • L4のサービス:固定IPが持てる

  • App ServiceをVNetに入れる

  • API Management をHTTPSのプロキシとして使う
  • VNet 統合でL4リソースにアクセス(Point to Site VPN)

社内資産であるL4とPaaSの最適解であるL7の統合が課題。

ちょっと私の業務内容とは全然違う話だったのでメモしてるポイントも違うかもですが、API Managementって自社WebサービスをAPI化して3rdパーティーに開放するときに使うイメージだったので、社内コントロール向けに開放するって考えが新鮮でした。

SP08 エバンジェリスト恒例スペシャル対談 ブロックチェーン/仮想通貨スペシャルトーク~今すぐ始めようビットコイン~

アイドルグループである仮想通貨少女、bitFlyerの社長さん、MS西脇さんの異色のセッション。仮想通貨少女が高校生のアイドルグループなのにブロックチェーンやハードフォークといったIT用語を説明してるのが面白かったです。会場では、ビットコインを買ったことがない人がほどんどで(登壇者も驚いていたが)、ブロックチェーンの仕組みの紹介からビットコインを実際に買ってみるとか、個人間送信してみるとか、割と基礎的な内容が多くて新たな知見は少なかったかな。

仮想通貨で個人間送金出来るとはいえ、LINE PAYもできるし、中国発のアリペイなども強い。ここらへんは、どの通貨が天下を取るのかの戦いだと思います。

日本ではいろんな意味で悪目立ちしてしまった仮想通貨ですが、裏側のブロックチェーン技術は本物。エンジニアがビジネスをリードできるインターネット以来の発明、しかもそれを日本がリードしている、このチャンスを逃さない手はないってbitFlyerの社長さんの発言が印象に残りました。

day2

AD12 コーディングレスなアプリ開発 -業務アプリを1時間で- [AD46 と同一内容]

業務部門のためのアプリを情シスがスクラッチから作ってると遅すぎるので、マイクロソフト社がテンプレから作れるPowerAppsを用意したよ。PowerBI / PowerApps / Microsoft Flowの3つを合わせてビジネスアプリケーションプラットフォームとか呼ぶよ。今回は45分くらいで

  • スマートフォンからの電車賃生産
    • GPSで自分の位置を取得
    • 出発地と目的地の駅を入力すると、裏側で電車料金計算
    • 写真で画像取り込み
    • OCRで画像の文字分析

をやります以下デモ。デモの量がすさまじく、ほんとに45分でアプリが作れました。これは”慣れれば”の話なので、初学者はトライアンドエラーしないといけないですが、慣れれば例えばモックをPowerAppsで作って業者に見せて発注する、とかもできるかもしれないです。

ググると、民生用でもノンコーディングでスマホアプリ作れるサービスがあるらしく。個人でもこういった世界が利用できるとなると、仲間内のためにiOSアプリ作ったりもできそうですね。

ただ、価格が高い…。自分が作って数人の友達に配布するレベルではこの金額は出せないですね。

AD02 Serverless の世界を進化させるイノベーション – Durable Functions

最初のセッションの後、Ask the speakerでいろいろと(AD12とその他別件)話していたので遅れて入室。大して聞けず。

AD63 Logic Apps でコードレスに作る ChatBot

LINEbotで写真が送られたらアクションするbotを作成。Logic AppsではLINEのメッセージを受けるように設計。LINEのメッセージ形式が分からなくてもエミュレート(?)する機能があり、楽に実装できるとのことでした。あと、bot系を作るならWebhook有りのLogic Appsで使わないと課金的に死ぬ、という話。

CI24 Microsoft 365 と Microsoft Azure で実現するサーバーレス業務アプリケーション

ソフトバンクテクノロジー社のセッション。Microsoft 365 を基盤として動作するSBT Flowと、Microsoft 365の紹介。Microsoft 365を基盤としているので、AzureADPの条件付きアクセスや権限コントロール機能を使う、IRMを利用して文章保護など、通常のワークフロー機能に加えてAzureADPの強力なガバナンス強化機能を使える。AADPの技術は理解しているからいいとして、SBT Flowってのが、他のワークフロー製品と比べてどの程度優位性があるのかが知りたいな~と思いました。

AC13 クラウドでここまでデキる Ver.1805 ~今こそ Windows 10 をモダンに管理する

Windows10展開時のAutoPilotと、Peer to Peer技術によるWindows Update時のInternetからのダウンロードサイズ削減。私のお客様でもWindows 10の帯域制御に四苦八苦されている方が多いので、P2Pによるダウンロードが魅力的だな~と思いました。余談ですが、Teamsのアプリも更新のたびにフル容量ダウンロードなのでなんとかしてほしく。この仕組みに乗ればうれしいです。

DA08 セキュリティマニアックス ~みんなで守ろうコネクテッドカー~

TechSummit 2017で聞いた話とあまり変わらず。

  • 自動車のソフトウェア化
    • MacOSXよりもコード量多い
    • バグなんて避けられない!
  • コードセキュリティとは
    • プログラム署名をする
    • パスワードのハードコーディングをしない
  • 自動車のCASE化
    • Connected
    • Autonomous
    • Sharing
    • EV
    • この4つを抑えればハッタリが効かせられる

ガチで守るのなら生産工場の現場からセキュアにしなければ、という話。

DA13 組織のデータ活用術~Power BIとAzure Machine Learningではじめるデータ解析実践編

7割くらいがAzureMLの話で、残り3割がPowerBI。新卒採用のデータと、3年後の社員のデータを比べて、有能なグループを定義するとか。すいません、ちょっと期待している内容と違ったのでピンときませんでした。MLはできないけど、PowerBIでもRDBのように設計して分析ができるらしく、そこから取り組んで行こうかなぁ…と思いました。

CI01 帰ってきた インフラ野郎 Azure チーム ~Azure データセンター テクノロジー解体新書 2018春~​

Azure データセンターの裏話。海底テーブル引いてるとか、今までのAzure物理マシンの遍歴。Available Zoneの話。Cloud Shell使いましょう便利ですよ、の話。物理マシン、IaaSの話だが…そこらへんを意識したくなければPaaS使いな!とのことでした。

参加できなかったもの

日程やら満席やらで参加できなかったもの。あるいは、資料公開されたら念のためチラ見したいもの。資料公開されたら感想を書いてきます。

  • AI19 Cognitive Services 最新情報 @ Build 2018 を一気にチェックする50分! [AI18 と同一内容]
  • AD36 実録 クラウドネイティブへの道:PaaS Firstで限界を超えろ!
  • AD28 ワタシハ Azure Functions チョットデキル
  • CI17 「Azure のセキュリティと言っても範囲が広すぎるので、どこから手を付けたら良いのか分からない!」という方のためのセッション
  • AD18 ノンコーディングでサーバーレス体験。Azure Logic Apps のすゝめ
  • CI09 クラウド アーキテクトへの道 ~ 基礎から学ぶサービス利用設計
  • AD21 開発者におくる Power BI を使う時に考えるべきアーキテクチャ ~ データを溜めるのは誰だ? ~
  • AD03 使い倒そう Visual Studio Code! -アプリ開発から遠隔ペアプロ、コンテナー管理、クラウド連携まで-
  • CI03 AD FS では守れない?!アカウント乗っ取りを防ぐためにすべき 3 つのこと ~ユーザー企業の実例のご紹介~
  • AD33 今更聞けない!?Microsoft Graph で始める Office 365 データ活用と事例の紹介
  • AI03 AI 活用の一歩を踏み出したい皆様に贈る Cognitive Services & Bot Framework はじめてみた物語
  • CI18 あなたの組織はなぜ忙しいのか?~Workplace Analyticsで組織変革にチャレンジ~
  • AD15 NoOps へ舵を切れ ~ Azure で実現するサーバレス自律運用システム
  • AD01 試作で止まらないための チャット Bot 開発
  • AC15 Windows 10 April 2018 Update の内容をまとめて紹介!
  • AD26 Serverless と NoOps が実現する近未来
  • CI16 Web API も狙われてる?? 使いこなそう今ドキ WAF
  • AD42 あとで困らないための Azure Active Directory 連携開発 A to Z
  • DA18 ブロックチェーンの未解決問題と仮想通貨のセキュリティ
  • AD20 実践から学ぶ!SNS ID を企業認証基盤で活用するには?
  • CI07 もうセキュリティはやりたくない!! ~ Microsoft ATP で実現するサイバー攻撃への「本当」の運用の仕方~
  • AD20 実践から学ぶ!SNS ID を企業認証基盤で活用するには?
  • AI01 コンテンツ/文書をより探しやすくするための Search x AI – Cognitive Search –

まとめ

専門外の話が多くて苦戦したけど、分かってる話を聞いてもしょうがない、という上でのチャレンジだったので楽しめました。家に帰っていろいろと触るまでがde:codeとのことなので、ちょくちょく手作りしていこうと思います。

Azure 仮想マシンをHTTPトリガーで起動/停止/サイズ変更などする

表題のような要件が生まれたのでやってみます。

前準備

Azure Powershellに自動ログインできないと始まりません。

以前、こんな記事を書いたのですが…

Azure上に作成した仮想マシンを作業時だけサイズ変更して快適に利用する(その他仮想マシン作成後のメモ) – 今日も元気にIT屋さん

セキュリティ上の理由でこの方法が使えなくなったので別の方法でやります。

Azure PowerShell スクリプトにて認証画面を出さずログインし、実行したい (2018/1/29 更新) ? Japan Azure Technical Support Engineers’ Blog

1. Azure Active Directory に、空のアプリケーションを作成し、アプリケーションの ID とパスワードを作成する

手順の通りに実行します。アプリケーションを作成し…シークレットキーを生成。

f:id:teraco:20180424175225j:plain
f:id:teraco:20180424175231j:plain

会社アカウントの場合、システム管理者が一般ユーザーがAzureポータルにログインできないよう、制御している可能性があります。その際はあきらめましょう。

2. 入手したアプリケーション ID とパスワードを認証情報にする

Azure にサービス プリンシパル名を登録します。という手順で躓きました。ブログの記載では

New-AzureRmRoleAssignment -ServicePrincipalName http://myTestApp -RoleDefinitionName Contributor

とありますが、”The provided information does not map to an AD object id.”というエラーになる。いろいろ調べたところ、時間が解決するという書き込みもありましたが、以下のように直接アプリケーションIDを指定する事で登録が出来ました。

New-AzureRmRoleAssignment -ServicePrincipalName [アプリケーションID] -RoleDefinitionName Contributor

参考にした記事:Use PowerShell to create a Service Principal in your AAD

3. Azure PowerShell からログイン

後は元記事の手順通りにログインが出来ます。

$secpasswd = ConvertTo-SecureString "[シークレットキー]" -AsPlainText -Force
$AppID = "[アプリケーションID]"
$TenantID = "[テナントID]"
$mycreds = New-Object System.Management.Automation.PSCredential ("$AppID", $secpasswd)
Login-AzureRmAccount -ServicePrincipal -Tenant $TenantID -Credential $mycreds[f:id:teraco:20180424175225j:plain]

HTTPトリガーから起動/停止/サイズ変更など

1. Azure Functionへの登録

上記PowerShellをAzure Functionに登録し、HTTPトリガーで動くようにします。

f:id:teraco:20180424175634j:plain
f:id:teraco:20180424175638j:plain

HTTPトリガーは以下のようなURLにアクセスすることで動作させることが可能です。

https://[アプリケーション名].azurewebsites.net/api/[関数名]?code=[functionキー]

HTTPトリガーの種類を”匿名”にすればcode=~の部分は不要です。が、セキュリティを高めるために、規定値で使用するのがいいでしょう。functionキーの表示兵法は、関数レベルの管理メニューからホスト キー(すべての関数) -> defaultを表示すればOK。

f:id:teraco:20180424180804j:plain

2. 引数受けの準備

指定したサーバーに対して、起動/停止のアクションを実施したいため、サーバー名とアクション内容を指定できるようにします。HTTPトリガーにGetで引数を投げた場合、以下の変数で受けることができます。

$req_query_[引数名]

今回は、サーバー名 = server、アクション内容 = modeで受けるため、以下のようなURLでGetリクエストを投げ…

https://[アプリケーション名].azurewebsites.net/api/[関数名]?code=[functionキー]&server=[サーバー名]&mode=[開始]

スクリプト中では以下のようなコードで受けます。

$mode = $req_query_mode
if($mode -eq $Null) {
"Please set mode Param(stop/start)"
exit
}
$Server = $req_query_server
if($Server -eq $Null) {
"Please set Server Param"
exit
}

3. PowerShellの登録

サーバーを起動/停止するpowershellコードを書きます。

$RGName = [リソースグループ名]
if($mode -eq "start") {
Start-AzureRmVM -ResourceGroupName $RGName -Name $server
} elseif($mode -eq "stop") {
Stop-AzureRmVM -ResourceGroupName $RGName -Name $server -Force
}

前準備を行う事でAzure PowerShell への自動ログインが可能となったので、自動ログイン後、仮想マシンに対してアクションを行うPowerShell スクリプトを作成します。ここでは仮想マシンの起動を行うようにします。

4. 資格情報の隠ぺい

これだとスクリプトの中に資格情報が記載されたままで怖いので、上記参照記事の通り、Functionの機能を用いて隠ぺいします。

Connect an Azure Function to Office 365 – GCITS

文字列を暗号化すると…

f:id:teraco:20180424180249j:plain

ファイルが生成される。

f:id:teraco:20180424180311j:plain

PassEnctyptKey.key をアップロードし。

f:id:teraco:20180424180404j:plain

EncryptedPassword.txt 中の文字列を環境変数に設定。

f:id:teraco:20180424180611j:plain

隠ぺい前はこちら。

$secpasswd = ConvertTo-SecureString "[シークレットキー]" -AsPlainText -Force
$AppID = "[アプリケーションID]"
$TenantID = "[テナントID]"

隠ぺい後はこちら。

$FunctionName = [関数名]
$keypath = "D:\home\site\wwwroot\$FunctionName\bin\keys\PassEncryptKey.key"
$secpasswd = $Env:SecretKey | ConvertTo-SecureString -Key (Get-Content $keypath)
$AppID = $Env:AppID
$TenantID = $Env:TenantID

Office 365 Multi-Geo(マルチジオ)機能について

Office 365 Multi-GeoがGAしたぽいのでまとめてみます。

Get global data location controls with Multi-Geo Capabilities in Office 365 – Microsoft Tech Community – 182710

使用条件

以下の製品ライセンスが適用されたユーザーが5,000ユーザー以上のOffice 365テナント。

  • Microsoft 365 F1, E1, E3 or E5
  • Office 365 F1, E1, E3 or E5
  • Exchange Online Plan 1 or Plan 2
  • OneDrive for Business Plan 1 or Plan 2
  • SharePoint Online Plan 1 or Plan 2

5,000ユーザー以上、という書き方をしていたので、ライセンス混在でも問題なさそう。

対応製品

  • Exchange Online
  • OneDrive for Businesss

今後、SharePoint OnlineとGroupsへの対応を予定している、とのこと。なぜOD4BとSPOのリリースタイミングが違うか謎。サイトライブラリへの対応が難しかったから?

設定方法

  1. 使用条件を満たしたうえで、マイクロソフト社営業に連絡
  2. マイクロソフト社にて認可後、Office 365 MessageCenterにてマルチジオ有効の通知が来るまで待つ。目安は数週間。
  3. OneDrive管理センターよりメインサイト以外にデータを保有するサテライトを選択(Exchange Onlineのみの場合は不要)
  4. Azure AD Powershellより、サテライトサイトにデータを移動したいユーザーに対してユーザー属性”PreferredDataLocation”を設定する(クラウドIDユーザーの手法。オンプレから同期したユーザーは別の方法で選択)。選択可能なロケーションは2018/4/18現在、以下の通り。
Geo Code
Asia/Pacific APC
Australia AUS
Canada CAN
European Union EUR
India IND(※)
Japan JPN
Korea KOR
United Kingdom GBR
United States NAM

※ Indiaは現状メインサイトのみ選択可能

Azure AD Powershellにて設定した”PreferredDataLocation”の通りに、Exchange Online、Onedrive for Businessのデータがサテライトサイトに移行される。ExOLとOD4Bのデータを別々のサイトに保管することはできない。そんな用途はないが…。

料金

  • サテライトサイトに所属するユーザー数×2ドル/月

リソースメールボックス、共有メールボックスは無料。5000名のユーザーで100名だけフランスなんすよ~な企業は100ユーザー分しか料金かからないので、積極的に使用するべきじゃないでしょうか。

※ テナント全体の5%以上のユーザーがサテライトユーザーじゃないとだめって縛りがある様子。

注意点・制約事項

同期ユーザーをサテライトユーザーとする場合の注意点

Teamsとskype、Yammerの違い。Teamsへの不満。

SkypeがTeamsに統合されるとか、TeamsがあればYammerは必要ないんじゃない?とかいろんな声がありますが、少し語ってみます。Teamsは1チームに○○人参加できてYammerは…のようなスペック比較はしません。

なおここで書く機能は変更されているかもしれないので、最新情報はMicrosoft Teams Blog – Microsoft Tech Communityをご確認ください。

SkypeとTeamsの違い

将来的にSkypeの機能はTeamsに統合されるのでTeamsを使わざるを得ず、比較してどちらが優れているか結論を出す意味がないです。よってここではTeamsを使うことを前提に、SkypeにあってTeamsにない機能、つまりMSさん、まーじでこの機能をTeamsに実装せんかったら許さんぜよという機能を上げていこうと思います。

1.状態変更通知のマーク

Skypeには”状態変更通知のマーク”という機能があります。

誰かの状態が変わったときに通知する – Skype for Business

これは連絡先一覧に登録したユーザーのプレゼンスが変化したときにポップアップを出す機能です。具体的な使いどころとしては、中々連絡がつかない上司を”状態変更通知のマーク”しておいて、”連絡可能”になった瞬間にポップアップを表示、素早くIMする or 話しかけにいく、などです。

f:id:teraco:20180309230216j:plain

f:id:teraco:20180309230219p:plain

あまり管理したくないタスクの1つに「○○さんに××を伝える」というのがあります。口頭で伝えると10秒で済むけどメールを書くとなると面倒。とはいえ、○○さんは不在のことが多く、○○さんを見かけたら話しかける、というタスクを常に意識する必要がある。

こういう時に”状態変更通知のマーク”機能を使うと、“連絡可能”になった瞬間にポップアップが表示され、リマインダー代わりになり、タスク管理の必要がなくなります。用事を口頭で済ますことで、メールを書いてお互いが疲弊することもなく、効率的。Skypeの機能を一番有効に利用している機能だと思います。

2.連絡先一覧

1.状態変更通知のマークが実装できないのは、Teamsに連絡先一覧の機能が存在しないからなんですよね。Skypeの場合、Outlookのようにユーザーを”連絡先”に登録する事ができ、そうするとアプリを立ち上げ連絡先一覧ビューを表示すると、登録したユーザーの一覧とプレゼンス一覧が表示されます。

[画面]

この機能のおかげで、Skypeアプリが連絡先に登録したユーザーのプレゼンスをウォッチし、状態の変更をトリガーに通知できるわけです。それ以外にも、ユーザーをカテゴライズし、仲のいい同僚は自分のプレゼンスが”応答不可”でも連絡OKにするなどできます。

3.複数ウィンドウ対応

SkypeがPC-モバイル間連携イケてないのと同じくらいイケてないと思うのですが、Teamsは現状マルチウィンドウに対応していません。つまり、Teamsで作業中、誰かからのIMを受けてしまうと、作業画面からIMの画面に遷移し、作業画面が閉じられてしまうのです。IMに返信した後、作業画面に戻ると、またIMが来て作業画面が閉じられる。非効率すぎてヤバいです。1つのアプリに機能を詰め込みすぎた弊害です。

4.アプリケーションの反応速度

遅いですよね、Teams。速度だけならSkypeの圧勝です。Webの世界ではページを開いた時のレスポンスが1秒遅れると30%のユーザーが離脱する言います。つまり1秒レスポンスが遅れると3割ほどのユーザーがストレスに感じるわけです。速さは正義。OA製品の世界で速さはあまり重視されませんが、もっと真剣に考えてほしいです。

噂だと、今のTeamsクライアントと兼用できるSkypeライクな軽量版Teamsクライアントがリリースされるらしいので、それがリリースされたら3と4は解消するかもしれません。けど、1と2はほんまに実装してほしいです。

YammerとTeamsの違い

一言でいうと、

で、似ているようで全然違うと僕は思います。

職場内のつながり・人との距離感

まずYammerは人との繋がりが広がります。TOPページにアクセスすると、自分が加入していないグループの投稿がレコメンドとして表示されます。面白そう、関係ありそうなグループを見つけることが簡単です。Teamsは全然広がりません。自分が加入しているチーム以外の投稿は一切表示されません。

Yammerの方が、ユーザーの人となりを感じることができます。なぜなら、よくYammerでやり取りする人の投稿は、自分が入っていないグループでもレコメンド機能でTOPページに表示されるし、アカウントをフォローして表示を多くすることもできるからです。自分の後輩が、自分が含まれたグループだとメンバーに対して敬語だけど、社内の業務外の集まりのグループではタメ語でリラックスしている、自分の知らない後輩の人となりも分かります。

Teamsはチームに参加している後輩の顔しか見えず、人となりがわからないです。なぜなら、チーム内でよくやり取りしても、チーム外の情報は一切分からないし、アカウントをフォローする事も出来ないからです。知らない側面は知らないままです。

よってYammerでよくやり取りする人は、個人同士の距離がより縮まっていく。Teamsはミッションだけの関係で、チームが解散したら繋がりも切れます。

情報の拡散

Yammerは投稿単位でURLが発行されるので、価値ある情報はURLを拡散することで広げることができるし、Yammer内ならリツイートでグループを跨いで拡散できます。Teamsは投稿単位でURLが発行されず、またチャネルの外に投稿を拡散できないので、情報を広めるのが難しいです。

twitterとLINEに例えると、twitterの1つの投稿がバズれば、リツイートでどんどん広がるし、投稿のURLも拡散していく。LINEグループ内で面白いことを言っても、グループ外部の人はその情報にアクセスできないので、グループ内で閉じられた情報となります。

非公開グループの仕様

Yammerで非公開グループを作成しても、検索でヒットすればグループが存在すること自体はわかってしまいます。なのでグループ名に「社長を失脚させる会」とか書いてるとヤバいです。Teamsは非公開グループなら検索でも引っかからないので安心です。また、Teamsは公開グループでもグループに参加しない限り情報(※)を見ることができない。グループに参加したことはログに残るため、いつの間にか知らない人にグループのやり取りを見られた、ということは発生しないです。

以上をいろいろ踏まえて。Yammerにグループを作るならYammerの性質を最大限生かせるように”公開”でグループを作成すべきだと思います。というか、Yammerで非公開グループ作るならTeamsで作れよ、って話です。YammerかTeamsかどちらにグループを作るか迷う場合、フォロー外から失礼されてもOK
むしろ歓迎ならYammer、そうじゃないならTeamsという感覚でよいと思います。

ということで、YammerとTeamsについてはどちらも特徴があるので1つに統合されなくていいと思うのですが、Yammerをサービス提供し続けるのなら使い物にならないゴミ検索機能はなんとか改善してほしいです。

※ 正確には、チャネル内のチャットは見れないが、TeamsのSharePoint領域に保存されたファイルの直リンクを持っていれば閲覧可能

Teams不満点

メールを捨ててTeamsに移ろう!と試みた時の不満点を書きます。

1.タスク管理機能がない

Outlookの場合、着信したメールに対して

  • 関係ないからゴミ箱行
  • 仕訳ルールでフォルダ振り分け
  • アラート設定で翌日ポップアップが出るようにする
  • 分類を割り当てて管理
  • 未読ステータスのままにして、後日対応

などいろいろやり方はあるのですが、Teamsの場合「投稿を保存する」しか管理機能がない。Outlook捨ててTeams使ってる人、これマジどうやってんすか…?

2.スケジューラー連動ができない

「1.タスク管理機能がない」でも書きましたが「このメールは15時からのMTGで内職するから15時にポップアップが上がるようにしとこ」ができない。

3.マルチウィンドウができない

「3.複数ウィンドウ対応」でも書きましたが、Teamsの中で全て完結させる思想のため、Excelなども内蔵ビューワーで開いてくれます。それはそれでよいのですが、Excel開いた後に、別のチームでやり取りしてる会話参照して~その会話で言及されてるパワポ開いて~Plannerで進捗確認して~となると、ちょまちょま無理やんけ、となり、外部のExcelPowerPointを開く羽目になる。

いままでパワーユーザーが自分なりにツールの機能を利用していたのが、なまじTeamsに機能が統合され、かつTeamsの自由度が低すぎるために結局、現状Teams1つでは不十分である、と言えます。

Monthly Office 365 Update (2018年1月、2月のブログ記事)

Office 365のアップデートを定期的にチェックして気になったものをピックアップするシリーズ。読んでたブログ記事で気になったものをメモ。

ブログ記事

AzureAD

cloudblogs.microsoft.com

AzureAD B2Cに関する改善点。パスワードの強度を設定できるようになった事、監査ログの出力、複数のSNSアカウントとの連携可能(既に連携済みのSNSアカウントから別のにチェンジもOKなど。

EM+S

cloudblogs.microsoft.com

2月のEM+S系まとめ。その中で気になった事は以下。

cloudblogs.microsoft.com

CloupAppSecurityで同一SaaS製品の複数のテナントに対応しました。例えばですが、Boxのテナントが部署ごとに分かれている場合は、すべてを管理できたりするのかな。

cloudblogs.microsoft.com

AzureADJoinしたWin10端末から、オンプレのプリンターにSSOしてプリントできる事。ご存知の通り、AzureADJoinのためにはオンプレADから離脱する必要があり、ファイルサーバーや物理プリンターにシングルサインオン出来なくなります。これを無理やり、Windows Hello for BusinessでSSO環境作る事は出来るのですが、プリンターとファイルサーバーという課題の1つがこれで解決した、という事になります。まぁファイルサーバーはSPOに持っていけ、という話で決着するやろな…。

cloudblogs.microsoft.com

O365グループに指定したプレフィックスを付与できる機能です。例えば、”Group-“を頭文字につけるとか。Azure ADP1以上が必要。これ以外にも、最近リリースされたGroups(Teams)関連の機能はP1が必要である場合が多いので要注意。

cloudblogs.microsoft.com

IntuneAPIがGAしたよ、という話。去年の秋くらいからGitHubにコードが上がっていましたが、今回正式にドキュメントも整備されたようです。これでIntune関連の運用を自動化する事ができるので、技術力さえあれば提案の幅が広がりそうですね。

Teams関係

techcommunity.microsoft.com

Teamsにskypeの機能を乗せ換えるロードマップ。だいたいスケジュール通りに行ってるっぽい。

techcommunity.microsoft.com

techcommunity.microsoft.com

1月と2月のTeams更新内容。地味に機能UPしてたりするので、目を通しておくのがいいでしょう。ちなみに私が最近不便に感じることで、iOSのTeamsアプリでスタンプが使えない、というのがあります。Teamsの公式ページ見ると堂々と”未対応です”と乗っていたので対応おなしゃす…。

その他

azure.microsoft.com

AzureFileShareの機能を使ってオンプレサーバーのファイルをバックアップする方法。全部マネージドサービスでやり切れて、今流行りのサーバーレスアーキテクチャーみたいになってます。

azure.microsoft.com

ExpressRouteの使用帯域をモニタリングできるようになりました。で、早速確認しようと思いましたが、ログインできる環境のER回線がまだクラシックポータルから移行で来てなかったです…。

Office 365 Education で次世代イノベーションに向けた包括的な共同学習機能を提供 – Office Blogs

これ、いいなって思ったのがOneNoteにロック機能がつく、という話なんですね。Education版限定の機能という事ですが、普通のOneNoteにも実装してほしいです。