Windows 10時代のアプリ互換性問題は、RemoteAppが救世主になるかも？：その知識、ホントに正しい？ Windowsにまつわる都市伝説（51）（2/3 ページ）

個人ユーザーには無料アップグレードが提供されているWindows 10ですが、2016年はビジネス分野への導入が進むと予想されます。その際に課題となるのが利用中のアプリの互換性。リモートデスクトップサービスの「RemoteAppテクノロジー」が、救世主になるかもしれません。

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

実は、Active DirectoryなしでもRemoteApp環境を構築できる

　Windows Server 2008／2008 R2のリモートデスクトップサービスでは、RemoteAppを「RemoteAppマネージャー」で構成します。Windows Server 2012以降では、「サーバーマネージャー」に統合された管理コンソールを使用して、セッションベースと仮想マシンベース（VDI）の両方で、共通の操作でRemoteAppを構成できます。いずれの場合も、Active Directoryドメイン環境が前提となります（画面2）。

画面2　Windows Server 2012 R2のリモートデスクトップサービスにおけるRemoteAppの構成

　実は、ワークグループ環境のスタンドアロンのリモートデスクトップ（RD）セッションホストでも、RemoteApp環境を構築することができます。もちろん、Windows Serverのリモートデスクトップサービスを利用する限り、RDライセンスサーバおよびRDS CAL（クライアントアクセスライセンス）も必要となりますが、Active Directoryドメインベースの標準的なリモートデスクトップサービスよりも簡素な環境で実現できます。

　RemoteAppは、Windows Server 2008以降のリモートデスクトップサービスがサポートする機能ですが、接続先がWindows Vista Ultimate／Enterprise（SP1および更新プログラム「KB961741」が必要）、Windows 7 Ultimate／Enterprise、Windows 8.1 Enterprise、Windows 10 Enterpriseに対するリモートデスクトップ接続でも利用可能です。WindowsのデスクトップOSの場合は、RD CALは必要ありませんが、マルチユーザー利用はできません。

　なお、Homeエディションはリモートデスクトップ接続のサーバ機能を備えていません。また、Professionalエディションは、RemoteAppをサポートしません（RemoteAppのための「Rdpshell.exe」が存在しません）。

　スタンドアロンサーバやデスクトップOSでRemoteAppによる接続を可能にする最も簡単な方法は、リモートデスクトップ接続を有効化した上で、サーバ側で以下のレジストリキーにある「fDisableAllowList」値を「1」に変更します（画面3）。

• キー：HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\TsAppAllowList
• 値の名前：fDisableAllowList
• 値の種類：REG_DWORD
• 値のデータ：1

画面3　RemoteAppによる接続をサポートするには「fDisableAllowList」値を「1」に設定する。この画面は、Windows 10 Enterpriseをサーバとして利用する場合の例

　コマンドプロンプトを管理者として開き、次の1行のコマンドラインを実行すれば、上記のレジストリ値を簡単に設定できます。

REG ADD "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\TsAppAllowList" /v fDisabledAllowList /t REG_DWORD /d 1 /F

　また、別の方法としては「fDisableAllowList」値を既定の「0」のままにして、「TsAppAllowList\Applications」キーの下に、利用を許可するアプリケーションごとのレジストリを作成する方法もありますが、こちらは少し複雑なので説明はしません。

　接続元のクライアント側では、拡張子「.RDP」のテキストファイルを作成し、次の5行を記述して保存します。作成したファイルをダブルクリックして接続を開始すれば、RemoteApp接続でリモートアプリケーションを実行できます（画面4）。

full address:s:接続先のコンピュータ名またはIPアドレス
remoteapplicationmode:i:1
remoteapplicationprogram:s:"アプリケーションのフルパス"
remoteapplicationname:s:"適当なアプリケーション名"
remoteapplicationcmdline:s:

画面4　RemoteAppを利用して、Windows 7上でWindows 10の「メモ帳」を実行しているところ

　なお、アプリケーションのフルパスには、アプリケーションの実行可能ファイル（.exe、.cmd、.batなど）やMicrosoft管理コンソール（.msc）、コントロールパネル（contsol.exe）、サーバ側のアプリケーションに関連付けられたドキュメントファイルのパス（サーバからアクセス可能なローカルまたはUNCパス）などを指定できます。Windows 8以降のストアアプリ（Windows 10のユニバーサルアプリ）は指定しても実行できないことに注意してください。また、Windows 10のMicrosoft Edgeはユニバーサルアプリであるため、RemoteAppには対応していません。

日本語入力環境の制約が、業務アプリにはメリットに

　RemoteAppは、アプリケーションだけでなく、一般に「IME（Input Method Editor）」と呼ばれる日本語入力システムについても、サーバ側で実行されることの影響を考慮する必要があります。

　本連載第32回でも説明したように、Windows 8以降はIMEのフロントエンドとしてローカルのIMEを利用するようになりましたが、バックエンドではサーバ側のIMEが動作しています。そのため、ユーザーはローカルのIMEを使っていると思いますが、ユーザー辞書はサーバ側にありますし、変換の学習結果もサーバ側に保存されます。また、フォントや外字もサーバ側のものです。

• 「RemoteApp」における悩ましき日本語入力環境の問題（本連載 第32回）

　この制約は「Microsoft Office」のようなデスクトップアプリケーションの提供方法として、ローカルインストールではなく、RemoteAppを利用する場合に問題になることがあります。アプリケーションはローカルと同じエクスペリエンスで利用できても、ユーザー辞書や変換学習がサーバ側にあると作業効率が低下する場合があるからです。

　しかし、業務アプリケーションにとっては、この制約は利点になるでしょう。例えば、シフトJIS（Shift_JIS）コードの業務データがあり、外字を含む古くからのデータを維持しなければならない場合、クライアント／サーバ形態ではクライアントPCへの外字の配布やメンテナンスに苦労すると思います。それが、RemoteAppを利用すれば、外字の管理をサーバで集中的に行えるので、クライアント環境に影響されずに維持できるのです。