Microsoft 365 Apps用の動的、リーン、ユニバーサル パッケージを構築する

注:

Microsoft 365 Apps Rangers によって作成されたこの記事では、お客様の実装全体で観察される一般的なプラクティスについて説明します。 お客様のorganizationに対するこのガイダンスの関連性を評価し、必要に応じてアプローチを適応することをお勧めします。

管理者は、organizationにMicrosoft 365 Appsをデプロイすることを計画している場合があります。 このようなデプロイは、多くの場合、基本的なMicrosoft 365 Appsをデバイスにプッシュするだけではありません。 ユーザーは、言語パック、校正ツール、Visio や Project などの追加の製品など、追加のコンポーネントが必要になる場合があります。 多くの場合、これらのシナリオは 2 番目のインストールと呼ばれますが、Microsoft 365 Appsの初期インストールは第 1 インストールと呼ばれることがよくあります。 第 1 回のインストール シナリオでは、 インストール オプション と、デプロイのサイズを適切に設定する最適 な方法を確認してください。

この記事では、Microsoft 365 Appsの動的、リーン、ユニバーサル パッケージを使用して 2 番目のインストールを実装することで、長期的なメンテナンス コストを大幅に削減し、ユーザーの満足度を向上させる方法について説明します。

課題

これまで、2 番目のインストール シナリオをサポートするタスクは、それぞれに専用のインストール パッケージを作成することで解決されました。 通常、管理者は必要なソース ファイル (約 3 ギガバイト) と Office 展開ツール (ODT) のコピーと、シナリオに合わせた構成ファイルを組み合わせます。

ただし、特に大規模な組織では、多くの場合、Microsoft 365 Appsの 1 つの構成セットがありません。 たとえば、更新チャネルが混在している場合があります。たとえば、大部分は月次エンタープライズ チャネルにあり、いくつかの特殊な目的のデバイスはエンタープライズ チャネル Semi-Annual にあります。 現在、32 ビットから 64 ビットに移行しており、しばらくの間、両方のアーキテクチャをサポートする必要があります。

前の例の各チャネルとアーキテクチャの言語パックの展開など、専用のを構築する場合は、4 つのパッケージが作成されます:月次エンタープライズ チャネル x86、月次エンタープライズ チャネル x64、Semi-Annual Enterprise Channel x86、Semi-Annual Enterprise Channel x64。 これは持続可能なアプローチではなく、次の欠点があります。

• メンテナンスコストが高い
  • 作成および保守するパッケージの数が多い。
  • 埋め込みソース ファイルは時間の経過と同時に古くなっており、サービスが必要です。
  • 実際のインストールが開始される前に、完全な 3 GB パッケージがデバイスに同期されるため、デプロイ中の帯域幅の消費量が多くなります。
• ユーザー エクスペリエンスが悪い
  • ユーザーは現在の構成を理解し、ソフトウェア ポータルから一致するパッケージを選択する必要があります。
  • 完全なソース ファイルが最初に同期されるため、デプロイ時間が長い。
  • 埋め込みソース ファイルが古い場合、更新サイクルが開始され、すべてのアプリが再び更新される前に、インストールによって完全インストールがダウングレードされます。

では、時間の経過と同時に維持するコストが低く、使い勝手の良いパッケージを構築するにはどうすればよいですか?

ソリューション: 動的パッケージ、リーン パッケージ、ユニバーサル パッケージ

これらの問題は、自己調整パッケージ、小型パッケージ、ユニバーサル パッケージを実装することで解決できます。 サンプル シナリオについて説明する前に、基本的な概念について説明しましょう。

何もハードコーディングしない 動的 パッケージをビルドします。 Office 展開ツール (ODT) の機能を使用して、パッケージが要件に合わせて自己調整できるようにします。

