Странное поведение из виртуализированного приложения App-V - невозможно запустить новый экземпляр, пока все остальные не будут закрыты

Сначала я должен извиниться за неопределенность этого. Это довольно сложно определить, поэтому я перехожу к публикации.

Среда - серверы Windows 2012 R2 Citrix 7.16, мультитенантные (что является причиной использования App-V).

Сначала несколько вещей о приложении.

  • Приложение упорядочено в последней версии App-V 5.1.
  • Приложение регистрирует исполняемый файл на сетевом ресурсе во время последовательности.
  • Клиентская часть приложений состоит в основном из регистрации этого файла. На клиенте нет локальных файлов.
  • Общий ресурс для чтения / выполнения (общий ресурс и разрешения NTFS)
  • Приложение работало нормально до тех пор, пока около 6 месяцев назад. Тогда все новые пакеты демонстрируют это поведение.
  • Не происходит, когда приложение не виртуализировано в App-V.

Немного о том, как это проявляется:

  • Ошибка всегда возникает после нормального рабочего времени, чаще всего через несколько часов. (Наша рабочая теория заключается в том, что, возможно, что-то во время сеанса выхода пользователя из системы / автоматического выхода из сеанса или повторного соединения сеанса вызывает это.)

  • По сути, ошибка заключается в том, что пользователи не могут запустить приложение. Ничего не произошло.

  • Эту ошибку легко обнаружить, поскольку в диспетчере задач все затронутые экземпляры приложений не имеют значков. Как и диспетчер задач, не может получить доступ / прочитать ресурс, однако мы протестировали доступ и файл и общий ресурс "открыты для бизнеса".

  • Если мы затем приступим к уничтожению всех экземпляров приложения, то пользователи смогут снова запускать приложения.

  • Возможно, уместно, что в пакетах есть другие приложения, которые могут быть запущены. Таким образом, виртуальная среда не была закрыта для всех пользователей, и пакет постоянно "использовался".

  • Эта техническая статья может быть актуальной - возможно, это связано с общим ресурсом кэшированного файла. Очень важно, однако: это не происходит, когда приложение не виртуализировано в App-V.

Мы попытаемся закрыть все сеансы, которые отключены / отключены от различных арендаторов с этой проблемой, и посмотрим, поможет ли это, но это все еще не очень хорошее решение.

Кроме этого, я просто надеюсь, что кто-то где-то испытал нечто подобное и нашел основную причину, или что кто-то умнее и более осведомлен об основных технологиях, используемых здесь, может, возможно, понять, что происходит, или дать мне некоторые идеи относительно того, что мы можем попробуй дальше.

Мы нашли некоторые сообщения об ошибках в журнале событий appv сегодня (ошибка 0x7A602510-0xF), которые приводят к этому тупику.

Вчера попытался агрессивно выйти из системы, чтобы устранить проблемы с повторным подключением к сеансу. Неудачно. Только два пользователя вошли в систему и были активны, а третий вызвал ошибку, без повторного подключения, без других отключенных / неактивных сеансов.

Этот поток ars выглядит как самый живой и актуальный, который я когда-либо видел (спасибо @TrententTye!). Попробуем получить доступ к файлу приложения несколькими разными способами: FQDN, IP, возможно, подключенный диск. Также пользователь kttii пишет, что Win2016, возможно, исправил проблему для них. И, наконец, упоминаются некоторые патчи WannaCry от мая 2017 года, которые на самом деле очень хорошо совпадают с тем, когда мы начали получать ошибку.

Огромное спасибо всем, кто сделал ретвит и внес свой вклад в твиттер! Вы, ребята, потрясающие.

редактирование: найдено сообщение об ошибке и техническая тупик.

edit2: @TrententTye предоставил этот ars-поток, который выглядит так же. Продолжаем с 2010/Win2003 по 2017/Win2012!

Источник

1 ответ

Решение

Я отвечаю на это сам, когда мы нашли ошибку, и я сделал обходной путь.

Это ошибка, мы знаем, что сейчас: https://support.microsoft.com/en-us/help/2536487/applications-crash-or-become-unresponsive-if-another-user-logs-off-a-r It также появлялся несколько раз, когда App-V не используется, но в 98% случаев это происходит, когда приложение виртуализировано.

Это обходной путь:

1 Создайте запланированное задание на сервере RDS/Xenapp, где проявляется ошибка. Установите его для запуска при загрузке или вскоре после этого. Это должно начаться прежде, чем любой пользователь запустит приложение. Это запланированное задание:

Заявка: PowerShell.exe

Параметры: -command "& 'C:\Program Files (x86)\Script\ReadLockFilesInFolder.ps1' '\\server\folder\'"

2 Сохраните это как скрипт 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

Сценарий работает, открывая файлы не только и содержит магический первый дескриптор, тем самым предотвращая его освобождение.

Заметки:

Скрипт освобождает дескриптор через 24 часа. Скрипт блокирует файлы только в первой папке. Добавьте "-recurse" позади Get-Childitem, чтобы просмотреть все папки.

Теперь это хорошо сработало для нас. Я также могу подтвердить, что это не происходит на Server 2016, как описывает КБ. надеюсь, это поможет

Источник
Другие вопросы по тегам