Skip to content

MS_MigrationToTerminalServices

Jump to bottom
nishi_74322014 edited this page Aug 31, 2026 · 1 revision

ターミナルサービス系への移行

概要

2 層 C/S 型アプリケーションからターミナルサービスへの移行についての注意点を纏めています。

  • この考え方は、Citrix Systems 社の MetaFrame、XenApp 等に対しても適用できます。
  • Windows Server 2008 からリモートデスクトップサービスと名称変更されています。

補足（名称のその後）: Windows Server 2008 R2 以降の正式名称は
リモート デスクトップ サービス（RDS） で、現在も継続している。
Citrix 側も XenApp → Citrix Virtual Apps に改称されている。
本ページの「ターミナルサービス」は、これらを含む
1 台のサーバに複数ユーザがログオンして画面を転送する方式の総称として読むとよい。

アプリケーション

  • ターミナルサービス上で動作させるアプリケーションは、
    マルチ セッション環境下で使用するアプリケーションとして設計されている必要がある。

  • PDF 出力（PDF 出力や PDF 参照）などは、可能
    （対象アプリケーションがターミナルサービス環境下での動作をサポートしている）。

確認方法

  • Windows XP のユーザ切り替えで、同時起動して、問題が起きない。
  • 2003 / 2008 へ 複数ユーザで、リモートデスク・トップ接続して、問題が起きない。
  • 最終的には、リモート デスクトップ サービスや XenApp 上で確認が望ましい。

UI

画像

解像度、色の設定は可能（リモート・デスクトップ接続の機能）。

操作性

一部ショートカットが異なることがあります。

SSO

セッション

ココで言うセッションとは、ログイン・セッションを指します。

セッション切断・再接続

タイムアウト設定があり

二重起動防止処理の扱い

  • XenApp
    • 「公開アプリケーション」では、1 ユーザ 1 インスタンスに制限可能。
    • 「公開デスクトップ」では複数起動を制限はアプリでの実装。

公開アプリケーションとは、RemoteApp に該当（RemoteApp での制御は未確認）。

リソース

ストレージやデバイスへのアクセスを修正（DB、ログ、プリンタ）。

排他制御

「サーバー上」と「ユーザー内」で意味が違うので注意。

＃ ターミナルサービスでは、「サーバー上」の排他も意識する必要がある。

クライアント・リソース

可能であればクライアント・リソースのリダイレクトを使用する。

  • クライアント・リソースのリダイレクト機能は、

    • クライアント PC のローカル・リソースを、「ターミナル サーバ」側にリダイレクトする。
    • これにより、例えば、クライアント PC のローカル ディスク ドライブをリダイレクトして、
      リモート デスクトップ内のエクスプローラ、アプリケーションから読み書き可能。

  • リダイレクト可能なクライアント PC のローカル・リソース

    • ディスク・ドライブ
    • プリンタ
    • オーディオ・デバイス
    • シリアル・ポート

印刷

  • ターミナルサービスからのネットワーク・プリンタへ出力
  • リダイレクト機能で、クライアント・プリンタに出力。

後者の方式が推奨（印刷量が大量過ぎると、サーバ側スプーラの負荷大）。

サーバ・リソース

永続化

ログファイル、レジストリ、データベース等、
ファイル・システム上の競合が発生しないか注意する。

  • ファイル・フォルダが競合する場合、以下のように対応する。

    • ユーザ毎にファイル名を変更する。
    • C:\Documents and Settings や、C:\Users を使用する。

  • スタンドアロンで使用していた
    RDBMS、レジストリ（階層型データベース）は、
    水平分割するなど、データの持ち方に工夫が必要になる。

補足（2 層 C/S からの移行で最も踏みやすい罠）: 単一ユーザ前提のアプリは、
作業ファイルやログを固定パス（C:\Temp\work.dat など）に置いていることが多い。
ターミナルサービス上では、これが全ユーザで同じ 1 ファイルを指すため、
上書き・ロック競合・情報漏洩のいずれかを引き起こす。
移行時は、固定パスのリテラルを機械的に洗い出し、
%LOCALAPPDATA% などのユーザ プロファイル配下へ寄せるのが定石。

カーネル・オブジェクトと名前空間

グローバルにしないと名前付きカーネルオブジェクトが別々になるので注意が必要。

例えば、起動数の制御は、mutex などの Windows 上の共有資源を使う。
ただし、他人のログイン・セッションとぶつからないように、資源の名前空間に注意する。

  • セッション間で共有するカーネル・オブジェクトはグローバル名前空間を使用する。

補足（Global\ を付けるかどうかは要件次第）: 名前付きオブジェクトは、
既定では**セッションごとの名前空間（Local\）**に作られる。したがって、

  • サーバ全体で 1 インスタンスに制限したい → Global\ を付ける
  • ユーザごとに 1 インスタンスに制限したい → 既定（Local\）のままでよい

2 層 C/S 時代の「PC で 1 つ」という二重起動防止は、
業務要件としては後者に相当することが多いので、
一律に Global\ へ寄せると全ユーザで 1 人しか起動できなくなる点に注意。
なお Global\ の使用には SeCreateGlobalPrivilege が必要である。

性能

ターミナルサービス系は、3 層 C/S の処理方式と比べて、
ログイン・セッション、プロセスなどの各種リソースを
ログインしたユーザ分消費するためリソース消費量が多くなる。

接続ユーザ数

サーバ 1 台あたりの接続ユーザ数の目安。

消費メモリ

ターミナルサービスで消費するメモリは、

  • デスクトップヒープ
  • アプリケーション

の使用するメモリ量。

ネットワーク・トラフィックの変化

  • 2 層 C/S 型では、クライアント－ DB 間の
    ネットワーク・トラフィックが主なボトルネックの原因になりますが、

  • ターミナル・サービスでは、上記に加えて、
    クライアント－サーバ間の RDP による画面転送の
    ネットワーク・トラフィックが主なボトルネックの原因になります。

補足（トラフィックの性質が変わる）: 画面転送は
描画の変化量に比例するため、帯域だけでなく遅延の影響を強く受ける。
2 層 C/S のボトルネックが「1 回の問い合わせで大量の行を運ぶこと」だったのに対し、
ターミナルサービスでは「スクロールやアニメーションで画面全体が塗り替わること」が効いてくる。
移行時には、グラデーション・大きな画像・派手な再描画を避ける
といった UI 側のチューニングが効果を持つ場合がある。

負荷テスト

多数のユーザをログインして業務負荷に相当するスクリプトなどを実行する。

  • Web の HTTP リクエスト（リクエスト電文）での負荷テストとは異なる方式。

  • UI 操作の記録・エミュレーションと言うレベルまでの負荷テストは一般的でない模様。

  • 参考

参考

Tags: Windows, 仮想化, 移行

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally