Назад | Перейти на главную страницу

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

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

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

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

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

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

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

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

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

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

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

изменить: найдено сообщение об ошибке и тупик.

edit2: @TrententTye способствовал эта арс-нить что похоже на ту же проблему. Переход с 2010 / Win2003 на 2017 / Win2012!

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

Это ошибка, теперь мы знаем: https://support.microsoft.com/en-us/help/2536487/applications-crash-or-become-unresponsive-if-another-user-logs-off-a-r Он также появлялся несколько раз, когда 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, как описано в KB. надеюсь, это поможет