Intuneを利用したMicrosoft 365 Apps の配布方法とバージョン管理

概要

Microsoft 365 AppsはIntuneで簡単にデバイスに配布可能です。特に制御などを考えなければ。

昔からよくある話として、勝手に機能が変わってもらっては困る、という要件があります。このような場合、システム管理者が特定のバージョンを配布し、更新管理もシステム管理者が制御することになります。
このようなきめ細やかな制御をIntune単体で実現することができるか、という話をしようと思います。
私自身スッキリする方法が見つけられているわけではありません。もっと良い方法があれば教えてもらえると助かります。

想定読者

• Windowsデバイスに対してMicrosoft 365 Appのインストールやバージョン管理を検討している人
• 脱オンプレを考えている人 / オンプレリソースを利用していない人

想定環境

• クライアントデバイスはWindows 10 or 11を想定
• Intuneを利用できること (Intune Suiteは不要)

まとめ

最初にまとめを書きます。あくまで私の考えですが、参考になれば幸いです。ご意見も募集中です！

利用したいバージョン	インターネット回線の帯域	採用すると良い管理手法	更新処理手動対応の必要性
特定チャネルの最新版	不安なし	Intuneのアプリ配布でチャネルのみ指定	なし
特定チャネルの最新版	不安あり	ODTでインストール・更新ソースをオンプレミスに指定	あり
特定チャネル・特定バージョンの最新版	不安なし	Intuneのアプリ配布+構成プロファイルでバージョン・ビルドを指定	あり
特定チャネル・特定バージョンの最新版	不安あり	ODTでインストール・更新ソースをオンプレミスに指定	あり
特定チャネル・特定バージョン・特定ビルド	不安なし	Intuneのアプリ配布+構成プロファイルでバージョン・ビルドを指定	あり
特定チャネル・特定バージョン・特定ビルド	不安あり	ODTでインストール・更新ソースをオンプレミスに指定	あり

Microsoft 365 Apps の配布方法

Intuneで配布する場合、アプリの配布機能からMicrosoft 365 Apps 専用の配布設定を選択できます。利用するチャネルなどの基本配布設定はGUIベースの構成デザイナーで指定できます。構成デザイナーにない設定を行いたい場合は、Office展開ツール(ODT)で利用するXMLデータを入力することもできます。

用意したMicrosoft 365 Appsは、アプリの割り当て方でデバイスへの配布方法を変更できます。

• 必須:デバイスに強制配布します。無操作でインストールされます。
• 登録済みデバイスで使用可能:ポータルサイトアプリを利用してユーザーが任意のタイミングでインストールできます。

ポータルサイトアプリでインストールする際の注意点

ポータルサイトアプリでインストールを行うと、ポータルサイトアプリ内でダウンロード中、インストール中といった進捗ステータスが表示されます。
Win32アプリは特に違和感なくインストールできます。

Microsoft 365 Appsの場合、インストールを始めてもステータスがダウンロード中から変わらない状況となりました。何時間待とうが変わらない。ポータルサイトアプリを起動しなおしても変わらない。ただ、イベントログや実際のアプリを見る限り、10分程度でインストールは完了しているようでした。ポータルサイトアプリの表示だけがおかしいだけのようです。
こちらの件をサポートに確認したところ、次のような回答をもらいました。

• ポータルサイトアプリに対するステータス報告に時間がかかっている可能性がある
• Win32アプリは常時起動しているIntune Management Extensionサービスがステータス報告をするので早い
• Microsoft 365 Apps は通常のチェックイン処理(数時間単位)でステータス報告をするため、反映に時間がかかる
  • Microsoft 365 Appsは複数アプリで構成されていることからこの傾向が強い
  • 手動でチェックインすることは有用

ステータス反映に時間がかかるのは分かりますが、それはあくまで管理センターに対してであって、ローカルの、処理をキックしているポータルサイトアプリのステータス反映に極端に時間がかかるのは納得いかないところです。

というわけで、ユーザーにポータルサイトアプリでMicrosoft 365 Appsをインストールさせることは、インストールが終わったかどうかが分かりにくいため不親切なのかと思います。

バージョンの指定方法

Microsoft 365 Appsのいわゆるバージョンは、チャネル・バージョン・ビルドで特定できます。各チャネルの最新版はMicrosoft 365 Apps の更新履歴 (日付別の一覧)で確認可能です。

• チャネル:最新、月次エンタープライズ、半期エンタープライズ など
• バージョン: 2406、2302 などといった4桁の数字
• ビルド: 16130.21042 といった表記で表される文字列
  • 上記でいう16130の部分はバージョンを表し、同一バージョンでは同じ値になる
  • 後述するターゲットバージョンで指定する際は、16.0.16130.21042 のようにビルド番号に「16.0」をつける必要がある

Microsoft 365 Appsをインストールする際、基本的に指定するものはチャネルのみです。更新する場合は、そのチャネル内の最新バージョン・ビルドになります。

ビルドの指定方法

インストール時点

アプリ配布の構成デザイナーおよびXMLデータでビルドを指定可能です。

