À quelle fréquence redémarrez-vous un serveur de bureau à distance (VM) Windows Server 2008R2 très utilisé?

Remarque: j'ai lu à quelle fréquence les serveurs Windows doivent-ils être redémarrés? mais cette question concerne spécifiquement notre serveur Remote Desktop .

Nous avons un serveur Windows Server 2008R2 - une machine virtuelle VMware ESX - sous licence pour les services Bureau à distance, 25 utilisateurs qui font également RRAS (SSTP). En moyenne en semaine, pendant les heures de travail, il y a entre 8 et 12 utilisateurs actifs connectés avec 4 à 6 utilisateurs "déconnectés" supplémentaires. Il dispose d'une réserve matérielle CPU de 12 GHz et de 16 Go de RAM, également entièrement réservés. La réservation du processeur est extensible à 24 GHz max en cas de besoin.

Beaucoup de nos utilisateurs dépendent exclusivement du serveur pour fonctionner. Ils se plaignent également amèrement de ses performances, mais beaucoup ne sont pas disposés à changer leurs habitudes de travail ou leurs logiciels pour améliorer leurs performances. Plus précisément:

• Les utilisateurs refusent de se déconnecter au lieu de se déconnecter
• Les utilisateurs insistent pour utiliser Lync 2013 au lieu de Lync 2010 (Lync 2013 est un porc de ressources notoire)

Je ne saurais trop insister sur l'importance de leur refus de se déconnecter. Les utilisateurs décontenancés continuent de monopoliser la RAM lorsqu'ils sont déconnectés, ce qui signifie qu'à tout moment, nous avons jusqu'à 16 instances de certains programmes en cours d'exécution.

J'ai également remarqué par expérience que les fuites / zombies ont tendance à s'accumuler plus longtemps qu'un serveur Remote Desktop a fonctionné. Après un redémarrage, le serveur est frais et beaucoup plus rapide, même lorsque l'on compare les performances après que de nombreux utilisateurs se sont connectés. J'ai également lu que les redémarrages réguliers peuvent être utiles.

J'ai donc proposé des redémarrages réguliers de la machine virtuelle - je voudrais le faire chaque semaine, disons samedi soir - car je pense que ces redémarrages résoudraient une grande partie du problème.

J'aimerais savoir si vous êtes administrateur Windows,

• Ai-je raison de dire que les déchets / zombies / fuites s'accumulent avec le temps de la session, même après qu'un utilisateur se déconnecte / se reconnecte?

• À quelle fréquence redémarrez- vous un serveur Windows similaire avec des services Bureau à distance?

En règle générale, je m'oppose à l'idée qu'un serveur Windows devrait être redémarré régulièrement, SAUF en ce qui concerne les serveurs TS / RDS. Nous redémarrons le nôtre tous les jours. Il efface les anciennes sessions, les versions en cours d'utilisation des ressources (CPU, RAM, descripteurs de fichiers, etc.), donc mon avis et suggestion serait de configurer un redémarrage planifié quotidien de vos serveurs RDS.

Notez que cette réponse n'est que mon avis. Il n'y a aucun énoncé de fait ici.

Les utilisateurs refusent de se déconnecter au lieu de se déconnecter

Configurez les stratégies de groupe appropriées pour les déconnecter automatiquement. Vous pouvez contrôler séparément un délai d'inactivité et une déconnexion. Cela devrait certainement minimiser une partie du problème pendant la journée.

Je redémarre ma batterie de serveurs TS 3 serveurs tous les jours à 3h00. Parce que, oui, la merde peut s'accumuler avec le temps lorsque beaucoup de gens utilisent un seul système. Nous avons 3 serveurs partagés entre 60 à 90 personnes selon le jour et la période de l'année.

Je n'ai probablement pas besoin de redémarrer fréquemment, mais nous avons commencé à utiliser les services Terminal Server avec Windows 2000 et nos pilotes d'imprimante étaient horribles à l'époque. Le spouleur d'impression échouerait essentiellement après un jour ou deux. Nous avons donc commencé à redémarrer tous les soirs car nous n'avions aucun moyen de convaincre les fabricants d'imprimantes de réparer leurs pilotes de merde.

Selon votre argent, votre temps et le bon sens de vos utilisateurs, une autre idée pourrait être de mettre en place un deuxième serveur. Vous devrez toujours redémarrer de temps en temps, mais vous semblez atteindre les limites d'un seul serveur.

Vous devriez pouvoir utiliser les mêmes licences d'accès client client (la licence n'est pas mon domaine le plus important), et selon votre solution de virtualisation, une machine virtuelle supplémentaire peut déjà être couverte par les licences existantes.

Même sans ressources VM supplémentaires et avec la surcharge supplémentaire du système d'exploitation, vous pouvez trouver que le système se comporte mieux comme deux CPU 6 GHZ distinctes et des machines virtuelles de mémoire 8GiB, en supposant que vous pouvez répartir la charge uniformément. Il existe trois méthodes potentielles:

