Office Pro Plusのできそうでできない事

新しい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の差は、

  • AはExchangeのみで利用できるグループ
  • Bは権限の設定(オンプレミスのファイルサーバーやSharePoint Online)で利用できる

また、①②の差については、

  • ①はActive Directoryでメンバーの変更を行う。この為、Office365で作成されたユーザーをメンバーに加えることはできず、同じくActive Directory上にいるディレクトリ同期されたユーザーのみメンバーにすることができる。
  • ②は、Exchange Onlineの機能でセルフサービス配布グループ(配布グループの作成、削除、配布グループへの参加または脱退をグループの管理者に委任することができる)として構成することができる。
  • ①は作成する際にADSIエディタなどでDisplayNameの属性を直接設定する必要がある。

20130421_01

などが大きいかと思います。

個人的な使い分けとしては、①のオブジェクトは少し作成・設定が面倒なので極力②をベースとして、

  • 社内でファイルサーバの権限などと合わせて設定されている部署・部門毎のグループのみ①-Bとして作成し、人事異動などの際の管理を容易にする。SharePoint Onlineの権限もこのグループを利用する。
  • 特定プロダクトやプロジェクトのMLなどについては②-Aとする。(同グループがSharePoint Onlineサイトを作成する場合は②-Bとする。)

とかがお勧めです。

また、その他として「動的配布グループ」という物が有ります。これは、全ユーザーの属性(例えば部門や住所、個別に設定した拡張属性を含みます)をベースとしたグループになります。このグループは、「唯一メーリングリストのメンバーとして誰が含まれているか、Outlook/OWAなどから見ることができない」物になります。

  • 社外のアドレスや個人の携帯電話のアドレスが含まれているグループ
  • “組合員”など”再雇用者”などの比較的センシティブな情報を取り扱うグループ
  • “首都圏の全ユーザー”などメンテナンスが難しいグループ

などの場合に利用する事が多いかと思います。動的配布グループ自体は、オンプレミスで作成してもディレクトリ同期されないので、Office365側で作成します。(ベースとなる属性情報などはActive Directory側で作成します)

注意点としては、①は配布グループの細かい挙動に関する設定もオンプレミス側で実施する必要があります。デフォルトの設定から変更しなければならない場合は、特にGUIなどは用意されていないので、DisplayNameと同様にADSIエディタなどで直接値を入れなくてはいけません。主な設定項目は以下の通りです。

デフォルト 変更可能な値
配布グループの管理者
(ManagedBy)
Organization Management 任意のユーザー
(※DNを指定します)
メンバー展開後のNDRの送信先
(ReportToOwner,ReportToOriginator)
送信しない ①元の送信者
②配布グループの管理者
配布グループに送信できるメンバー
(msExchRequireAuthToSendTo)
全員 内部のユーザーのみ
グローバルアドレス帳への掲載
(msExchHideFronAddressLists)
載る 載せない

括弧内は対応するActive Directoryの属性。必要に応じてオンプレミスのADのスキーマを拡張する必要があります。

さすがに少し面倒なので、利用する際はPowerShellとかを上手く組み合わせて定型化することをお勧めさせて頂きます。

新しいOffice 365 ProPlusを移行前のE3で使う

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="\\w15ad01\share\" 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:\>\\w15ad01\share\setup.exe /configure \\w15ad01\share\configuration.xml
20130416_01

すると、スタートメニューに2013ベースの新しいOffice ProPlusがインストールされます。
20130416_02

何かのアプリケーション(例えばWord)を立ち上げると、Officeのライセンス認証を求められますので、ここでおもむろに既存E3テナントのメールアドレス(ID)、パスワードを入力します。
20130416_03 20130416_04

すると、アップグレード前のテナントでも認証され、新しいProPlusが利用できます。
20130416_05 20130416_06 20130416_07

ちなみに、このやり方の場合、Office2013自体が認証機能を持っているため、別途サインインアシスタントのインストールは必要ありません。

Office365の管理されたクイック実行

Office 365で提供されるOffice Professional Plusは、従来のインストーラーを利用したインストールという方式ではなく、オンデマンドでのストリーミング配信という方式になりました。

ストリーミング配信には2種類あり、①クイック実行 ②オンデマンドとなってます。オンデマンドは基本的にテンポラリで一時的に利用する物になりますが、今回は常用するクイック実行について話をしたいと思います。
20130410_02

クイック実行は、通常は各クライアントから直接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を押します。続いて、解凍先を求められるので、展開に利用する共有フォルダに展開します。
20130410_03

解凍が完了すると、configuration.xml と setup.exeという2つのファイルが作成されます。

まず、configuration.xmlの内容を修正して、ダウンロードするプロダクトのエディッションと言語パックを指定します。今回は、サンプルとして32bit版のOffice365の日本語、英語版をダウンロード対象としてみます。
20130410_04

.xmlファイルの構成が終わったら、setup.exe /download configuration.xml を実行します。
20130410_01

共有フォルダ配下にOffice – Data – (バージョン名)の階層のフォルダが作成され、現在のバージョンのファイルがダウンロードされます。また、xml内で指定された日本語と英語の言語パックもダウンロードされます。
20130410_05 20130410_06

