.NET開発基盤部会」によって運営されています。†2層C/S型アプリケーションからターミナルサービスへの移行についての注意点を纏めています。Systems社のMetaFrame?、XenApp?等に対しても適用できます。2008からリモートデスクトップサービスと名称変更されています。セッション環境下で使用するアプリケーションとして設計されている必要がある。PDF出力(PDF出力やPDF参照)などは、可能。(対象アプリケーションがターミナルサービス環境下での動作をサポートしている)。ユーザ切り替えで、同時起動して、問題が起きない。複数ユーザで、リモートデスク・トップ接続して、問題が起きない。サービスやXenApp?上で確認が望ましい。解像度、色の設定は可能(リモート・デスクトップ接続の機能)。一部ショートカットが異なることがあります。†ココで言うセッションとは、ログイン・セッションを指します。†XenAPP「公開アプリケーション」では、1ユーザ1インスタンスに制限可能。「公開デスクトップ」では複数起動を制限はアプリでの実装。公開アプリケーションとは、RemoteAppに該当(RemoteAppでの制御は未確認)。「サーバー上」と「ユーザー内」で意味が違うので注意。#ターミナルサービスでは、「サーバー上」の排他も意識する必要がある。可能であればクライアント・リソースのリダイレクトを使用する。サーバ」側にリダイレクトする。デスクトップ内のエクスプローラ、アプリケーションから読み書き可能。†ターミナルサービスからのネットワーク・プリンタへ出力リダイレクト機能で、クライアント・プリンタに出力。†ログファイル、レジストリ、データベース等、ファイル・システム上の競合が発生しないか注意する。ファイル・フォルダが競合する場合、以下のように対応する。ユーザ毎にファイル名を変更する。Settingsや、C:\Usersを使用する。水平分割するなど、データの持ち方に工夫が必要になる。†グローバルにしないと名前付きカーネルオブジェクトが別々になるので注意が必要。起動数の制御は、mutexなどのWindows上の共有資源を使う。他人のログイン・セッションとぶつからないように、資源の名前空間に注意する。セッション間で共有するカーネル・オブジェクトはグローバル名前空間を使用する。カーネル・オブジェクトはセッション間で共有されません。セッションでアクセスします。†ターミナルサービス系は、3層C/Sの処理方式と比べて、ログイン・セッション、プロセスなどの各種リソースをログインしたユーザ分消費するためリソース消費量が多くなる。†ターミナルサービスで消費するメモリは、デスクトップヒープアプリケーションの使用するメモリ量。†2層C/S型では、クライアント-DB間のネットワーク・トラフィックが主なボトルネックの原因になりますが、ターミナル・サービスでは、上記に加えて、クライアント-サーバ間のRDPによる画面転送のネットワーク・トラフィックが主なボトルネックの原因になります。多数のユーザをログインして業務負荷に相当するスクリプトなどを実行する。WebのHTTPリクエスト(リクエスト電文)での負荷テストとは異なる方式。UI操作の記録・エミュレーションと言うレベルまでの負荷テストは一般的でない模様。アプリケーションの要件も確認。