Не удается заставить Windows-приложение “забыть” исходный путь установки.

Вопрос или проблема

У меня есть примерно 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 содержит именно эту информацию.

Решение проблемы:

В связи с данной проблемой, можно предложить несколько стратегий:

  1. Ручное редактирование реестра:

    Если менять настройки GPO не представляется возможным, можно попытаться вручную изменить ключи реестра. Для этого потребуется:

    • Открыть редактор реестра (regedit).
    • Перейти в HKCR\Installer\Products\XXXXXX\SourceList\Net.
    • Изменять записи, указывающие на старый путь, на новый путь \\new_server.new_domain\app_path.

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

  2. Использование утилит управления MSI:

    Вам стоит попробовать другие утилиты для управления исходниками MSI:

    • Найти или скачать утилиту MsiSourceList из Windows SDK, которая позволяет изменять списки источников MSI. Обратите внимание на документацию новой версии SDK для точной локализации утилиты.
    • Использовать ORCA (утилита из Windows SDK) для редактирования MSI-файлов и изменения значений SOURCELIST перед установкой.
  3. Автоматизация процесса через скрипты:

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

  4. Идентификация дополнительных зависимостей:

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

Резюме:

Чтобы гарантировать успешное обновление приложений, необходимо обеспечить корректное обновление источников установки в реестре, а также внимательно следить за изменением путей использованных приложений. Использование системных инструментов из SDK и написание скриптов для автоматизации процесса может значительно ускорить решение проблемы и минимизировать риск ошибок.

Оцените материал
Добавить комментарий

Капча загружается...