「勝手にUPされちゃうの?映っちゃいけないものが映ってるんだけど」ってなりそうですが、Teams会議に参加した人しか動画を見る権限がないのでOK。内容を確認後、全社公開や、権限を絞って公開します。映っちゃいけない画面にモザイクをかけて再UPしたい、となると、一度Streamから動画をダウンロードして動画編集ソフトで編集後、新規動画としてUPする形になります。StreamにUPした時の工夫せっかく動画をUPしたので、見やすいようにしました。動画に目次をつけるhh:mm:ss形式で説明文を書くことで、動画の該当時刻にジャンプできるリンクが自動生成されます。後から動画を見返す人が1時間くらいの動画を最初から見るのは大変だと思うので、必要な動画部分にジャンプできるようにしました。目安として、2,3分に1つ、目次を作りました。この目次は完全に手動で作成していますが、PPTに記載済みの目次に、話題が切り替わるタイミングの時刻を記録していくだけだったので、20分~30分ほどで作成できました。動画に字幕を付ける電車の中など音を出せない環境で動画を見る時に字幕があればいいなぁ...と思って付けましたが、これがめちゃくちゃ大変でした。字幕の元ネタとして、勉強会の音声を自動書き起こししたテキストデータを編集したのですが、まず書き起こし精度が悪い。今回、対面の勉強会なので参加してくれる人を意識したしゃべりにしたのですが、音声書き起こされるように意識してしゃべらないと精度が悪いと思いました。2点目は、そもそも動画の音声に合わせて字幕を表示するのに、動画編集的なスキルが必要、ということです。動画でしゃべりだすタイミングで適切に字幕を表示するその字幕を適切なタイミングで消す長文の場合、動画が見やすいように、適切に字幕を区切って表示するという調整が難しく...。1秒単位の調整だと違和感があり、かといってミリ秒単位でこだわると、いくら時間があっても足りません。動画ファイルはWebVTTという形式でUPすればよく、UPしたデータはStream側で保存し、後から再UPもできます。WebVTTはただのテキスト形式であり扱いやすく、これは良かったのです。形式は以下の通り、1行目にWEBVTTって書いて、3行目以降に字幕を表示する時間と、テキストの内容を記載していきます。0:00:14.000では、○○の講習会を始めたいと思います。0:00:34.000この講義というかミーティングは、録画する予定です。これを見てる人はもう録画されてるのを見ているんじゃないかな、と思っています。0:00:42.000録画の関係でプレゼンモードではなく、パワーポイント普通に表示する方針で行こうと思います。そんなのもあって、10分の書き起こしをするのに1時間くらいかかりました。ここで、よく考えたら電車の中でみたけりゃイヤホンすればいいんじゃね?と気づいたので、字幕作成はやめました。字幕について一番効果的な改善策は英語でしゃべればStream側で自動テキスト書き起こしして字幕作ってくれるよですが、そりゃ厳しいので...。全文書き起こしは時間がかかるので、重要なところだけ字幕を表示する、などの対応をすることでしょうか。前述の通り、イヤホンで聞けばいいし、目次作ればある程度話題を選んでジャンプできるので、字幕機能は使わなくてもいいかな、と思いました。しゃべってる人の様子を動画に乗せるPPTの画面だけを動画で流すより、しゃべってる人の顔やしぐさも一緒に乗せた方が、動画への没入感が高いらしいです。自分のしゃべってる姿がStreamにUPされるのでよいかな、と思いました。分かりづらいけど、右下に表示されてる箱っすね。まとめ東進衛星予備校が成功してるし、LinkedInLearingやSchoo!、TechAcademyなどの動画学習サイトも盛況。個人的にも、ただ資料を配布するより、動画もまとめて提供するのが効果が高いと思います。Streamで簡単に実現できるので、みなさんも試してみてください。kenakamuさんとお話しする機会があり、自分なりに整理できたのでメモ。Powershell)なども増え、コードとモジュールの管理が必要となる。「これってバッチサーバー上で動かしているのと、何が違うんだろう...?」と思ったのが、考えるきっかけです。LogicAppsとFlowの違いを説明することが多いので、まとめようと思いました。料金LogicAppsはステップ毎に課金が発生。functionsは実行回数とCPU時間による課金、Flowは500回/日の回数制限があります。動かすだけならfunctionsとFlowは無料で使え、バッチサーバーも環境がある場合(ほとんどある)は、実質無料で使えます。functionsはコードで動かす必要がある。GUIの場合、設計書がなくてもある程度意味が分かるのが大きなメリット。お客さんが設計書なしでもOKと言ってくれる。作成の背景を記した要件定義書は残しておいた方がよいが...。自社管理用にプログラム設計書はほしい。Apps、Flowの方が、気軽にあれこれいじれるメリットはある。その簡易さと引き換えにコードには自由度がある。functionsと連携できるので自由度△としました。Functionだけの制約で、1回の実行時間が5分(工夫すれば10分)となる。5分あればある程度の処理は出来るが...。他は実質時間制限なし。基盤バッチサーバーはIaaSとなり、基盤の再起動タイミングなどを考慮して設計することが必要。安定性LogicAppsやFlowは(実績ベースだと)起動に失敗し、うまく動かないことがある。IaaS上でタスクスケジューラーやJP1で動かす場合、ほぼ確実にプログラムがキックする。...という意味で、こういう評価にさせてもらいました。functionsの実績は手元にないので、とりあえず”中”にしました。権限Flowだけがユーザー権限であり、ユーザーが自分が出来る範囲のタスクをFlowで実装するもの。よってLogicAppsが元になっているとはいえ、自分ができないことはFlowにも出来ないです。(本当に抜け道がないか自分で確認したわけではないけど、設計思想はそう。)なので「Flowでいろいろできちゃうかもしれないから、禁止しよう!」はナンセンス。中には、手動で私用のGmailにメールを送るのはいいが、自動転送はシステム的に禁止する、などのナンセンス運用の企業もあるが...。×ユーザーとしてしまったけど、ユーザー権限だから逆にいいこともあり、一概には言えません。365の運用ではほぼ確実に必要なバッチであり、サーバーレスの概念の登場前はバッチサーバーで動かしていたのがほとんどと思われる。これは引き続きバッチサーバーで動かした方がよいのではないか、と思えてきました。管理者業務なのでFlowは除外。1ユーザー毎に発行するコマンドが多く、LogicAppsで処理すると処理が長くなりそうな事。AzureADのユーザー属性によって処理内容を変化させる必要があり、分岐のパターンによってはコードで実装したほうがスマートであること。コマンドが通らなかった場合の、エラーハンドリングが必要なこと(例外処理が多い)など。ログ監視バッチ一定期間毎にクラウドサービスのログにアクセスしてデータをエクスポートする。これはコマンドは単純ですが、ログが大量の場合、APIからの戻り時間が不安なため、バッチサーバーで実行したほうがいいかもしれません。管理者が実施するアクションか、ユーザーが実施するものかこれでFlowかそれ以外かを分けられます。本来管理者が実施する業務だが、無料のFlowを使いたいため、システムアカウント権限でFlowを動かす方法はあり。”本来すべきではない”かもしれないけど。タイマージョブか、そうではないかもしタイマージョブ以外、例えばHTTPトリガーの場合、バッチサーバー上で動かすプログラムをHTTPトリガーで動かすのは面倒であるため、バッチサーバーは使わない方がよいと考える。functionsは候補から外れる。ミッションクリティカルなアクションであるか1度くらい失敗して、それに気づかなくてもよいかどうか。functionsで動作させるべきである。Appsを使う意味は少ない。Functionsを組み合わせれば実現可能の場合。その場合にどの製品を使用するかは会社の開発ポリシーによります。Appsの部品としてのみ使用を許可、それ単体では動かさない、よって20行以上のコードを書くのは禁止する、など。社内にコーディング規約的があるとすると1つの関数に実装する機能は1つまでなど、ある程度のポリシーがあるはずです。それと同じことをクラウド製品でも検討する必要があると思います。まとめkenakamuさんがおっしゃっていたのは「なんでもできるからこそ、製品が生まれたニーズを知り、最適な使い方をする必要がある。私自身、これだけサーバーレスだiPaaSだともてはやされていたとしても、コードを書いて、バッチサーバーで動かす方がいい場合もあると思いました。最近がんばってるAzureADチームがナイスな新機能をリリースしてくれました。上記権限を保有し、かつMFAが有効になっていないアカウントについて、強制的にMFAが有効になります。これらのアカウントをスクリプトで使用していたり、共用で使用している場合は、運用上支障が出ます。機能を無効化するこの機能はプレビューであり、GAされた段階で強制MFAが発動します。それを防ぐためには以下画面で「ポリシーを使用しない」を選択します。MFAを有効にしないアカウントを選ぶMFAを使わないアカウントが整理できている場合、同じ画面から除外対象アカウントを指定できるので、MFAを有効にしないアカウントを指定します。他の選択肢として「全ての管理者アカウントでMFA有効化」がありますが、この設定を使用すると後述の通りスクリプトでの管理タスク実行に支障が出るため、現実的には「MFAを除外するアカウント指定」を使用するべきでしょう。MSも「全てのアカウントについてMFAを利用するのではなく、緊急用の管理者アカウントを1つはMFAをオフにする方法」を提示しています。Docsさらっとしか流し読みしてませんが、パスワード文字列を2つか3つに分けて、別々の人間が知るようにする、などが書かれています。SIer的な立場としてこんなうざったい機能がリリースされたからオフにしちゃいましょうはアウトな気がします。今までは規定値がMFAオフだったので許されていたかもしれませんが、今後は規定値がオンなのをオフにするので...。果たして、顧客の同意を取ってからオフにするべきでしょう。推奨設定といってもスクリプトで管理者アカウント使いたい!という人向けに推奨設定が出ていました。207160対話的に使用する管理者アカウント人間が非定形作業で使用するアカウントは(ちょっと面倒ですが)二要素認証を有効にします。Docs「俺はSecurePasswordでパスワードを暗号化してるんだ!」「パスワードも十分強力にしてるんだ!」「だから二要素認証なんて要らなんだ!」という方はご自由にどうぞ。タスクスケジューラーなどで動かす管理者アカウント夜間バッチなどに埋め込んでいるアカウントはMFAが使えません。MFAオンにしているとバッチが動きません。仕方なくMFAをオフにするのですが、その場合は以下のように注意をしてください、とのこと。RDPを禁止するクラウドIDなら問題ないですね管理者作業に用途を限定し、メールなどは有効化しないようにする着信したマルウェアをクリックしちゃうと大変ですからね居力なパスワードをセットするアカウントに対する監査ログを有効化し、定期的にチェックする社内IPからのアクセスに限定する管理役割を厳密に設計し、不要なコマンドレットの実行権限を外すこれはさすがにめんどくさい...。Identity)という仕組みが勧められています。365的には使えないものになっています。MSIの仕組みを詳しく理解していません。余談:GraphAPI同僚とこの件に会話していて「もしかしてGraphAPIで適切にアクセス権を振れば、MFA回避できるんじゃね?」という話題が出たので試しました。結果、GraphAPIでもMFAが効いたことをお知らせいたします(当然ですね)。一点注意として、強制MFA有効化前にトークンを取得していれば、継続してアクセスが可能であり、トークンの有効期限が切れた時点でMFAを求められ、スクリプトでのアクセスが不可になります。余談:MFAの実装方法とGA時期予想KBの注意書きに、MFAが有効になった管理者アカウントは、POP/SMTP/レガシーのOutlookクライアントからもアクセスがブロックされるよと書かれていました。Premiumのプレビュー機能として実装されたレガシーブロックの機能を利用していると考えられます(旧MFAはレガシーブロックできなかった...はず)。policyも有効にならないのかな?と思いました。スマートロックアウトのカスタマイズ機能についてこんなリリース(プレビュー)がありました。禁止パスワードの定義オンプレADのパスワード保護となります。1と2は以前からGraphAPI経由で変更できた機能です。docs.microsoft.com3は新しくリリースされました。ADのロックアウト値は規定で10回連続でパスワードを間違えた場合60秒間ロックアウトがかかるです。この値を変更できます。この機能の何がうれしいの?ということですが...。ADが導入できない場合など。外部からアタックされてもアカウントが即ロックしないように、100回連続でパスワードを間違えてもOKにしたい、など。前者はセキュリティ重視、後者は利便性重視ですね。ADで提供しているブラックリストIPIPロックアウトスマートロックアウトの3つの機能で、利益目的の攻撃者のアタックをほぼ防げる、と主張しています。1はそもそも怪しい所からのアクセスは禁止する、2はパスワードスプレー攻撃への対応、3はブルートフォース攻撃への対応です。そこらへんのロジックはMS本社のSIMONSさんの神エントリをご覧ください。Securityてことで、利便性重視の設定にしてしまって問題ないと思われます。具体的には、NISTのガイドラインに従って、ロックアウト回数を100回にするのがよいです...ってMS日本のセキュリティの方が言ってました。ADで認証している場合、この記載は無視してもらって大丈夫、のはずです。側を先にロックアウトさせ、オンプレADを継続できるようにする施策のようです。ADのパスワードロック閾値が動作するのか?てのは疑問です。パススルー認証導入したことないから分からんけど。ロックアウト閾値の変更これは単純で、登録した単語を含むパスワードの設定を禁止できる機能です。面白い所は、「よく置き換えられる文字を自動的に禁止する」こと。passwordという単語を登録した場合p@sswordpassw0rdp@ssw0rdp@$$w0rdなどなども、同時に禁止されるようです。ADで禁止されているパスワードを使っているユーザーをあぶりだす事が出来るお楽しみ機能です。ADのパスワードポリシーは無視されるので、P@ssw0rdのような脆弱パスワードがインターネットにさらされることになり危険ですので、有効にしたほうがよい気がします。この機能を有効にする際に”強制”と”監査”が設定でき、”監査”だと弱いパスワード設定しているユーザー一覧が出力され、”強制”で設定を強制できるようです。ADで使える”と言っている日本のMSに確認した所、v2が必要です、と言われたE1テナントだと設定自体が出来なかったP1テナントだと設定が可能であると、現状ではどのライセンスが必要なのかはっきりしません。システムがせいだとするなら、少なくともAADP1以上は必要のようです。GraphAPIの時も”AADP1で設定は出来るけど、AADP2しか使っちゃいけない機能だから、設定するとライセンス違反”という罠があったので、MSから公式アナウンスが出るまでは触らない方がよさそうです。追記ブログ更新されてました。Directoryだそうです。13:00-18:00。参加者は80名くらい(?)でした。以下、セッションとその他感想です。細かい感想は上記リンク先のtogatterまとめを見ればよい気がするので、このエントリでは私が単純に思ったことを書きます。SCCM「自宅ラック友の会」というパワーワードを引っ提げて、オンプレ・クライアントのカテゴリ感が強い、ProPlusとSCCMの話。O365利用のためには最新版のOfficeが必要で、事実上ProPlusの更新管理をする必要がある。SACのアップデートについていく必要があり、企業ユーザーには難関である。SCCM使えばそこは管理できる。展開ツール(ODT)で作れるconfig.xml使ってProPlusの更新運用を設計したことがあり、ひとまずそれはうまく回っている様子です。SCCMの事はよー分からん。Win10デリバリチームに聞くと、Win10の管理にはSCCM必須やし結局2020年になればみんなWin10になるから勉強するしかないっすよ(しろよ)、との事らしい。ProPlusの更新管理をする必要があるんだろうな、って。Win10のWindowsUpdateには、拠点の代表クライアントPC1台に更新プログラムを配置して、LAN内の他のマシンはそのマシンにUpdateを取に行かせることでWAN回線を節約する機能がある。詳しくはde:code18のWin10更新管理のセッション参照)欠点としては、このフローに乗らないソフトウェアもあって。ProPlus製品じゃないからクライアントPCが個別にインターネットに更新プログラム取りに行って死ぬ、など。365入れるお客さんは製品群をトータルで管理できる事を期待しているしSIerとしても期待しているので、MSさん推奨のSCCM構成組むから、全部そのフローに乗せて更新できるようにしてよ、とは言いたいです。SIer視点だと、365の躍進でクラウドベースのエンジニアが重宝され、枯れた技術として軽視(?)されてきたオンプレAD・PCクライアント管理人が、逆にクラウドの方が枯れてきて今後は主役になりそうな気がするんですよね。その時にクラウドベースのエンジニアとオンプレエンジニアが協力してM365環境に一気通貫で対応出来れば、他社に比べて相当アドバンテージになりそうな気がするんだけどな。FlowがWin10のアクションを拾えるようになったりしたら、RPAもM365で作れるようになるかもだし、ハッカソン開いてM365で遊び倒すのも面白いかもしれない。最低限の要件としてWin10/O365のSACに乗れるレベルの更新運用勝ちパターンを構築する事でしょうか。黄金郷が見えてくる気がします。展開ツール(ODT)がGUIで作れるようになった、ってのがありがたい情報でした。使ってみたところから業務での利活用促進を考える)アイディアがめっちゃ面白かったです!365の製品知っててアイディアがあれば、こんないろいろ出来るんだなって。Onlineはモバイルからたどり着き辛いから、ガワをPowerAppsで作るってアイディアが面白かったです。あとは目立たないけど失敗事例も。非ITの人に新しくアカウントを作ってもらったり、普段のソフトウェアを変更してもらうのは難しい。Plannerの機能単体だと、TodolistやasanaなどのPJ管理ツールでもいいんだけど、他のサービスも使って、それらのサービスと1つのアカウントでSSO出来るって利便性が非ITの人向けにはいいなって思いました。keep...など、用途によって一番最適なツールを選ぶことが出来るけど、そうじゃない人には苦痛なだけなので。一通りなんでもそろってる365の強みかなと。LT助成金の話が面白かったです。知らなかったので、こういう視点の発表もあるんだって驚きました。あ、あと自分も発表しました。終わった後でtwitter見ると好意的な反応が多くてうれしかったです。Onlineを選びました。Onlineじゃね?と思っているので、これからもネタがあれば発信します。Teamsこれは圧巻でした。いうストーリーを持ってお客さんに話せるとコロっといっちゃうのかな、と思いました。自分の話をすると、EM+S案件には2年前くらいから関わって、それ系のイベントも行っているのですが、イベントでEM+Sの機能が押されることはなく、まさに啓蒙活動が中心なイメージ。外部からの攻撃に対する製品だから当然なんですけど、セキュリティリスクはこんなんですよ、発生したら某社みたいになっちゃいましょ、みたいな。セキュリティ施策ってどうしても”前例主義”で見直しが少ない、まさに「Teamsを危険と言いつつメールの添付ファイルな野放しな状況」が各社なのです。情シス担当者としては波風立てたくないし、上の人も危険性が分かっている人は少ない。EM+Sに関わらずセキュリティ製品を売る人は、そういった目に見えない危険性とかリスクをストーリー立ててしっかり説明する必要があるんだなぁ~とエンジニアの私は眺めてました。お仕事取ってきてくれてありがとうございます。EM+Sに関しては、AIPとか条件付きアクセスがシナリオ通りにいかない所もあるんですけども。Service使ってPowerAppsに通知送るとかIFTTTと連携してGPS自動連動とか、Flowは知識増やしでアイディア練れば面白いネタがいくらでも埋まってそう。Serviceは全然わかっていないので、ちゃんと触って何が出来るか理解したい。PowerAppsは最近アツい。サービスは一通り触った事になるのかな?と思うので早めに取り組もう。StuffHub?何それ?まとめそんな感じで今回も非常に面白かったです。主催者のもくだいさん、お菓子係のみなさま、ありがとうございました。次回もぜひ参加できればと思います。365のアップデートを定期的にチェックして気になったものをピックアップするシリーズ。マンスリーなのに3か月分を一気に更新。ライブラリその他各種ブログ情報その前に。iCalendarこちら、リリースされました。予想通り、iCalをインターネットに公開する方式なので、情報漏れます。コメント→連携されないは大丈夫。漏れるのはタスクの件名欄のみ。大騒ぎしなくていいかも。予定表は、タスクの件名と日付の情報だけicsファイルに含まれ、本文にはPlannerへのリンクが表示される。Onlineでいう「件名だけ公開」と同じような形ですまたicsファイルの公開アドレスは簡単に推測できるものではないです。https://tasks.office.com/[O365テナントID]/Calendar/Plan/[プラン名?グループ名?]?t=[乱数?_発行日付(ミリ秒単位?)]外部のユーザーが総当たりで公開されているプランのカレンダーにアクセス成功する確率は低いです。ことで、神経質にならなくてもいいかもですが、気持ち悪い場合、以下の手順でPlannerの共有をOFFにします。予定表の同期をオフにします。GroupsがOutlook左ペインに自動的に追加される仕様だったが、表示されなくなる。Teamsをヘビーに使っている場合、いつの間にかTeamsとしてしか使っていないO365グループが左ペインにぽこぽこ追加されているためウザい。この判断はOKだと思います。csvでの配信になります。URLを更新するサービスを販売している事業者は、サービス継続のためにネットワーク機器に仕込んでいる仕組みの変更が必要となります。Routeを通るか通らないかの情報が取れませんでした。Routeの有無も含む情報が取れるようになったので、まさに望んでいた情報が手に入ることとなります。FlowやLogicAppsでRESTの解析もできるからプログラム書く必要もないし、よい変更だと思います。To-Doでサブタスクを追加できたり、他人とTo-Doの共有ができるようになりました。最初のリリースの時に触って失望して、今はasanaでタスク管理しているのですが、ずっとTo-Doを使っている人が「そこそこ使えますよ」とか言っているので、勉強のために使ってみようかなと思うこの頃です。グループは、強制的にグループに紐づいたSharepointサイトができるのですが、その規定値が非公開になりますよ、という話。customersとある条件を満たしたテナントでは、Teamsのトライアルが使用できるようになり、ユーザー自身の意思でTeamsを使用開始できる、という話...っておい。この機能は対象のテナントにプレゼントされて規定で有効になるため、嫌ならOFFにしてね、とのことです。Docs僕のテナントでは既にTeamsを使っているため対象のテナントではないのですが、これ、意識的にTeamsを使わせてないテナントとかで有効になってたら大変じゃないの?ちょっと動作確認が取れないので、どんなものかわからないのですが...。Online管理センターからセキュリティ&コンプライアンスセンターに代わるらしいです。機能も強化され、保管機能が増えたり選べるアクションが増えたりする様子。email今まで、O365グループに紐づいたPlannerのタスクに誰かがコメントしたら都度O365グループにメールが飛んで、O365グループの受信トレイをフォローしているユーザーにびしばしメールが飛んでいたのが、変更後は、自分が関係ないタスクのメールは、変わらずO365グループに飛ぶんだけど、関係ないユーザーには転送されない、という仕組みらしいです。O365グループに着信したメールは問答無用で転送される仕様だと思ってたのですが、こんなコントロールもできるんですね...?翻訳間違ってるのかな。本当ならいい変更だと思います。Center検疫機能がセキュリティ&コンプライアンスセンターに代わるのと同じで、メッセージの検索も代わっていくようです。CommunicationsO365管理センターのサービスの状態で、障害によって影響を受けているユーザー数が見れたのですが...。これが5月30日に廃止されるようです。以前(2016年くらい)に、O365の管理センターが新しくなって、指定したユーザーのステータスが見れるようになるぜ!って言われてたのですが、リリースがキャンセルされたようです。iOSの新しい機能のリリース予告www.microsoft.comセキュリティ関係ではプロキシを設定できるようになった1つのO365アカウントにしか接続できないようになった1について。WindowsPCではプロキシを踏ませて指定したサイト以外へのアクセスを遮断する、というのがセオリー。iOSから個人のGmailアカウントに対してのアクセスをブロックする、という使い方ができる。2についてはそのままの意味で、「O365」というアカウント種別を1つしか設定できなくなるので、個人のO365アカウントへの接続を禁止することができる。MS-500,MS-100,MS-101を受験して合格しました。