どうもミツシマです。
今回はMicrosoft 365アプリ(旧Office 365アプリ)の更新に関して、インターネット上からプログラムを更新するのではなく、社内(オンプレ)の共有フォルダを参照して更新する方法を検証してみました。
最近WSUSを触る機会があったのですが、WSUSだけではMicrosoft 365アプリやOffice 2019に関しては管理出来ない仕様です。
※WSUS+SCCMがあれば出来るらしいですが。
管理PCが多く存在する環境では、それぞれがインターネット上に更新を取りに行くと、かなりのNW帯域を消費することが予想されます。
それを軽減する方法として、社内共有フォルダ上に更新プログラム(パッケージ?)を配置して、そこを参照させる方法があります。
今回はこの方法について検証していきたいと思います。
検証環境
サーバーOS:Windows Server 2016
クライアントOS:Windows 10 Pro 20H2
という感じです。
まずはグループポリシーを設定していきます。
この辺りの操作は以前検証した「(Microsoft 365)アプリの更新チャネルをADのGPOで変更する方法を検証してみた」でやっているので割愛します。
テンプレートを展開したら、
「コンピューターの構成」-「ポリシー」-「管理用テンプレート」-「Microsoft Office 2016」-「更新プログラムのパス」を「有効」にして、共有フォルダのパスを入力します。

※共有フォルダ上に最終的に配置するのは「setup.exe」・「xmlファイル」・「batファイル」となります。

(注)クライアントPCからは「読み取りと実行」権限でアクセス出来るように共有フォルダを構成する必要があります。
365アプリの表記が統一されてないのは目をつぶろう。。。(^_^;)
今回は「Microsoft 365 Apps for Enterprise」でテストしているので、xmlファイルはこんな感じになってます。(あくまで一例です。)
各種xmlファイルの表記について
Office 展開ツールのオプションの構成
等を参考にしてください。
batファイルの中身は単純にMicrosoft 365アプリをダウンロードしてくるだけなので、単純です。
今回はMicrosoft 365アプリ(旧Office 365アプリ)の更新に関して、インターネット上からプログラムを更新するのではなく、社内(オンプレ)の共有フォルダを参照して更新する方法を検証してみました。
最近WSUSを触る機会があったのですが、WSUSだけではMicrosoft 365アプリやOffice 2019に関しては管理出来ない仕様です。
※WSUS+SCCMがあれば出来るらしいですが。
管理PCが多く存在する環境では、それぞれがインターネット上に更新を取りに行くと、かなりのNW帯域を消費することが予想されます。
それを軽減する方法として、社内共有フォルダ上に更新プログラム(パッケージ?)を配置して、そこを参照させる方法があります。
今回はこの方法について検証していきたいと思います。
検証環境
サーバーOS:Windows Server 2016
クライアントOS:Windows 10 Pro 20H2
〜検証手順〜
大まかな手順の流れは- グループポリシーを設定する
- Microsoft 365アプリの更新プログラム(パッケージ?)をダウンロードするxmlファイルを準備する
- ダウンロードを実行するbatファイルを用意する
- タスクスケジューラで定期的に365アプリ(パッケージ?)をダウンロードする
という感じです。
まずはグループポリシーを設定していきます。
〜グループポリシーの設定〜
Microsoft 365アプリを管理するためには、グループポリシーテンプレートをダウンロードする必要があります。この辺りの操作は以前検証した「(Microsoft 365)アプリの更新チャネルをADのGPOで変更する方法を検証してみた」でやっているので割愛します。
テンプレートを展開したら、
「コンピューターの構成」-「ポリシー」-「管理用テンプレート」-「Microsoft Office 2016」-「更新プログラムのパス」を「有効」にして、共有フォルダのパスを入力します。

※共有フォルダ上に最終的に配置するのは「setup.exe」・「xmlファイル」・「batファイル」となります。

(注)クライアントPCからは「読み取りと実行」権限でアクセス出来るように共有フォルダを構成する必要があります。
365アプリの表記が統一されてないのは目をつぶろう。。。(^_^;)
〜xmlファイルの準備〜
次にxmlファイルを準備します。今回は「Microsoft 365 Apps for Enterprise」でテストしているので、xmlファイルはこんな感じになってます。(あくまで一例です。)
<Configuration ID="18dfa0f2-3c79-4c9d-9ab6-66c17d0359f5">
<!-- Add OfficeClientEdition="32" Channel="SemiAnnual" -->
<Add OfficeClientEdition="32" Channel="SemiAnnual" AllowCdnFallback="FALSE">
<Product ID="O365ProPlusRetail">
<Language ID="ja-jp" />
<ExcludeApp ID="Groove" />
<ExcludeApp ID="Lync" />
</Product>
</Add>
</Configuration>
各種xmlファイルの表記について
Office 展開ツールのオプションの構成
等を参考にしてください。
〜batファイルの準備〜
次にbatファイルを準備します。batファイルの中身は単純にMicrosoft 365アプリをダウンロードしてくるだけなので、単純です。
@echo off
REM 環境変数定義
set ExeFile="D:\Office365\Program\setup.exe"
set ConfigFile="D:\Office365\Program\Microsoft365E-Apps.download.xml"
REM Officeプログラムダウンロード
echo "Office365プログラムダウンロード中"
echo "画面を閉じないでください"
%ExeFile% /download %ConfigFile%
exit /b
(注)手動実行時に確認しやすいようにecho文を入れてますが、実際にタスクスケジューラで自動化した際にはあまり意味ないので、なくても構いません^^;
タスクを新規作成し、以下を設定していきます。
こんな感じでタスクスケジューラの設定は完了です。
ちなみに第3火曜日にした理由としては、「Microsoft 365 Apps の更新チャネルの概要」にもあるように
更新が大体、毎月第2火曜日にあるからです。
更新されてすぐだと不具合もあるかもしれないので、1週間後にしてます。
(この辺りは第4週火曜日とかにしてもいいかもしれませんね)
実際にうまく動作すれば「Office」フォルダが作成され、そこにプログラム(Data)がダウンロードされます。
既に最新プログラムがある際にはそれ以上ダウンロードはされず、古いバージョンしかなかった場合には、新しいバージョンのプログラムがダウンロードされるようです。
<プログラムバージョンが1種のみ>


