Office 365 ProPlus の更新プログラムを管理する

対象: 新Office365 Office 365 Enterprise

(この記事は 2014 年 1 月 28日に Office ブログに投稿された記事 Managing Updatesfor Office 365 ProPlus – Part 2の翻訳です。最新情報については、翻訳元の記事をご参照ください。)

今回は、Office の互換性とデプロイメントのグローバルなエキスパートである Curtis Sawin と Martin Nothnagel が共同で執筆した記事をご紹介します。この記事では、管理者による Office 365 ProPlus 更新プログラムのスムーズなデプロイメントを支援する自動更新機能について説明します。

概要

この記事のパート 1 では、自動更新の動作についてご説明し、Office 365 ProPlus の新しい更新プロセスに関してお客様から多く寄せられる懸念事項とその対処方法をお伝えしました。また、記事全体を通して、更新プログラムのテストとデプロイメントについて一貫したプロセスを確立することの価値も取り上げています。

月次ビルドにはセキュリティ更新プログラム、セキュリティ以外の更新プログラム、機能強化が含まれているため、更新済みビルドのテストとデプロイメントを単一プロセスに集約することで、多様性に起因するリスクが低減され、自動化の範囲も広がり、リスクを緩和できます。さらに、こうした変更の実装に伴うリスクを確実に低減しながら、Service Pack 1 やメジャーアップデートといった変更にもすばやく対応することが可能になります。

そこで気になるのが、このようなプロセスのしくみ、必要なテストの種類、自動化の方法ではないでしょうか。

この記事では、テストとデプロイメントのプロセスを完全に自動化しながら、処理の内容とタイミングを高度に制御する方法を、例を示しながら説明します。現在の環境に自動更新を組み込む方法を検討されるうえでお役立ていただければ幸いです。

テスト/更新プロセスの概要

テストとデプロイメントのプロセスを完全に自動化する手順を以下に簡単にまとめます。

1. テスト対象のグループを決定する

2. 社内ソースからテスト対象グループに更新プログラムを配布するように構成する

3. その他のユーザーには、別の社内ソースから更新プログラムを配布するように構成する

4. "Patch Tuesday" 後、テスト用ソースを更新する

5. テスト対象グループに Office を使用してもらう

6. 2 ～ 3 週間後に実稼働用ソースを更新する

7. 復旧のための手段を用意する

では、これらの手順を 1 つずつ詳しく見ていきましょう。

テスト/更新プロセスの詳細

手順 1: テスト対象のグループを決定する

テスト対象グループに適したユーザーを見つけるこの手順が、最も大変かもしれません。IT 部門のスタッフ、社内のアプリケーションオーナー、開発者などを含めたり、各部門から代表者を選出したりすることもできますし、またはこれらのユーザーを混成させてもかまいません。テストは、全社の他のユーザーよりも先にこれらのメンバーに更新済みビルドを提供し、テスト期間中に Office アプリケーションを普段と同じように使用してもらうという方法で実施します。テスト対象グループが数週間検証して問題がなければ、更新済みの Office ビルドは全社に配布されることとなるため、グループメンバーには信頼できるユーザーを選出してください。

手順 2: 社内ソースからテスト��象グループに更新プログラムを配布するように構成する

テスト対象グループ向けの Office 365 ProPlus の構成と、全社向けの Office 365 ProPlus の構成では、更新プログラムを入手する場所が違います。セットアップ時、configuration.xml ファイルの Updates 要素を構成し、更新プログラムを有効化して UpdatePath 属性の参照先を社内ソースにします。セットアップ時に構成した更新プログラムの場所が記述されたサンプルの XML ファイル "TestingGroup.xml" の内容を以下に示します。

TestingGroup.xml の内容

</Product>

</Add>

</Configuration>

テスト対象グループに Office 365 ProPlus をインストールするコマンドラインは次のようになります。

Setup.exe /configure TestingGroup.xml

この setup.exe は、クイック実行用 Office 展開ツール (英語) のものです。

手順 3: その他のユーザーには、別の社内ソースから更新プログラムを配布するように構成する

次に、テスト対象グループ以外のユーザーが使用する別のソースの場所を指定し、そのソースから更新プログラムを検索するよう Office 365 ProPlus を構成します。この構成を記述したサンプルの XML ファイル "Production.xml" の内容を以下に示します。

Production.xml の内容

