Office 365を知る参考書(?)

Office 365とかAzureについていろいろ書きたいと思います。別に参考書ではありません。韻踏んでみたかっただけです。

番外編!Azureもくもく会@新宿 No.13に行ってみた【まとめと所感】

本日はこちらのもくもく会に参加してまいりました。

azure-mokumoku.connpass.com

ノンコーディングDayということで、メインはLogic AppsとFlowで各々作りたいものを作ろうぜ!という会で、まず自己紹介から始まり、約一時間のもくもくタイム、そして最後に発表したい人は成果発表するという流れでした。
色々と学びと気づきがあったので、簡単にまとめます。

気付き1:Azureとの親和性高し!VMの監視も楽々

成果発表の中にAzureのVMのCPUが閾値を超えたらSlackに通知する、といったものがありました。
Azure Event Gridを使うことで、様々なイベントをトリガーにし、Slackに発砲できるので、Azure上のVMの監視にはもってこいの方法ですね。

docs.microsoft.com

オンプレミスのサーバーをP2VしてAzureのVMを運用している、という会社がどんどん増えている中で、非常に有効な手段であると感じました。

IFTTTやZapierとか同様のサービスが多い中で、Azureと親和性の高いマイクロソフト純正のサービス、というのはLogic Apps/Flowの大きなメリットだと思います。

また、Azure AutomationもAzureの管理には向いているので、こういったものも活用し、ChatOpsを実現する、というのも比較的容易にできるのではないかと感じました。

気付き2:とっても簡単!Cognitive Serviceとの連携

本日の成果発表の中でLogoc AppsからCustom Vision APIComputer Vision APIを使う、というものもありました。(各サービスのURLは下記参照)

azure.microsoft.com

azure.microsoft.com

OneDriveにアップした画像ファイルをComputer Vision APIを使って画像の説明をSlackに投稿するというものや、一部途中ではありましたがPinterestとCustom Vision APIを組み合わせるといったものなどアイディア次第で色々できるんだな~と思いました。

ハンバーガーの画像と組み合わせて何かできないかな?とふと思ったりもしました。

気付き3:ノンコーディングでループも簡単

私が今日取り組んだのがFlow内でのループです。
以前作成した近くのハンバーガー屋さんを探す仕組みのノンコーディング版です。
以前はAzure Functions内でAPIのコールおよびTeams(Slack)に投稿していましたが、今日はFunctionsを使わずにAPIをコールし、取得したJSONをパースしてループする、といったものを実装してみました。

はまったポイントとして、実際の応答からJSONスキーマを生成し、JSONをパース出来るのですが(以下画像参照)、生成されるJSONスキーマと実際の応答のJSONのデータで恐らく多少の差異があったようで、エラーになってしまうということがありました。JSONスキーマを工夫することで、エラーを回避することができました。

f:id:takeru55555:20171117000148p:plain

多少のはまりポイントはあったものの、今回の実装でFunctionsを使わずともノンコーディングで実装することができました。

まとめ

Logic AppsやFlowはアイディア次第で色々と面白いことができそうだなあと思いました。
Cognitive Serviceとの親和性も非常に高く、とても簡単につなぎこみができるので、これからも色々と使ってみようと思います。

ではまた次回。

【Teams】とっても簡単!Microsoft Flowを使ってハンバーガー関連のツイートをTeamsに投稿する

こんにちは。
唐突ですが、好きな食べ物を食べる瞬間って幸せですよね。私はハンバーガーが大好きなのですが、特に最初の一口目を頬張る瞬間はなんとも素晴らしいものです。