• Version=MatchInstalled を使用して、予期しない更新を防ぎ、クライアントにインストールされているバージョンを制御し続けます。 ビルド番号のハードコーディングは不要で、すぐに古くなります。
• Language=MatchInstalled を使用して、Office が既に使用しているのと同じ言語セットを使用してインストールするように Visio や Project などに指示します。 それらを一覧表示したり、必要な言語を挿入するスクリプトを作成したりする必要はありません。

パッケージからソース ファイルを削除して 、リーン パッケージをビルドします。 これには複数の利点があります。

• パッケージ サイズは、ODT とその構成ファイルの場合、3 GB から 10 MB 未満に小さくなります。
• クライアントに 3 GB のインストール パッケージをプッシュする代わりに、クライアントが必要なものを Office Content Delivery Network (CDN) から必要なものをプルして、帯域幅を節約できます。
  • 既存の Microsoft 365 Apps インストールに Project を追加する場合は、Office 共有コンポーネントが既にインストールされているため、50 MB 未満をダウンロードする必要があります。
  • Visio のインストールは、通常、テンプレート/ステンシルがダウンロードの大部分を果たしており、言語の数に基づいて 100 から 200 MB です。
  • 校正ツールのインストールは、通常、200 から 300 MB の完全な言語パックに対して、30 から 50 MB です。
• 2 つ目のインストール シナリオは頻繁に発生しにくく、インターネットトラフィックの負荷が軽減され、最終的に影響が軽減されます。
• Microsoft が新機能やセキュリティと品質の修正プログラムをリリースするたびに、ソース ファイルを更新する必要はありません。

アーキテクチャや更新チャネルなどのハード コーディングを行わないで 、ユニバーサル パッケージを構築します。 ODT は既存のインストールと動的に一致するため、パッケージはすべての更新チャネルとアーキテクチャで動作します。 たとえば、Visio をインストールするための 4 つのパッケージを用意する代わりに、更新チャネルとアーキテクチャのすべての順列で動作する 1 つのユニバーサル パッケージがあります。

• OfficeClientEdition を除外すると、混合 x86/x64 環境でパッケージがユニバーサルになります。
• チャネルを除外すると、更新プログラム チャネル間でパッケージがユニバーサルになります。

動的パッケージ、リーン パッケージ、ユニバーサル パッケージを構築してメリットを得る方法

アイデアは、構成ファイル内の何かをハードコーディングするのではなく、代わりに Office 展開ツールの賢さを可能な限り利用することです。

プロジェクトを既存のインストールのMicrosoft 365 Appsに追加するために構築された "クラシック" パッケージを見てみましょう。 ソース ファイル (~3 ギガバイト) と構成ファイルがあります。これは、達成したい内容を明示的に示しています。

<Configuration>
 <Add OfficeClientEdition="64" Channel="MonthlyEnterprise">
  <Product ID="ProjectProRetail">
   <Language ID="en-us" />
  </Product>
 </Add>
 <Display Level="None" />
</Configuration>

動的パッケージ、リーン パッケージ、ユニバーサル パッケージの概念を適用すると、結果は次のようになります。

<Configuration>
 <Add Version="MatchInstalled">
  <Product ID="ProjectProRetail">
   <Language ID="MatchInstalled" TargetProduct="O365ProPlusRetail" />
  </Product>
 </Add>
 <Display Level="None" />
</Configuration>

では、何が変わったのか、どのような利点がありますか?

• ODT がインストールされているバージョンと自動的に一致するため、OfficeClientEdition-attribute を削除しました。
  • 利点: 構成ファイルが x86 と x64 の両方のシナリオで機能するようになりました。
• 同じ理由でチャネルを削除しました。 ODT は、既に割り当てられている更新チャネルと自動的に一致します。
  • 特典 I: パッケージは、すべての更新チャネル (現在のチャネル、月次エンタープライズ チャネル、Semi-Annual エンタープライズ チャネルなど) に対して機能します。
  • 特典 II: 中央 IT として提供されていない更新プログラム チャネルにも機能します。 現在のチャネルを実行しているユーザーもあれば、Insider ビルド上にあるユーザーもいます。 心配しないでください。それはちょうど動作します。