</Product>

</Add>

</Configuration>

全社のユーザーに Office 365 ProPlus をインストールするコマンドラインは次のようになります。

Setup.exe /configure Production.xml

手順 4: "Patch Tuesday" 後、テスト用ソースを更新する

新しいビルドは毎月第 2 火曜日 ("Patch Tuesday" と呼ばれています) にマイクロソフトのコンテンツ配信ネットワーク (CDN) に公開されるため、これにあわせて社内ソースを更新する必要があります。CDN はグローバルネットワークなので、通常は Patch Tuesday の当日中に CDN のすべての場所でビルドが入手できるようになります。つまり Patch Tuesday の翌日ごろにソースを更新すれば、ビルドを確実に最新の状態にすることができます。

このプロセスを自動化して管理作業を楽にする方法を紹介しましょう。これには、単一ワークステーション上でスケジュールされたタスクを使用して、Office 展開ツールを実行する定期タスクを /download スイッチで作成します。以下は、(手順 2 で指定した) テスト用ソースを最新ビルドで更新するための XML ファイルとコマンドラインのサンプルです。

UpdateTestingSource.xml の内容

</Product>

</Add>

</Configuration>

テスト用ソースに Office 365 ProPlus ソースファイルをダウンロードするコマンドラインは次のようになります。

Setup.exe /download UpdateTestingSource.xml

この XML ファイルには Version 属性が指定されていないため、上記のコマンドラインを実行すると、その時点で利用可能な最新バージョンがダウンロードされます。

以下は、上記のコマンドラインを毎月第 2 火曜日に実行するタスクスケジューラのスクリーンショットです。

これを実行することで、毎月第 2 火曜日にテスト用ソースが最新ビルドで自動更新されます。

Office 自動更新のタスクは、夜間に週 3 回、およびログオン時に毎回実行するようスケジュールされています。自動更新を有効化すると、Office 365 ProPlus がインストールされたクライアントコンピューター上でこのタスクが次に実行されたときに、テスト対象グループが更新済みビルドを入手することになります。

手順 5: テスト対象グループに Office を使用してもらう

(理想を言えば) IT 部門外のユーザーに依頼したい手順です。これについては、記事の最後で改めて説明します。

手順 6: 2 ～ 3 週間後に実稼働用ソースを更新する

更新済みビルドのユーザー受け入れテスト終了後に、テスト用ソースから実稼働用ソースにファイルをコピーします。これが最後の手順です。この例では、毎月最終週の金曜日に実施することにします。実際のタイミングは、新しいビルドのテストに要する期間と、他の大多数のクライアントをリスクにさらしたままにする期間の最適なバランスを見極めながら、現在の環境が抱えるニーズ、リスク、法的要件を踏まえて決定する必要があります。また、Office 365 ProPlus ソースファイルは、CDN からダウンロードするのではなく、テスト用ソースから実稼働用ソースの場所にコピーします。

その理由を説明します。Version 属性を指定しないため、CDN からは常に最新バージョンをダウンロードすることになりますが、アウトオブバンドビルドがリリースされている場合には (これまでにリリースされたことは 1 回しかありませんが)、毎月最終週の金曜日にダウンロードするビルドが、毎月第 2 週の火曜日にダウンロードしてテストしたビルドとは異なる可能性があります。このようなケースは非常にまれだとは思いますが、テスト用ソースのファイルを実稼働用ソースにコピーすることで、テスト済みのソースファイルを 100% 確実に提供することができます。

ソースファイルのコピーは、スケジュールされたタスクで実行できます。スクリプトやコマンドは現在使っているものを自由に適用可能です。

メモ: 新しいソースファイルをソースの場所にダウンロードまたはコピーする場合、既存のソースファイルを必ず事前に削除してください。Office 365 ProPlus では、公開されたビルドごとに新しいフォルダーが作成され (フォルダー名にはビルド番号が使用されます)、既存のファイルが上書きされません。以前のソースフォルダーを削除しないと、以下の図のように、ソースの場所に複数の Office ビルドが混在することになります。

各 Office ビルドのサイズは 900 MB を超えるため、同じフォルダーに複数のソースが格納されれば、すぐにストレージ上限に達してしまいます。Office 365 ProPlus 用のアーカイブを別途作成してそこにファイルを移動しておけば、古いファイルが今後必要になった場合も簡単に入手できます。

