Windows 10時代のアプリ互換性問題は、RemoteAppが救世主になるかも？ という記事を見つけました
常に新しくなるWindows 10とMicrosoft Edgeは従来型アプリにとって厄介？
「Windows as a Service（WaaS：サービスとしてのWindows）」として提供されるWindows 10は、新機能を含む新しいバージョン（ビルド）が年に数回提供され、継続的にアップグレードされていきます。企業ユーザーには「アップグレードを延期する」というオプションが提供されますが、アップグレードサイクルが長くなるだけで、「アップグレードしない」という選択肢は提供されません
企業内で開発した業務アプリケーションの開発者やパッケージアプリケーションのベンダーにとって、WaaSで変化し続けるWindows 10は少し厄介な存在です。2015年11月に提供された「Windows 10 バージョン1511（November Update）」は、事前に知らされることなく、発表と同時に配布が開始されました。
Windows 10 バージョン1511にアップグレードしたことで、互換性問題により動かなくなったアプリケーションは実際に存在しました。「開発者が『Windows Insider Program』に参加して、プレビュービルドでテストしていれば避けられたんじゃないの」という人もいるでしょう。しかし、正式版でのテストを経なければ、動作保証なんてできないはずです。
Windows 10では「Microsoft Edge」が既定のWebブラウザとなりました。Windows 10には互換性のために「Internet Explorer（IE）11」も引き続き搭載されていますが、IEを前提としたWebアプリケーションの場合、Webアプリケーションが既定のMicrosoft Edgeで開いてしまい、正常に動作しないということもあるでしょう。企業内で開発したアプリケーションであれば「グループポリシー」などを使用して、既定のWebブラウザをIEに一括変更することで対処できます。しかし、パッケージアプリケーションの場合、ユーザーに既定のWebブラウザをIEに変更してくださいと要求するのは難しいかもしれません。
RemoteAppテクノロジーが有効な解決策の一つになる？
Windows 8.1以前からWindows 10へのアップグレードに伴うアプリケーション互換性問題や既定になるMicrosoft Edgeの問題、およびWindows 10へのアップグレード後に始まる継続的なアップグレードによる絶え間ない仕様変更の可能性には、Windows Serverの「リモートデスクトップサービス（RDS）」が備える「RemoteAppテクノロジー」が有効なソリューションになるかもしれません。
RDSは、Windows Serverのデスクトップ環境をマルチユーザーで利用するサービスです。RemoteAppは、リモートで実行されるアプリをあたかもローカルで実行しているかのように利用できるRDSの機能です。Windows Server 2008 R2以降はWindows Serverの代わりに、WindowsデスクトップOSをHyper-V上で集中的に実行するVDI（仮想デスクトップインフラストラクチャ）にも対応していますが、RemoteAppはVDIの環境でも利用できます。
懸案となっているアプリケーションがRDSの環境で問題なく動くのであれば、サーバ側でアプリケーションを集中的に実行させ、Windowsクライアントからはアプリケーションの画面をリモートで操作させるようにできます。IEに依存するアプリケーションの場合、Windows Server 2008のサーバで動かせば、IE 9をWindows Server 2008のサポート期限である2020年1月15日まで安心して維持できます。
デスクトップ全体に接続してアプリケーションやIEを利用することもできますが、RemoteAppを利用すると素早くアプリケーションを開始し、少ないネットワーク使用帯域で、ローカルのデスクトップ上でアプリケーションの画面を統合できます（画面1）。また、アプリケーションからローカルのデータやプリンタを利用できるというメリットもあります。
また、マイクロソフトはWindowsクライアントだけでなく、Android、iOS、Mac、Windows Phone、Windows 10 Mobileを実行するさまざまなデバイスに対しても、RemoteApp対応のリモートデスクトップアプリを無料提供しています。RemoteAppを利用すれば、Windowsのバージョンやプラットフォームに影響されることなく、アプリケーションを提供できます。しかも、アプリケーションはサーバ側にあるので、アプリケーションの構成や更新を一元的に管理できます。
実は、Active DirectoryなしでもRemoteApp環境を構築できる
Windows Server 2008／2008 R2のリモートデスクトップサービスでは、RemoteAppを「RemoteAppマネージャー」で構成します。Windows Server 2012以降では、「サーバーマネージャー」に統合された管理コンソールを使用して、セッションベースと仮想マシンベース（VDI）の両方で、共通の操作でRemoteAppを構成できます。いずれの場合も、Active Directoryドメイン環境が前提となります
実は、ワークグループ環境のスタンドアロンのリモートデスクトップ（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」に変更します
•キー：HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\TsAppAllowList
•値の名前：fDisableAllowList
•値の種類：REG_DWORD
•値のデータ：1
コマンドプロンプトを管理者として開き、次の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アドレス
2.remoteapplicationmode:i:1
3.remoteapplicationprogram:s:"アプリケーションのフルパス"
4.remoteapplicationname:s:"適当なアプリケーション名"
5.remoteapplicationcmdline:s:
なお、アプリケーションのフルパスには、アプリケーションの実行可能ファイル（.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を利用すれば、外字の管理をサーバで集中的に行えるので、クライアント環境に影響されずに維持できるのです。
アプリの終了でログオフさせたい場合には……
デスクトップ全体へのリモートデスクトップ接続は、「ログオン（サインイン）」「切断」「ログアウト（サインアウト）」のいずれかで、セッションを接続または切断することができます。RemoteAppの場合、1つ目のアプリケーションの実行でログオンが行われ、2つ目以降のアプリケーションの実行は同じセッション内で行われます。アプリケーションを終了しても、既定ではセッションはサーバが再起動されるか、デスクトップ全体に接続してログアウト操作するまで維持されます。
Active Directoryドメインベースの標準的なリモートデスクトップサービスの展開では、標準の管理ツールを使用してセッションの時間制限や切断の動作をカスタマイズできますが、スタンドアロン環境ではそれができません。対策は、「ローカルコンピューターポリシー」によるカスタマイズです。例えば、アプリケーションを終了したら短時間でセッションも終了する（ログオフする）ようにしたいのであれば、次のポリシーを構成します。これにより、アプリケーション終了後、最短1分でセッションを終了させることができます。
•ローカルコンピューターポリシー：コンピューターの構成\管理用テンプレート\Windows コンポーネント\リモート デスクトップ サービス\リモート デスクトップ セッション ホスト\セッションの時間制限
•切断されたセッションの制限時間を設定する：1分以上の時間
•アクティブでアイドル状態になっているリモート デスクトップ サービス セッションの制限時間を設定する：なし
•制限時間に達したらセッションを中止する：有効
カーソルが点滅しない問題
筆者も先日まで気付かなかったのですが、リモートデスクトップ接続では、カーソルの点滅設定（「コントロールパネル」→「キーボード」→「速度」→「カーソルの点滅速度」）に関係なく、カーソルの点滅は無効化されます。
主に入力業務を行うアプリケーションの場合、カーソルが点滅していないと、現在のフォーカスがどこにあるのか分かりにくい場合があります。RemoteApp接続の場合は、それがさらに分かりにくくなります
リモートデスクトップ接続でカーソルの点滅が無効になるのは、リモートデスクトップ接続のネットワーク使用帯域を節約するためのWindows Server 2003およびWindows XPからの既定の仕様のようです。確認してみたところ、Windows 2000 Serverまでは何も設定しなくても、リモートデスクトップ接続のセッションでカーソルは点滅していました。
この既定の動作を解除し、カーソルを点滅するようにするには、サーバ側に次のレジストリ値を作成します（画面6）。
•キー：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server
•値の名前：CursorBlinkEnable
•値の種類：REG_SZ
•値のデータ：1
コマンドプロンプトを管理者として開き、次の1行のコマンドラインを実行すれば、上記のレジストリ値を簡単に作成できます。
REG ADD "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v "CursorBlinkEnable" /t REG_SZ /d 1
絶えず変化するWindows 10に、業務アプリケーションをその都度対応させていくのは大変な作業です。しかし、RemoteAppテクノロジーを利用して業務アプリケーションの環境を全てサーバ側に置いてしまえば、クライアント側の変更なんて「どんと来い」です。
面白い話ですが 一般ユーザーには 使用不可か
常に新しくなるWindows 10とMicrosoft Edgeは従来型アプリにとって厄介？
「Windows as a Service（WaaS：サービスとしてのWindows）」として提供されるWindows 10は、新機能を含む新しいバージョン（ビルド）が年に数回提供され、継続的にアップグレードされていきます。企業ユーザーには「アップグレードを延期する」というオプションが提供されますが、アップグレードサイクルが長くなるだけで、「アップグレードしない」という選択肢は提供されません
企業内で開発した業務アプリケーションの開発者やパッケージアプリケーションのベンダーにとって、WaaSで変化し続けるWindows 10は少し厄介な存在です。2015年11月に提供された「Windows 10 バージョン1511（November Update）」は、事前に知らされることなく、発表と同時に配布が開始されました。
Windows 10 バージョン1511にアップグレードしたことで、互換性問題により動かなくなったアプリケーションは実際に存在しました。「開発者が『Windows Insider Program』に参加して、プレビュービルドでテストしていれば避けられたんじゃないの」という人もいるでしょう。しかし、正式版でのテストを経なければ、動作保証なんてできないはずです。
Windows 10では「Microsoft Edge」が既定のWebブラウザとなりました。Windows 10には互換性のために「Internet Explorer（IE）11」も引き続き搭載されていますが、IEを前提としたWebアプリケーションの場合、Webアプリケーションが既定のMicrosoft Edgeで開いてしまい、正常に動作しないということもあるでしょう。企業内で開発したアプリケーションであれば「グループポリシー」などを使用して、既定のWebブラウザをIEに一括変更することで対処できます。しかし、パッケージアプリケーションの場合、ユーザーに既定のWebブラウザをIEに変更してくださいと要求するのは難しいかもしれません。
RemoteAppテクノロジーが有効な解決策の一つになる？
Windows 8.1以前からWindows 10へのアップグレードに伴うアプリケーション互換性問題や既定になるMicrosoft Edgeの問題、およびWindows 10へのアップグレード後に始まる継続的なアップグレードによる絶え間ない仕様変更の可能性には、Windows Serverの「リモートデスクトップサービス（RDS）」が備える「RemoteAppテクノロジー」が有効なソリューションになるかもしれません。
RDSは、Windows Serverのデスクトップ環境をマルチユーザーで利用するサービスです。RemoteAppは、リモートで実行されるアプリをあたかもローカルで実行しているかのように利用できるRDSの機能です。Windows Server 2008 R2以降はWindows Serverの代わりに、WindowsデスクトップOSをHyper-V上で集中的に実行するVDI（仮想デスクトップインフラストラクチャ）にも対応していますが、RemoteAppはVDIの環境でも利用できます。
懸案となっているアプリケーションがRDSの環境で問題なく動くのであれば、サーバ側でアプリケーションを集中的に実行させ、Windowsクライアントからはアプリケーションの画面をリモートで操作させるようにできます。IEに依存するアプリケーションの場合、Windows Server 2008のサーバで動かせば、IE 9をWindows Server 2008のサポート期限である2020年1月15日まで安心して維持できます。
デスクトップ全体に接続してアプリケーションやIEを利用することもできますが、RemoteAppを利用すると素早くアプリケーションを開始し、少ないネットワーク使用帯域で、ローカルのデスクトップ上でアプリケーションの画面を統合できます（画面1）。また、アプリケーションからローカルのデータやプリンタを利用できるというメリットもあります。
また、マイクロソフトはWindowsクライアントだけでなく、Android、iOS、Mac、Windows Phone、Windows 10 Mobileを実行するさまざまなデバイスに対しても、RemoteApp対応のリモートデスクトップアプリを無料提供しています。RemoteAppを利用すれば、Windowsのバージョンやプラットフォームに影響されることなく、アプリケーションを提供できます。しかも、アプリケーションはサーバ側にあるので、アプリケーションの構成や更新を一元的に管理できます。
実は、Active DirectoryなしでもRemoteApp環境を構築できる
Windows Server 2008／2008 R2のリモートデスクトップサービスでは、RemoteAppを「RemoteAppマネージャー」で構成します。Windows Server 2012以降では、「サーバーマネージャー」に統合された管理コンソールを使用して、セッションベースと仮想マシンベース（VDI）の両方で、共通の操作でRemoteAppを構成できます。いずれの場合も、Active Directoryドメイン環境が前提となります
実は、ワークグループ環境のスタンドアロンのリモートデスクトップ（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」に変更します
•キー：HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\TsAppAllowList
•値の名前：fDisableAllowList
•値の種類：REG_DWORD
•値のデータ：1
コマンドプロンプトを管理者として開き、次の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アドレス
2.remoteapplicationmode:i:1
3.remoteapplicationprogram:s:"アプリケーションのフルパス"
4.remoteapplicationname:s:"適当なアプリケーション名"
5.remoteapplicationcmdline:s:
なお、アプリケーションのフルパスには、アプリケーションの実行可能ファイル（.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を利用すれば、外字の管理をサーバで集中的に行えるので、クライアント環境に影響されずに維持できるのです。
アプリの終了でログオフさせたい場合には……
デスクトップ全体へのリモートデスクトップ接続は、「ログオン（サインイン）」「切断」「ログアウト（サインアウト）」のいずれかで、セッションを接続または切断することができます。RemoteAppの場合、1つ目のアプリケーションの実行でログオンが行われ、2つ目以降のアプリケーションの実行は同じセッション内で行われます。アプリケーションを終了しても、既定ではセッションはサーバが再起動されるか、デスクトップ全体に接続してログアウト操作するまで維持されます。
Active Directoryドメインベースの標準的なリモートデスクトップサービスの展開では、標準の管理ツールを使用してセッションの時間制限や切断の動作をカスタマイズできますが、スタンドアロン環境ではそれができません。対策は、「ローカルコンピューターポリシー」によるカスタマイズです。例えば、アプリケーションを終了したら短時間でセッションも終了する（ログオフする）ようにしたいのであれば、次のポリシーを構成します。これにより、アプリケーション終了後、最短1分でセッションを終了させることができます。
•ローカルコンピューターポリシー：コンピューターの構成\管理用テンプレート\Windows コンポーネント\リモート デスクトップ サービス\リモート デスクトップ セッション ホスト\セッションの時間制限
•切断されたセッションの制限時間を設定する：1分以上の時間
•アクティブでアイドル状態になっているリモート デスクトップ サービス セッションの制限時間を設定する：なし
•制限時間に達したらセッションを中止する：有効
カーソルが点滅しない問題
筆者も先日まで気付かなかったのですが、リモートデスクトップ接続では、カーソルの点滅設定（「コントロールパネル」→「キーボード」→「速度」→「カーソルの点滅速度」）に関係なく、カーソルの点滅は無効化されます。
主に入力業務を行うアプリケーションの場合、カーソルが点滅していないと、現在のフォーカスがどこにあるのか分かりにくい場合があります。RemoteApp接続の場合は、それがさらに分かりにくくなります
リモートデスクトップ接続でカーソルの点滅が無効になるのは、リモートデスクトップ接続のネットワーク使用帯域を節約するためのWindows Server 2003およびWindows XPからの既定の仕様のようです。確認してみたところ、Windows 2000 Serverまでは何も設定しなくても、リモートデスクトップ接続のセッションでカーソルは点滅していました。
この既定の動作を解除し、カーソルを点滅するようにするには、サーバ側に次のレジストリ値を作成します（画面6）。
•キー：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server
•値の名前：CursorBlinkEnable
•値の種類：REG_SZ
•値のデータ：1
コマンドプロンプトを管理者として開き、次の1行のコマンドラインを実行すれば、上記のレジストリ値を簡単に作成できます。
REG ADD "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v "CursorBlinkEnable" /t REG_SZ /d 1
絶えず変化するWindows 10に、業務アプリケーションをその都度対応させていくのは大変な作業です。しかし、RemoteAppテクノロジーを利用して業務アプリケーションの環境を全てサーバ側に置いてしまえば、クライアント側の変更なんて「どんと来い」です。
面白い話ですが 一般ユーザーには 使用不可か
※コメント投稿者のブログIDはブログ作成者のみに通知されます