Office 365で儲けられるエンジニアとは

この投稿は 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を使いこなしてどう業務に活かしているの?
  • セキュリティにはどこまでお金をかけてどのレベルまで取り組めば良いの?
  • 社内で自立的に対応していけるようにする運用体制はどう作っていったら良い?

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

第17回Office 365勉強会に登壇します

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

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

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

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

Microsoft MVPを再受賞しました

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

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

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

MVP_Logo_Horizontal_Secondary_Blue286_RGB_300ppi

ExpressRoute for Office365の期待とギャップ

先日、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アドレスの増減に対応する運用負荷に関する不安

20160601_01

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

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

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

6/1に第15回Office365勉強会を開催します

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

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

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

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

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

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

Microsoft MVPアワード再受賞しました

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

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

MVP_Logo_Horizontal_Secondary_Blue286_RGB_300ppi

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

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

Office 365管理者が2015年度考えるべき5つのこと

皆さんこんにちは。

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

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と付き合うことになった方にも、勿論昔からのユーザーの方にも為になる内容になるように、スピーカー一同頑張って内容を考えている所です。

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

一般ユーザーのセルフパスワードリセット(詳細)

前回の投稿では、一般ユーザーのセルフパスワードリセットの概要を紹介させて頂きました。

追加とおさらいとして。一般ユーザーのセルフパスワードリセットを利用する場合、Azure ADの管理画面から有効化を行います。

有効化を行わないデフォルトの状態だと当然セルフパスワードリセットは利用できないのですが、何もしていないテナントでも、少し挙動が変わりました。今までは、[管理者に連絡]というボタンから管理者宛に飛んでいたパスワードのリセット要求のメールの中に

ユーザーが自分でパスワードをリセットできるようにしますか? ほんの数回のクリックで組織のユーザーのパスワードのリセットを有効にする方法をご確認ください。

という様な機能説明のページへのリンクが併記されるようになりました。このメールが来て、初めてこの機能の実装に気がつく管理者の方も多いかも知れませんね。
スクリーンショット (135) スクリーンショット (136) スクリーンショット (138)

それでは、詳細設定の方に入っていきたいと思います。まずはセルフサービスができるユーザーの限定。通常社内にいるようなユーザーやパートナー社員に対してはこの機能を解放しないというようなケースで利用できます。

[パスワードリセットへのアクセスの制限]を[はい]に設定することにより、この機能が有効化されます。[SSPR セキュリティ グループ ユーザー]という名前の空のグループが新規で作成されますので、こちらにパスワードリセットをさせるユーザーを適宜追加して利用します。【本機能はプレビュー中の為変更になる可能性が有ります】
スクリーンショット (133) スクリーンショット (134)

また、前回の投稿では、ユーザーに登録用のリンクを送って自身で登録して貰う方法を紹介しましたが、管理メニューの[○○(テナント名)のユーザーを今すぐ編集します]というリンクから辿れるユーザー管理画面の[勤務先]から、電話番号と電子メールアドレスは入力することができます。

ちなみに、ユーザーが使用できる認証方法との対応は、認証用電話が[携帯電話]、別の認証電話番号が[会社電話]、認証用メールが[連絡用電子メール アドレス]になります。
スクリーンショット (129) スクリーンショット (130)

続いては、[秘密の質問]です。インターネットサイトなどでよく見かける物ですが、管理者側としては[①登録する必要がある質問の数]と[②リセットに必要な質問の数] [③秘密の質問]を設定する必要があります。【本機能はプレビュー中の為変更になる可能性が有ります】

スクリーンショット (139)

数は、その性質上③≧①≧②にする必要があります。①②は3-5が設定できる範囲になります。ここでは試しに①=②=③=5個にしてますが、悪い見本ですね。

  1. (後述しますが)回答の最低文字数は3文字なのに姓を答えさせるって1文字とか2文字の人はどうするの?
  2. ペット飼ったこと無い人は回答できないし
  3. 回答できない質問があるくせに、実質全部の質問に何らかの回答を設定しなくてはいけない

普通に企業IDとしてやるなら、③10個>①5個>②3個くらいですかね? まあ、ここではサンプルなので仮に入力して進めてみます。

