Observação: Li Com que freqüência os servidores do Windows Precisa ser reiniciado? mas esta questão pertence ao nosso servidor Remote Desktop especificamente.
Temos um servidor Windows Server 2008 R2 - um VM VMware ESX - licenciado para os Serviços de Área de Trabalho Remota, 25 usuários que também fazem RRAS (SSTP). Em um dia de semana normal, durante as horas de trabalho, há entre 8 e 12 usuários ativos conectados com mais 4-6 usuários "desconectados". Ele tem uma reserva de 12 GHz da CPU e 16 GB de RAM, também totalmente reservada. A reserva da CPU é expansível até 24 GHz max quando necessário.
Muitos dos nossos usuários confiam exclusivamente no servidor para trabalhar. Eles também se queixam amargamente do seu desempenho, mas muitos não estão dispostos a mudar hábitos de trabalho ou software para melhorar seu desempenho. Especificamente:
Eu não posso exagerar o significado de sua recusa em fazer logoff. Os usuários desconfigurados continuam a consumir RAM enquanto estão desconectados, o que significa que a qualquer momento, temos até 16 instâncias de determinados programas em execução.
Eu também notei através da experiência que vazamentos / zumbis tendem a somar o tempo que um servidor de Área de Trabalho Remota está rodando. Depois de uma reinicialização, o servidor é novo e muito mais rápido, mesmo quando comparamos o desempenho após muitos usuários terem feito login. Também li que as reinicializações regulares podem ser úteis.
Por isso, propus a reinicialização regular da VM - gostaria de fazê-lo semanalmente, por exemplo, no sábado à noite - já que acho que essas reinicializações resolveriam muitos problemas.
Gostaria de saber se você é um administrador do Windows
Estou certo sobre o fato de que lixo / zumbis / vazamentos se acumulam com o tempo da sessão, mesmo depois que um usuário se desconecta / reconecta?
Com que freqüência você reinicia um Windows Server com os Serviços de Área de Trabalho Remota?
Geralmente, eu sou contra a idéia de que um servidor Windows deve ser reinicializado em um horário regular EXCETO em relação aos servidores TS / RDS. Nós reiniciámos o nosso todos os dias. Ele limpa sessões antigas, libera recursos em uso (CPU, RAM, identificadores de arquivo, etc.), então minha opinião e sugestão seria que você configurasse uma reinicialização diária agendada de seus servidores RDS.
Note que esta resposta é apenas a minha opinião. Não há nenhuma declaração de fato aqui.
Users refuse to log off instead of disconnect
Configure as políticas de grupo apropriadas para efetuar o logoff automático. Você pode controlar separadamente um tempo limite ocioso e logoff. Isso certamente deve minimizar alguns dos problemas durante o dia.
Eu reinicio meu farm TS de 3 servidores diariamente às 3:00 da manhã. Porque, sim, porcaria pode acumular ao longo do tempo quando você tem muita gente usando um único sistema. Temos 3 servidores compartilhados entre 60 a 90 pessoas, dependendo do dia, época do ano.
Eu provavelmente não preciso reiniciar isso com frequência, mas começamos a usar serviços de terminal com o Windows 2000, e os drivers da nossa impressora eram horríveis na época. O spooler de impressão basicamente falharia após um ou dois dias de funcionamento. Então, começamos a reinicializar todas as noites, já que não tínhamos nenhuma vantagem para fazer com que os fabricantes de impressoras consertassem seus drivers ruins.
Dependendo do seu dinheiro, tempo e da perspicácia de seus usuários, outra ideia poderia ser levantar um segundo servidor. Você ainda precisará reinicializar ocasionalmente, mas parece que está atingindo os limites de um único servidor.
Você deve ser capaz de usar as mesmas CALs de cliente (o licenciamento não é minha área mais strong) e, dependendo da sua solução de virtualização, uma VM adicional pode já estar coberta pelo licenciamento existente.
Mesmo sem recursos adicionais de VM e com a sobrecarga extra do SO, você pode achar que o sistema manipula melhor como duas CPU separadas de 6 GHZ e VM de memória de 8GiB, supondo que você possa dividir a carga uniformemente. Existem três métodos possíveis:
Defina um TTL longo em suas entradas round-robin se você não quiser que os clientes deixem sessões desconectadas em um servidor depois que o cache DNS expire e eles adquiram o IP do outro servidor. Como alternativa, torne o nome do host do computador ao qual eles se ligaram como óbvio (por exemplo, faça parte do plano de fundo) e peça a eles que se reconectem a esse nome de host se quiserem ressuscitar sua sessão.
† Se eles sempre usarem a mesma área de trabalho, basta modificar o arquivo hosts na área de trabalho local. Se eles se moverem entre máquinas, escreva um script (distribuído por meio da diretiva de grupo) para analisar o arquivo host de forma que a entrada DNS que eles usam atualmente para o servidor aponte para o IP do servidor que esse usuário em particular deve estar usando. Substitua a linha que contém esse nome DNS, se já existir, ou adicione-o ao final do arquivo, se não existir.
Estou familiarizado com o "tipo de usuário" que se recusa a fazer logoff. No entanto, eles pareciam não ter nenhum problema em entender que o servidor estaria reinicializando todas as noites para que qualquer trabalho não salvo fosse perdido. Isso está no Server 2008 R2 TS Supporting Cerca de 20 usuários em uma única máquina.
> Usuários se recusam a fazer logoff ao invés de desconectar
Você tem uma questão de gerenciamento / recursos humanos aqui e não técnica. Se as pessoas que permanecerem conectadas estiverem afetando o trabalho de outras pessoas (reduzindo o desempenho desnecessariamente), então existem apenas duas soluções:
Faça disso um problema técnico e organize um aumento de recursos (mais RAM, SSD no lugar de spinning metal, ...), se possível, para que o problema desapareça dessa maneira. É claro que há limites para o que você pode conseguir lançando novos recursos em uma única máquina, mas pode funcionar.
Persista como um problema de gestão de pessoas e encontre alguma maneira de encorajar (ou falhar em que reforçar ) a disciplina apropriada. É claro que isso pode estar fora de sua responsabilidade direta, por isso pode ser bastante complicado, dependendo da política do seu escritório ...
Tivemos um problema semelhante com as pessoas que nunca reiniciavam suas máquinas desktop, o que significa que as atualizações de segurança eram às vezes enfileiradas por meses. A política de segurança afirma que "correções para questões de segurança devem ser instaladas em tempo hábil, imediatamente nos casos em que já existem explorações na natureza, a menos que mitigações suficientes possam ser provadas". -Os computadores Windows irão reiniciar durante a noite em uma terça-feira se houver atualizações pendentes, sem exceções. Se alguém argumentar contra isso, há dois contadores fáceis: se não seguirmos essa política, perderemos nosso credenciamento ISO-isto-e-aquilo-e-outros na próxima vez que houver qualquer auditoria que seja importante para o negócio, e nossos contratos com nossos clientes também fazem declarações sobre a política de segurança (como às vezes lidamos com seus dados, temos que garantir que seus dados estão seguros conosco), de modo que, sem essa imposição, estamos violando alguns contratos muito caros.
> Os usuários insistem em usar o Lync 2013 em vez do Lync 2010 (o Lync 2013 é um notório porco de recursos)
Existe uma razão específica pela qual, além de quererem coisas mais brilhantes? Se há uma característica que eles realmente precisam, então pode haver pouco que você possa fazer sobre esse ângulo.
Se um aplicativo de bate-papo é o principal problema de recursos, gostaria de saber se existe uma maneira de matar apenas instâncias desse programa nas sessões ociosas em vez de matar todas as sessões?
> eles perdem o trabalho toda vez que eu reinicio sem aviso suficiente, ou seja, para reiniciar tudo o que eles precisam saber por "meio-dia" daquele dia
Você não declara a natureza do trabalho, de modo que isso depende muito do que é, mas eles podem estar falhando na devida diligência (ou seja, não fazendo seu trabalho corretamente ).
Se eles não estão salvando documentos regularmente, eles estão colocando seu trabalho em risco, não você. O que aconteceria se houvesse falta de energia ou outra falha que derrubasse o servidor? Eles também te culpariam?
É claro que, se eles estiverem trabalhando ativamente no momento da reinicialização ou precisarem deixar processos longos em andamento sem acompanhamento, pode haver um problema de agendamento genuíno que você precisa resolver entre você.
Com o risco de soar como uma pessoa de vendas, usamos o Reinício de rolagem ShutdownPlus . Nós configuramos para tentar reiniciar nossos servidores todas as noites. Funciona muito bem - você pode configurá-lo para reiniciar apenas os servidores depois que todos estiverem desconectados. Ele reiniciará o loop se alguém ainda estiver usando o servidor RD um número X de vezes. O ferramental também pode fazer logoff dos usuários, se você quiser. Ou até mesmo ligue suas VMs @ ESXi.
Estou usando um par de GPOs que desconectam usuários desconectados após algumas horas. E desconecta sessões ativas após um certo tempo ocioso, é claro. É um método bem gracioso, além do programa ocasional que impede que as sessões sejam encerradas. Nós trabalhamos em torno daqueles embora. A forma como o instalamos agora, cada servidor tenta reiniciar a cada hora, das 22h00 às 7h00, até que seja bem-sucedido, é claro. Efetivamente, os usuários reinicializam pelo menos 2/3 vezes por semana, o que é bom para mim.
Infelizmente, este não é um programa gratuito, mas faz o trabalho muito bom. Estou implementando um script powershell que esperançosamente atualizará os servidores antes de reinicializar também.
Resposta direta à reinicialização do servidor Microsoft SIM / NÃO. Ah, se a vida fosse assim tão fácil! Isso depende dos aplicativos em execução no servidor. Mas aqui está um guia simples, mas NÃO é uma regra difícil e rápida.
Servidor físico em execução no servidor do Windows ** x Versão ** ( Reinicialização automática e Agenda ) 95% pode ser reinicializado uma vez a cada quinzena sem preocupações reais. (Verifique se o patch aplicado é relevante e obrigatório). Certifique-se de testar completamente o patch em seu (s) servidor (es) de teste antes de liberar para os sistemas de produção / produção.
VMWare Servidores Virtuais executando o Windows Server Versão x - Reinicie uma vez por quinzena ( Veja o comentário acima se as correções são aplicadas )
Servidor VMWare físico NUNCA / Raramente e somente se requerido nunca agendado. (Normalmente, muito estável, se mantido atualizado) patches / atualizações VMWare exigirá uma reinicialização.
VMWare executando o Windows SQL (Limitar reinicializações, Aplicar patches do Windows MANUALMENTE SOMENTE! reiniciar o patch IF exige isso e somente depois de ter interrompido TODAS as conexões de clientes) Verifique se as conexões foram reconectadas quando o servidor estiver de volta. Os SQL Servers podem demorar um pouco para serem reinicializados, portanto, planeje isso fora de horas.
Lembrete: Antes de fazer qualquer alteração para um VMWare (Windows Server) SNAPSHOT isso! Se o sistema falhar após o Service Patch ou se as atualizações aplicadas ou os aplicativos falharem, você poderá obter rapidamente o backup do servidor e executá-lo com o tempo de inatividade limitado. Lembre-se de fazer anotações de erros, para que você possa encontrar a correção, não deixe o sistema sozinho porque falhou, pois pode falhar no futuro.
Espero que ajude e corra um pouco para esclarecer as coisas.