¿Con qué frecuencia reinicia un servidor de escritorio remoto (VM) Windows Server 2008R2 muy utilizado?

Nota: He leído ¿Con qué frecuencia se deben reiniciar los servidores de Windows? pero esta pregunta se refiere específicamente a nuestro servidor de escritorio remoto .

Tenemos un servidor Windows Server 2008R2, una VM VMware ESX, con licencia para Servicios de escritorio remoto, 25 usuarios que también hace RRAS (SSTP). En un día laborable promedio, durante las horas de trabajo, hay entre 8 y 12 usuarios activos conectados con un adicional de 4-6 usuarios "desconectados". Tiene una reserva rígida de CPU de 12 GHz y 16 GB de RAM, también completamente reservada. La reserva de CPU se puede ampliar a 24 GHz máx. Cuando sea necesario.

Muchos de nuestros usuarios confían exclusivamente en el servidor para trabajar. También se quejan amargamente de su rendimiento, pero muchos no están dispuestos a cambiar los hábitos de trabajo o el software para mejorar su rendimiento. Específicamente:

• Los usuarios se niegan a cerrar sesión en lugar de desconectarse
• Los usuarios insisten en usar Lync 2013 en lugar de Lync 2010 (Lync 2013 es un conocido consumidor de recursos)

No puedo exagerar la importancia de su negativa a cerrar sesión. Los usuarios desconectados continúan acumulando RAM mientras están desconectados, lo que significa que en cualquier momento tenemos en ejecución hasta 16 instancias de ciertos programas.

También he notado por experiencia que las fugas / zombis tienden a acumularse cuanto más tiempo se ejecuta un servidor de Escritorio remoto. Después de un reinicio, el servidor es nuevo y mucho más rápido, incluso cuando se compara el rendimiento después de que muchos usuarios hayan iniciado sesión. También he leído que los reinicios regulares pueden ser útiles.

Por lo tanto, he propuesto reinicios regulares de la máquina virtual (me gustaría hacerlo semanalmente, por ejemplo, el sábado por la noche), ya que siento que estos reinicios resolverían gran parte del problema.

Me gustaría saber, si usted es administrador de Windows,

• ¿Tengo razón sobre el hecho de que la basura / zombies / fugas se acumulan con el tiempo de sesión, incluso después de que un usuario se desconecta / vuelve a conectar?

• ¿Con qué frecuencia reinicia un servidor de Windows de uso similar con servicios de escritorio remoto?

En general, me opongo a la idea de que un servidor de Windows se reinicie con una programación regular, EXCEPTO en relación con los servidores TS / RDS. Reiniciamos el nuestro todos los días. Limpia las sesiones antiguas, libera recursos en uso (CPU, RAM, identificadores de archivos, etc.), por lo que mi opinión y sugerencia sería que configure un reinicio diario programado de sus servidores RDS.

Tenga en cuenta que esta respuesta es solo mi opinión. No hay una declaración de hechos aquí.

Los usuarios se niegan a cerrar sesión en lugar de desconectarse

Configure las políticas de grupo apropiadas para cerrarlas automáticamente. Puede controlar por separado un tiempo de espera inactivo y cerrar sesión. Eso ciertamente debería minimizar algunos de los problemas durante el día.

Reinicio mi granja de TS de 3 servidores diariamente a las 3:00 a.m. Porque sí, la basura puede acumularse con el tiempo cuando hay muchas personas que usan un solo sistema. Tenemos 3 servidores compartidos entre 60 y 90 personas, según el día y la época del año.

Probablemente no necesite reiniciar esto con frecuencia, pero comenzamos a usar servicios de terminal con Windows 2000, y nuestros controladores de impresora eran horribles en ese momento. La cola de impresión básicamente fallará después de un día o dos de estar despierto. Así que comenzamos a reiniciar todas las noches ya que no teníamos ningún apalancamiento para que los fabricantes de impresoras arreglaran sus controladores deficientes.

Dependiendo de su efectivo, tiempo y la inteligencia de sus usuarios, otra idea podría ser poner de pie un segundo servidor. Aún necesitará reiniciar ocasionalmente, pero parece que está llegando a los límites de un solo servidor.

Debería poder utilizar las mismas CAL de cliente (las licencias no son mi área más sólida), y dependiendo de su solución de virtualización, una VM adicional ya puede estar cubierta por las licencias existentes.

Incluso sin recursos de VM adicionales y con la sobrecarga del sistema operativo adicional, puede encontrar que el sistema se maneja mejor como dos CPU de 6 GHZ separadas y VM de memoria de 8GiB, suponiendo que puede dividir la carga de manera uniforme. Hay tres métodos potenciales:

