Вопрос или проблема
У меня есть примерно 100 систем Windows 10 Pro с различными приложениями, установленными из UNC-пути вида \\old_server.old_domain\app_path (сетевая среда AD). Эти приложения были установлены через GPO на old_domain.
Мы перенесли системы в new_domain. Новый сервер теперь размещает установщики MSI. Были созданы новые GPO для обновления/установки приложений.
Новые установки работают хорошо. Однако обновления существующих приложений завершаются неудачно. При проверке мы обнаружили, что установщик запрашивает оригинальный путь \\old_server.old_domain\app_path.
Мы попробовали решения, упомянутые на https://stackoverflow.com/questions/4069431/how-to-manually-remove-msi-installation:
- Удаление, за которым следует очистка установщика Windows для удаления всех старых данных установки. Однако после перезагрузки приложение снова появляется в приложении очистки установщика Windows. Более того, под ключом
HKCR\Installer\Products\XXXXXX\SourceList\Net
ключ1
указывает на\\old_server.old_domain\app_path
- Использование Revouninstaller -> тот же результат
- Использование инструмента Microsoft fixit, упомянутого в том же посте -> тот же результат
- Установка пакета из нового пути с опцией
SOURCELIST
, то есть вызовmsiexec -i \\new_server.new_domain\package.msi SOURCELIST="\\new_server.new_domain\"
. В этом случае мы видим, что подHKCR\\Installer\\Products\\XXXXXX\\SourceList\\Net
создается новая СТРОКА2
после установки, указывающая на новый путь. Но она не сохраняется после перезагрузки, возвращаясь к единственному значению1\
(которое содержит старый путь)
Была статья, в которой упоминался инструмент MsiSourceList
, который можно использовать для изменения этих источников MSI. Он должен быть включен в SDK Windows, но я не смог его найти.
Ответ или решение
Проблема, с которой вы столкнулись, связана с тем, что приложения, установленные через GPO, «помнят» исходный путь установки из раздела реестра Windows. Это может вызвать сложности при обновлении приложений после миграции на новый домен и сервер, потому что установщики продолжают искать файлы в старом UNC-пути.
Причина проблемы:
Когда приложения устанавливаются через MSI-пакеты, Windows сохраняет данные о путях исходных установок в реестре, чтобы обеспечивать целостность и возможность восстановления установок. Ключ реестра HKCR\Installer\Products\XXXXXX\SourceList\Net
содержит именно эту информацию.
Решение проблемы:
В связи с данной проблемой, можно предложить несколько стратегий:
-
Ручное редактирование реестра:
Если менять настройки GPO не представляется возможным, можно попытаться вручную изменить ключи реестра. Для этого потребуется:
- Открыть редактор реестра (regedit).
- Перейти в
HKCR\Installer\Products\XXXXXX\SourceList\Net
. - Изменять записи, указывающие на старый путь, на новый путь
\\new_server.new_domain\app_path
.
Важно создать резервную копию реестра перед изменениями, чтобы избежать потерь в случае ошибки.
-
Использование утилит управления MSI:
Вам стоит попробовать другие утилиты для управления исходниками MSI:
- Найти или скачать утилиту
MsiSourceList
из Windows SDK, которая позволяет изменять списки источников MSI. Обратите внимание на документацию новой версии SDK для точной локализации утилиты. - Использовать
ORCA
(утилита из Windows SDK) для редактирования MSI-файлов и изменения значений SOURCELIST перед установкой.
- Найти или скачать утилиту
-
Автоматизация процесса через скрипты:
Можно создать скрипт на PowerShell/VBScript, который будет автоматически изменять записи реестра на всех ваших системах. Этот метод требует сетевых прав и различных настроек безопасности, чтобы быть выполненным на всех станциях.
-
Идентификация дополнительных зависимостей:
Проверьте, нет ли других зависимостей, которые может потребоваться обновить или удалить для успешного применения нового пути установки.
Резюме:
Чтобы гарантировать успешное обновление приложений, необходимо обеспечить корректное обновление источников установки в реестре, а также внимательно следить за изменением путей использованных приложений. Использование системных инструментов из SDK и написание скриптов для автоматизации процесса может значительно ускорить решение проблемы и минимизировать риск ошибок.