構成デザイナーでの指定

構成デザイナーでビルドを指定し、割り当てを必須にすると、このビルドがクライアントに強制されます。クライアント側で手動更新して新しいビルドをインストールしたとしても、しばらくすると元のビルドに戻ります。Win32アプリの検出ルールでバージョンを指定するとこのバージョンが強制される、のと同じイメージになります。毎月セキュリティ更新があるMicrosoft 365 Appsの場合、毎月ビルドの指定し直しが必要、ということになります。
この方法でビルドを変更する場合、Microsoft 365 Appsは更新ではなく上書きインストールされることになります。上書きインストールはアプリが起動していないタイミングでしか動作しないため、Microsoft 365 Apps自身の更新処理と比較して更新されにくい状況になると考えられます。

XMLデータでの指定

XMLデータでビルドを指定した場合、このビルドは強制されません。

運用を考えると、構成デザイナーでのビルド指定は避けた方が良いように思います。

インストール後

前述の通り構成デザイナーでビルドを指定をしている場合は、構成デザイナーのビルドが強制されます。

上記以外の方法でインストールしている場合、構成プロファイルのターゲットバージョンを利用することでビルドを強制可能です。こちらは更新処理で適用されるビルドの上限を設定するイメージとなります。
毎月のセキュリティ更新リリース時にターゲットバージョンの値を変えることで、クライアントは更新処理でバージョンアップされます。

バージョンの指定方法

インストール時点

チャネルを指定することで、バージョンを指定することとほぼ同義になります。
チャネルはアプリ配布の構成デザイナーおよびXMLデータで指定可能です。
チャネルではなく、明示的にバージョンを指定することはできません。明示的にバージョンを指定したい場合はビルドとバージョンをセットで指定する必要ありです。

インストール後

インストール時と同じで、バージョンを指定することとほぼ同義になります。

チャネルを指定すると、通常そのチャネルで使われているバージョンの最新ビルドが適用されます。このためチャネルを指定さえすれば、常にそのチャネルで使われるバージョンの最新ビルドを利用できます。つまり自動更新を有効にするだけで安全に(メジャーバージョンアップさせることなく)毎月のセキュリティ更新を適用できるということです。

が、半期エンタープライズチャネルは一つのチャネル内に複数のバージョンが混在する時があります(チャネル内のバージョンアップが近い時と推測)。

このタイミングでチャネルのみ指定していると、新しいバージョンに更新されます。ここで従来のバージョンに固定する方法はありません。バージョン指定もできないので、半期エンタープライズチャネル内の特定バージョンを利用したいときは、ビルドまで指定する必要があります。

このような状況のため、半期エンタープライズチャネルに関しては、チャネルを指定するだけで特定バージョンの最新ビルドに自動更新させる、ということはできません。毎月システム管理者がビルドを指定して更新できる状態にする必要があります。

チャネルの指定方法

インストール時

アプリ配布の構成デザイナーおよびXMLデータでチャネルを指定可能です。

インストール後

構成プロファイルの更新プログラムチャネルで指定可能です。

インストールおよび更新の取得場所(ソース)

更新プログラムの適用方法はMicrosoft 365 Apps の更新プログラム管理方法の選択 に記載の通り4つの方法があります。更新元となるデータの置き場所(更新ソース)で分類すると、インターネットとオンプレの2種類になります。これは更新だけでなくインストールも同じです。

ネットワーク帯域に関する考慮事項

更新ソースをどこに置いたとしても、更新ソースとデバイス間のネットワーク帯域を意識する必要があります。私は経験上、以下のように考えています。

• 毎月のビルドの更新はネットワーク帯域にほとんど影響がない
• バージョンの更新はネットワーク帯域に大いに影響がある

ソースをオンプレミスとする場合

オンプレミスのソースとしてファイルサーバやウェブサーバを利用可能です。ここにODTでダウンロードしたデータを配置します。クライアントは、ODTのXMLデータや構成プロファイルでこの更新ソースを参照するように指定します。
更新ソースに配置したODTでダウンロードしたバージョン・ビルドが、クライアントが更新可能なバージョンとなります。このため更新ソースのバージョンをクライアントに強制可能です。

更新ソースをファイルサーバとした場合、更新のダウンロードトラフィックの制御を簡単に行うことはできないと考えます。
更新ソースをウェブサーバとした場合、例えばアクセス元制限をすることで簡易的に段階配布、ダウンロードトラフィックの集中を避けることが可能です。アクセス元制御を手動管理する必要はありますが。

インストール及び更新ソースをオンプレミスとした場合、インターネット環境ではインストールも更新も行うことはできません。AutopilotもLANまたはVPN必須となります。

ソースをインターネットとする場合

どこからでもインストール、更新が可能ですが、ネットワークのトラフィック制御を考慮する必要があります。
Microsoft 365 Appsの更新トラフィックは配信の最適化で制御されるため、基本配信の最適化で調整する必要があると考えます。
配信の最適化の運用経験はまだないため、現時点での記載は省略させていただきます。