<古いバージョンのプログラムが存在した上でダウンロード実行した場合>


半期チャネルの場合には1回の更新で約2.5GBくらいはダウンロードされるようなので、年に1回や半年に1回、Officeフォルダを綺麗にするのがいいかもしれませんね。
※今回は検証なのでOfficeフォルダを綺麗にするような動作はbatに組み込んでいませんが、それもやり方次第で可能です。
ここまでで準備が出来ましたので、最後に動作確認していきます。
〜実際の動作確認〜
検証でインターネット上から更新取得されても困るので、検証時のクライアントにはデフォルトゲートウェイを入力せずに検証しました。
まずはGPOが正しく反映されているかを確認します。
レジストリエディタを起動して確認します。
「HKLM¥SOFTWARE¥Policies¥Microsoft¥Office¥16.0¥common¥Officeupdate」
を確認するとしっかりとGPOが反映されていることが確認出来ます。

後はこの状態でExcel等を起動してアプリの更新を実行します。
<更新前>

<更新後>

ちゃんと更新出来たので一安心です( ´ー`)フゥー...
今回はこんなところで検証終わりたいと思います!!
Windows OSの更新管理はWSUS
Microsoft 365アプリは今回の方法
じゃあ仮にストアアプリの更新管理をLAN内でやりたい場合には何か方法があるのだろうか?
なんて思っちゃいました(ー_ー)!!
〜タスクスケジューラの設定〜
最後にタスクスケジューラを設定し、毎月の365アプリのダウンロードを自動化するように設定します。タスクを新規作成し、以下を設定していきます。
- 「SYSTEMで実行する」ように指定する
- 「毎月 第3火曜日に実行する」ように指定する
- 「実行するタスク(プログラムパスと開始オプション)」を指定する
こんな感じでタスクスケジューラの設定は完了です。
ちなみに第3火曜日にした理由としては、「Microsoft 365 Apps の更新チャネルの概要」にもあるように
更新が大体、毎月第2火曜日にあるからです。
更新されてすぐだと不具合もあるかもしれないので、1週間後にしてます。
(この辺りは第4週火曜日とかにしてもいいかもしれませんね)
実際にうまく動作すれば「Office」フォルダが作成され、そこにプログラム(Data)がダウンロードされます。
既に最新プログラムがある際にはそれ以上ダウンロードはされず、古いバージョンしかなかった場合には、新しいバージョンのプログラムがダウンロードされるようです。
<プログラムバージョンが1種のみ>


<古いバージョンのプログラムが存在した上でダウンロード実行した場合>


半期チャネルの場合には1回の更新で約2.5GBくらいはダウンロードされるようなので、年に1回や半年に1回、Officeフォルダを綺麗にするのがいいかもしれませんね。
※今回は検証なのでOfficeフォルダを綺麗にするような動作はbatに組み込んでいませんが、それもやり方次第で可能です。
ここまでで準備が出来ましたので、最後に動作確認していきます。
〜実際の動作確認〜
検証でインターネット上から更新取得されても困るので、検証時のクライアントにはデフォルトゲートウェイを入力せずに検証しました。まずはGPOが正しく反映されているかを確認します。
レジストリエディタを起動して確認します。
「HKLM¥SOFTWARE¥Policies¥Microsoft¥Office¥16.0¥common¥Officeupdate」
を確認するとしっかりとGPOが反映されていることが確認出来ます。

後はこの状態でExcel等を起動してアプリの更新を実行します。
<更新前>

<更新後>

ちゃんと更新出来たので一安心です( ´ー`)フゥー...
今回はこんなところで検証終わりたいと思います!!
Windows OSの更新管理はWSUS
Microsoft 365アプリは今回の方法
じゃあ仮にストアアプリの更新管理をLAN内でやりたい場合には何か方法があるのだろうか?
なんて思っちゃいました(ー_ー)!!
スポンサードリンク
コメント