1. Le moyen le plus propre consiste à utiliser une solution d'équilibrage de charge basée sur le réseau appropriée, comme celles fournies par F5 Networks, Cisco Systems et des sociétés similaires. Si vous avez déjà acheté une solution comme celle-ci, cela vaut la peine de l'utiliser ici. Vous pouvez ensuite ignorer le reste de la réponse car le f5 sera alors en mesure d'analyser de manière appropriée toutes les requêtes pour le FQDN utilisé pour accéder à votre serveur RD actuel et renvoyer une IP appropriée en fonction du moins utilisé de vos serveurs.
2. Round-Robin DNS est une solution praticable. Cela ne garantira pas une charge parfaitement uniforme, mais cela pourrait être un arrêt utile lorsque vous éduquez vos utilisateurs (voir 3) si vous ne pouvez pas utiliser un équilibreur de charge réseau. Remplacez le nom DNS actuel que les clients utilisent par deux enregistrements d'hôte qui ont le même nom mais des adresses IP différentes (vos deux serveurs), idéalement, configurez également des enregistrements d'hôte distincts (de préférence basés sur le nom d'hôte du serveur) liés à chaque serveur individuel.

Définissez un TTL long sur vos entrées à tour de rôle si vous ne voulez pas que les clients quittent les sessions déconnectées sur un serveur une fois leur cache DNS expiré et qu'ils acquièrent l'IP de l'autre serveur. Vous pouvez également rendre évident le nom d'hôte de l'ordinateur auquel ils se sont connectés (par exemple, en faire partie de l'arrière-plan) et leur demander de se reconnecter à ce nom d'hôte s'ils souhaitent ressusciter leur session.

3. Demandez à vos clients de répartir la charge. Avec environ 25 utilisateurs, il peut être possible de demander simplement (par e-mail ou par un message de connexion sur le serveur) à certains utilisateurs de frapper un serveur et aux autres de frapper l'autre. Alternativement, si vous contrôlez leur plate-forme de bureau ou s'ils accèdent au serveur via citrix ou un autre dispositif de virtualisation d'applications, configurez simplement leur fichier d'hôtes † afin qu'ils frappent toujours le même serveur (bureau) / garantissent que le même utilisateur est toujours envoyé au même serveur ( appareil).

† S'ils utiliseront toujours le même bureau, modifiez simplement le fichier hosts sur le bureau local. S'ils se déplacent entre les machines, écrivez un script (distribué via la stratégie de groupe) pour analyser le fichier hôte de sorte que l'entrée DNS qu'ils utilisent actuellement pour le serveur pointe vers l'IP du serveur que l'utilisateur particulier devrait utiliser. Remplacez la ligne contenant ce nom DNS s'il existe déjà ou ajoutez-le à la fin du fichier s'il ne l'est pas.

Je connais le "type d'utilisateur" qui refuse de se déconnecter. Cependant, ils semblaient n'avoir aucun problème à comprendre que le serveur redémarrerait tous les soirs, de sorte que tout travail non enregistré serait perdu. Il s'agit de Server 2008 R2 TS prenant en charge environ 20 utilisateurs sur une seule machine.

> Les utilisateurs refusent de se déconnecter au lieu de se déconnecter

Vous avez ici un problème de gestion / RH plutôt qu'un problème technique. Si les personnes qui restent connectées affectent le travail des autres (en réduisant inutilement les performances), il n'y a vraiment que deux solutions:

1. Faites-en un problème technique et prévoyez une augmentation des ressources (plus de RAM, SSD à la place du métal en rotation, ...) si possible pour que le problème disparaisse de cette façon. Bien sûr, il y a des limites à ce que vous pouvez réaliser en lançant de nouvelles ressources sur une seule machine, mais cela peut fonctionner.

2. Considérez cela comme un problème de gestion des personnes et trouvez un moyen d'encourager (ou à défaut d' appliquer ) une discipline appropriée. Bien sûr, cela peut être en dehors de votre responsabilité directe, donc cela peut être assez délicat en fonction de la politique de votre bureau ...

Nous avons eu un problème similaire avec des personnes qui ne redémarraient jamais leurs machines de bureau, ce qui signifie que les mises à jour de sécurité étaient parfois mises en file d'attente pendant des mois. La politique de sécurité a déclaré que "les correctifs pour les problèmes de sécurité connus devraient être installés en temps opportun, immédiatement dans les cas où des exploits existent déjà dans la nature, à moins que des atténuations suffisantes ne puissent être prouvées", donc au final, il a été simplement appliqué par la stratégie de groupe: tous les non -les machines Windows redémarreront du jour au lendemain un mardi s'il y a des mises à jour en attente, sans exception. Si quelqu'un s'oppose à cela, il y a deux compteurs faciles: si nous ne suivons pas cette politique, nous perdrions notre accréditation ISO-ce-que-et-l'autre la prochaine fois qu'il y aura un audit qui est important pour l'entreprise,

