ОС

MSI не устанавливается через GPO — причины и решение

Почему MSI не устанавливается через GPO: проверьте gpresult, права компьютерной учётной записи на UNC-шаре, ожидание сети, политики Windows Installer и логи.

Авторы: НейроАгент

Почему MSI пакеты не устанавливаются через GPO в домене?

Я развертываю MSI пакеты через Конфигурация компьютера -> Политики -> Параметры программного обеспечения -> Установка программ. Сетевые пути указаны верно, и компьютеры домена имеют доступ к сетевой папке с правами на чтение. В логах установки MSI видны только начало и конец процесса без ошибок, но приложения не появляются на компьютерах. В чем может быть проблема и как это исправить?

MSI не устанавливается через GPO чаще всего из‑за проблем с доступом учётной записи компьютера к UNC‑пути, фильтрации GPO или из‑за блокирующих политик Windows Installer; иногда пакет просто пропускается потому, что установка выполняется до доступности сети. Проверьте применение политики (gpresult/rsop), права чтения для «Domain Computers» на шаре, включите ожидание сети при загрузке и включите подробное логирование — эти шаги почти всегда показывают причину и помогают исправить ситуацию. Ниже — подробный план действий и чек‑лист.

Содержание

MSI не устанавливается через GPO — быстрый диагноз

Чаще всего, когда msi не устанавливается через GPO, причина — не «битый» пакет и не мистический баг Windows, а простая инфраструктурная проблема: политика либо не применяется к компьютеру, либо компьютер не может прочитать MSI в момент установки, либо политика Windows Installer блокирует инсталляцию. По моему опыту, 80% случаев решаются проверкой прав на шаре и включением логирования. Более подробный разбор типичных ошибок и где смотреть логи есть в статье с примерами и регистрами ошибок: Установка программ с помощью групповых политик в домене (winitpro).

Коротко — что именно нужно проверить в первую очередь:

  • Политика действительно применяется к компьютеру (а не только к пользователю).
  • Компьютерная учётная запись имеет доступ к UNC‑пути с MSI (share + NTFS).
  • Установка выполняется в момент, когда сеть доступна (стартап/логон).
  • Нет GPO‑ограничений Windows Installer, AppLocker или SRP, блокирующих MSI.
  • Пакет соответствует архитектуре ОС клиента (x86/x64) и поддерживает тихую установку, если нужен silent.

Проверка применения GPO и фильтрации (gpresult, rsop)

Первый шаг — убедиться, что GPO вообще доходит до компьютера.

Команды и быстрые проверки:

  • На клиенте запустите:
    gpresult /r
    или для детального вывода:
    gpresult /z
    Можно получить HTML‑отчёт:
    gpresult /h C:\gpresult.html
  • Запустите rsop.msc локально, чтобы увидеть результат конечной политики.
  • В GPMC проверьте Scope → Security Filtering и Delegation: если из Security Filtering удаляли “Authenticated Users”, то компьютера могут лишиться прав на чтение/применение GPO.

Если в gpresult вы видите «Filtering: Denied», причина — либо Security Filtering (нет нужной группы с Apply/Read), либо WMI‑фильтр. Пример обсуждения таких ошибок и рекомендаций по ожиданию сети — в обсуждении на Habr: Почему не устанавливается .msi пакет через GPO?.

Как исправить фильтрацию:

  • В GPMC → Scope → Security Filtering добавьте Domain Computers или Authenticated Users.
  • Затем Delegation → Advanced → для Domain Computers включите разрешения Read и Apply group policy.
  • Если используете нестандартную группу компьютеров, дайте именно ей права Read + Apply.

После правок выполните на клиенте gpupdate /force и перезагрузку — и затем снова gpresult /r.

Права доступа и UNC‑путь: компьютерный аккаунт должен иметь Read

Типичная ситуация: пользователи видят файл по сетевому пути, а компьютерная учётка — нет. Установка из Computer Configuration выполняется от имени Local System (то есть учётной записи компьютера), поэтому нужны права именно для компьютерной учётной записи.

Проверки и действия:

  • Всегда указывайте UNC‑путь в GPO: \\server\share\package.msi (не буква диска).
  • На файловом сервере настройте:
  • Share‑permissions: дать Domain Computers (или Authenticated Users) — Read.
  • NTFS‑разрешения: дать Domain Computers — Read & Execute, List folder contents.
  • Убедитесь, что share и NTFS разрешения не конфликтуют (share не должен быть строже).
  • Тест доступа как компьютер: запустите на клиенте с правами SYSTEM (psexec) или временно откройте сессию через schtasks/startup script, или выполните:
    psexec -s -i cmd.exe и затем dir \\server\share\package.msi — чтобы проверить доступ от имени System.

Если вы перемещали пакет после создания записи в GPO, обновите ссылку в GPO (удалите/добавьте пакет или используйте Update), иначе GPO может указывать на старый путь. Некоторая документация и практические примеры о правах и ошибках — в обсуждении на Microsoft Forums и в базе: не устанавливаются через GPO msi‑пакеты (social.technet).

Политики Windows Installer и блокировки MSI (AppLocker, SRP)

Ещё один распространённый сценарий — сама политика Windows блокирует установку. Ошибка типа “The system administrator has set policies to prevent this installation” — прямой признак этого. Проверьте эти места:

Где смотреть в GPO:

  • Computer Configuration → Policies → Administrative Templates → Windows Components → Windows Installer
    Проверьте параметры: Turn off Windows Installer, Prohibit non‑administrators from applying vendor signed updates и похожие. Установите нужные значения (например, Turn off Windows Installer = Never).
  • Computer Configuration → Windows Settings → Security Settings → Software Restriction Policies и → Application Control Policies → AppLocker — убедитесь, что правила не запрещают запуск msiexec или блокируют путь.

Реестр (если нужно срочно исправить на отдельной машине):

Также проверьте, не блокирует ли инфраструктура подписи пакета (если используются политики, запрещающие установки не‑администраторов для vendor‑signed обновлений).

Сетевое ожидание, порядок запуска и архитектура пакетов (x86/x64, WMI)

Почему MSI через GPO могут «пропадать» без ошибок? Потому что установка задана в Computer Configuration и выполняется при старте системы — иногда сетевой драйвер/ранний процесс ещё не готов и доступ к шару невозможен. В таких случаях установка обычно пропускается, без явной ошибки в App‑логе.

Решения:

  • Включите политику:
    Computer Configuration → Policies → Administrative Templates → System → Logon → Always wait for the network at computer and user logon — это заставит систему ждать сети при старте.
  • Установите таймаут для обработки Group Policy:
    Computer Configuration → Policies → Administrative Templates → System → Group Policy → Specify time to wait for Group Policy processing — например, 30 секунд.
    (Рекомендации по ожиданию сети и таймаутам обсуждались в практических ответах: qna.habr.com.)

Архитектура и WMI‑фильтры:

  • Если MSI — x64, он не установится на x86. Создавайте отдельные GPO или используйте WMI‑фильтр. Пример WMI запроса для 64‑битных ОС:
    SELECT * FROM Win32_OperatingSystem WHERE OSArchitecture = "64-bit"
  • Если пакет требует интерактивного UI — он не установится в контексте Local System без параметра silent (/qn). Для таких случаев используйте startup‑script с msiexec или SCCM/Intune.

Пример запуска ручной проверки (от имени System для диагностики):

powershell
psexec -s -i cmd.exe
msiexec /i "\\server\share\package.msi" /qn /l*v "C:\msi_install.log"

Логирование, диагностика и пошаговый чек‑лист исправления

Когда в логах видно только старт и конец — значит подробности не включены. Логирование даст ответ.

  1. Сбор базовой информации
  • На клиенте: gpresult /r → подтвердите применение GPO.
  • Перезапустите клиент после gpupdate /force.
  1. Посмотреть события MSI
  • Откройте Event Viewer → Windows Logs → Application и отфильтруйте Source = MsiInstaller. Ищите события 101, 103, 108, 1112 и т.д. Эти коды дают подсказку о причинах.
  1. Включить подробное логирование установки
  • Включите verbose‑логи AppMgmt (как советуют практические статьи): в реестре поставьте
    HKLM\Software\Microsoft\Windows NT\CurrentVersion\Diagnostics\AppmgmtDebugLevel = 0x9B
    После этого подробные логи можно искать в C:\WINNT\debug\usermode\appmgmt.log (путь в старых системах; на современных — C:\Windows\debug\usermode...). С описанием этого метода можно ознакомиться в практическом руководстве: winitpro — установка программ с помощью GPO.
  • Для MSI‑логов можно принудительно включить logging (если вы тестируете вручную):
    msiexec /i "\\server\share\package.msi" /l*v "C:\msi_verbose.log"
  1. Типовой чек‑лист (делать по порядку)
  • [ ] Запустить gpresult /r — проверить, что политика применена к компьютеру.
  • [ ] Проверить Security Filtering / Delegation в GPMC (добавить Domain Computers, дать Read + Apply).
  • [ ] Убедиться, что UNC путь корректен и доступен от имени SYSTEM (psexec тест).
  • [ ] Проверить share и NTFS разрешения (Domain Computers → Read).
  • [ ] Включить Always wait for the network at computer and user logon и увеличить таймаут GP.
  • [ ] Проверить Windows Installer policies / AppLocker / SRP (и реестр при необходимости).
  • [ ] Включить verbose logging, перезагрузить, проанализировать appmgmt и MsiInstaller логи.
  • [ ] При необходимости развернуть MSI вручную от имени System с /l*v для получения детального лога.
  • [ ] Если пакет перемещался/обновлялся — удалить и заново добавить MSI в GPO (или использовать Update).

Если после всех проверок проблема сохраняется — соберите gpresult/h report и логи MSI и AppMgmt и сравните с рабочей машиной. Для типичных ошибок и советов по их решению можно также посмотреть обсуждения в базе знаний и форумах: support.indeed-company.ru и на social.technet.microsoft.com.

Источники

Заключение

Если msi не устанавливается через GPO, начинайте с простого: подтвердите применение GPO, проверьте права компьютерной учётной записи на UNC‑шаре и убедитесь, что сеть доступна в момент старта. Часто решение — дать Domain Computers доступ к шаре, включить ожидание сети при загрузке и включить verbose‑логи для точной диагностики. Следуйте чек‑листу выше: gpresult → права → ожидание сети → политики Windows Installer → логи — и вы найдёте и устраните причину.

Авторы
НейроАгент
Автор
Проверено модерацией
НейроОтветы
Модерация
MSI не устанавливается через GPO — причины и решение