手順 7: 復旧のための手段を用意する

これまでの手順で、テスト対象グループによる 2 ～ 3 週間のテストを実施し、テスト済みの最新ビルドを全社に提供するまでのプロセス全体を自動化することができました。このプロセスを 1 回設定すれば、リスクが低く、メンテナンスの手間もかからない、完全に自動化された手法で Office 365 ProPlus を変更できるようになります。

では、テスト対象グループが問題を見つけた場合はどうすればよいでしょうか。ここでは、以前のビルドに復旧する (元に戻す) ための手順を説明します。

まず、更新済みビルドを実稼働環境に公開すべきでないとテスト対象グループが判断した時点で、テスト用ソースから実稼働用ソースにソースファイルをコピーするようにスケジュールされたタスクを無効化する必要があります。ソースファイルが更新されなければ、スケジュールされた Office 自動更新のタスクも無効化され、実稼働環境のエンドユーザーに最新ビルドが配布されません。

テスト対象グループが見つけた問題の重要度や影響に応じて、以前のバージョンに戻すか、テスト対象グループには最新ビルドを継続して使用してもらうかを選択します。完全に元に戻す場合は、XML ファイルを使用して復旧先のバージョンを指定し、setup.exe /configure を再度実行する必要があります。この構成を記述したサンプルの XML ファイル "Downgrade.xml" の内容を以下に示します。

Downgrade.xml の内容

</Product>

</Add>

</Configuration>

この XML ファイルでは 3 つの点に注目してください。まず、Version 属性でインストールするバージョンを指定します。次に、現在インストールされているバージョンよりも古いバージョンをインストールする場合には Add 要素の ForceDowngrade 属性も指定します。

最後に、FORCEAPPSHUTDOWN プロパティも必ず指定します。setup.exe の実行時に Office プロセスが 1 つでも実行されていると、アップグレードまたはダウングレードは失敗します。このプロパティを追加することでダウングレードが正常に実行されます。

テストに関する注意点

必要な手順は以上です。最新ビルドのテストは、テスト対象グループのメンバーとぜひ連携して行ってください。膨大な量の機能をテストしなければならないため、社内のたった 1 人のユーザーが Office のすべての機能を試し、問題なしと断言することは困難を極めます。ソフトウェア互換性テストは、そのソフトウェアを日常的に利用しているユーザーに担当してもらうのが一番です。また、ソフトウェア互換性テストでは、滞りなく通常の業務に使用できたという回答をテスト対象グループから引き出すことが目標となります。社内のさまざまな部門の代表者にテストを実施してもらえば、更新済みソフトウェアの導入が業務に与える影響を適切に判断できます。これは IT 部門の負担を少なくすることにもつながります。

テスト対象のメンバーはテスト期間中だからといって普段行わないような操作をする必要はありません。普段と同じ作業を進め、問題を見つけた場合にはいつもと同じように報告してもらいます。

まとめ

上記のテスト/更新プロセスの例を通して、以下のようなメリットを確認しました。

• 自動化を活用したゼロタッチアプローチが実現される

• 管理作業や手動テストの労力が軽減される

• プロセスの一貫性を確保することで、プロセス自体の質が向上する

• テスト期間は 2 ～ 3 週間

• 問題がなければ実稼働環境に自動でデプロイできる

• 最新ビルドの導入見送りや、古いビルドの復旧が可能

このアプローチの特長は、Office ビルドに実装された変更の内容にかかわらず、変更の適用手順が一貫しているので、リスクを削減できることです。これによって、通常の月次ビルド、最新の Service Pack、またはメジャーバージョンといった Office 365 ProPlus の変更を、すばやく低コストで適用できるようになります。そして、スピーディな変更適用、企業全体の機動性向上、コストとリスクの最小化を維持すると同時に、プロセスの品質を一定水準以上に維持することができます。

参考資料

「クイック実行 configuration.xml ファイルのリファレンス」

「Office 365 クイック実行セットアップのアーキテクチャの概要」の「更新プログラム」セクション

「新 Office ガレージシリーズ: クイック実行環境における Office ソフトウェア更新プログラムの解説 (英語)」

「新 Office ガレージシリーズ: クイック実行のカスタマイズとデプロイメントの詳細パート 3 - ソフトウェア配布ツールとの統合と自動化 (英語)」

「Microsoft Office 2013 クイック実行」