そんなわけで、タイトル通りハンバーガーとTeamsを絡めたことを書こうと思います。
Microsoft Flowを利用し、Twitterハッシュタグに特定のもの(今回は#ハンバーガー)があった場合、Teamsの特定チャネルに投稿する、というものになります。
Microsoft Flowも非常に便利なツールなので、ぜひ活用してみてください。

事前準備

まずはMicrosoft Flowが利用できる環境を準備しましょう。Microsoft FLowは様々なサービスを組み合わせ、自動化ができるサービスで、基本的なOffice 365プランでは利用可能です。(詳細なプランの情報についてはこちらを参照)
似ているサービスとしてはIFTTTやZapierが挙げられますね。

次にTwitterを利用するのでTwitterのアカウントを用意しましょう。

また、Flow経由で投稿するTeamsのチャネルも用意しましょう。今回は以前の投稿作成した「Hamburger」チームの「Cheese Burger」チャネルを利用します。

なお、Microsoft Flowはプランによって実行できる回数が異なるので、多数の実行が予想される場合は注意してください。特に今回のようにTwitterなど、SNSと連携する場合は、ほうっておくとあっという間に上限に達する場合がありますので注意が必要です。

フローを作ってみる。

それではMicrosoft Flowでフローを作ってみましょう。Office 365ポータル等かMicrosoft Flowを開きます。
フローはテンプレートから作ることも可能ですし、一から作成することも可能です。
f:id:takeru55555:20171114235415p:plain

今回はテンプレートから作ってみます。「新しいツイートがハッシュタグと一致したときにMicrosoft Teamsに投稿する」を利用します。

f:id:takeru55555:20171114235300p:plain

連携するサービスのアカウント情報が必要になるので、今回はTwitterのアカウントでサインインします。

f:id:takeru55555:20171115000420p:plain

サインインしたら「続行」をクリックします。

f:id:takeru55555:20171115000756p:plain

 

以下のように検索テキストに任意のテキスト、Team IdとChannel Idにもそれぞれ任意のチーム名、チャネル名を設定し、「フローの作成」-「完了」でフローを保存してください。
f:id:takeru55555:20171115001026p:plain

ここまででフローの作成が完了しました。

Teamsに投稿されるのを待つ

それでは設定したハッシュタグTwitterに投稿されるのを待ちましょう。

以下のようにちゃんと投稿されてますね。(すごい勢いで投稿されておりました。。)

f:id:takeru55555:20171115003415p:plain

有効にしている時間は10分くらいだったのですが、思った以上に実行数が多かったです。(「#ハンバーガー」の実力を少し甘く見てたようですね。。)
先ほども書いたように実行回数には制限があるので、キーワードのチョイスには気をつけましょう。
また、今回のテンプレートの場合、リツイートも投稿されてしまいますので、除外したい場合は条件を書いたり別途考える必要があります。

ちなみにFlow側でも実行履歴を確認できます。

f:id:takeru55555:20171115002844p:plain

とっても簡単ですね。
今回はTwitterを利用しましたが、もちろんほかのサービスとも連携できます。例えばExchange Onlineで特定の送信者からのメールをTeamsに投稿するといったことも簡単に実装できます。また、テンプレートも充実しているので、活用すると非常に便利なサービスです。

TeamsというよりもFlowよりの話になりましたが、今回は以上になります。

今後Teamsと他サービスの連携やチーム作成での運用いったあたりを少し検証しようと思いますので、そのあたりについて投稿しようと思います。

ではまた次回。

【Teams】とっても簡単!Advanced REST clientを使ってIncoming Webhook経由でTeamsに投稿する

本格的に寒くなりましたね〜〜。(毎度天気の話ですいません。。)
私は雪国出身(今は関東在住)なのですが、それでも東京寒いな〜と感じます。周りのマスクの着用率も日に日に増えてきている気がてますので、手洗いうがいを心がけましょう。

さて、前回の投稿でIncoming Webhookのことを書く、と書いたので、Advanced REST clientというGoogle Chromeのアドオンを使ってTeamsのIncoming Webhook経由で投稿するというないようについて備忘録として書こうと思います。
昨今様々なクラウドサービスある中でAPI経由で何かする、と言ったことは非常に良くありまが、その際に、Advanced REST clientのようなツールを使えると、curlなどコマンドを叩かなくてもAPIを実行できるというのは非常に便利です。知らない方は参考にしていただければ幸いです。

事前準備

まず前提のTeamsのお話。Teamsの構造ですが、Slackとは違い「チーム」-「チャネル」の二階層があります。(Slackは一階層)
チームは各部署、チャネルは部署のチームごとや部署内での情報共有の目的別に作るといった使い方が良さそうですね。
それでは、本題に入りましょう。今回利用するIncoming Webhookですが、チーム単位ではなく、チャネルごとに設定する必要があります。
今回は以下のように「Hamburger」チームに「Cheese Burger」チャネルを作っておりますので、このチャネルにIncoming Webhookを追加してHTTP経由で投稿できるように設定しましょう。
まず、チャネル名の右の「・・・」をクリックし、コネクタをクリックします。

f:id:takeru55555:20171113203058p:plain

コネクタを選択できますので、「Incoming Webhook」を構成します。※前回の投稿で触れたように、テナント全体の設定でIncoming Webhookが許可されていないとここで出てこないため、ご注意ください。

f:id:takeru55555:20171113203203p:plain

任意の名前や画像を選択し、作成をクリックします。

f:id:takeru55555:20171113203644p:plain

作成をクリックすると、URLが表示されるので、コピーボタンでコピーし、控えておいてください。※このURLを知っているとこのチャネルに投稿できてしまいますので、大切に保管しましょう

f:id:takeru55555:20171113203834p:plain

最後に完了をクリックします。
※すぐSlackと比べるのは良くないのですが、そういえばOutgoing Webhooksはないんですね。

そして今回の主役のもう一つ。Advanced REST clientをインストールしてみましょう。
Google Chromeのアドオンとして「Advanced REST client」を追加します。

f:id:takeru55555:20171113204426p:plain

ここまでで準備が整いました。

HTTP経由で投稿してみる

それでは早速投稿してみましょう。Advanced REST clientを立ち上げ、以下のように設定します。

  • Method: POST
  • Request URL:Incoming Webhookを追加した時に発行されたURL

また、Bodyタブをクリックし、以下のように設定します。

  • Body content type:application/json
  • Property name:text
  • Editor view:任意ですが、JSON editorがわかりやすいと思います
  • Property value投稿したい任意のテキスト※今回は「Cheeseburgers are so delicious!!」

f:id:takeru55555:20171113205721p:plain

「SEND」ボタンをクリックし、200が返って来ればOKです。

f:id:takeru55555:20171113205908p:plain

Teams側にもちゃんとCheeseburgers are so delicious!!が投稿されてますね。

f:id:takeru55555:20171113210002p:plain

非常に簡単ですよね。Incoming Webhookを利用することで、システムで異常を検知したらTeamsに投げると言ったことも比較的容易に実現することができます。

また、Advanced REST clientを使うことで、非常に簡単にAPIを叩けるので、私は良くAzure FunctionsやAzure Automationのテストをするのに利用していたりするので、重宝しております。

本日はここまでとなります。

次回は別の方法でTeamsに投稿するやり方として、これまたOffice 365のサービスとして提供されているMicorosoft Flowを利用した投稿について書ければと思います。
(飽きっぽいと良く言われるB型なので、続けられるように頑張ります。)

ではまた次回。

【Teams】Teams初心者がTeamsを使ってみた。[使い始める編]

最近夜は大分寒くなりましたね~~。昼と夜とで気温差が高いので着るものに少し困ってしまいますね。(普段は私服なので)
電車でもゴホゴホしている人が多いので、風邪ひかないように気を付けなければですね。
さて、前回の投稿でTeamsをちゃんと使おうかなと書きましたので、備忘録として使ってみた感想等々を書きます。

ちなみに私はSlackユーザーなので、Microsoft版Slackと言われている?Teamsのことはざっくりとは理解しているつもりでしたが、触ってみると細かい違いがいくつかありました。この辺の違いについても今度記載したいと思います。

まずそもそもTeamsってなんじゃい!という話ですが、一言で言うとチャットツールです。
チャットツールなので、リアルタイムなコミュニケーションが非常に円滑にできるというメリットがあります。

実際私の所属している会社ではコミュニケーションツールとしてSlackを使っておりますが、社内間のコミュニケーションはほぼSlackで完結します。
社内でメールをするなんてことは非常に稀です。そのくらいチャットツールは非常に強力なコミュニケーションツールです。
また、この手のサービスのメリットとしては、他のサービスとのインテグレーションも挙げられます。例えば、サーバーの死活監視をしておき異常を検知したら通知を行う、といったこともよくある使い方かと思います。
(ここまではTeamsに限らずSlackやその他サービスの一般的なメリットでありますが。)

Teamsのメリットとしては、やはりOffice 365をお使いの会社は利用可能だということではないでしょうか。(もちろんプランにもよります。詳細はこちら
ただし、Office 365の1サービスゆえに他のサービスとの使い分けが難しかったりもするので、このあたりに悩まれている会社さんは多いのではないでしょうか。

Yammerとの違い

特に分かりづらいのはYammerとの違いですね。この辺りはMSさんが記事を公開してくれてますね。

【2017年版】Skype, Skype for Business, Teams, Yammer の違いは?【10/30 更新】 – Microsoft Partner Network ブログ

実際にコミュニケーションの特性的に以下のような感じでしょうか。

Teams:
緊急性(リアルタイム性)のある情報
(例)今打ち合わせ中なんだけど、至急これ教えて~!電車遅れてるから打ち合わせ遅れる>< 

Yammer:
緊急性(リアルタイム性)の低い比較的ゆるい情報
(例)渋谷界隈の美味しいお店、イベントの告知

ん~~、、特性が違うのはなんとなくは分かる、ただ使い分けは難しいですよね。
渋谷界隈の美味しいお店もイベントの告知もTeamsに投稿しても十分な情報だと思いますし、イベント告知もチャット特有の流れてしまうことを避けたいのであれば、SharePointにリストを作ってそこに投稿しても良いと思います。
となると、流れて欲しくない情報で、かつSharePointにも乗せれないゆるい情報はYammerという感じでしょうか。使い分けが少し難しいですね。

完全に個人的な意見ですが、まずはTeamsを使い、運用がしっかりと定着してから、どうしてもそこに乗らない「ゆるい」情報があればYammerの利用を検討する、といった形が良いのではと考えております。

下手に色々手を出しすぎるとどちらも使われないもの、になってしまうでしょうし。
ちなみに私が所属している会社では以前YammerとSlackと併用しておりました。しかし、今はSlackを社内間のメインのコミュニケーションツールとして使うようにしましたが、全く不便を感じてません。

ただし、大企業やグループ会社で一つのOffice 365を利用している、といった場合はYammerのメリットも出てくるかと思います。TeamsはOffice 365グループの機能であるため、1つのグループが2500人までという制限がありますし、同じ会社で接点が無い場合が多いといった大きな企業においては、YammerのようなSNSツールは有用であると考えております。このあたりは企業によって千差万別なのかなと。

使ってみた

ではそんなTeamsを使い始めてみました。まずはライセンスですね。

f:id:takeru55555:20171111002935p:plain


基本的にはこれで使えます。管理者側でもう少し細かな設定をしたい場合は次の設定ですね。「設定」の「サービスとアドイン」からMicrosoft Teamsを選択。

f:id:takeru55555:20171111003140p:plain

そうすると管理者の細かな設定が行うことができます。
ここでどのアプリを許可するか設定できますが、少なくとも「Incoming Webhook」の利用を許可しておいた方が良いと思います。http経由で投稿ができたりするので、死活監視をしておいて、異常を検知したら、http経由でTeamsに投稿する、といったことが可能になります。

f:id:takeru55555:20171111003502p:plain

あとはワッフルマークからTeamsをクリックすることで使うことができます。
※ブラウザで開いた画面です。

f:id:takeru55555:20171111003752p:plain


使い始めるのも簡単ですね。

今度はWebhookを追加して他のサービスと連携のお話でも書いてみようかと思います。

ではまた次回。

第20回 Office 365勉強会まとめと所感

前回から大分空いてしまいました。。。さぼり癖ですね、良くない良くない。

先日2017/11/4(土)に開催された第20回 Office 365 勉強会に参加してきましたので、後から振り返られるようにまとめておきます。

jpo365ug.connpass.com

ちなみに私もお菓子タイムにLTさせていただきました。
各セッションの簡単なまとめと所感について記載しております。

Office 365 を NPO に導入してみました(仮)

タイトル通りNPOにOffice 365を導入したお話です。
通常のOffice 365の苦労に比べてNPO団体特有の審査等で時間がかかったお話など普段聞けないお話もありました。
また、非常に共感した話として、これはOffice 365の導入について言える話ですが、なんでもできる魔法の箱!というイメージが強いので、そうではないということを最初から伝えることが非常に大事だというお話もありました。本当にその通りだと思います。
他にもSharePointの権限のお話など多くの人が躓きがちな部分の話もありました。

Exchange エンジニアが語る、Exchange Online の設計要素

こちらはExchange Onlineを導入する上で必要な設計要素が簡潔にかつ的確に網羅されておりました。
Office 365をご利用のお客様や導入ベンダーが増えていて、携わる方の母数は確実に増えている中で、こういった話は非常に貴重だなと感じました。

休憩&お菓子タイム&ライトニングトーク

私もこの時間にOffice 365×ハンバーガーというゆるいテーマでLTさせていただきました。
資料は以下にアップしております。※ちなみにスライドは自作しました

www.slideshare.net


他にもPowerQueryのお話やFormsのお話、Flow便利だよ!というお話など短い時間で非常に興味深いお話が多かったように思えます。
また、いつも思いますが、お菓子選びのセンスが抜群です。

MFCMAPI を用いた Office 365 トラブルシューティング

非常にディープな内容でした。MFCMAPIというツールを用いて様々なトラブルシューティングを実施するというお話でしたが、MAPIのプロパティを丸裸にするツールで「やり方によっては簡単に壊れるから注意してね♬」というものでした。私も試すときはテスト環境で実施しようと思います。
本ツールでのトラブルシューティングは通常プレミアサポートにて実施される内容らしく、普段のサービスリクエストでは聞けない情報のため非常に貴重でした。

Microsoft 365 で両立するセキュリティと働き方改革

何かと話題のMicrosoft 365。その中でもセキュリティについてのお話。
DefenderATPというクライアント側でのふるまい検地を行うサービスについての説明もありました。全体的にセキュリティに対するコンセプトが一貫していて、また、高機能で製品としても素晴らしいと思います。ただ高機能な分、高額でもあるので、どの程度の需要が今後出てくるものかはある種楽しみなところでございます。

 

上記がセッションの内容でした。また、各セッションにおいて、質問のコーナーがございまして、その中でTeamsとYammerの使い分けの話が出ておりました。
Yammer=リアルタイム性の低いSNSツール、Teams=リアルタイムのコミュニケーションツールのようにコミュニケーションの性質ごとにツールを使い分けるというケースが多いと思うのですが、この使い分けは正直私の中で少し腹落ちしていない部分があるので、今後しっかり触ってみようと思います。

ではまた次回。

【SharePoint Online】IPアドレスでのアクセス制御

東日本大震災から今日で6年ですね。Yahooで3.11と検索すると10円寄付されるようですので、後1時間程度しかありませんが是非。

fukko.yahoo.co.jp


さて、今日はOffice 365勉強会でした。100名ほどの方が土曜日なのにも関わらず集まるという素敵なコミュニティですね。スピーカーや主催の方、場所提供の会社さんありがとうございます。ブログを書くところまでが勉強会とのことでしたので、約3ヶ月ぶりに投稿いたします。笑

私もSharePonint Onlineの新機能であるIPアドレス制御についてLTさせていただきましたので、今日はその内容を書きたいと思います。

blogs.technet.microsoft.com

まだ先行リリースの機能ですので、今後変更される可能性は大いにあり得ます。その点ご注意ください。

設定方法

正式リリース前の機能のため、先行リリースを有効化する必要があります。
※本番環境に先行リリースを有効化することは気を付けましょう。私はテスト環境で実施しています。

f:id:takeru55555:20170311225856p:plain

しばらくすると「デバイスアクセス」というメニューが出てきます。許可するIPアドレスを入力する箇所があるので、ここにアクセスを許可するIPアドレスを入力してください。

f:id:takeru55555:20170311230001p:plain

(注)必ずアクセス可能なIPアドレスを入れてください。以下のように、場合によってはアクセスができなくなる可能性があります。

管理エクスペリエンス

管理者は、ネットワーク範囲に現在のマシンの IP アドレスを含める必要があります。IP アドレス範囲は厳格に遵守されるため、管理者のマシンの IP が含まれていないと管理セッションがロックアウトされます。管理セッションがロックアウトされた場合は、サポート担当に接続の再確立を依頼してください。

許可IP以外からのアクセス

それでは、登録されていないIPアドレスからアクセスしてみましょう。以下のようにアクセスが拒否されます。

f:id:takeru55555:20170311230143p:plain

設定としては、非常に簡単にIPアドレス制御を実装することができました。現時点では例外の設定ができないため、全ユーザーにIP制御が適用されます。そのため、特定の管理者だけはアクセス制御をかけないといったことはできません。

非常に素直なIP制御

さて、このIPアドレス制御は非常に素直に適用されます。ユーザーにも管理者もどちらにもIP制御がかかりますし、すべてのサイトコレクションに適用されます。また、まさかのSharePoint管理センターにも適用されます。そのため、災害時などにIP制御を無効化したいという要望を現時点では満たすことができません。(せっかくのクラウドのメリットをあまり享受できていないような。。)

そのため、現時点で実運用を想定するのであればAzure AD Premiumの条件付きアクセスかサードパーティー製のソリューションを組み合わせるのが良いかと思います。
とはいえ、手軽に実現出来るに越したことはないので、これからに期待の機能ですね。

それではまた次回に。(いろいろ書きたいことはあるので頻度を上げたいですね笑)

トランスポートルールで実現する企業ブランディング

みなさんどうも初めまして!

これからOffice 365とMicorosoft Azureに関する情報とかとか自分の備忘録も兼ねて書いていきます。(タイトルは実は韻踏んでみてます)
技術的なところから小ネタ的なところまで書いていけたらと思ってます。
皆様のお役に少しでも立てればと思いますので、どうかよろしくお願い致します。

 現在Office 365 Advent Calenderに参加中で、MVPの方々が多数参加されている中参加でき、大変恐縮でございます。
(ぼーっとしてたらブログの一発目の投稿がAdvent Calendarでの投稿になってしまいました。。)

www.adventar.org


さてさてそんな初投稿の私ですが、メールの署名での企業ブランディングについて書こうかと思ってます
ここで二つ質問です!

みなさんメールに署名はつけてますか??
多くのビジネスマンの方はビジネスマナーとして会社に入社した時に教えられることかと思いますので、 意図的に署名を付けない方を除き、多くの方は「はい」と答えるかと思います。

それではみなさんの会社では署名が統一されていますか??
ここでは多くの方が「いいえ」と答えるかと思います。
とある調査では70パーセント以上の企業でメールの署名は統一されていないそうです。
(実は私が所属する会社も全員統一はできてなかったりします)
もちろん署名に電話番号やメールアドレスなど必要な情報が網羅されていれば署名の機能としては問題ないですが、 メールを受け取る側に気を配るのであれば、署名が統一されていた方が与える印象は良いですよね。
多くの企業では個人でビジネスをしているわけではないので、例えば営業がいて購買がいて技術者がいてカスタマーサポートがいてとかの会社だとそれぞれバラバラの署名が付いているのと、企業のロゴなんかが入った署名がビシッとあるのでは、 与える印象は後者の方が良いのではないでしょうか。

前置きが長くなりましたが、そんなわけで企業内での署名の統一を実現しちゃおう!というのが今日の内容です。

もちろん会社全員が使う署名テンプレートを作っておき、その署名を各人が使うというのもできるのですが、 部署移動や部署名変更のたびに実施が必要であったり、OotWとOutlookでは署名を同期してくれないのでそれぞれで署名を登録する必要があったりとエンドユーザーの負荷が少し高いと思います。
そこで今回はタイトル通りExchange Onlineのトランスポートルールで実現する方法を紹介します。

トランスポートルールには「免責事項の追加」という処理があります。
これを使うことで本文に任意の文字列やHTMLタグを差し込むことができます。
免責事項に会社全体で使う署名を作成せしておき、ユーザーがメールを署名を付けずに送ると トランスポートルールで自動的に署名を付けてくれると言った仕組みです。
また、免責事項では変数も用意されており、主に以下のようなものを使うことができます。
%%displayname%%(表示名)
%%company%%(会社名)
%%department%%(部署)
%%Email%%(メールアドレス)
%%title%%(役職)
%%Phone%%(電話番号)
%%zipcode%%(郵便番号)
%%state%%(都道府県)
%%city%%(市区町村)
%%street%%(番地)

これらを組み合わせることで部署移動があってもOffice 365をメンテナンス(ADと連携している場合はADをメンテナンス)すれば対応できますし、 エンドユーザーが署名を登録したり明示的に付けたりと言ったことをする必要もなくなります。
実際に以下のようなトランスポートルールを作成してみました。
今回はSignature Makerで署名のサンプルを作成しました。

signature-maker.net

f:id:takeru55555:20161206233020p:plain

これらのルールを適用し、実際にメールを送ると受信者は以下のような署名がついたメールを受け取ります。 これだとパッと見てどこの会社からのメールかわかりますねー!

f:id:takeru55555:20161207000640p:plain

また、トランスポートルールですので、様々な条件を組み合わせることで、 対顧客向けの署名を作ったり、添付ファイルがあった場合特定の文言を差し込んだりといったことも可能です。
以下は添付ファイルがあった際にちょっとした文言を追加する例です。 (前回Office 365勉強会で同様の内容をLTさせてもらいました)

f:id:takeru55555:20161207010310p:plain

実装方法はとてもシンプルですが、中々便利な機能なのではないでしょうか。
是非皆様の企業でも企業のブランディングの一つとしてはこういった機能を使ってみてはいかがでしょうか。 

今日はこの辺で。明日もAdvent Calendarは続きますので、そちらも是非チェックしてください。
ではでは、また次回。