1. La forma más limpia es utilizar una solución adecuada de equilibrio de carga basada en la red, como las proporcionadas por F5 Networks, Cisco Systems y compañías similares. Si ya ha comprado una solución como esta, valdría la pena usarla aquí. Luego puede ignorar el resto de la respuesta, ya que el f5 podrá analizar adecuadamente todas las consultas para el FQDN utilizado para acceder a su servidor RD actual y devolver una IP apropiada basada en el servidor menos utilizado.
2. Round-Robin DNS es una solución aceptable. No garantizará una carga perfectamente uniforme, pero podría ser un recurso útil mientras educa a sus usuarios (ver 3) si no puede usar un equilibrador de carga de red. Reemplace el nombre DNS actual que los clientes están usando con dos registros de host que tienen el mismo nombre pero diferentes IP (sus dos servidores), idealmente también configure registros de host separados (preferiblemente basados ​​en el nombre de host del servidor) que está vinculado a cada servidor individual.

Establezca un TTL largo en sus entradas de round-robin si no desea que los clientes abandonen las sesiones desconectadas en un servidor una vez que caduque su caché DNS y adquieran la IP del otro servidor. Alternativamente, haga que el nombre de host de la computadora a la que se han conectado sea obvio (por ejemplo, hágalo parte del fondo) y pídales que se vuelvan a conectar a ese nombre de host si desean resucitar su sesión.

3. Haga que sus clientes distribuyan la carga. Con ~ 25 usuarios, es posible simplemente pedir (por correo electrónico o un mensaje de inicio de sesión en el servidor) que ciertos usuarios accedan a un servidor y el resto a otro. Alternativamente, si controla su plataforma de escritorio o accede al servidor a través de citrix u otro dispositivo de virtualización de aplicaciones, simplemente configure su archivo de hosts † para que siempre lleguen al mismo servidor (escritorio) / asegúrese de que siempre se envíe al mismo usuario al mismo servidor ( aparato).

† Si siempre usarán el mismo escritorio, simplemente modifique el archivo hosts en el escritorio local. Si se mueven entre máquinas, escriba una secuencia de comandos (distribuida a través de la política de grupo) para analizar el archivo de host de modo que la entrada DNS que usan actualmente para el servidor apunte a la IP del servidor que ese usuario en particular debería usar. Reemplace la línea que contiene ese nombre DNS si ya existe, o agréguelo al final del archivo si no existe.

Estoy familiarizado con el "tipo de usuario" que se niega a cerrar sesión. Sin embargo, parecían no tener problemas para entender que el Servidor se reiniciaría todas las noches, por lo que se perdería cualquier trabajo no guardado. Esto está en el servidor 2008 R2 TS que admite aproximadamente 20 usuarios en una sola máquina.

> Los usuarios se niegan a cerrar sesión en lugar de desconectarse

Tiene un problema de gestión / recursos humanos aquí en lugar de uno técnico. Si las personas que permanecen conectadas están afectando el trabajo de otras personas (al reducir el rendimiento innecesariamente), entonces solo hay realmente dos soluciones:

1. Conviértalo en un problema técnico y organice un aumento de recursos (más RAM, SSD en lugar de spinning metal, ...) si es posible para que el problema desaparezca de esa manera. Por supuesto, hay límites para lo que puede lograr al lanzar nuevos recursos en una sola máquina, pero podría funcionar.

2. Persíguelo como un problema de gestión de personas y encuentre alguna forma de alentar (o no aplicar esa ) disciplina apropiada. Por supuesto, esto puede estar fuera de su responsabilidad directa, por lo que podría ser bastante complicado dependiendo de la política de su oficina ...

Tuvimos un problema similar con las personas que nunca reiniciaron sus máquinas de escritorio, lo que significa que las actualizaciones de seguridad a veces se pusieron en cola durante meses. La política de seguridad indicó que "los parches para conocer los problemas de seguridad deben instalarse de manera oportuna, inmediatamente en los casos en que ya existan exploits en la naturaleza, a menos que se puedan probar suficientes mitigaciones", por lo que al final simplemente se hizo cumplir por la política del grupo: todos no -server Las máquinas de Windows se reiniciarán durante la noche de un martes si hay actualizaciones pendientes, sin excepciones. Si alguien argumenta en contra de esto, hay dos contadores fáciles: si no seguimos esa política, perderíamos nuestra acreditación ISO-este-y-el-otro la próxima vez que haya una auditoría que sea importante para el negocio,

