Windows Server 2019 RDS VDI 非永続デスクトップの業務アプリ更新を反映する方法（管理ツールなし・GPO不可）

Windows Server 2019 の RDS VDI で非永続デスクトップを運用していると、業務アプリの更新が意外と厄介です。GPO配布も管理ツールもない場合でも、ゴールデンイメージを更新して再展開する手順を押さえれば、少ない台数でも安全に最新版へ揃えられます。

前提：RDS VDI（非永続デスクトップ）では「端末に更新を当てる」発想が破綻しやすい

Windows Server 2019 の RDS（Remote Desktop Services）で VDI（Virtual Desktop Infrastructure）を構成し、sysprep 済みの Windows 10 イメージから複数台の 非永続（non-persistent）デスクトップを展開しているケースでは、業務アプリの更新に独特のクセがあります。

結論から言うと、非永続デスクトップのアプリ更新は「ゴールデンイメージ（元イメージ）を更新し、VDI を再展開して反映する」運用が基本です。GPO 配布（ソフトウェアインストール/スタートアップスクリプト等）が使えない、SCCM/Intune などの管理ツールもない、という制約があるならなおさらです。

なぜ非永続デスクトップだと自動更新が効きにくいのか

非永続デスクトップは、ログオフや再起動、再作成のタイミングで OSディスクの変更が破棄される設計になっていることが多く、端末に対して行った更新は「その瞬間だけ」になりがちです。仕組みとしては、ベースとなるマスターイメージに差分ディスクを重ねる（または再作成する）方式が一般的で、差分側に書き込まれた更新は恒久的に残りません。

観点	永続（persistent）	非永続（non-persistent）
OSディスクの状態	基本的に保持される	ログオフ/再作成で破棄されやすい
アプリ更新の考え方	各端末を更新しても意味がある	各端末の更新は消えるため効果が薄い
運用の軸	端末管理（パッチ・配布・個別対応）	マスター管理（イメージ更新・再展開）
向いている用途	個別要件が強い端末/検証端末	同一構成で揃える業務端末

また、業務アプリ側の事情として次のようなパターンもよくあります。

• per-machine（端末単位）インストールが前提で、更新にも管理者権限が必要
• 更新サービスやタスクが 「仮想/共有環境では無効」として自動更新が抑制される
• ユーザーが毎回同じ端末を使う前提ではないため、アプリの「差分更新」が想定どおり積み上がらない
• 更新に伴う再起動が必要だが、VDI のセッション運用と噛み合わず先延ばしになりがち

このため、非永続デスクトップで「各VMに手作業で更新」や「ユーザーに更新させる」運用は、台数が少なくても事故の温床になります。確実に揃えるなら、元イメージを更新して再展開が最短距離です。

今回の条件（管理ツールなし／GPO配布不可／5台）での最適解

ご質問の条件は次のように整理できます。

• Windows Server 2019 の RDS VDI
• sysprep 済み Windows 10 から非永続デスクトップを 5 台展開
• 業務アプリを更新したい
• GPO で配布できない
• SCCM/Intune 等の管理ソフトもない

この条件だと、更新の「配布/実行」を各VDIに横展開する仕組みを新規に用意するより、ゴールデンイメージを更新して再展開する方が、工数もリスクも小さいです。特に 5 台規模なら、更新作業は「仕組みづくり」より「確実に同じ状態に揃える」ことを優先した方が失敗しにくくなります。

全体像：マスター更新 → 検証 → キャプチャ → 再展開

更新作業は、次の流れに分解して考えると迷いません。

フェーズ	作業内容	成果物/ゴール	ポイント
準備	現状把握、インストーラー確保、影響範囲確認	更新手順とロールバック案	「どこが変わるか」を先に明確化
マスター更新	旧版アンインストール → 新版インストール	更新済みマスターVM	per-machine 前提で整理
検証	起動/ログオン/業務操作/印刷/連携など確認	OK/NG 判定	「使う機能」から逆算してテスト
キャプチャ	sysprep・イメージ化・テンプレート化	新しいゴールデンイメージ	再展開しても同じ状態になるか
再展開	VDI を再作成/再構成し全台へ反映	全VDIが最新版	段階展開とロールバックを用意

