Terminal Service上で動作するにはいくつか前提条件があります。ハードとかで物理的にサーバに一つしかないようなものをシェアするというのは置いといて。
ユーザごとに割り当てられるフォルダを決め打ちしない
たとえば、%temp%フォルダはセッションごとに割り振られます。C:\documents and settings\アカウント名\local settings\tempの配下にさらにセッション番号のフォルダが自動的に作られます。いくらセッション番号でユニークになるといっても、同名アカウントであればユーザプロファイルは上書きされるので、絶対にやらないでください。Active Directoryのユーザ管理面倒だから〜といってやらない人多いんですよねぇ..。具体的にはユーザ単位の配色、規定プリンタなどがあとから変更した人の情報で上書きされます。
kernel objectの名前
Mutex,セマフォ,イベント,共有メモリなどなど、カーネルオブジェクトのうち同期系のオブジェクトはGlobal\(システム全体)かLocal\(現在のユーザだけ)のPrefixをつける必要があります。何もつけなければGlobal。なので、Prefixを忘れているだけでも同時ログインすると問題が出るプログラムができてしまいます。ちなみにWindows 2000以降であればTerminal Serviceの有無関係なくPrefixつけてかまいません。NT 4.0やWindows 9x/Meを考えると問題が出てきます。なんせWTSAPI32.DLLがありませんから。
テスト
動作確認する場合、管理用に許可されているリモート接続でもかまいません。これは2セッションまで同時にログインできるので、テストでも重宝します。私も最初はこの機能使ってテストしています。Terminal ServiceのCAL買ってもいいのですけど、Terminal Serviceにするとまたまたいろいろ運用面倒だし、2007 Office SystemからはTerminal Serviceで使うとボリュームライセンスのほうを買わないといけないみたいですし。まぁ、企業で使う場合はボリュームライセンスですよね、きっと...。参考)Deploy the 2007 Office system on a Terminal Services-enabled computer
本題
ここまで前ふり。さて、何も考えていない場合、複数のユーザセッションで同時に起動するアプリケーションを作ると、共有メモリやイベント、Mutex、セマフォなどが意図しない動きになります。たちが悪いのは「複数のユーザが使う」ということに思い当たる人が多くないので、動作テストする時も「1セッションだけ」でやっちゃうんですよね...。ええ、今日Terminal Serviceに対応していない古い版を持ってきて、「1セッションだけならTerminal Service対応しているじゃないか」と真顔(?)で言ってくれる人がいて、どう理解されているんだと頭抱えました...。
