本日、品川のMicrosoftで開催された第5回Office365勉強会に登壇しました。
Office365のアップデートが始まったばかりということもあり、情報の正確性というよりは先行性を重視した内容としてしまったため、スライドの公開はする予定は無いのですが、何か有ったときに「そういえばそんな話も聞いたことあったな」と思い出して頂ければと思います。
公式に何か移行に関する不具合等が判明した場合は、随時 Known issues – Upgrade to Office365 にアップデートされていくと思いますので、是非ご覧頂ければと思います。
Office365のディレクトリ同期ツールがバージョンアップして、パスワード同期の機能が実装されたとのことで、早速試してみました。
インストール方法は今までと基本的に変わりません。Office365のテナント側でディレクトリ同期を有効化した上で以下の手順でインストールします。
1. .NET 3.5の機能をインストールする
ディレクトリ同期ツールのインストールには、.NET Frameworks 3.5が必要になります。無い場合はエラーになります。
2.ディレクトリ同期ツールをインストールする
続いてdirsync-ja.exeを実行してセットアップします。190MB程になったので、かなりファイルサイズが大きくなりましたね。最後の画面でチェックボックスを入れ、そのまま構成ウィザードを実行します。
3,構成ウィザードを実行する
ディレクトリ構成ウィザードでは、Office365の全体管理者のID/PASS、Active DirectoryのEnterprise Adminsの権限を持ったアカウントのID/PASSを指定します。
ちなみに、6/6現在のバージョン(1.0.6385.0012)だとハイブリッド機能にバグがあるらしく、ここは有効化しない方が良いと思われます。新しく.0024のバージョンが近日中に公開されると思われます。（Exchangeが組織内にある場合のみ有効化可能です）
[パスワード同期]ここの項目が新しく加わってます。[パスワード同期を有効にする]のチェックボックスをチェックしてから[次へ]をクリックします。
これでインストールは完了です。初回同期でオブジェクトが作成されると共に、パスワードの初期同期も実行されます。このため、Active Directoryのパスワードですぐログインができるようになりました。
さて、それでは少し細かい所を触っていきましょう。まず、MIISClientを事項するのに必要な権限がMIISAdminsからFIMSyncAdminsに変わりましたので、運用でMIISClientを触っている人は気をつけた方が良いでしょう。
また、ディレクトリ同期用のアカウントがMSOL_AD_SYNCからAAD_xxxxxxに変更されました。
また、パスワード同期が有効化されていても、Office365側でもパスワードを変更することが可能です。ただし、オンプレミスのADにパスワードは同期されません。つまり、ディレクトリ同期と同様、同期の方向はAD→Office365の一方向です。
次に、パスワードの同期間隔です。ご存じの通り、ディレクトリ同期ツールは3時間に1度しか同期されません。さすがにパスワードの同期がそれほど長いかかると実用に耐えないということか、パスワードの同期のみ、より短時間で同期されるとMicrosoftのサイトにも記載されてます。
試しにパスワードリセットしてみると、ものの1分ほどでディレクトリ同期サーバのイベントログに変更要求とその成功が記録され、パスワードが同期されています。ちなみに、ディレクトリ同期のコンソール画面であるMIISClientには何も表示されません。
色々と試したところ、どうやら2分間隔で定期的にパスワード変更が有った場合にそれを同期させているようです。細かいところだと、2分間の間に複数回同じIDで変更が掛かった場合は最新のパスワード情報のみ同期され、また、仮パスワード（次回ログオン時に変更を要求する物）については同期されないようです。
これを利用すると、管理者としてはプロビジョニングとパスワード管理の簡素化、利用者に対しても複数のパスワードを管理しなくて良いという利便性が提供できるので、手軽なソリューションとして利用できそうです。
Office365では、当初IPv6はサポートせずにIPv4のみでの接続となっていました。
ただ、その後のバージョンアップなどの際に、ポータルや 以前の記事 にあるPowerShellのエンドポイントなどから先行して、徐々にIPv6対応が進んで行っています。
新しいバージョンのExchange Onlineでは、クライアントアクセスの一部もIPv6で接続できるようになるようです。
そもそも、新しいバージョンのExchange Onlineでは、POP/IMAPからの接続先やSMTPの接続先がユーザー毎では無く、全て固定で
と設定されております。この共用で使われているサーバープールへの接続がIPv6で有効化されました。
よって、試しにIPv4/v6のデュアルスタックのサーバーからopensslとかでIMAPに接続して認証要求を出してみると、社内IP帯以外からのアドレスを拒否するように設定しているオンプレミスのADFSサーバでは以下の様なログが表示されてアクセスが拒否されます。
x-ms-forwarded-client-ipの欄に、2001:2e～というIPv6アドレスがしっかり記録されています。
というわけで、アクセス制御をIPv4ベースの物で展開されている方（というか、基本的にはそうかと。サンプルもそうですし）については、少なくとも「意図しないIPv6アドレスからはアクセスされないようにルールが設定されているか」「IPv6化されている社内拠点からのアクセスが拒否されないか」は確認した方が良いかもしれませんね。
新しいOffice365では、管理権限を持っていない一般ユーザーは、初回アクセスから一定期間（2週間くらい？）経過すると、ログオン時に以下の様な画面が表示されます。
ようこそ画面ではなくOutlookが初期表示として表示されるようになるとのメッセージです。確かに、再ログインするとOutlookが表示されます。[了解しました]しか押せませんし、設定を戻すこともできません。
Fiddlerで動きを追ってみると、https://portal.microsoftonline.com/default.aspx に接続しに行くと、https://www.outlook.com/owa/xxxxx.onmicrosoft.com/?exsvurl=1&ll-cc=1041&modurl=0 にリダイレクトされるようです。
上にも書きましたが、現在これを止めたり元の様な設定に戻す方法はありません。
ただし、?DisableIWLanding=true というオプションを付けると上記の処理をスキップしてくれるようです。
https://portal.microsoftonline.com/ などにブックマークしている場合は、ブックマークを
などに変更すると、元の様に常に「Office365にようこそ」の画面に常時接続できるようになります。
エンドユーザーへの影響を少しでも減らしたい方はブックマーク先を変更した方が良いかもしれませんね。
確かに、利便性を考えると…というので気を利かせているのだろうとは思いますが、そういう人は最初からOWAに直に入るURLをユーザーにブックマークさせていると思うのです…
新しいOffice 365で利用されるクイック実行ですが、クライアントへのアプリケーションの配信により新旧クライアントバージョンの混在やメンテナンスの自動化など、多くのメリットがある物となっております。
ただ、従前からのOfficeの利用形態と比較した場合、できないことというのもいくつか出てきておりますので、ここでは主な物をいくつか紹介したいと思います。
「そもそも使わないアプリケーションは誤操作の元なので」「インストールする領域がもったいないので」などの理由で、使用するアプリケーションのみ選択してインストールするというケースが有るかと思います。
Office Pro Plusでは、フルパッケージインストールの配信イメージしか用意されていないので、個別のアプリケーションのインストールする/しないを設定することはできません。
アプリケーションのインストールだけではなく、アップデートもフルパッケージイメージ単位で行われます。
プラグインの互換性などの問題で、特定のアプリケーションのみ異なるマイナーバージョンとする（例えばOutlookのみサービスパックを当てない状態にする）などの運用はできなくなりました。
Office Pro Plusではバージョンダウン権はありません。管理者の展開準備のため、一定の猶予期間は用意されますが（例えば、Office 2010は2014/4/8まで）、それまでに新しいバージョンに変更する必要があります。
アプリケーションは、デフォルトの状態では毎日更新がチェックされ、更新されている場合は自動的に更新がされるようになります。管理者が事前に確認をしてから更新させるなどの運用を行うことは可能ですが、管理者に許容されている適用のスキップの期間は最大11ヶ月になりますので、それまでに更新させる必要があります。
アプリケーションのインストールや更新プログラムの配信は、社内で用意した共有フォルダなどから実施することはできますが、アクティベーション自体は定期的（最低限30日に1回）にインターネットに接続して実施する必要があります。
リモートデスクトップ環境で利用できるのはボリュームライセンス形式で提供されているOffice 2013のみです。
特に、バージョン管理の部分については今の運用ポリシーに対してかなりの変更を余儀なくされる組織も少なくないのではと認識しています。
ただ、ブラウザやOSもそうですが、クラウドをどんどん活用していく上では「基本最新の物を利用する」というポリシーに今後どんどん寄せて行かざるを得ないかと最近ひしひしと感じております。
Exchange Onlineでメーリングリストとして利用できる配布グループには、配布グループと（メールが有効な）セキュリティグループの2種類があります。また、ディレクトリ同期を有効にしている場合は、それぞれそのグループがオンプレミスのADで環境化で作成した物と、Office365で作成した物で、計4種類のグループが存在します。
今回は、その4種類を以下の通りとして、簡単にその特徴と使い分けについて紹介したいと思います。
| ①オンプレミスのAD上で作成 | ②Office365上で作成 | |
| A.配布グループ | dg1@contoso-jp.com | dg2@contoso-jp.com |
| B.セキュリティグループ | sg1@contoso-jp.com | sg2@contoso-jp.com |
A,Bの差は、
また、①②の差については、
などが大きいかと思います。
個人的な使い分けとしては、①のオブジェクトは少し作成・設定が面倒なので極力②をベースとして、
とかがお勧めです。
また、その他として「動的配布グループ」という物が有ります。これは、全ユーザーの属性（例えば部門や住所、個別に設定した拡張属性を含みます）をベースとしたグループになります。このグループは、「唯一メーリングリストのメンバーとして誰が含まれているか、Outlook/OWAなどから見ることができない」物になります。
などの場合に利用する事が多いかと思います。動的配布グループ自体は、オンプレミスで作成してもディレクトリ同期されないので、Office365側で作成します。（ベースとなる属性情報などはActive Directory側で作成します）
注意点としては、①は配布グループの細かい挙動に関する設定もオンプレミス側で実施する必要があります。デフォルトの設定から変更しなければならない場合は、特にGUIなどは用意されていないので、DisplayNameと同様にADSIエディタなどで直接値を入れなくてはいけません。主な設定項目は以下の通りです。
| デフォルト | 変更可能な値 | |
| 配布グループの管理者 (ManagedBy) |
Organization Management | 任意のユーザー （※DNを指定します） |
| メンバー展開後のNDRの送信先 (ReportToOwner,ReportToOriginator) |
送信しない | ①元の送信者 ②配布グループの管理者 |
| 配布グループに送信できるメンバー (msExchRequireAuthToSendTo) |
全員 | 内部のユーザーのみ |
| グローバルアドレス帳への掲載 (msExchHideFronAddressLists) |
載る | 載せない |
括弧内は対応するActive Directoryの属性。必要に応じてオンプレミスのADのスキーマを拡張する必要があります。
さすがに少し面倒なので、利用する際はPowerShellとかを上手く組み合わせて定型化することをお勧めさせて頂きます。
Office365のE3などを利用しているユーザーは、最新のOfficeがサブスクリプションで利用できます。ただし、現在アップデートがまだ行われていないテナントでは新しいOfficeを利用できません。
今回は、少しでも早く利用を開始したい方の為に、アップグレード前のE3テナントで新しいOffice（2013ベース）を利用できる方法を紹介します。
※本投稿による手順は、あくまで検証に基づく物でありMicrosoftによって正式にサポートされていない可能性が有ります。実施は自己責任で実行をお願いします。
まず、アップグレード前のテナントではOfficeのダウンロードリンクが表示されていません。アップグレード後のテナントからURLを直接抜いてくるのもスマートでは無いので、公開されている情報であるOffice Deployment Tool for Click-to-Runから利用したいと思います。
詳細は以前の記事を参照して頂ければと思いますが、setup.exeとconfiguration.xmlを取り出し、以下の様にxmlファイルを作成し、/downloadでイメージをダウンロードした後、/configureで各クライアントに展開します。
<Configuration>
<Add SourcePath="\w15ad01share" OfficeClientEdition="32" >
<Product ID="O365ProPlusRetail">
<Language ID="ja-jp" />
</Product>
</Add>
<Updates Enabled="TRUE" />
<Display Level="None" AcceptEULA="TRUE" />
<Logging Name="OfficeSetup.txt" Path="%temp%" />
<Property Name="AUTOACTIVATE" Value="1" />
</Configuration>
例えば、上記の場合は、/downloadを付けて実行するとイメージがw15ad01上の共有フォルダshareに最新の32bit版がダウンロードされます。
続いて、/configureスイッチを付けて実行すると、クライアントでインストールが実行されます。
c:>\w15ad01sharesetup.exe /configure \w15ad01shareconfiguration.xml
すると、スタートメニューに2013ベースの新しいOffice ProPlusがインストールされます。
何かのアプリケーション（例えばWord）を立ち上げると、Officeのライセンス認証を求められますので、ここでおもむろに既存E3テナントのメールアドレス（ID）、パスワードを入力します。
すると、アップグレード前のテナントでも認証され、新しいProPlusが利用できます。
ちなみに、このやり方の場合、Office2013自体が認証機能を持っているため、別途サインインアシスタントのインストールは必要ありません。
Office 365で提供されるOffice Professional Plusは、従来のインストーラーを利用したインストールという方式ではなく、オンデマンドでのストリーミング配信という方式になりました。
ストリーミング配信には2種類あり、①クイック実行 ②オンデマンドとなってます。オンデマンドは基本的にテンポラリで一時的に利用する物になりますが、今回は常用するクイック実行について話をしたいと思います。
クイック実行は、通常は各クライアントから直接Office365（実体はインターネット上のキャッシュサーバー）に要求が出され、ダウンロードされます。パッケージはExcelやWordなどのコンポーネント単位では無く、Officeスイート全体のパッケージとしてダウンロードされます。
また、毎日更新の有無がチェックされて常に最新の状態のOfficeが利用されるようになります。この更新は、「更新する必要のあるデータのみ」「Officeスイート全体として」ダウンロードされます。
このダウンロードならびに更新の適用についてですが、企業（特に中規模～大企業）で利用しようとすると、通常の方式だと「新規ならびに更新のタイミングで大量のインターネットトラフィックが発生する」「IT管理者が関知しないバージョンアップが実施される」などの問題が発生することが想定されます。
この為、クイック実行ではIT管理者により管理したOffice365の展開ということが可能になってます。共有フォルダ1つあれば実現できますので、簡単にその方法を紹介したいと思います。
まずは、Download Center(英語)からOffice展開ツールをダウンロードします。（ベータ用の物では無いバージョンをダウンロードして下さい。）
Office Deployment Tool for Click-to-Run
http://www.microsoft.com/en-us/download/details.aspx?id=36778
ダウンロードした物を実行すると、使用許諾が表示されるので、確認してContinueを押します。続いて、解凍先を求められるので、展開に利用する共有フォルダに展開します。
解凍が完了すると、configuration.xml と setup.exeという2つのファイルが作成されます。
まず、configuration.xmlの内容を修正して、ダウンロードするプロダクトのエディッションと言語パックを指定します。今回は、サンプルとして32bit版のOffice365の日本語、英語版をダウンロード対象としてみます。
.xmlファイルの構成が終わったら、setup.exe /download configuration.xml を実行します。
共有フォルダ配下にOffice – Data – (バージョン名)の階層のフォルダが作成され、現在のバージョンのファイルがダウンロードされます。また、xml内で指定された日本語と英語の言語パックもダウンロードされます。
あとは、実際の利用シーンに合わせてxmlファイルをカスタマイズし、管理者がテストされたバージョンのOfficeを利用者の言語に合わせて展開してあげればOKです。例えば、15.0.4481.1510のテストが完了したので、日本のユーザー向けに以下の様なconfiguration-jp.xmlを作成します。
このファイルを読み込むように指定して、クライアントPCからファイルサーバー上のsetup.exeを実行します。\serversharesetup.exe /configure \servershareconfiguration-jp.xml すると、コマンドを実行して数分でインストールされたプログラムとして登録されます。
ネットワークの帯域にも因りますが、1GB程度の転送が終了するとコマンドも終了します。実環境では、このコマンドを配信してインストールさせていくような感じになるかと思われます。
また、xml内で更新チェックの場所もファイルサーバーとして指定しましたので、インストール後の更新はそのファイルサーバーをチェックし、管理者により置かれた更新が有った場合、差分をダウンロードする形となります。
今後メインの配布・更新方法になっていくと思われますので、一杯触ってノウハウを溜めていきたいと思います。
詳細な情報などは以下のMicrosoftのサイトを参照になさって下さい。
【参考】
クイック実行用 Office 展開ツール
http://technet.microsoft.com/ja-jp/library/jj219422.aspx
Office 365 クイック実行製品をカスタマイズする方法
http://blogs.technet.com/b/office_jp/archive/2013/02/06/office-365-how-to-customize-clicktorun-for-office-365.aspx
Office 365 ProPlus 管理者シリーズ: クライアントの展開オプション
http://blogs.technet.com/b/microsoft_office_/archive/2012/12/07/office-365-proplus.aspx
Office365の管理用PowerShellでは、シングルサインオンを行うのに必要なドメインの設定を行うことができます。
マイクロソフトが標準で提供するAD FSを利用する場合は、Office365側の設定とオンプレミスのADFSサーバの内容を一緒に更新してくれるNew-MsolFederatedDomain、Update-MsolFederatedDomain、Convert-MsolDomainToFederatedやConvert-MsolDomainToStandardコマンドレットが用意されており、同時に設定を更新してくれます。
対して、Shibbolethなど、AD FSとは異なる方式でシングルサインオンを構成しようとした場合、Office365ドメインの設定のみ変更をする必要があります。この場合に用意されているコマンドレットがSet-MsolDomainAuthenticationです。例えば、contoso.comのドメイン名の用途をシングルサインオンに構成したい場合は、以下の様にします。
Set-MsolDomainAuthentication -Authentication Federated -DomainName contoso.com
通常ドメインに戻したい場合は以下になります。
Set-MsolDomainAuthentication -Authentication Managed -DomainName contoso.com
コマンドとその処理対象に対するイメージはこんな感じです。
これは、AD FSに障害が発生して、緊急避難的にフェデレーションIDからクラウドIDにするのにも利用できます。通常はConvert-MsolDomainToStandardを利用して、
といった流れになりますが、AD FSサーバに接続できないとこのコマンド自体が発行できませんので、AD FSサーバー障害時など、そもそもアクセスできない場合は、Set-MsolDomainAuthenticationsコマンドレットで上記1番のみ実行し、その後3番の工程を手動で実施するという手法を取る形になります。
Windows Server 2012によるADFS構築に引き続き、今回はADFS ProxyサーバをWindows Server 2012上に構成してみたいと思います。
作成する環境はこんな感じです。通常はDMZ上の別セグメントに構成しますが、検証を行う上ではあまり関係ないので。
AD FSの時よりは準備は少ないです。基本的には公的証明書（通常はAD FSで利用している物と同じ物）をエクスポートした物さえ有れば良いです。今回は、Digicertさんで取った公的証明書を利用しています。ちなみに、なぜAD FS Proxyが必要だとか、公的証明書が必要だとかは過去の記事をご参照下さい。
まずは、hostsファイルを構成します。AD FS Proxyは通常インターネット上のDNSサーバを向いており、AD FSサービス名（例: sts.contoso.com）に対して接続をしようとした場合、自分自身のグローバルIPアドレスに解決してしまって接続できません。これを、DNSの名前解決より優先されるhostsファイルに書くことにより、AD FSサーバーに接続しに行くようにします。
続いては、[役割と機能の追加]で[Active Directoryフェデレーションサービス]を追加します。
依存する関連サービスのIISなども同時にインストールされます。
AD FSでは、[フェデレーションサービスプロキシ]を選択します。IISはデフォルトのままで大丈夫なので、次へを押していくとインストールが完了します。
続いて、SSL関係の設定を行います。IISサービスマネージャーを開き、[サーバー証明書]の項目を選びます。[インポート]を選択し、用意しておいた証明書（.pfxファイル）とパスワードを入力します。エクスポートできるようにチェックは付けておきます。
続いては、インポートした証明書を利用してSSLのサイトを作成します。IISマネージャーの[サイト]を開き、[Default Web Site]をクリックして[バインドの編集]を選択します。デフォルトでは、HTTP（ポート80）でしか応答しないようになっているので、HTTPS（ポート443）で先ほどのSSL証明書を利用してAD FSサービス名に対して応答するようにします。
最後に、AD FS Proxyの構成です。スタートメニューの[ADFSフェデレーションサーバープロキシの構成ウィザード]を選択します。
フェデレーションサービス名を入力すると、AD FSサービスへのアクセスの資格情報を求められます。ここでは、AD FSにアクセスできる管理アカウントを指定します。次へを押すと、構成が完了です。
OSの基本機能でほぼいけますので、簡単ですね。
また、外部DNSでAD FSサービス名をAD FS Proxyに接続できるグローバルIPアドレスに解決できるように構成しておきます。必要に応じて、AD FSの実際のアドレスにNATするようにFirewallの設定を行います。
動作確認の為、接続してみます。ポータルからIDを入力すると、自動的に画面がリダイレクトし、AD FS Proxyのフォーム認証画面に飛びます。ここで、ID/PASSを入力してして[サインイン]をクリックすると、Office365にActive Directoryの資格情報でサインインすることができます。
