Уже более года все наши сотрудники работают только в опубликованных приложениях, а централизуем мы всё это через Parallels RAS. Есть у нас и автоматический механизм публикации ЭЦП: если авторизованный пользователь запускает сайт, допустим таможни, то предварительно в его HKCU пишется ЭЦП компании и запускается нужный плагин. Это отлично работает с КОНТУР, СБИС, КРИПТО-ПРО, но плагин от госуслуг (IFCPlugin) пришлось допиливать напильником, а к разработчикам остались вопросы…
Когда поступила заявка на установку очередного плагина, читающего ЭЦП, я не ожидал ничего сложного. Для работы с ЭЦП у нас выделен отдельный RDS-хост на котором уже стояло несколько плагинов и всё отлично работало. Я скачал плагин госуслуг с официального сайта и не мудрствуя лукаво запустил установку в машинном контексте из привилегированного шелла:
msiexec -i c:\pathtofile\mypackage.msi ALLUSERS=1
На первый взгляд, установка прошла успешно. В списке установленных программ на этом хосте появился «Плагин пользователя систем электронного правительства», под своей учетной записью я смог авторизоваться с помощью ЭЦП. Но у других пользователей плагин так и не заработал, будто и не был установлен.
Куда же ты запропастился?
Плагин госуслуг, в отличие от других аналогичных решений, никак не сообщает о своем присутствии пользователю. Нет иконки в трее, нет группы в стартовом меню, не нашел я его и в «Program Files». Т.к. под моей учеткой работала авторизация в Chrome, а она работает с помощью браузерного плагина, который, в свою очередь, должен иметь MessagingHost, я решил поискать этот процесс.
Каково же было мое удивление, когда я обнаружил этот процесс (ifc_chrome_host.exe) в собственной $Env:APPDATA! Иными словами, инсталлятор плагина, полностью игнорируя машинный контекст, поставил приложение внутрь моего профиля. Причем даже не в $Env:LOCALAPPDATA, а в подлежащую роумингу часть профиля. У нас включен роуминг аппдаты (на эту тему можно долго холливорить, но мы считаем, что в нашем случае — это правильно). Т.е. IFCPlugin установился в мой профиль, хранящийся на файловом сервере, куда только я имею доступ, но зарегистрировал себя и свои классы в машинном контексте на RDS-хосте. Вполне логично, что у пользователей плагина, по сути, не было.
Достаем напильник
Открываем старую добрую orca и смотрим на структуру директорий установщика IFCPlugin.msi:
TARGETDIR = AppDataFolder. Чем руководствовались разработчики я понять не смог. Заменяем на ProgramFiles64Folder или ProgramFilesFolder по вкусу.
Смотрим что с реестром:
Как видим, всё, кроме классов, прописывается в HKCU. Т.к. меня волновало функционирование лишь плагина для Google Chrome, то я изменил ветку только трем отмеченным параметрам на 2, что соответствует HKLM. Подозреваю, что для Firefox сработает аналогично.
Еще один напильник
Устанавливаю заново. Плагин ожидаемо появляется в $Env:ProgramFiles, но у пользователей, почему-то сразу падает процесс ifc_chrome_host.exe, хотя он уже запускается. Берем procmon и смотрим что ему не хватает.
Выясняется, что он пытается писать логи вот сюда:
$Env:ProgramFiles\Rostelecom\IFCPlugin\X.X.X.X\x32\LOGS
Пользователи, по умолчанию, разумеется, не имеют там доступа на запись. Исправляем.
Заключение
Работает. Что курили разработчики и зачем это было сделано именно так, осталось для меня загадкой.
Взято отсюда https://habr.com/ru/post/502998/