> Los usuarios insisten en usar Lync 2013 en lugar de Lync 2010 (Lync 2013 es un conocido consumidor de recursos)

¿Hay alguna razón específica por la cual, aparte de que quieren cosas más nuevas y brillantes? Si hay una característica que realmente necesitan, entonces puede haber poco que pueda hacer al respecto.

Si una aplicación de chat es el principal problema de recursos, me pregunto si hay una manera de matar solo instancias de ese programa en las sesiones inactivas en lugar de matar todas las sesiones.

> pierden trabajo cada vez que reinicio sin previo aviso, es decir, para reiniciar todo lo que necesitan saber antes del "mediodía" de ese día

Usted no declara la naturaleza del trabajo, por lo que esto depende mucho de lo que sea, pero pueden estar fallando en la debida diligencia (es decir, no están haciendo su trabajo correctamente ).

Si ellos no están ahorrando documentos regularidad que están poniendo en riesgo su trabajo, no tú. ¿Qué sucedería si hubiera un corte de energía u otra falla que derribó el servidor? ¿Te culparían a ti también?

Por supuesto, si están trabajando activamente en el momento del reinicio o si necesitan dejar desatendidos los procesos de ejecución prolongada, entonces puede haber un problema de programación genuino que debe resolver entre ustedes.

Con el riesgo de parecer una persona de ventas, utilizamos ShutdownPlus Rolling Restart . Lo hemos configurado para intentar reiniciar nuestros servidores todas las noches. Funciona bastante bien: puede configurarlo para reiniciar los servidores solo después de que todos hayan cerrado la sesión. Reiniciará el bucle si alguien sigue usando el servidor RD varias veces X. Las herramientas también pueden cerrar la sesión de los usuarios, si lo desea. O incluso reinicie sus VMs @ ESXi.

Lo estoy usando con un par de GPO que desconecta a los usuarios desconectados después de un par de horas. Y desconecta las sesiones activas después de un cierto tiempo de inactividad, por supuesto. Es un método bastante elegante, aparte del programa esporádico ocasional que evita que las sesiones se cierren. Hemos trabajado alrededor de esos sin embargo. De la forma en que lo hemos configurado ahora, cada servidor intenta reiniciarse cada hora de 22.00 a 7.00, hasta que tenga éxito, por supuesto. Efectivamente, los usuarios reinician al menos 2/3 veces a la semana, lo cual está bien para mí.

Lamentablemente, este no es un programa gratuito, pero hace el trabajo bastante bien. Estoy implementando un script de PowerShell que con suerte actualizará los servidores antes de reiniciar también.

La respuesta directa al servidor de Microsoft se reinicia SÍ / NO. ¡Oh, si la vida fuera tan fácil! Depende de las aplicaciones que se ejecutan en el servidor. Pero aquí hay una guía simple pero NO una regla dura y rápida.

Servidor físico Ejecutando el servidor Windows ** x Versión ** ( Reinicio automático y programación ) El 95% se puede reiniciar una vez cada quince días sin ninguna preocupación real. (Compruebe que el parche que se está aplicando es relevante y obligatorio). Asegúrese de probar completamente el parche en su (s) servidor (es) de prueba antes de lanzarlo a los sistemas en vivo / producción.

Servidores virtuales VMWare que ejecutan la versión Windows Server x : reinicie una vez cada quince días ( consulte el comentario anterior si se aplican parches )

Servidor VMWare físico NUNCA / Raramente y solo si es necesario, nunca programado. (Normalmente muy estable si se mantiene actualizado) Los parches / actualizaciones de VMWare requerirán un reinicio.

VMWare funcionamiento de Windows SQL (reinicios límite, Aplicar parches de Windows manualmente sólo! Reinicio SI parche lo requiere y sólo después de que haya dejado de TODAS las conexiones de los clientes) Comprobar las conexiones han vuelto a conectar vez que el servidor es una copia de seguridad. Los servidores SQL pueden tardar bastante en reiniciarse, así que planifique esto fuera de las horas.

Recordatorio: antes de hacer CUALQUIER cambio a un VMWare (Windows Server) ¡INSTANTÁNEO! si el sistema se bloquea después de Service Patch o se aplican actualizaciones o las aplicaciones no se inician, puede obtener rápidamente la copia de seguridad del servidor y ejecutarla con un tiempo de inactividad limitado. Recuerde tomar notas de los errores para que pueda encontrar la solución, no deje el sistema solo porque falló, ya que puede fallar en el futuro.

Espero que ayude y sirva para aclarar las cosas.