事前準備：更新に入る前に確認しておくこと

「インストールできた」だけで終わらせないために、最低限ここを押さえてから作業を始めると安定します。

アプリのインストール形態を把握する

• MSI か EXE か（サイレントオプション・ログ出力方法が変わる）
• per-machine / per-user（非永続は原則 per-machine が扱いやすい）
• 更新方式（上書き更新が可能か、旧版アンインストール必須か）
• 依存関係（.NET、VC++ ランタイム、Java、ブラウザアドオン等）
• ライセンス形態（端末固定/ユーザー固定/ライセンスサーバー/トークン）

「残したいもの」と「消えてよいもの」を仕分ける

非永続だと、OS側に置いたものは基本的に消えます。逆に言えば、残すべきデータは OS の外（プロファイルコンテナやファイルサーバー等）に置く設計が必要です。アプリ更新の前に、どこに何が保存されるかを把握しておくと、再展開後の問い合わせが激減します。

種類	よくある保存先	非永続での扱い	対策例
ユーザーデータ	ドキュメント/デスクトップ/業務フォルダ	消えると致命的	ホームドライブ/OneDrive/共有フォルダへ退避
アプリ設定（ユーザー単位）	%APPDATA% / HKCU	プロファイルが残るなら保持可能	FSLogix などでプロファイルを永続化
アプリ設定（端末単位）	ProgramData / HKLM	再展開で初期化される	必要ならマスターへ組み込み、または起動時に復元
プラグイン/アドイン	アプリ配下/Office 配下	再展開で揃う	マスターで一括管理（手動導入を禁止）

ロールバック用に「戻れる状態」を作る

更新は必ずしも成功しません。特に業務アプリは「最新版が常に正義」ではないため、ロールバックを先に用意します。

• 旧ゴールデンイメージを 削除せず保管（テンプレート/スナップショット/バックアップ）
• 更新済みイメージをいきなり全台展開せず、検証用の1台で動かす
• 障害時の切り戻し手順（どのコレクションを切り替えるか、ユーザーへの案内）を文書化

手順：ゴールデンイメージ（マスター）を更新する

環境の作り方（Hyper-V、VMware、他）によって画面は変わりますが、考え方は共通です。ここでは「マスターとなる Windows 10 をメンテナンス用に起動し、アプリを更新して、再度イメージ化して配布する」という流れで説明します。

メンテナンス用マスターVMを作る

• 現在のゴールデンイメージから メンテナンス用のVMを1台クローン/展開する
• ユーザーが普段使うVDIコレクションとは切り離し、検証専用として扱う
• 可能なら、更新前の状態で スナップショットを取得しておく

ポイントは「普段使っている非永続VDI（差分が消える個体）」を直すのではなく、元になるマスターを直すことです。

旧版を確実にアンインストールする

上書き更新できるアプリでも、非永続環境ではバージョンの混在や残骸がトラブルになりがちです。基本は 旧版アンインストール → 新版インストールで揃えます。

• 「アプリと機能」または「プログラムと機能」でアンインストール
• MSI 製品なら msiexec を使って静かにアンインストール（ログも残す）
• アンインストール後に再起動が要求される場合は、一度再起動してから次へ進む

MSI の例（製品コードが分かっている場合）

msiexec /x {PRODUCT-CODE-GUID} /qn /norestart /l*v C:\Temp\app_uninstall.log

「製品コードが分からない」「EXE でしか提供されていない」場合は、ベンダーが用意しているアンインストーラーや、コマンドラインスイッチ（/uninstall など）を確認して、必ずログを残すのがおすすめです。

最新版をインストールする（できればサイレント＋ログ出力）

マスター更新は “再現性” が命です。次回以降の更新でも同じ手順で回せるよう、可能な限りサイレント実行とログ出力を行います。

MSI の例

msiexec /i C:\Installers\app_latest.msi /qn /norestart /l*v C:\Temp\app_install.log

EXE の例（一般的なパターン）

C:\Installers\app_latest.exe /silent /norestart /log C:\Temp\app_install.log

