使用頻度の高いWindows Server 2008R2リモートデスクトップサーバー（VM）をどのくらいの頻度で再起動しますか？
注：私は Windowsサーバーを再起動する必要がある頻度はどれくらいですか？ を読みましたが、この質問はリモートデスクトップサーバーに関係します具体的に。
私たちはWindows Server 2008R2サーバーを持っています-VMware ESX VM-リモートデスクトップサービスのライセンス、25人のユーザーがRRAS（SSTP）も行います。平均的な平日、勤務時間中は、 8と12のログインした、アクティブなユーザーと4〜6の「切断された」ユーザー。12GHzのCPUハード予約と16 GBのRAM 、完全に予約済み。CPU予約は、必要に応じて最大24 GHzまで拡張できます。
ユーザーの多くは、サーバーのみを使用して作業しています。彼らはまた、そのパフォーマンスについてひどく不平を言っていますが、多くの人はパフォーマンスを改善するために作業習慣やソフトウェアを変更することを望んでいません。具体的には：
- ユーザーが切断するのではなく拒否するログオフする
- ユーザーは、Lync 2010の代わりにLync 2013を使用しています（Lync 2013は悪名高いリソースを独占しています）。
ログオフを拒否することの重要性を誇張することはできません。 切断されたユーザーはRAMを独占し続けます 切断されている間、これは常に、最大16のインスタンスの特定のインスタンスがあることを意味します実行中のプログラム。
また、リモートデスクトップサーバーが実行されている時間が長くなるほど、リーク/ゾンビが増加する傾向があることも経験からわかりました。再起動後、多くのユーザーがログインした後のパフォーマンスを比較した場合でも、サーバーは新鮮ではるかに高速です。また、定期的な再起動が役立つ場合があることも読みました。
VMの定期的な再起動を提案しました-毎週、たとえば土曜日の夜にそれを実行したいと思います-これらの再起動で多くの問題が解決すると思うので。
知りたいのですが、あなたがWindows管理者であれば、
ユーザーが切断/再接続した後でも、ガベージ/ゾンビ/リークがセッション時間とともに蓄積するという事実は正しいですか？
同様に利用されているWindows Serverをリモートデスクトップサービスで再起動する頻度はどれくらいですか？
一般に、Windowsサーバーを定期的に再起動する必要があるという考えには反対です[〜＃〜] except [〜＃〜] TS/RDSサーバーに関して。私たちは毎日再起動します。古いセッション、使用中のリソース（CPU、RAM、ファイルハンドルなど）が解放されるため、RDSサーバーの毎日のスケジュールされた再起動を構成することをお勧めします。
この回答は私の意見にすぎないことに注意してください。ここには事実の説明はありません。
ユーザーは切断する代わりにログオフを拒否します
それらを自動ログオフする適切なグループポリシーを設定します。アイドルタイムアウトとログオフを個別に制御できます。それは確かに日中の問題のいくつかを最小限に抑えるはずです。
3サーバーのTSファームを毎日午前3時に再起動します。なぜなら、多くの人が単一のシステムを使用している場合、はいがらくたは時間とともに蓄積する可能性があるからです。 3台のサーバーを1日の時間帯に応じて60〜90人で共有しています。
これを頻繁に再起動する必要はないかもしれませんが、Windows 2000でターミナルサービスを使い始めたので、当時のプリンタードライバーはひどいものでした。印刷スプーラーは、基本的に1日か2日稼働すると失敗します。そのため、プリンターの製造元に問題のあるドライバーを修正させるための手段がなかったため、毎晩再起動を開始しました。
現金、時間、およびユーザーの知識に応じて、2つ目のサーバーを立ち上げることもできます。それでも時々再起動する必要がありますが、単一サーバーの制限に達しているようです。
同じクライアントCALを使用できるはずです（ライセンスは私の最も重要な領域ではありません）。仮想化ソリューションによっては、追加のVMが既存のライセンスですでにカバーされている場合があります。
追加のVMリソースがなく、追加のOSオーバーヘッドがある場合でも、負荷を均等に分割できると仮定すると、2つの別々の6 GHZ CPUおよび8GiBメモリVMとしてシステムの処理が向上することがあります。3つあります。可能な方法：
- 最もクリーンな方法は、F5 Networks、Cisco Systems、および類似の会社が提供するものなど、適切なネットワークベースの負荷分散ソリューションを使用することです。このようなソリューションをすでに購入している場合は、ここで使用する価値があります。 f5は現在のRDサーバーへのアクセスに使用されるFQDNのすべてのクエリを適切に解析し、サーバーの使用率が最も低いものに基づいて適切なIPを返すため、残りの回答を無視できます。
- ラウンドロビンDNS は、まずまずの解決策です。完全に均等な負荷を保証するものではありませんが、ネットワークロードバランサーを使用できない場合は、ユーザーを教育する際（3を参照）に役立つ一時的なギャップになる可能性があります。クライアントが使用している現在のDNS名を、同じ名前でIPが異なる2つのホストレコード（2つのサーバー）で置き換えます。理想的には、個々のサーバーにリンクされている個別のホストレコードも（できればサーバーホスト名に基づいて）構成します。
DNSキャッシュの期限が切れ、クライアントが他のサーバーのIPを取得した後で、クライアントが1つのサーバーで切断されたセッションを離れたくない場合は、ラウンドロビンエントリに長いTTLを設定します。または、接続先のコンピュータのホスト名（バックグラウンドの一部にするなど）。セッションを復活させたい場合は、そのホスト名に再接続するように依頼します。
- クライアントに負荷を分散させます。ユーザー数が25未満の場合、特定のユーザーに1つのサーバーをヒットし、残りのユーザーにもう1つのサーバーをヒットするよう（サーバー上の電子メールまたはログインメッセージを介して）要求するだけでよい場合があります。または、デスクトッププラットフォームを制御している場合、またはcitrixや別のアプリケーション仮想化アプライアンスを介してサーバーにアクセスしている場合は、単に hosts file †を設定して、常に同じサーバー（デスクトップ）にアクセスするようにし、同じユーザーが常に同じサーバー（アプライアンス）に送信されます。
†常に同じデスクトップを使用する場合は、ローカルデスクトップのホストファイルを変更するだけです。マシン間を移動する場合は、スクリプト（グループポリシーを介して配布）を記述してホストファイルを解析し、現在サーバーに使用されているDNSエントリが特定のユーザーが使用するサーバーのIPを指すようにします。そのDNS名が既に存在する場合は、その行を置き換えます。存在しない場合は、ファイルの最後に追加します。
ログオフを拒否する「ユーザータイプ」に精通しています。ただし、サーバーは毎晩再起動するため、保存されていない作業は失われることを理解しているようです。これは、1台のマシンで約20人のユーザーをサポートするServer 2008 R2 TSにあります。
>ユーザーは切断する代わりにログオフを拒否します
技術的な問題ではなく、管理/人事の問題があります。ログオンしたままのユーザーが影響を及ぼしている場合他のユーザーの作業（パフォーマンスを不必要に低下させることにより）解決策は2つだけです。
それを技術的な問題にして、可能であればリソースの増加（より多くのRAM、SSDの代わりにSSDなど）を手配して、問題が解決するようにします。もちろん、単一のマシンに新しいリソースを投入することで達成できることには制限がありますが、それでうまくいくかもしれません。
それを人事管理の問題として捉え、適切な規律を奨励（または失敗させるenforcing）する方法を見つけます。もちろん、これはあなたの直接の責任の範囲外であるかもしれないので、それはあなたのオフィスの政治に応じてかなりトリッキーになるかもしれません...
デスクトップマシンを再起動しないという同様の問題があり、セキュリティ更新が数か月間キューに入れられることがありました。セキュリティポリシーでは、「既知のセキュリティ問題のパッチは、十分な緩和策が証明されない限り、エクスプロイトがすでに存在している場合は、直ちに適時にインストールする必要がある」と述べ、結局、グループポリシーによって単純に適用されました。 -server Windowsマシンは、保留中の更新がある場合、例外なく、火曜日に一晩再起動します。誰かがこれに反対する場合、2つの簡単なカウンターがあります。そのポリシーに従わないと、次にビジネスで重要な監査が行われるときに、ISO-これとその他の認定が失われます。クライアントとの契約では、セキュリティポリシーについても説明します（データを処理する場合があるため、データが安全であることをクライアントに保証する必要があるため）。この強制がないと、非常に高額な契約に違反することになります。
>ユーザーは、Lync 2010の代わりにLync 2013を使用するよう主張します（Lync 2013は悪名高いリソースの独占です）
彼らがより新しい光沢のあるものを望んでいる以外に、特定の理由はありますか？彼らが本当に必要としている機能があれば、この角度についてできることはほとんどないかもしれません。
チャットアプリケーションが主なリソースの問題である場合、セッション全体を殺すのではなく、アイドルセッションでそのプログラムのインスタンスのみを殺す方法があるのでしょうか。
>彼らは私が十分な予告なしに再起動するたびに仕事を失います、すなわち、彼らはその日の「正午」までに知る必要があるすべてを再起動するには
あなたは仕事の性質を述べていないので、これはそれが何であるかに非常に依存していますが、彼らはデューデリジェンスで失敗しているかもしれません（つまり、彼らの仕事を適切に行っていない）。
彼らが定期的にドキュメントを保存していない場合、theyはあなたではなく彼らの仕事を危険にさらしています。サーバーが停止するような停電やその他の障害が発生した場合はどうなりますか？彼らもあなたを責めますか？
もちろん、再起動時にアクティブに動作している場合や、長時間実行されているプロセスを無人のままにする必要がある場合は、本当のスケジュールの問題が発生する可能性があります。
Microsoftサーバーへの正解は、YES/NOをリブートします。ああ、人生がそんなに簡単だったら！サーバーで実行されているアプリケーションに依存します。しかし、これは簡単なガイドですが、厳格な規則ではありません。
Windowsサーバーを実行している物理サーバー** xバージョン**（自動再起動＆スケジュール）95％再起動できます隔週に1回、本当の心配はありません。 （適用されているパッチが適切で必要であることを確認してください）。ライブ/本番システムにリリースする前に、テストサーバーでパッチを完全にテストしてください。
VMWare Windows Serverを実行する仮想サーバーxバージョン-2週間に1回再起動（パッチが適用されている場合は上記のコメントを参照）
Physical VMWare Server NEVER /めったに、そして必要な場合にのみスケジュールされません。 （通常、最新の状態に保つと非常に安定します）VMWareパッチ/アップデートは再起動が必要になります。
VMWare実行中Windows SQL（再起動を制限し、Windowsパッチを適用MANUALLY ONLY！再起動[〜＃〜] if [〜＃〜 ]パッチはそれを必要とし、すべてのクライアント接続を停止した後でのみ）サーバーがバックアップされたら、接続が再接続されていることを確認します。 SQL Serverの再起動にはかなり時間がかかる場合があるため、これは数時間のうちに計画してください。
注意：VMWare（Windows Server）に変更を加える前に、それをスナップショットしてください！サービスパッチまたは更新の適用後、またはアプリケーションの起動に失敗した後にシステムがクラッシュした場合、限られたダウンタイムでサーバーバックアップをすばやく実行できます。エラーを記録しておくことを忘れないようにしてください。修正を見つけられるように、システムが単独で放置されないようにしてください。
物事を片付けるための小さな方法に役立ち、行くことを願っています。
営業担当者のように聞こえるリスクがあるため、 ShutdownPlus Rolling Restart を使用します。毎晩サーバーを再起動するように設定されています。それはかなりうまくいきます-誰もがログオフした後でのみサーバーを再起動するように設定できます。誰かがまだRDサーバーをX回使用している場合は、ループが再開されます。このツールは、必要に応じてユーザーをログオフすることもできます。または、VMをESXiでパワーサイクルします。
いくつかのGPOで使用しています。これにより、切断されたユーザーが数時間後にログオフされます。また、一定のアイドル時間が経過すると、アクティブなセッションが切断されます。これは、セッションが終了しないようにするための、時折発生する不正なプログラムです。ただし、これを回避しました。これをセットアップした方法により、すべてのサーバーが22.00から7.00まで1時間ごとに再起動を試みます。少なくとも週に2/3回、これは私には問題ありません。
残念ながら、これは無料のプログラムではありませんが、かなりうまくいきます。私は再起動する前にサーバーを更新できると期待されるpowershellスクリプトを実装しています。