Вопросы Теги

Strange behavior from App-V virtualized application - can't start new instance until all others are closed

I first must apologize for the vagueness of this. It is rather hard to pin down, which is why I turn to posting this.

The environment is Windows 2012 R2 Citrix 7.16 servers, multi-tenant (which is the reason for App-V being used).

First a few things about the application.

  • The application is sequenced in the latest App-V 5.1.
  • The application registers an exe file on a network share, during sequencing.
  • The applications client part consist mostly of registering this file. There are not local files on client.
  • The share is read/execute (share and NTFS permissions)
  • The application worked fine until some time about 6 months ago. Then all new packages exhibit this behavior.
  • Does not happen when application is not virtualized in App-V.

A bit about how it manifests:

  • The error always occur after normal working hours, mostly a few hours after. (Our working theory is that perhaps something during a user logout/idle session auto-logout or a session reconnect that triggers this.)

  • The error is essentially that users can't start the application. Nothing happens.

  • It is easy to spot this error because in Task Manager all application instances affected have no icons. Like Task Manager can't доступ / чтение ресурса, однако мы проверили доступ и файл и общий доступ «открыты для бизнеса».

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

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

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

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

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

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

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

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

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

edit: Найдено сообщение об ошибке и тупик техники.

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

1
задан 7 February 2018 в 11:20
1 ответ

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

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

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

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

Приложение: PowerShell.exe

Параметры: -команда "& 'C: \ Program Files (x86) \ Script \ ReadLockFilesInFolder.ps1' '\\ server \ папка \ '"

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, как описано в KB. Надеюсь, это поможет

0
ответ дан 4 December 2019 в 04:14

Теги

Похожие вопросы