• インストーラーは、ネットワークから落としてその場で実行するより、社内共有に保管して版管理する
• 「オンラインアップデートで最新版へ」ではなく、オフラインインストーラーを使う（いつの間にか版が変わる事故を防ぐ）
• 業務要件的に自動更新が不要/危険なら、自動更新機能はマスター側で無効化し、更新はイメージ更新で統一する

VDI向けの追加調整（必要な場合のみ）

アプリによっては、VDI での同時利用やリダイレクト機能（印刷/USB/クリップボード等）と相性が出ます。次の項目は、該当する場合だけ実施します。

• 初回起動時にしか出ない設定ウィザードを、管理者で一度起動して完了させる
• 業務で必要なテンプレート、辞書、証明書などを ProgramData や共有フォルダに配置
• アプリが使うファイアウォール例外やURL許可リストを設定
• RDS/VDIで非推奨の常駐モジュールや自動更新タスクを停止（ベンダー推奨がある場合）

動作確認：テスト観点を「実業務」に寄せる

「起動したからOK」だと、本番で詰みます。最低限、次のような観点で確認します。

• 起動・ログオン・終了が正常（プロセスが残留しない）
• ファイルの作成/保存/印刷/エクスポートが正常
• 他システム連携（ブラウザ起動、URLスキーム、Office連携、PDF連携など）が正常
• ライセンス認証が正常（再展開後も問題が起きない方式か）
• イベントログに致命的なエラーが残らない

sysprep とイメージ化：更新済み状態を“配布可能な形”にする

すでに sysprep 済みの Windows 10 から展開している場合でも、マスターを更新したら「再度配布できる状態」に整える必要があります。一般的には、次のいずれかの運用になります。

• メンテナンス用マスターVM（sysprep前）を常設し、更新のたびに sysprep → キャプチャする
• 更新前スナップショットに戻せる前提で、更新 → sysprep → キャプチャを繰り返す

注意点として、sysprep は OS や構成によって制約（実行回数、ストアアプリ、更新の状態など）で失敗することがあります。更新作業を始める前に、必ず「sysprep まで通る」状態を確保しておくと、夜間作業が地獄になりません。

手順：更新済みイメージで非永続VDIを再展開する

RDS VDI の具体的な再展開方法は構成次第ですが、狙いは常に同じです。新しいゴールデンイメージを参照するデスクトップを作り直し、ユーザーを新しい方へ寄せることです。

段階展開（おすすめ）

いきなり全台を置き換えるのではなく、次の順番にすると安全です。

1. 検証用の 1 台だけ新イメージで作成し、管理者/代表ユーザーで動作確認する
2. 問題がなければ残り 4 台を新イメージで再作成する
3. 旧イメージのコレクション/テンプレートは、一定期間だけ保管しておく

再展開後に必ずやる確認

• 全VDIでアプリのバージョンが揃っている（起動して表示される版も確認）
• ショートカットやファイル関連付けが正しい
• ユーザープロファイル（デスクトップや設定）が期待どおり残っている
• プリンタやドライブリダイレクトなど、RDS 側の機能が阻害されていない

アプリのバージョン確認を“作業手順”に組み込む

更新作業は「インストールした気がする」になりやすいので、バージョン確認をチェックリスト化します。GUI で見てもよいですが、ログとして残すなら PowerShell が便利です。

インストール済みバージョンをレジストリから確認する例

Get-ItemProperty "HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*" |
  Where-Object { $_.DisplayName -like "*アプリ名*" } |
  Select-Object DisplayName, DisplayVersion, Publisher

64bit OS で 32bit アプリを探す例

Get-ItemProperty "HKLM:\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*" |
  Where-Object { $_.DisplayName -like "*アプリ名*" } |
  Select-Object DisplayName, DisplayVersion, Publisher

これを「マスターVMで確認」「再展開後のVDIでも確認」と二段階にするだけで、反映漏れが激減します。

よくある落とし穴と対処

