かなり時間が空いてしまいましたが、9/26にAPACのMVPによって開催されたMVP Community Camp 2014の5日目（テーマ：Office 365）に登壇させて頂きました。
テーマはOffice 365、中小企業向けに技術よりではなく、初級～中級レベルにということで、なかなか普段の勉強会などとは違っていたので色々考えたのですが、「Office 365使いこなし術」というタイトルで、Office 365を利用しようと思っている、もしくは利用し始めたがいまいち使いこなせていないと感じる方向けにお話をさせて頂きました。
当日の発表資料はこちら
Lyncを利用したOnlineセミナーでしたので、録音も公開されるようでしたら追ってこちらの方でもアナウンスさせて頂きます。
本日、Microsoft MVPをOffice 365の分野で受賞させて頂きました。
おかげさまで、2012年より3年連続での受賞となります。
コミュニティフォーラムとこちらのBlog、勉強会などでの活動を評価頂いたものと考えておりますが、これからの1年もMVPの名に恥じぬよう頑張って活動したいと思ってます。
Office 365は、ここのところ周辺機能が拡充されてきているのに続き、そろそろ次期バージョンの影もちらちら見えだしてきていますので、新しめの機能を追いかけつつ、既存の分野も便利な使い方などをどんどん紹介していければと考えております。
以前の投稿で、ADFSやディレクトリ同期の環境が整っているかを調べるOffice365 Deployment Readiness Toolというツールを紹介させて頂きました。ドメインに所属するコンピュータ上から実行してADの様々な情報などを取得してくれるお手軽良いツールだったのですが、いつの間にか公開が終了してしまいました。
その後継となるのが今回紹介するOnRampというオンラインツールです。こちらは、ダウンロードするのではなくオンラインから利用するタイプの物です。
OnRampへのアクセスは、直接 https://onramp.office365.com/onramp/ から直接行くか、Office 365管理センターの[セットアップ]から画面右側の[展開の準備状況の確認]を選択して接続します。
このツールは、Office365テナント側の設定がきちんと出来ているかどうかなども確認をします。この為、Office365の管理者アカウントも必要になります。管理者ポータルから遷移した場合は既にログインされた状態ですので、[Sign In]ボタンをクリックするだけでアクセスが可能です。（Office365テナントをまだ持っていない場合は、ここからサインアップすることも可能です）
サインインすると、まずはどのクラウドサービスについて調べるかが表示されます。（将来的にはOffice365以外のクラウドサービスについても調査できるようになるのですかね？） ここでは、[Office365]を選択し、次の画面でOffice365で何を使うのかを選択します。ここでは全てチェックを入れてNextを押します。
次に、利用するIDの種別についてチェックを入れます。一番上はクラウドIDを利用するかどうか、次にディレクトリ同期を利用するか、最後にADFSを利用するかです。ここではとりあえず全部チェックを入れて[Next]をクリックします。
続いてはemailの移行を行うかどうかのチェックです。Exchange移行等を計画している場合はここでチェックを入れます。
今までの回答内容によっては、ここれITプロに助けを求めましょうと確認画面が出ますが、もちろん、私はITプロですと選択してNextを押します。
これで、ようやくチェック画面に推移します。まずは、コマンドを実行するための拡張モジュールのインストールを求められるのでインストールを行った後、[start testing]をクリックします。
このツールですが少しアプリケーションの前提条件が多く、「①Windows Azure Active Directory Sign-in Assistant」「②Windows Azure Active Directory Module for Windows PowerShell」「③②のHostfix」「④Windows Management Framework Core package 2.0」がインストールされていない場合は、こちらでダウンロードリンクなどが表示されます。また、サインインアシスタントなどで上手く認識されない場合は、一度アンインストールしてここのリンクから辿れる英語版をインストールして試してみましょう。
さて、実行結果です。それぞれの区分毎に成功したか失敗したかが表示され、[view details]を選択すると詳細を辿ることが出来ます。それぞれの詳細の中では、さらに小項目ずつのテスト結果が表示され、失敗した物が有る場合は失敗した物のみ表示されるようにフィルタリング条件が設定されています。成功した物も含めて全て見たい場合はこのフィルタを[All results]にすると全て表示されます。
また、更に失敗したテストにカーソルを合わせ、右側のペインの[View details of this check]を押すと何がNGだったかが表示されます。ここでは、サンプルとしてUPNが設定されていないアカウント（＝ディレクトリ同期、ADFSができない）に対するエラーや、パスワード長要件を満たしていない（ディレクトリ同期によるパスワード同期ができない）などのエラーが出てきました。
以前のツールと比較すると、少し手軽さは無くなってしまっているのですが、最初の方の画面にもあるとおり、この辺りの機能は徐々にユーザーの声を反映させて本体側の管理ポータルのセットアップの工程に統合されていくようです。
以前の投稿で、IE以外からADFSにシングルサインオンしようとした場合に、いくつか設定変更をしない部分があるということを紹介しました。
Windows Server 2012 R2のADFSにおいても、デフォルトの状態だとIE以外からはシングルサインオンできません。イントラネットのポータルからIDを入力すると、ADFS Proxy経由でアクセスした際と同じフォーム認証の画面に飛んでしまいます。（以下、Chromeでの画面例）
今回は、IE以外のブラウザからも入れるようにする方法を紹介します。
以前は、拡張認証の対応用にIISの設定を変更しましたが、Windows Server 2012 R2のADFSではそもそもIISを利用してません。この為、対応のための設定変更はADFSで実行します。
主に設定に関係するのはSet-ADFSPropertiesの以下のパラメータです。（[ ]内はデフォルト値）
ExtendedProtectionTokenCheckは、拡張認証に対応している場合は利用を許可すると言う物ですが、昔調べた際はIE以外は対応しているブラウザが無かった為にWindows7では対応をしなくてはいけなかった物ですが、今回調べた限りではサードパーティのブラウザ側でも対応が進んでいるのか、特に設定変更の必要はありませんでした。
次に、WIASupportedUserAgentsのパラメータです。Windows Server 2012 R2のADFSは、このパラメータを見てシングルサインオンさせるかフォームベース認証にするかを判断しています。これを、ChromeやFirefox用にMozilla/5.0を設定してみます。ご利用の環境に合わせて “Safari/6.0”, “Safari/7.0” なども追加して頂ければ、と思います。
$old=(Get-AdfsProperties).WIASupportedUserAgents $new=$old+"Mozilla/5.0" Set-ADFSProperties -WIASupportedUserAgents $new
Chromeは、IEの設定をそのまま見て動作してくれますので、特に何も無くシングルサインオンできるようになりました。
ただし、Firefoxの場合は以下の様にID、PASSの入力画面がポップアップします。
これは、以前の投稿でも紹介した通りADFSのFQDNをIEでの「イントラネット」に設定しないといけないのと同じ理屈でセキュリティ上の問題からです。
about:configで設定画面に入った後、network.automatic-ntlm-auth.trusted-urisの項目にADFSのFQDNを設定すれば以下の様にシングルサインオンできるようになります。
注意点としては、ブラウザのバージョンアップによりUserAgentの値が変わった場合はシングルサインオンができなくなりますので、こちらの管理を運用の中でしていく必要があります。
急な休暇が入った場合や会議室だけおさえて欲しいと頼まれた場合など、他の人や会議室メールボックスのカレンダーに予定を書きたいケースがあります。
こういったケースでは色々と皆さん工夫されて運用されているようなのですが、今回は私がやってる方法について書きたいと思います。
編集者の権限を他のユーザーに一般的に与えているような組織であれば勿論問題無いですが、デフォルト設定だと直接のカレンダーアイテムの作成はできません。
仕方ないので、会議開催通知をとして自分を含めた会議を作成します。
ただ、こうすると自分にも予定が入ってしまいます。とはいえ、自分の予定を削除しようとすると、相手先にも会議のキャンセル通知が行ってしまい、最終的な予定表の見た目はCanceled: と入ってしまいます。これだと折角入れたのにあまり意味が無いですよね。
そもそも、これは「会議」という予定表アイテムの以下の様な特性によります。
今回は、この辺のところを上手く悪用利用して、相手だけに予定を入れてみたいと思います。
まず、これを実施するには自分の他に1人協力者が必要です。今回は、例えばユーザーBの予定を入れる際に、隣の席のCさんに手伝って貰うことを想定します。
まずは、先ほどのようにサッカー観戦で休んでるユーザーBに会議開催通知を送って仮の予定を作成します。
その後、ユーザーCに一時的にすべてのアイテムに対しての削除権限を付与します。
そして、ユーザーCに頼んで自分の入れたその予定を削除して貰います。Outlook 2010だと右クリックで削除ができた記憶があるのですが、2013だと右クリックからは会議キャンセル通知の（代理送信の）作成に推移してしまうため、Shift+DELキーを押してアイテムを完全削除します。これで、ユーザーAの予定表アイテムが削除されました。
ユーザーAのOutlookに戻って予定表を見てみると、ユーザーBの予定は残っているのに、ユーザーAの予定表からはアイテムが削除されているのが分かると思います。
簡単な流れは以下の通りです。（確認ができたら、付与した削除権限は元に戻しておきましょう。）
感覚的に正規な動作では無い気がするので、Outlookへの更新プログラムの適用などで将来的に出来なくなってしまうかもしれませんが、比較的リーズナブルな手順なのでよろしければお試し頂ければと思います。
最近Office365を利用していると、いくつかの環境でこんな場面に出くわすことがあります。
①Office365から[サインアウト]をクリックする
②一度サインアウト画面にリダイレクトされて…
③あれ？元の画面に戻ってきた。
こんな症状の時は、今までの経験則からすると大体原因は2つです。
1つ目は、最初にサインインしたURLが誤っていた（自社ドメインのCNAMEにoutlook.comを指定して利用していた）場合。2つ目は、サイトのゾーンの問題です。
今回は、正規の https://portal.office.com からログインしているので、1つ目では無いです。
そう、今回は、上記のURLが新しくポータル用のURLになった（他のURLから行っても勝手にリダイレクトされる）のに、それをブラウザ側の設定に対応させていなかったのが原因と推測されます。
というわけで、インターネットオプションの[セキュリティ][信頼済みサイト]に新しいURL https://portal.office.com を入れてみます。
これで、サインアウトを実行すると…無事、サインアウトできるようになりました！
URL変わると言われた時点で気づければ良かったのですが…。なかなかこう言うのは事象が出てからで無いと気がつかないですね。難しいっす。
ドメインレジストラの大手であるお名前.comさんで提供しているレンタルDNSが遂にSRVレコードに対応しました！
私もいくつかのドメインで利用させて頂いておりますので、今回はそちらの設定方法をご紹介させて頂きます。
まず、Office 365管理センターでドメインのメニューを開きます。（左のような[ようこそ画面]が表示されている場合は、右下の[Office 365管理センターに移動]をクリックして移動します）
[ドメインの追加]から[手順1を開始する]をクリックし、追加したいドメイン名を入力します。
ドメインの所有確認のページが表示されますので、[一般的な手順]を選択して認証に必要なDNSレコードを取得します。今回は、TXTレコードを利用して所有確認をしてみたいと思います。
次に、お名前.com側の管理画面[ドメインnavi]にアクセスします。 今回はTXTレコードの追加なので、[ドメイン設定]のタブから、[ネームサーバーの設定][DNS関連機能の設定]をクリックし、[DNSレコード設定を利用する]の横の[設定する]を開きます。
ドメイン名を選択して[入力画面へ進む]としてDNSレコードの設定画面に移ります。
ここでは、先ほどOffice365の画面に表示されたTXTレコードの値を入力します。ホスト名は空のままでTYPEを[TXT]とし、TTLはデフォルトの3600のまま、VALUEに[MS=ms…]の値を入力し、[追加]をクリックします。
下の方に、[DNSレコード設定用ネームサーバー変更確認]のチェックがありますが、現在別のDNSを利用していて移行する場合などは、他のDNSレコードもこの画面で移植が終わってから[確認画面へ進む]を押して次に進むようにして下さい。確認画面の内容で間違いなければ[設定する]を押します。これでドメインの所有確認用のDNSレコードの作成が完了しました。
次に、元の画面に戻って確認ボタンをクリックすると、DNSの登録が完了していれば[（ドメイン名）を所有していることを確認しました。]と表示され、ドメインが追加されます。
以前は、ここでDNSレコードの値などをキャッシュして比較的長時間（場合によっては48時間）確認までに時間がかかることが有ったのですが、今回何パターンか試した限りでは、ここの確認サーバではDNSのキャッシュされる期間がDNSサーバ側で設定した値より比較的短くチューニングされているのか、数分程で確認が取れるようになりました。
さて、次はOffice365サービスで独自ドメインを利用する為のDNSレコードの作成です。[手順2を開始する]をクリックし、[今はユーザーを追加しません][次へ]をクリックします。
[手順3を開始する]をクリックし、[Exchange Online][Lync Online]にチェックが入っていることを確認して[次へ]をクリックします。
ここで追加すべきDNSレコードの一覧が追加されます。（試した時点ではMXが1個、CNAMEが4個、TXTが1個とSRVが2個でした）
元のお名前.comの管理者画面に戻って、先ほどTXTレコードを追加したのと同じように追加します。以下が入力例です。特にSRVレコードは記載方法が少し他に比べると面倒なのでお気を付け下さい。それぞれ入力後、[追加]をクリックします。
また、先ほどドメイン名の所有確認したTXTレコードは今後は利用しませんので、この場で削除しておきましょう。消しても消さなくても動作には何も影響は有りませんが、ゴミが残ってしまっているのも気持ち悪いですし。確認画面で確認できたら[設定する]をクリックします。
ドメイン名の所有確認の画面に比べると若干時間がかかるケースが多いですが、しばらく待つと、上記で入力した内容が正しければDNSレコードの確認が終了し、独自ドメインをOffice365で利用する事ができるようになります。
以前の投稿で、SRVレコードの対応状況について少しお話ししましたが、当時はほとんどど存在していなかったSRVレコード対応のサービスも、お名前.comさんのような大手をはじめ、いくつか対応して来てくれているようで嬉しい限りです。
先週・今週と2週連続で勉強会に登壇させて頂きました。ご参加頂きました方々、本当にどうもありがとうございました。
両方ともOffice365の運用を中心とした部分でお話をさせて頂きましたが、「サービス全般」と「ID連携システム」という、別々の切り口での話となった為資料も全部作り直し…同じテーマにしておけば良かったと少し後悔(w
ただ、両方とも奇しくも結論としては「サービスはどんどん進化していくので、頑張って着いていきましょう」ということになりました。
オンプレミスと違い、サービス側は（望む、望まないに関わらず）どんどん進化していくので、そこに接続するクライアントや連携するシステムは上手く着いていかないといけません。
そこで今までとの差分が出た場合でも、基本的にその差分を埋めるのはサービス利用者である自分たち自身です。サービスを上手く乗りこなしていけるよう、これからも横の繋がりを大事にしつつ、情報発信していければなと思います。
なお、当日の資料などはSlideShareにアップしてありますので、よろしければご覧下さい。（間違いの指摘なども頂けると嬉しいです）
同じような勉強会での講演や執筆依頼などについては、TwitterかFacebookあたりで要請頂ければ都合の着く範囲で対応させて頂きますので、お気軽にお問い合わせ頂ければと思います。
最近本業が忙しくてなかなかblogも書けていない状態ですが、いくつか勉強会の登壇予定がありますのでお知らせします。
【6/21】SQLWorld★大阪#24
【6/28】.NETラボ 勉強会 2014年6月 ~認証系を勉強する1日～
【8/2】第9回 Office365勉強会
導入するユーザーの要件によっては、どうしてもオンプレミスのExchange Serverで立てないといけないケースもあるので、Exchange Onlineの仕様は定期的にチェックしてます。
ご存じかと思いますが、Exchange Onlineを初めとするOffice365のサービス仕様は昨年からファイル（.docxや.pdf）ではなくTechnet上でのオンラインベースでの公開に変更されています。
2014-04-21版をチェックしていたところ、2013-09-09と比較して色々と変更が加わってました。今回はその中から1つ紹介します。
保存中のデータの暗号化 (BitLocker)
Exchange Server 2013 ○（管理者が有効にする必要がある旨の注記有り）
Exchange Online（全てのプラン） ○
この項目、悪い言い方ですがRFPでOffice365外しをする際に利用される、かなりメジャーな仕様でした。今回こちらが実装されたようですが、ユーザーから見てあまり機能面で響く物では無いので特にアナウンスとしては無かったのでしょうか。
例えば他にも以下の様な「オンプレではできるがOffice365では出来ない物」が有りましたが、いずれも実装されていっており、機能要件としてマルバツ表作ってもほぼ差が出ない状態になってきています。
が、いざ実際に導入フェーズになってみると、色々と機能一覧では出てこない非機能要件の面で差異が出てきて、時には問題になったりもします。
というわけで、来月のSQLWorldさんの勉強会ではその辺りの事を踏まえた上で、運用を踏まえたスムーズなOffice 365導入についてお話ししたいと思います。
向く組織、向かない組織、導入が決まったのであれば変えていくべきポイントなど、具体例含めて紹介したいと考えています。