ログオン時間の短縮とリソースの節約には「RemoteApp」が効果的：その知識、ホントに正しい？ Windowsにまつわる都市伝説（31）

前回は、Windows 8以降の初回ログオンに時間がかかることと、リモートデスクトップ接続経由であれば少しだけ時間を短縮できることを説明しました。さらに時間とリソースを節約できる方法があります。それは「RemoteApp」です。

» 2015年05月12日 05時00分公開

[山市良，テクニカルライター]

フルデスクトップではなく、RemoteAppプログラムを使う方法

　Windows Server 2012 R2およびWindows Server 2012の「リモートデスクトップサービス（RDS）」は、「セッションベースのデスクトップ」と「仮想マシンベースのデスクトップ」の二つのタイプのリモートデスクトップ環境をウィザードベースで簡単に展開し、同じコンソール、同じ操作性で管理することができます。

　セッションベースのデスクトップは、リモートデスクトップ（RD）セッションホストの役割を実行するWindows Serverに対するマルチユーザーのリモートデスクトップ接続環境を提供します。

　仮想マシンベースのデスクトップは、Windows Server Hyper-V上で集中的に実行されるWindowsデスクトップOS（Windows 7 Service Pack（SP）1以降のEnterpriseエディション）の仮想マシンに対する、ユーザーと仮想マシンの1対1（またはプール）のリモートデスクトップ接続環境を提供します。こちらは、マイクロソフトのVDI（Virtual Desktop Infrastructure：仮想デスクトップインフラストラクチャ）の実装です。

　Windows Server 2012のRDSでは、セッションベースと仮想マシンベースの両方で、デスクトップ全体へのリモートデスクトップ接続の代わりに、“アプリケーションウィンドウ単位の接続”を可能にする「RemoteApp」展開が可能です（画面1）。RemoteAppは、Windows Server 2008およびRDP 6.0からサポートされているリモートデスクトップサービス／接続の機能であり、以前は「ターミナルサービス（TS）RemoteApp」という名前でした。

画面1　「RemoteApp」はデスクトップ全体ではなく、アプリケーションウィンドウへの接続を可能にする。セッションベースと仮想マシンベースの両方で、同じ手順でアプリケーションを公開できる

RemoteApp専用シェルだから軽くて速い

　RemoteAppは、デスクトップ全体ではなく、リモートで実行されるアプリケーションのウィンドウ範囲の画面表示だけを転送してローカルのデスクトップ上に表示するため、ネットワーク使用帯域を節約できることは容易に想像できるでしょう。RemoteAppの利点はそれだけではありません。初回を含め、ログオン時間がデスクトップ全体への接続に比べて短時間で済みます。

　次の画面2は、左側がRDセッションホストへのデスクトップ全体への接続で、右側はRemoteAppで「ペイント」を実行した様子になります。デスクトップ全体への初回ログオンには約30秒かかりましたが、RemoteApp接続の初回ログオンはアプリケーションの起動完了まで含めても15秒程度と短時間で済みました。同じユーザーで2回目にログオンすると、どちらも数秒で完了します。

画面2　デスクトップ全体へのリモートデスクトップ接続（左）とRemoteApp接続（右）。初回ログオンにかかる時間はデスクトップ全体（左）が30秒、RemoteApp（右）が15秒

　なお、RemoteAppではアプリケーションの起動時間も関係してくるので、アプリケーションによってはRemoteAppの方が時間がかかることもあります。デスクトップ全体に接続してから、スタートメニューなどからアプリケーションを手動で開始することを考えれば、RemoteAppの方が速いことに違いはありません。

　このログオン時間の違いは、デスクトップ全体へのリモートデスクトップ接続とRemoteApp接続で、デスクトップ環境を準備するシェルの違いになります。デスクトップ全体へのリモートデスクトップ接続は、ローカルログオンと同様に「Windowsエクスプローラーシェル」（explorer.exe）がデスクトップ環境を提供します。一方、RemoteAppの場合は、RemoteApp専用の「RemoteAppシェル」（Rdpshell.exe）がアプリケーションの実行環境を提供します。

　RDセッションホストへのリモートデスクトップ接続は、管理者が「シャドウ」という機能でリモート表示／制御することが可能です。この機能を利用して、RemoteAppで「ペイント」を実行中のユーザーのセッションに接続してみると、真っ黒の背景に「ペイント」のウィンドウだけが存在する、テレビ番組の映像の合成（クロマキー合成）前の状態のような様子を目にすることができます（画面3）。なお、アプリケーションで日本語入力を行っている場合は、アプリケーションのウィンドウに加えてIMEの言語バーも表示される場合があります。