症状	原因の典型	対処の方向性
更新したはずなのに、翌日には旧版に戻っている	非永続で差分が破棄されている	各VM更新をやめて、マスター更新→再展開に切り替える
一部のVDIだけ版が違う	旧イメージから作られたVMが混在	イメージの参照先を統一し、再作成で揃える
インストールは成功するが起動しない	依存ランタイム不足、権限、ドライバ要件	必要コンポーネントをマスターへ組み込み、イベントログで原因確認
初回起動時に毎回ウィザードが出る	初期設定が端末側（ProgramData/HKLM）に保存されている	マスターで一度完了させるか、起動時に設定ファイルを配布する
ライセンスが毎回飛ぶ/再認証になる	端末IDにひも付く方式で、非永続と相性が悪い	ユーザー/サーバーライセンスへ変更、ベンダーにVDI前提の方式を確認

管理ツールなしでも回る「マスター更新」の運用テンプレ

台数が少ないうちは気合で回ってしまいがちですが、仕組み化しておくと更新が怖くなくなります。

イメージに“バージョン番号”を付ける

• 例：Win10-RDS-Base-2025.12 / Win10-RDS-Base-2026.01
• アプリ更新時は、変更点（アプリ名・版・実施日）を簡単にメモする
• 旧版イメージは一定期間だけ残す（ロールバック用）

インストーラー保管場所を固定する

• 社内共有フォルダに「アプリ名/バージョン」単位で保管
• ベンダーサイトから都度ダウンロードしない（リンク切れ/差し替えリスク）
• 可能ならハッシュ（SHA256 など）を記録して、同一ファイルであることを担保

検証担当を決め、テスト手順を固定する

5 台規模でも、更新が失敗すると業務影響は同じです。テスト項目を「毎回同じ」にしておくと、判断が速くなります。

チェック項目	確認方法	合格条件
起動/終了	実際に起動して終了、タスクマネージャー確認	残留プロセスなし
主要業務操作	代表的な帳票/画面/処理を1つずつ	エラーなく完了
保存/印刷	PDF出力やプリンタ出力	出力が正常
連携	ブラウザ/Office/外部ツール連携	想定どおり連携
パフォーマンス	起動時間/操作感の体感	著しい劣化がない

どうしても「再展開」が難しいときの代替策

基本はマスター更新→再展開ですが、事情によってはすぐに再展開できない場合もあります。そのときの“妥協案”も知っておくと、トラブル対応の引き出しになります。

起動時に更新を当てる（ワークアラウンド）

マスターに「起動時チェック＋必要ならインストール」を仕込めば、GPO がなくても一定の強制力を持たせられます。たとえば、スタートアップフォルダやタスクスケジューラで PowerShell を実行し、共有フォルダの最新版と比較してインストールする方法です。

ただし非永続では、再起動や再作成のたびに同じ更新処理が走る可能性があり、ネットワーク負荷やログオン遅延を招きます。恒久運用というより「緊急避難」として考えるのが無難です。

RemoteApp 化してサーバー側で一元更新する

VDI のデスクトップにアプリを配るのではなく、RDS の RemoteApp として公開し、アプリはサーバー側で持つ設計に寄せる手もあります。アプリ更新がサーバー単位になり、VDI の再展開頻度を下げられることがあります。

• メリット：更新対象が減る、端末差異が出にくい
• デメリット：アプリの互換性、周辺機器、操作感、同時接続数などの設計が必要

アプリの配布方式を見直す（MSIX など）

アプリが MSIX に対応している、あるいはパッケージ化できるなら、配布と更新のやり方を中長期で改善できます。ただし、現状「管理ツールなし」で運用している場合、仕組み導入のコストが先に立つため、短期解としてはマスター更新が現実的です。

まとめ：非永続VDIのアプリ更新は「再インストール＋再展開」が一番確実

非永続デスクトップでは、各端末に更新を当てても状態が残らず、アプリの自動更新も効きにくいことがあります。GPO 配布や SCCM/Intune 等が使えないならなおさら、ゴールデンイメージで旧版をアンインストール → 新版をインストール → 更新済みイメージでVDIを再展開という流れが、最も確実で運用コストも読める方法です。

台数が 5 台規模なら、「配布の仕組みを頑張る」より「マスター更新の手順を固める」方が、結果的に早く・安全に・同一構成を維持できます。まずは検証用 1 台で更新の流れを固め、うまくいったら全台へ展開する、という段階的な運用をおすすめします。