• Version="MatchInstalled" を追加しました。これにより、ODT によって既にインストールされているのと同じバージョンが確実にインストールされます。
  • 利点: 予期しない更新プログラムなしで、デプロイされたバージョンを制御できます。
• 現在インストールされている言語と一致するように 言語 ID="MatchInstalled" と TargetProduct を追加し、インストールする言語のハードコーディングされた一覧を置き換えました。
  • 利点 I: ユーザーは、Office 用に既にインストールされているのと同じ Project の言語を持っています。
  • 特典 II: 言語パックのインストールを再要求する必要はありません。
  • 特典 III: また、中央の IT 管理者が提供していない使用頻度の高い言語でも機能し、ユーザーを満足させます。
• ソース ファイルを削除しました。 ODT は、Office CDN からソース ファイルの正しいセットを時間内にフェッチします。
  • 特典 I: パッケージが古くなることはありません。 ソース ファイルのメンテナンスは必要ありません。
  • 特典 II: ダウンロードは約 3 GB ではなく約 50 MB です。

もう 1 つの例: 動的、無駄のない、ユニバーサルな方法で言語パックと校正ツールを追加する

言語パックの追加や校正ツールなど、他のシナリオについても簡単に見てみましょう。 ドイツ語言語パックをインストールするクラシック構成ファイルは、次のようになります。

<Configuration>
 <Add OfficeClientEdition="64" Channel="MonthlyEnterprise">
  <Product ID="LanguagePack">
   <Language ID="de-de" />
  </Product>
 </Add>
 <Display Level="None" />
</Configuration>

ここでも、この構成ファイルは特定の 1 つのシナリオでのみ機能します (更新チャネルは月次エンタープライズ チャネルに設定され、64 ビットがインストールされています)。 その他のシナリオでは、追加のファイルとパッケージでカバーする必要があります。これにより、複雑さと所有権のコストが増加します。 動的、無駄のない、普遍的な方法でこれを修正します。

<Configuration>
 <Add Version="MatchInstalled">
  <Product ID="LanguagePack">
   <Language ID="de-de" />
  </Product>
 </Add>
 <Display Level="None" />
</Configuration>

この 1 つの構成ファイルは、x86/x64 と、現在のチャネル、月次エンタープライズ チャネル、Semi-Annual エンタープライズ チャネルなど、すべての更新チャネルで機能します。 そのため、環境内で 5 つの言語を追加する場合は、これらの "config file + ODT" パッケージのうち 5 つをビルドするだけです。 校正ツールの場合は、ProductID を "ProofingTools" に変更するだけです。

独自の構成を構築する

上記の概念は、ODT が使用されている限り、すべての Click-To-Run ベースのインストールと製品に普遍的に適用されます。 指定した製品 ID をシナリオに変更できます。 詳細については、 サポートされている製品 ID の一覧 を参照してください。

前提条件/注意事項

この概念を環境内で機能させるために満たす必要がある前提条件と、いくつかの注意事項を次に示します。

• Office 展開ツール 16.0.11615.33602 以降を使用して、Version="MatchInstalled" を有効にします。
• ODT は、一致するソース ファイルを Office CDN 上で検索できる必要があります。
• インストールを実行するために使用しているコンテキストがプロキシを走査できることを確認します。 詳細については、「Office 365 ProPlus展開とプロキシ サーバーのガイダンス」を参照してください。
• アプリのインストールに使用するアカウント (ユーザーまたはシステム) がインターネットに接続できることを確認します。
• 前に示したカスタマイズされた構成ファイルは、(/configure スイッチを使用して) 製品をインストールする場合に適していますが、/download スイッチでは動作しません。 ODT にはダウンロードを実行するための詳細 (アーキテクチャなど) がないため、これは予想されます。 上記の概念では、ファイルを事前にダウンロードする必要はありません。