画面3　RemoteAppプログラムの実行中にユーザーセッションにシャドウ接続すると、テレビ番組の映像の合成前のような状態になっている

　RemoteAppシェルの環境は、背景もなければ、タスクバーもスタートメニューもありません。その分、エクスプローラーシェルに比べて、リソースが少なくて済みます。ローカルの［Ctrl］＋［Alt］＋［Del］キーに相当するリモートデスクトップ接続の［Ctrl］＋［Alt］＋［End］キーで「タスクマネージャー」を起動してみると、エクスプローラーシェルのメモリ使用が数十MBなのに対して、RemoteAppシェルは2MB以下でした。メモリ使用量はその都度変化しますが、RemoteAppシェルはエクスプローラーシェルの約10分の1以下のメモリで動作します（画面4）。

画面4　RemoteAppシェルは、エクスプローラーシェルと比べて、圧倒的に少ないメモリで動作する

Windows 8.1のVDI環境でも比較してみました

　Windows 8.1 Enterpriseを実行する複数の仮想マシンで構成されたVDI環境でも同様に、メモリの使用状況を比較してみました。なお、比較のために、仮想マシンの構成は仮想プロセッサー1基、メモリ1GBで共通しており、RemoteFX仮想GPU（RemoteFX 3Dビデオアダプター）は割り当てていません。ちなみに、RemoteFX仮想GPUは、RemoteAppをサポートしていない（RemoteAppによる接続ができない）ことを念のため指摘しておきましょう。

　次の画面5は、左側がVDIの仮想マシンへのデスクトップ全体へのリモートデスクトップ接続、右側がRemoteAppでペイントを実行している様子になります。RDセッションホストの場合と同じように、RemoteAppシェルはエクスプローラーシェルの10分の1以下のメモリで動作します。

画面5　Windows 8.1のVDI環境において、デスクトップの全体に接続した場合（左）と、RemoteAppでペイントを実行した場合（右）のシェルのメモリ使用量の比較。RemoteAppシェルはやはり10分の1以下

　シェルのメモリ使用量が少ない分、RemoteApp環境では個々の仮想マシンが必要とするメモリが少なくて済みます。「タスクマネージャー」を起動して比較してみると、一目瞭然です（画面6）。

画面6　デスクトップ全体への接続とRemoteApp接続では、仮想マシンが必要とするメモリ量も違う。RemoteAppはより少ないメモリで済む

　フルデスクトップ環境よりも速くて軽いRemoteAppはいいことずくめのようですが、実は日本語環境では場合によっては不都合な仕様となっています。次回はその辺りを説明します。

「その知識、ホントに正しい？ Windowsにまつわる都市伝説」バックナンバー

筆者紹介

山市良（やまいちりょう）

岩手県花巻市在住。Microsoft MVP：Hyper-V（Oct 2008 - Sep 2015）。SIer、IT出版社、中堅企業のシステム管理者を経て、フリーのテクニカルライターに。マイクロソフト製品、テクノロジを中心に、IT雑誌、Webサイトへの記事の寄稿、ドキュメント作成、事例取材などを手掛ける。個人ブログは『山市良のえぬなんとかわーるど』。

ファイル共有プロトコルSMB／CIFS（その1）
今回より、Windowsネットワークの核心、SMB／CIFSに入る。ネットワーク設計やトラブルシュートなどで不可欠な知識だ。
ファイル共有プロトコルSMB／CIFS（その2）
Windowsネットワークの核心、SMB／CIFS解説の第2回。SMBプロトコルにおけるリソースの公開とその使用までの処理を追う。
ファイル共有プロトコルSMB／CIFS（その3
SMB／CIFSプロトコルのパケットの構造やコマンド・コードの詳細。Windowsネットワークのトラシューには必須の情報だ。
強化されたファイル共有プロトコルSMB 3.0の概要
Windows Server 2012ではファイル共有プロトコルが強化され、SMB 3.0となった。クラスター環境対応やスケールアウト／マルチチャンネル対応などによるパフォーマンス改善、そして管理機能の強化と、改善点は多岐にわたる。本稿ではその概要をまとめておく。