Terminal Service対応プログラムを作るには(前準備編)

序文 　会社では忘れた頃に「MetaFrame対応のプログラムってどうやって作るの？」と聞かれます。一言で「複数の人が同時にアクセスしているから、それを考えることと、Terminal Serviceで動いているかどうかの判定を行えばいいです」と言っているのですが、だれもこれでは理解してくれません(当たり前？)。 　Windows 2000時代のものですが、MicrosoftのOptimizing Applications for Windows 2000 Terminal Services and Windows NT Server 4.0, Terminal Server EditionというページにTSAppDev.docというWordファイルがありますので、この中から解説します。 　Windows Server 2003で変更になったところや、MetaFrame固有の話は適宜補足します。 必要環境

• Platform SDK+Visual C++6.0か、Visual Studio .NET(2002/2003のいずれでもいいはずです)。この中にあるwtsapi32.hが必要になります。libはダイナミックリンクをするのが普通だと思うので、なくてもかまいません。
• Windows 2000 Server/Windows XP/Windows Server 2003のいずれか。欲を言えば、すべてがあるといいです。コンソールセッションへの接続、簡易ユーザ切り替え(XPのみ)、アプリケーションモードとリモート管理モード(Serverのみ)など、判定が重要になる場合があります。
• あるとうれしいMetaFrame。基本的にTerminal Serviceで動作するマルチユーザープログラムはMetaFrame上で動作します。しかし、シームレスウィンドウや、コンテンツリダイレクトの機能を味わってしまうとTerminal Serviceには戻れません。アプリケーションを違和感なく使えることと、Terminal Serviceに比べて特に狭帯域における性能もよいので、ユーザなどに提案する場合はこちらがおすすめです。個人ではちょっと手が出にくい値段ですが。

　では、まず基本的なプログラムの考え方を解説します。 気をつけなくてはならないこと 権限 　仮にもユーザがサーバにログインすることになるので、Administartor権限を与えないと動作しないようなプログラムを作らないようにしましょう。特に、Windows Server 2003では「Remote Desktop Users」というグループに所属していないとTerminal Serviceへログインできなくなりました。MetaFrameではanonymouse(匿名)ユーザという設定もありますが、これはその名の通り、一時的に割り付けられるユーザなので、ユーザプロファイルが保存されません。恒久的に使用するようなユーザは必ずユーザアカウントでログインしましょう。 　そして、ドメインコントローラへは管理以外の目的で接続しないようにしましょう。MetaFrameのマニュアルでもはっきり推奨しないと明記されています。つまりWindows 2000 Serverの場合はリモート管理モード、Windows Server 2003の場合、リモートデスクトップのみにしましょう。 　アクセス許可の互換性も「Windows 2000 Users」(Windows 2000 Server)、「完全なセキュリティ」(Windows Server 2003)にしましょう。これはアプリケーションを動作させる場合でも、まずこのモードで動作させてから、不都合があるようなレガシアプリケーションがあった場合のみ変更を検討しましょう(後からいつでも変更することができます)。 CPUの使いすぎ 　ゲームや、マルチメディア系、ベンチマークのように、一時的にCPUを独占するようなプログラムを作らないようにしましょう。複数人が共有するため、一人がCPUを使い尽くすと、他のユーザが制限を受けます。 ディスクアクセス過多 　同じ理由で、がんがんディスクにアクセスするような(しなくてはならないような)ソフトは作らないようにしましょう。そんなことしないよ！と思っても、意図しない状況でそうなることがあります。典型的な例としてはDLLの呼び出しがあります。複数のユーザが同時に、異なるDLLをロードすると、仮想メモリと物理メモリのスワップが頻繁に発生して、パフォーマンス低下を招くことがあります。オフィスで使用する専用端末形式であれば、ある程度動作させるプログラムを絞った方がいいでしょう。 メモリはいっぱい 　メモリは当然ですが、あればあるだけ使います。最近のアプリケーションは巨大なものになる傾向が特に強いので、使用量に気をつけましょう。 ネットワーク帯域 　通常のクライアント/サーバシステムであれば、基本的にサーバに流れるデータのみを気にすればよいのですが、Terminal Serviceを経由する場合、マウスやキーボードの入力情報および、ビットマップイメージの画面もネットワークに流れることになります。きわめて大量のトラフィックが流れる場合、ネットワークボードを多重化するなどの対策が必要になるでしょう。 サーバに接続されている特殊なハードウェア 　CD-ROM等を使う場合、複数のユーザが同時に使用すると競合が発生します。そのほかにもシリアルポートや、パラレルポート、USBなどが該当します。アクセスしなくてはならないようなプログラムにしましょう。 　Terminal Serviceではシリアル、パラレルポートはTerminal Serviceクライアント側のポートをサーバのポートに見せかけるような処理もできます。さらにMetaFrameではクライアントドライブをサーバのドライブに見せかけるということもできます。ただし、USB機器は一部(ICカードリーダなど)を除いてMetaFrameでもサポートされていません。帯域を使いすぎるからだそうです。 今なら仮想CD-ROMソフトのサーバ版みたいなので、ISOイメージを各クライアントにCD-ROMの用にして見せるツールがあるとうれしいかもしれないですね。 常にあなた以外の誰かが使っている(かもしれない) 　VMWare,Virtual PC(Server)などの仮想PCを実現するソフトと異なり、Terminal Serviceではそれぞれのセッションは完全に独立した環境ではありません。管理者権限を持っている誰かがサービスを止めてしまうと、同じサーバにログインしている他のユーザでもそのサービスが止まっている状態になり、プログラムが動作しなくなるかもしれません。あるいはHKEY_LOCAL_MACHINE配下のような、全体に影響を与えるレジストリを編集すると、次にログインした人が被害を受けるかもしれません。全体に設定を与えるような事をしないようにしましょう。 プログラムを作る側にわかりやすく言えば、イベント、ミューテックス、セマフォなどのカーネルリソースを使う場合は注意しましょう。これらのカーネルオブジェクトは何も考えずに作るとログインユーザ全体に影響を与えるので、改造が必要になります(後述)。 　長くなったので、いったんここまで。次に続きます。