ユーザー自身で http://go.microsoft.com/fwlink/p/?LinkId=524980 にアクセスし、答えられる質問を選び、それに3文字以上で回答を設定します。(全角、半角どちらも1文字としてカウントされます。)
スクリーンショット (141) スクリーンショット (144)

そうするとパスワードリセット画面の項目の中に、[セキュリティの質問に回答する]が現れます。ここに、設定した回答と同じ物を入力すると、パスワードリセットを行う事ができます。(パスワード強度を表示する部分が文字化けしているのは、まあ愛嬌って事で)
スクリーンショット (146) スクリーンショット (147) スクリーンショット (156) e382b9e382afe383aae383bce383b3e382b7e383a7e38383e38388-148

セキュリティを強化させるため、認証に必要とされる数を、デフォルトの1から2に変更することもできます。従来の管理者アカウントのパスワードリセットには電子メールと携帯電話の両方が必要だったので、そちらと同じレベルと考えると良いかと思います。

スクリーンショット (149)

2に変更すると、認証画面が[確認ステップ1]と[確認ステップ2]に分かれます。ちなみに、当然と言えば当然ですが[携帯電話にSMS送信]と[携帯電話に発信]で2個とはカウントしてくれません。片方で認証が取れると選択肢から消えます。
スクリーンショット (150) スクリーンショット (154)

その他の機能です。
スクリーンショット (156)

ユーザーがAzureのアクセスパネルにアクセスした際に以下の様な表示を出して情報の入力を促すことができます。(ただ、Office 365の一般ユーザーはあまりアクセスパネルにログインする機会自体が無いかも知れませんので、その場合はリンクを各ユーザーに伝えて入力する形になります。)
スクリーンショット (127)

また、連絡先データの再確認を行う間隔を設定できます。デフォルトは180日です。0日に設定すると、再確認は発生しません。

認証情報が分からなくなったユーザーが管理者に連絡する手段として[管理者に連絡]のリンクが設定されていますが、これをURLやメールアドレスに変更することもできます。
スクリーンショット (157)

ディレクトリ同期環境の場合、[パスワードの書き戻し]機能を有効化するようにとの記載がありますが、残念ながらこちらについては引き続きAzure AD Premiumのサブスクリプションが必要になります。

想定していないパスワードリセットを検知するために、通知機能がデフォルトで有効化されています。複数管理者がいる場合など、対応依頼が来たメールに対して対応済みかどうかを知るために、他の管理者にパスワードリセットするオプションも設定できます。

 

うまく使いこなせば、セキュリティレベルをそれほど下げないで管理者の負荷を軽減できる物になりますので、是非、色々と使い方を研究してみてください。

関連記事:一般ユーザーのセルフパスワードリセット

一般ユーザーのセルフパスワードリセット

Office 365では、以前より管理者アカウントに対してセルフパスワードリセットの機能が提供されていました。

これは、特に中小企業などで社内に全体管理者のユーザーが1名しかいない状況でも、パスワード忘れや退職等に対応できるようにするというのが主たる目的でした。

ただ、それ以外の一般ユーザーのパスワード忘れへの対応というのは、管理者の稼働の多くを必要とする物の一つであり、機能の一般ユーザーへの提供が望まれていました。Azure AD Premiumのサブスクリプションを購入すれば従来から利用はできていたのですが、今回、Office 365のサブスクリプションを有しているユーザーは、この機能が無償で提供されるようになりました。

この機能を有効化するには、Azure ADの管理画面にログインした後、[ユーザーパスワードのリセットポリシー][パスワードのリセットが有効になっているユーザー]を[はい]に変更します。
スクリーンショット (50) スクリーンショット (51)

これで、管理者側の設定は完了です。

次に、機能の利用対象である全ユーザーに対して以下のURLを通知し、携帯電話やメールの情報を登録して貰います。

http://go.microsoft.com/fwlink/p/?LinkId=524980

ユーザーがこの画面にアクセスすると、このような画面が表示されて情報の入力を促されます。
スクリーンショット (42)

