Comportamento estranho do aplicativo virtualizado do App-V - não é possível iniciar uma nova instância até que todas as outras estejam fechadas

Question

Eu primeiro devo me desculpar pela imprecisão disso. É bastante difícil de definir, e é por isso que eu recorro a postar isso.

O ambiente é o Windows 2012 R2 Citrix 7.16, multi-tenant (que é a razão da utilização do App-V).

Primeiro algumas coisas sobre o aplicativo.

• O aplicativo é sequenciado no mais recente App-V 5.1.
• O aplicativo registra um arquivo exe em um compartilhamento de rede, durante o sequenciamento.
• A parte do cliente de aplicativos consiste principalmente em registrar esse arquivo. Não há arquivos locais no cliente.
• O compartilhamento é lido / executado (permissões de compartilhamento e NTFS)
• A aplicação funcionou bem até há cerca de 6 meses. Então todos os novos pacotes exibem esse comportamento.
• Não acontece quando o aplicativo não é virtualizado no App-V.

Um pouco sobre como se manifesta:

• O erro sempre ocorre após o horário normal de trabalho, principalmente algumas horas depois. (Nossa teoria de trabalho é que, talvez, algo durante uma desconexão automática de sessão de logout / sessão ociosa ou uma sessão reconectar que aciona isso.)

• O erro é essencialmente que os usuários não podem iniciar o aplicativo. Nada acontece.

• É fácil detectar esse erro porque no Gerenciador de Tarefas todas as instâncias do aplicativo afetadas não possuem ícones. Como o Gerenciador de Tarefas não pode acessar / ler o recurso, no entanto, testamos o acesso eo arquivo e compartilhamento é "aberto para negócios".

• Se, em seguida, continuarmos a eliminar todas as instâncias do aplicativo, os usuários poderão iniciar os aplicativos novamente.

• Talvez seja relevante que existam outros aplicativos nos pacotes que podem ser executados. Portanto, o Ambiente Virtual não foi desativado para todos os usuários e o pacote está "em uso" o tempo todo.

• Este artigo da technet pode ser relevante - talvez isso esteja relacionado ao recurso compartilhado de um arquivo em cache. Muito importante: isso não acontece quando o aplicativo não é virtualizado no App-V.

Vamos tentar fechar todas as sessões que estão ociosas / desconectadas dos diferentes locatários com esse problema e ver se isso ajuda, mas ainda não é uma correção muito boa.

Além disso, eu só espero que alguém em algum lugar tenha experimentado algo semelhante e encontrado a causa raiz, ou que alguém mais inteligente e mais bem informado sobre as principais tecnologias em uso aqui possa entender o que está acontecendo ou me dar algumas idéias o que podemos tentar a seguir.

Encontramos algumas mensagens de erro no log de eventos do appv hoje (erro 0x7A602510-0xF), que levam a este beco sem saída .

Tentou fazer logoff agressivamente de usuários ontem para eliminar problemas com a reconexão de sessão. Sem sorte. Apenas dois usuários efetuaram logon e ativos e um terceiro acionou o erro, nenhuma reconexão, nenhuma outra sessão desconectada / inativa.

Este ars-thread parece ser o mais vivo e mais relevante que já vi até agora (obrigado @TrententTye!). Vai tentar acessar o aplicativo-arquivo de algumas maneiras diferentes, FQDN, IP, talvez mapeado drive. Também o usuário kttii escreve que o Win2016 pode ter corrigido o problema para eles. E, por último, alguns patches do WannaCry de maio de 2017 são mencionados, os quais realmente se alinham muito bem quando começamos a receber o erro.

Um enorme obrigado a todos que retweetaram e contribuíram com twitter ! Vocês são incríveis.

edit: Mensagem de erro encontrada e beco sem saída da technet.

edit2: @TrententTye contribuiu este ars-thread que parece ser o mesmo problema. Indo de 2010 / Win2003 para 2017 / Win2012!

    

Answer 1

Estou respondendo isso enquanto encontramos o bug e eu fiz uma solução alternativa.

Este é o bug, sabemos disso agora: link Ele também apareceu algumas vezes quando o App-V não é usado, mas 98% do tempo é quando o aplicativo é virtualizado.

Esta é a solução alternativa:

1 Crie uma tarefa agendada no servidor RDS / Xenapp onde o bug se manifesta. Defina para começar na inicialização ou logo em seguida. Deve começar antes que qualquer usuário inicie o aplicativo. Esta é a tarefa agendada:

Aplicação: PowerShell.exe

Parâmetros: -command "& 'C:\Program Files (x86)\Script\ReadLockFilesInFolder.ps1' '\server\folder\'"

2 Salve isso como um script do PowerShell:

$AllOfTheFiles = Get-childitem -Path $args[0] -File | Select-Object -ExpandProperty FullName

$fileLocks = @()

foreach ($afile in $AllOfTheFiles) {
    $fileLocks+=[System.io.File]::Open("$afile",'Open','Read','Read')
}

Start-Sleep -s 86400

O script funciona abrindo os arquivos de forma não exclusiva e mantém a primeira alça mágica, evitando que ela seja liberada.

Notas:

O script libera o identificador após 24 horas. O script só bloqueia arquivos na primeira pasta. Coloque um "-recurse" por trás do Get-Childitem para verificar todas as pastas.

Isso agora funcionou bem para nós. Também posso confirmar que isso não ocorre no Server 2016, como a KB descreve. Espero que isso ajude