あとは、実際の利用シーンに合わせてxmlファイルをカスタマイズし、管理者がテストされたバージョンのOfficeを利用者の言語に合わせて展開してあげればOKです。例えば、15.0.4481.1510のテストが完了したので、日本のユーザー向けに以下の様なconfiguration-jp.xmlを作成します。
20130410_07

このファイルを読み込むように指定して、クライアントPCからファイルサーバー上のsetup.exeを実行します。\\server\share\setup.exe /configure \\server\share\configuration-jp.xml  すると、コマンドを実行して数分でインストールされたプログラムとして登録されます。
20130410_08 20130410_09

ネットワークの帯域にも因りますが、1GB程度の転送が終了するとコマンドも終了します。実環境では、このコマンドを配信してインストールさせていくような感じになるかと思われます。
20130410_10

また、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

Set-MsolDomainAuthentocation

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

コマンドとその処理対象に対するイメージはこんな感じです。
20130405_01

これは、AD FSに障害が発生して、緊急避難的にフェデレーションIDからクラウドIDにするのにも利用できます。通常はConvert-MsolDomainToStandardを利用して、

  1. Office365のドメインの認証方式をID/PASSによる通常の方式に変換
  2. ADFSのOffice365の設定を削除
  3. Active DirectoryのID情報を元に、Office365のユーザーに対して初期パスワードを発行

といった流れになりますが、AD FSサーバに接続できないとこのコマンド自体が発行できませんので、AD FSサーバー障害時など、そもそもアクセスできない場合は、Set-MsolDomainAuthenticationsコマンドレットで上記1番のみ実行し、その後3番の工程を手動で実施するという手法を取る形になります。

Windows Server 2012によるADFS Proxy構築

Windows Server 2012によるADFS構築に引き続き、今回はADFS ProxyサーバをWindows Server 2012上に構成してみたいと思います。

作成する環境はこんな感じです。通常はDMZ上の別セグメントに構成しますが、検証を行う上ではあまり関係ないので。
20130403_33

AD FSの時よりは準備は少ないです。基本的には公的証明書(通常はAD FSで利用している物と同じ物)をエクスポートした物さえ有れば良いです。今回は、Digicertさんで取った公的証明書を利用しています。ちなみに、なぜAD FS Proxyが必要だとか、公的証明書が必要だとかは過去の記事をご参照下さい。

まずは、hostsファイルを構成します。AD FS Proxyは通常インターネット上のDNSサーバを向いており、AD FSサービス名(例: sts.contoso.com)に対して接続をしようとした場合、自分自身のグローバルIPアドレスに解決してしまって接続できません。これを、DNSの名前解決より優先されるhostsファイルに書くことにより、AD FSサーバーに接続しに行くようにします。
20130403_01

続いては、[役割と機能の追加]で[Active Directoryフェデレーションサービス]を追加します。
20130403_02 20130403_03 20130403_04 20130403_05 20130403_06

依存する関連サービスのIISなども同時にインストールされます。
20130403_07 20130403_08 20130403_09

AD FSでは、[フェデレーションサービスプロキシ]を選択します。IISはデフォルトのままで大丈夫なので、次へを押していくとインストールが完了します。
20130403_10 20130403_11 20130403_12 20130403_13 20130403_14 20130403_15

続いて、SSL関係の設定を行います。IISサービスマネージャーを開き、[サーバー証明書]の項目を選びます。[インポート]を選択し、用意しておいた証明書(.pfxファイル)とパスワードを入力します。エクスポートできるようにチェックは付けておきます。
20130403_16 20130403_17 20130403_18 20130403_19

続いては、インポートした証明書を利用してSSLのサイトを作成します。IISマネージャーの[サイト]を開き、[Default Web Site]をクリックして[バインドの編集]を選択します。デフォルトでは、HTTP(ポート80)でしか応答しないようになっているので、HTTPS(ポート443)で先ほどのSSL証明書を利用してAD FSサービス名に対して応答するようにします。
20130403_20 20130403_21 20130403_22

最後に、AD FS Proxyの構成です。スタートメニューの[ADFSフェデレーションサーバープロキシの構成ウィザード]を選択します。
20130403_23

フェデレーションサービス名を入力すると、AD FSサービスへのアクセスの資格情報を求められます。ここでは、AD FSにアクセスできる管理アカウントを指定します。次へを押すと、構成が完了です。
20130403_24 20130403_25 20130403_26 20130403_27 20130403_28

OSの基本機能でほぼいけますので、簡単ですね。

また、外部DNSでAD FSサービス名をAD FS Proxyに接続できるグローバルIPアドレスに解決できるように構成しておきます。必要に応じて、AD FSの実際のアドレスにNATするようにFirewallの設定を行います。

動作確認の為、接続してみます。ポータルからIDを入力すると、自動的に画面がリダイレクトし、AD FS Proxyのフォーム認証画面に飛びます。ここで、ID/PASSを入力してして[サインイン]をクリックすると、Office365にActive Directoryの資格情報でサインインすることができます。
20130403_29 20130403_30 20130403_32 20130403_31