ターミナル サービスは、Windows ネットワーク環境で非常に便利なサービスです。しかし、使い方を誤ると、ユーザーに多大な迷惑をかける可能性があります。たとえば、ユーザー データの損失につながり、ネットワークにセキュリティ リスクをもたらす可能性があります。ターミナル サービスの構成プロセス中に、誰もが注目する価値のあるコンテンツがまだいくつかあります。 1. 必要に応じて、サーバーをブロック解除モードで動作させます。
ターミナル サービスは Microsoft オペレーティング システムに長い間存在していましたが。ただし、2008R2 ではいくつかの改良が加えられています。中でも、ブロック解除モードは大きな目玉です。管理者は、何らかの理由でターミナル サーバーをオフラインにする必要がある場合があります。以前のバージョンでは、これによりユーザー データが失われる可能性がありました。その時点では、管理者はユーザーの接続を切断するために、change logon /disable コマンドしか使用できなかったためです。ただし、このコマンドを使用すると、新しいユーザーがログインできなくなりますが、セッションから切断したユーザーがターミナル サーバーに再接続することもできなくなります。ターミナル サーバーがダウンすると、ユーザーはセッションとそのセッションに関連付けられたデータを失います。このため、以前のバージョンでは、ターミナル サーバーをオフラインにする場合、管理者は細心の注意を払う必要がありました。ユーザーが仕事を休んでいるときにオフラインにすることを選択する必要がある場合など。これにより、日常のメンテナンス作業に無用な手間がかかります。
しかし、この状況は 2008R2 で大幅に改善されました。このバージョンのターミナル サービスではブロック解除モードが導入されたためです。サーバーをこの動作モードに設定すると、管理者はサーバーをオフラインにした後に新しいユーザーの接続をブロックできます。ただし、サーバーでは、既存のセッションを持つユーザーがターミナル サーバーに再接続できるようになります。もちろん、ユーザーが再接続した後は関連するプロンプトが表示されるため、ユーザーは適切なジョブを時間内に送信できます。明らかに、浚渫モードでの作業方法の方がはるかに人道的です。この動作モードを変更するのも非常に簡単です。これは、change logon /drain という 1 つのコマンドで実行できます。このコマンドを実行した後は、他の新しいユーザーはターミナル サーバーにログインできなくなることに注意してください。ユーザーに再度ログインを許可したい場合は、少し面倒で 2 つの手順が必要です。 1 つ目は、change logon /drainumtilrestart コマンドを実行することです。次に、ターミナル サービスが再起動されます。ユーザーはログインできるようになります。このブロック解除モードは、管理者がターミナル サーバーを保守する際に非常に役立つことがわかります。
2. WSRM を通じてターミナル サービスのユーザーにリソースを割り当てます。
ターミナル サービスをサーバーとして使用する場合、多くのユーザーがターミナル サービスに接続することになります。次に問題になるのは、これらのリソースをどのように割り当てるかということです。何も対策が講じられない場合、システムはデフォルトで均等に割り当てます。このとき、ユーザーが増えると端末サービスのパフォーマンスが急激に低下します。このため、2008 年のターミナル サービスでは、Microsoft は他の製品の関連経験も活用し、WSRM を使用してターミナル サーバーの各ユーザーのリソースの使用を管理しました。
WSRM（System Resource Manager）もwin2008で新たに実装された内容です。そして、R2 パッチでいくつかの修正が行われました。このコンポーネントを使用すると、システム管理者はサーバー リソースを割り当てることができます。つまり、アプリケーション、サービス、プロセス間でメモリや CPU などの主要なリソースをどのように割り当てるかということです。 WSRM システム リソース マネージャーをターミナル サービスと組み合わせて使用すると、管理者は各ユーザーまたはセッションに許可される最大リソース制限をより正確に制御できます。ユーザーまたはセッションが使用できるリソースを制限することにより、システム管理者はユーザーがターミナル サーバーのリソースを最大限に活用する機会を減らすことができます。
実際の作業では、一部の特別なアカウントに対して比較的高いリソース使用量を設定することがよくあります。一般ユーザーには制限がかかります。これは主に、ターミナル サービスのアップグレードなど、ターミナル サービスのメンテナンス中にシステム リソースが大量に消費されるためです。そうしないと、アップグレードが失敗するか、アップグレード時間が延長される可能性があります。このため、管理者アカウントのニーズを優先する必要があります。次に、複数のサービスが同じサーバー上で実行されている場合です。ターミナル サービスに加えてメールボックス サービスなどがある場合は、ターミナル サービスの総リソース消費量を制限する必要があります。ターミナル サービスが多くのリソースを占有し、他のアプリケーション サービスの動作に悪影響を与えることを防ぐため。
つまり、2008 環境では、端末からアクセスされるユーザーの数が比較的多い場合、または複数のアプリケーション サービスがサーバー上に同時にデプロイされている場合、著者はユーザーが WSRM システム リソース マネージャーを使用して、適切なリソースを割り当てることを推奨します。各ユーザーおよび各サービスのリソースの最大使用量。同時に、異なるユーザーと異なるサービスは、実際の状況に応じて異なる方法で扱う必要があります。つまり、主要なユーザーと主要なサービスに対するリソース使用制限を緩和する必要があります。大量のリソースを占有するその他の小規模または不定期のサービスは制限する必要があります。これにより、さまざまなサービスやユーザー間のリソースをめぐる競争が軽減されます。
3. ターミナル サーバーをアップグレードするときは注意してください。
ターミナル サーバーをアップグレードする場合、作成者は新規インストールを推奨します。ただし、サーバー上にターミナル サービスに加えて他のアプリケーション サービスがある場合、このアプローチはあまり合理的ではありません。データベース サービスとターミナル サービスが両方とも同じサーバー上にある場合、再インストールする場合はデータベース サービスを再展開する必要があります。この仕事は二日でとても大規模なものになります。この場合、アップグレードできるのはターミナル サービスのみです。ただし、アップグレードする場合は特別な注意が必要です。ただし、Microsoft はアップグレードにおいて非常に良い仕事をしました。しかし、実際の業務では、アップグレード後にターミナルサービスが正常に動作しない状況に遭遇することがよくあります。これが起こる理由はたくさんあります。アップグレードの失敗、アップグレード後の互換性の問題など。
このため、オペレーティング システムやアプリケーションの更新プログラム (パッチも同様) は、ターミナル サーバーに適用する前に別のサーバーでテストすることをお勧めします。つまり、最初にターミナル サーバーの複製を作成し (元のターミナル サーバーと同じサービスとアプリケーションを使用して)、次に複製されたターミナル サーバーを最初にアップグレードします。アップグレードが既存のアプリケーションやサービスと競合するかどうかを判断するため。このプロセス中に、管理者は関連資料に記載されていないコンテンツを発見することもあります。アップグレード前に必要な準備作業、アップグレード後に関連するアプリケーション サービスを再構成する必要があるかどうかなど。たとえば、サービスのアップグレード後、プリンタードライバーなどの再インストールが必要になる場合があります。これらを予測するのは困難です。問題はテスト後にのみ発見できます。
アップグレード プロセス中には予期せぬ理由が発生する可能性があるため、著者は、アップグレードする前に注意し、関連データをバックアップすることをお勧めします。もちろん、ベスト プラクティスとして、作成者は元のサーバーではなく最新のターミナル サーバーを使用することを推奨しています。つまり、最新バージョンのターミナル サービスがサーバーに展開され、元のサーバーが直接置き換えられます。ただし、これには、各ファイル共有と印刷デバイスを再作成したり、各クライアントをサポートする最新のドライバーを再インストールしたりするなど、より大きな作業負荷が必要になります。しかし、アップグレードによって引き起こされる問題に比べれば、それでも価値はあります。実際の業務において、最大の問題は業務量の増加ではありません。代わりに、追加のサーバーをバックアップとして追加する必要があります。次に、ユーザー データベースなどのデータはまだ移植する必要があります。
つまり、Win2008R2 ではターミナル サービスに多くの改善が加えられ、多くの新機能が追加されました。システム管理者はこれらの機能を柔軟に活用して業務を改善する必要があります。ただし、以前のバージョンのターミナル サービスから 2008R2 バージョンのターミナル サービスにアップグレードする場合は注意が必要です。ここでの私の提案は、アップグレードではなく再デプロイすることです。
-