> Les utilisateurs insistent pour utiliser Lync 2013 au lieu de Lync 2010 (Lync 2013 est un porc de ressources notoire)

Y a-t-il une raison spécifique pour laquelle, à part qu'ils veulent des choses plus récentes et plus brillantes? S'il y a une fonctionnalité dont ils ont vraiment besoin, il n'y a peut-être pas grand-chose à faire à propos de cet angle.

Si une application de chat est le principal problème de ressources, je me demande s'il existe un moyen de tuer uniquement les instances de ce programme dans les sessions inactives au lieu de tuer toutes les sessions?

> ils perdent du travail chaque fois que je redémarre sans préavis suffisant, c'est-à-dire pour redémarrer tout ce qu'ils doivent savoir avant "midi" de la journée

Vous ne précisez pas la nature du travail, donc cela dépend beaucoup de ce que c'est, mais ils peuvent échouer à la diligence raisonnable (c'est-à-dire ne pas faire leur travail correctement ).

S'ils n'enregistrent pas régulièrement des documents, ils mettent leur travail en danger, pas vous. Que se passerait-il s'il y avait une panne de courant ou une autre panne qui avait coupé le serveur? Vous blâmeraient-ils aussi?

Bien sûr, s'ils travaillent activement au moment du redémarrage ou doivent laisser des processus de longue durée sans surveillance, il peut y avoir un véritable problème de planification que vous devez résoudre entre vous.

Avec le risque de ressembler à un vendeur - nous utilisons ShutdownPlus Rolling Restart . Nous l'avons configuré pour essayer de redémarrer nos serveurs tous les soirs. Cela fonctionne assez bien - vous pouvez le configurer pour redémarrer les serveurs uniquement après que tout le monde a été déconnecté. Il redémarrera la boucle si quelqu'un utilise encore le serveur RD un nombre X de fois. L'outillage peut également déconnecter les utilisateurs pour vous, si vous le souhaitez. Ou même, utilisez vos VMs @ ESXi pour les recycler.

Je l'utilise avec quelques GPO qui déconnectent les utilisateurs déconnectés après quelques heures. Et déconnecte les sessions actives après un certain temps d'inactivité bien sûr. C'est une méthode assez gracieuse, à part le programme de voyous occasionnels qui empêche la fermeture des sessions. Nous avons cependant travaillé sur ces problèmes. La façon dont nous l'avons configuré maintenant, chaque serveur essaie de redémarrer toutes les heures de 22h00 à 7h00, jusqu'à ce qu'il réussisse bien sûr. En effet, les utilisateurs redémarrent au moins 2/3 fois par semaine, ce qui me convient.

Malheureusement, ce n'est pas un programme gratuit, mais il fait très bien le travail. J'implémente un script PowerShell qui, espérons-le, mettra à jour les serveurs avant de redémarrer également.

Réponse directe au redémarrage du serveur Microsoft OUI / NON. Oh si la vie était si simple! Cela dépend des applications exécutées sur le serveur. Mais voici un guide simple mais PAS une règle dure et rapide.

Serveur physique exécutant le serveur Windows ** x version ** ( redémarrage automatique et planification ) 95% peuvent être redémarrés une fois tous les quinze jours sans aucun problème réel. (Vérifiez que le patch appliqué est pertinent et requis). Assurez-vous de tester entièrement le correctif sur vos serveurs de test avant de le publier sur les systèmes en direct / de production.

Serveurs virtuels VMWare exécutant Windows Server x Version - Redémarrez une fois tous les quinze jours ( voir le commentaire ci-dessus si des correctifs sont appliqués )

Serveur VMWare physique JAMAIS / Rarement et seulement si nécessaire, jamais planifié. (Normalement très stable s'il est mis à jour) Les correctifs / mises à jour VMWare nécessiteront un redémarrage.

VMWare en cours d' exécution de Windows SQL (Les redémarrages Limit, appliquez Windows patches MANUELLEMENT SEULEMENT! Redémarrage SI correctif exige et seulement après avoir arrêté ses clients tous les connexions) Vérifiez les connexions ont rebranché une fois le serveur est de retour. Les serveurs SQL peuvent prendre un certain temps pour redémarrer, alors planifiez cela en dehors des heures.

Rappel: Avant de faire TOUT changé en VMWare (Windows Server) INSTANTANÉ! si le système se bloque après l'application du correctif de service ou des mises à jour ou si les applications ne démarrent pas, vous pouvez rapidement obtenir la sauvegarde et l'exécution du serveur avec un temps d'arrêt limité. N'oubliez pas de noter les erreurs afin que vous puissiez trouver que le correctif ne laisse pas le système seul car il a échoué, car il pourrait échouer à l'avenir.

J'espère que cela aide et va un peu pour clarifier les choses.