電話番号の登録は、国番号と電話番号を入力してショートメールもしくは電話での認証となります。[電話する]ボタンを押すと、入力した電話番号に電話が掛かってきて、[確認を完了する為に#を押して下さい]と言われるので、[#]を押すと登録が完了します。
スクリーンショット (43) スクリーンショット (45)

 なお、前は+81の後に続けて入力する番号は先頭の0を除いた、例えば9012345678などの値を入力する必要がありましたが、この記事を書いている時点では09012345678と入力しても問題無く電話は掛かってきて認証できました。

続いて、メールアドレスの登録です。メールアドレスを入力した後に、[電子メールを送信する]をクリックするとメールが飛んできます。そのメールの値を入力します。

なお、勿論このメールはOffice 365のパスワードを忘れたときに送信されてくる物になりますので、Office 365のアドレスではなく、例えば携帯のアドレスやgma…、いや、Outlook.comのアドレスなどを設定する必要があります。
スクリーンショット (46) スクリーンショット (47) スクリーンショット (61)

これでクライアント側の設定は完了です。
スクリーンショット (49)

さて、実際の利用シーンです。セルフパスワードリセットを利用するには、サインイン画面の下に表示されている[アカウントにアクセスできない場合]をクリックします。
スクリーンショット (62)

登録してある情報のどれを利用して本人確認をするかの画面がでますので、ここで利用する情報を選択します。今回は電子メールで認証をしています。

携帯電話は、登録したときと同じようにショートメールか電話を選択できます。電子メールと違うのは、登録してある電話番号を認証用に入力する必要があるということです。これは、実際に個人の携帯などに電話が掛かってくるので、間違い電話防止などの意味もあるのでしょうね。
スクリーンショット (53) スクリーンショット (54)スクリーンショット (55)

認証が完了すると、リセットするパスワードの入力画面になりますので、新しいパスワードを入力します。上書きのリセットの扱いのようで、前回と同じパスワードを入力しても別にエラーにはなりませんでした。
スクリーンショット (57) スクリーンショット (58)

今回は、まずデフォルト状態でのセルフサービスパスワードリセットを紹介させて頂きました。

Azure AD側では、もう少しこの操作の詳細を設定できるオプションが用意されていますので、そちらは次の機会に紹介させて頂きます。

関連記事:一般ユーザーのセルフパスワードリセット(詳細)

Office 365 サインイン画面のカスタマイズ

Azure Active Directory Premiumで利用可能であった一部のオプションが、Office 365を利用しているユーザー向けに利用できるようになりましたので紹介します。

今回紹介するのは、サインイン画面のカスタマイズです。

設定するには、Office 365管理センターではなく、Microsoft Azureのポータルから設定をする必要があります。[サービス設定] – [パスワード]の下の方や、左のナビゲーションバーの管理者メニューの一番下の[Azure AD]にもリンクがありますが、Azure AD管理センターにアクセスします。
20150222_01

まだAzureにサインアップしていない場合、携帯の番号やクレジットカード番号を入力して無料評価版としてサインアップします。無料評価版のままでも試せますが、30日間の期限がありますので、期限が切れる前に従量課金制にアップグレードして利用しましょう。あくまで従量課金なので、有償のサービスを利用しないままであれば0円課金のまま継続利用できます。

ポータルのを開くと、最初は唯一利用中であるディレクトリ(Active Directory)のみ表示されます。ここの[構成]メニューを選択します。
20150222_05

 

[ブランドのカスタマイズ]を選択します。
20150222_06

 

バナー(画面右上部に表示される物)やサインインページの図(左側に表示される画像)やテキスト(画面下部に表示される)などを設定します。
20150222_07_2

下のチェックボタンを押してしばらく待つと完成です。ちなみに、サインインページの図は、最大サイズが500KBに制限されていますので、保存中にエラーが発生した場合はまずファイルサイズを確認してみて下さい。

いつものサインイン画面ですが、IDを入力すると…
20150222_10

先ほど指定した画面に飛ぶようになります。
20150222_11

コーポレートカラーや会社のロゴなどを表示したり、下の部分にカスタマイズしたテキストを表示させることができますので、未ログインの状態のユーザーに対して提示したい情報、例えばID/パスワードを忘れた場合の対応方法や利用開始の申請方法など入れておくと便利です。

ただし、こちらはIDや会社のメールドメインなどを入れただけでも他のユーザーにも表示されますので、社内向けヘルプデスクの電話番号などあまりオープンにすべきでない情報は載せない方が良いかもしれません。