Desde que alguns de nossos clientes migraram para o Windows Server 2016, tivemos falhas muito mais frequentes (duras) de nosso aplicativo .net gerenciado.
A configuração exata: o compartilhamento de arquivos do Windows Server 2016 entrega o aplicativo, na sessão RDS do Windows Server 2016 (outra máquina) o aplicativo (gerenciado) é iniciado, às vezes falha com "parou de funcionar", sem exceção, nada. É reproduzível em partes do programa e não é devido a erros conhecidos/de outra forma reproduzíveis.
Parece estar relacionado a algo como https://support.microsoft.com/en-gb/help/2536487/applications-crash-or-become-unresponsive-if-another-user-logs-off-ar embora haja afirma que esse problema não existe mais com o WS2016.
Problemas de rede e sessões fantasmas (usuários que não fazem logoff por dias/semanas) parecem amplificar esse problema.
Agora vamos recomendar aos nossos usuários que configurem o logoff automático (no modo ocioso) em suas máquinas Windows Server 2016 RDS, ainda não há feedback sobre se isso ajuda.
Esse tipo de problema é conhecido? Existe alguma solução alternativa conhecida?
Estamos enfrentando o mesmo problema.
Servidor de aplicativos Server 2008 r2 entregando aplicativos para um cluster ws 2016 rds.
Os atalhos do aplicativo são redirecionados para usuários do RDS de um compartilhamento no servidor de aplicativos do servidor 2008 r2.
Atualizamos nosso cluster rds 2012 para 2016 especificamente para resolver esse problema, pois a solução da Microsoft para o problema conforme você postou acima relacionado ao FCB é atualizar para o servidor 2016.
É bom saber que ainda funciona com um servidor de arquivos do servidor 2016, pois essa seria nossa próxima etapa de solução de problemas (atualizar o servidor de arquivos).
O aplicativo funcionou por 2 meses desde a atualização para o servidor 2016 no lado RDS sem problemas.
Hoje temos os 'erros na página' e o mesmo comportamento como se ainda estivéssemos acessando o aplicativo do WS 2012 RDS.
Não podemos nos dar ao luxo de executar o aplicativo localmente devido à necessidade de arquivos compartilhados redirecionados em todos os servidores no cluster RDS, por custos de licenciamento de implantação (por servidor instalado) e balanceamento de carga, portanto, 'implantar localmente' não é uma opção para nós.
Parece que 2016 ainda tem problemas com o FCB.
O logoff automático piorará se for realmente o problema do FCB, assim que o usuário segurando o 'manipulação mágica do arquivo' no compartilhamento remoto fechar o aplicativo ou sair do RDS, o aplicativo travará para vários usuários.
No servidor 2012, usamos tarefas agendadas e um script para abrir o aplicativo em um cronômetro antes de qualquer usuário fazer login e, em seguida, usar 'WAIT' para manter o bloqueio de arquivo aberto por 24 horas e, em seguida, limpá-lo no final do dia, repita o enxágue, apenas para manter o 'manipulação do arquivo mágico' aberto e bloqueado para um processo em segundo plano e não para um usuário, mas isso é esquisito na melhor das hipóteses e não é sustentável a longo prazo.
Chegamos até a usar um de nossos robôs de prisma azul de desenvolvimento para fazer login e abrir o aplicativo antes do horário comercial, mas como nossa base de usuários é indiana e opera quase 247, não era viável como uma solução de longo prazo, mas funciona se você tiver uma base de usuários estável 'somente das 9 às 5' e souber quando as pessoas farão logon e logoff em uma programação confiável.
A chave é abrir o aplicativo antes de qualquer outro usuário e manter o identificador de arquivo ABERTO, essa é a melhor maneira de contornar o problema.
Você notará que o aplicativo está aberto no servidor rds, mas nenhum identificador de arquivo aberto está visível para o exe no gerenciador de compartilhamento e armazenamento no servidor de arquivos para o usuário em questão quando esse problema ocorre e o aplicativo falha. O bloqueio no lado do servidor de arquivos terá desaparecido. Assim que o usuário segurando o bloqueio pertencente ao FCB para o arquivo de aplicativo compartilhado fecha o aplicativo ou faz logoff, o caos se instala.
o único ponteiro real para você seria garantir que o compartilhamento de arquivos com os arquivos do aplicativo não esteja em um disco que está sendo capturado enquanto os usuários estão usando o aplicativo - vi que essa é a causa raiz em outras caixas do servidor 2016 , mas, infelizmente, não é a causa em nosso caso particular.
Esperávamos que o WS 2016 fosse realmente a solução, conforme anunciado, mas estamos confiantes de que é um problema do servidor Windows que ainda não foi corrigido, apesar de ter sido anunciado como corrigido no WS 2016. É estranho que esteja funcionando para nós há 2 meses WS 2016 RDS, mas começou a acontecer novamente hoje.
Ainda estamos analisando isso e temos meses de notas de solução de problemas sobre isso, se você precisar de qualquer outra ajuda (embora isso se refira principalmente ao RDS 2012).
Além disso, poderíamos usar algumas dicas de outros administradores, pois estamos enfrentando isso novamente a partir de hoje e estamos no servidor 2016.
Por acaso, seu compartilhamento de aplicativo está em um NAS ou conectado ao servidor de aplicativos por ISCSI e você está usando o GOODSYNC para backups em nível de arquivo do compartilhamento de aplicativo?
Bem.
Apenas para atualizar.
Outra correção mais permanente para o problema é fazer o downgrade do .Net framework de 4.xx e superior para o .Net framework 4.0.
Se você estiver em uma posição em que possa fazer isso, os erros serão interrompidos.
O problema do FCB é mais pronunciado em todos os WS OS de 2008r2 para cima se o .Net instalado estiver acima de 4,5
Testamos em um laboratório com VMs do servidor 2008r2 para cima até 2016 e podemos concluir que o problema é introduzido com a atualização de 4.0 para 4.5.x ou 4.xx
Não é uma correção de trabalho muito boa para ambientes de produção, mas gostaria de informar que o problema desaparece ao fazer o downgrade do .Net para nós em todos os sistemas operacionais que testamos até agora.
Infelizmente, não podemos implementar o acima, mas definitivamente elimina o problema em nossa experiência.
Parece que o problema do FCB está diretamente ligado ao 4.5.xe superior em todos os sistemas operacionais Windows Server.
Vá entender - algo foi introduzido na estrutura que causa o problema.
Se você estiver em 2016 e estiver enfrentando o problema, verifique também os logs de erros do Fault Tolerant Heap no visualizador de eventos.
Se você estiver vendo erros de heap tolerante a falhas relacionados ao seu aplicativo, o aplicativo pode ser excluído do FTH no registro, o que, em alguns casos, também corrigirá as falhas.
Quanto ao nosso problema específico, uma reinicialização noturna programada o corrigiu, pelo menos até o ponto em que é suportável.
Minha experiência é que a implementação do ambiente de desktop do usuário do servidor Windows 2016 está bloqueando o tráfego e/por portas DCOM. Em um cluster de servidores, surgem problemas de comunicação com aplicativos em cluster para os quais é necessário se comunicar entre si. Como estamos bloqueando o tráfego de entrada/saída nos servidores de aplicativos, o serviço windowsupdate apresenta um erro e bloqueia o aplicativo ao mesmo tempo...
Liguei para o helpdesk da MS há 3 anos e ainda não recebi uma solução, então não somos responsáveis por falhas de aplicativos de terceiros ...