Event ID 4103 в PowerShell — причины и решение

TL;DR

Event ID 4103 появляется в журнале Microsoft-Windows-PowerShell/Operational при вызове команд PowerShell. Чаще всего причина — строгая политика исполнения, повреждённые или несовместимые модули или нехватка прав. Проверьте детали события в Просмотре событий, проверьте и при необходимости измените ExecutionPolicy, проверьте модули и права пользователя. В статье — пошаговые проверки, варианты устранения, чеклисты для ролей и схема принятия решений.

Снимок экрана: иконка Event ID 4103 в журнале PowerShell

Event ID 4103 — это сообщение в журнале, которое чаще всего информирует о вызове команды или скрипта в PowerShell и регистрируется в логе Microsoft-Windows-PowerShell/Operational. Оно само по себе часто информационное, но может помогать обнаружить ошибки исполнения, попытки выполнить запрещённый скрипт или конфликты модулей.

Что означает запись Event ID 4103

Event ID 4103 фиксирует контекст вызова: какую команду запускали, от какого пользователя, и какие ошибки или предупреждения возникли во время выполнения. Это полезно для аудита, расследований безопасности и отладки скриптов.

Краткое определение: PowerShell Execution Event — запись о выполнении команд/скриптов в логах PowerShell.

Важно: само по себе событие может не указывать на сбой платформы, но его детали помогут понять, была ли операция заблокирована политикой или провалилась из‑за ошибки.

Распространённые причины появления Event ID 4103

Execution policy (политика исполнения) слишком жёсткая и блокирует выполнение скриптов. Например, режим AllSigned или Restricted.
Повреждённые, устаревшие или несовместимые модули PowerShell, которые при импорте генерируют ошибки.
Недостаточные права у пользователя или процесса (нет прав на чтение/запись файлов, на запуск удалённых команд, на доступ к ресурсам).
Групповые политики (GPO) или параметры безопасности, запрещающие определённые сценарии.
Синтаксические ошибки в скрипте или использование неподдерживаемых команд/функций для текущей версии PowerShell.

Быстрая проверка перед углублённой отладкой

Перед началом сложных действий выполните эти простые проверки:

Убедитесь, что PowerShell обновлён до поддерживаемой версии.
Установите все важные обновления Windows.
Откройте скрипты и проверьте синтаксис и корректность путей/переменных.
Проверьте права учётной записи, под которой запускается скрипт.
Просмотрите групповые политики, связанные с PowerShell.

Если всё выше в порядке — переходите к пошаговой диагностике ниже.

Пошаговая диагностика и устранение

1. Просмотр деталей события

Нажмите клавишу Windows, введите Просмотр событий и нажмите Открыть.
Перейдите: Windows Logs\Application или в ветку Microsoft-Windows-PowerShell/Operational (в зависимости от конфигурации).
В правой панели найдите и выберите запись Event ID 4103.
Перейдите во вкладки Общие и Подробно, чтобы получить текст сообщения и контекст (пользователь, командная строка, ошибки).

Разбор текста события часто указывает, заблокировал ли PowerShell выполнение политикой исполнения, или произошла конкретная ошибка загрузки модуля.

2. Проверка Execution Policy

Нажмите Windows, введите powershell, выберите Запуск от имени администратора.
Выполните команду:

Get-ExecutionPolicy

Если политика слишком жёсткая (например, Restricted или AllSigned) и вы доверяете скрипту, поменяйте политику на более разрешающую:

Set-ExecutionPolicy RemoteSigned — обычно безопасный вариант для администраторов.

Set-ExecutionPolicy Bypass -Scope Process — временно для сессии (без изменения системных настроек).

Диалог установки Execution Policy

Примечание: меняйте политику обдуманно. Для систем с высокой безопасностью согласуйте изменения с политикой организации.

3. Проверка модулей и импорта

Посмотрите список импортируемых модулей и их версии: Get-Module -ListAvailable.
Попробуйте запустить проблемную команду вручную в интерактивной сессии и посмотрите на ошибки импорта.
Если модуль вызывает ошибку, переустановите его из надёжного источника (PowerShell Gallery или репозитория организации): Install-Module .

Когда модуль устарел или скомпилирован для другой версии CLR/PowerShell, он может генерировать ошибки при загрузке.

4. Проверка прав доступа

Убедитесь, что учётная запись запуска имеет права на файлы скрипта и необходимые ресурсы (сетевые пути, БД, ключи реестра).
Для удалённых вызовов проверьте настройки WinRM и политику CredSSP/TrustedHosts, если используется.

5. Групповая политика и централизованные настройки

Проверьте GPO: Administrative Templates → Windows Components → Windows PowerShell.
Проверьте настройки, накладывающие ExecutionPolicy или запрещающие удалённое выполнение.

6. Логирование и отладка скриптов

Включите подробное логирование: добавьте -Verbose и -Debug при запуске команд для получения дополнительного вывода.
Вставьте в скрипт проверки и обработчики ошибок (Try/Catch) с логированием деталей ошибки.

Дополнительные подходы и когда основной план не помогает

Если событие появляется только для одного пользователя — проблема в профиле или правах этой учётной записи.
Если событие массово — проверьте GPO и распространённые обновления/изменения конфигурации.
При подозрении на компрометацию просмотрите записи безопасности и сопоставьте с временем и источником запуска.

Краткая методология расследования (SOP)

Собрать контекст события (время, пользователь, команда).
Воспроизвести ошибку в контролируемой среде.
Проверить ExecutionPolicy и модули.
Проверить права доступа и GPO.
Внедрить исправление и верифицировать устранение (см. Критерии приёмки).

Критерии приёмки

Событие 4103 более не появляется при выполнении аналогичных команд.
Команда/скрипт выполняется успешно в тестовой среде и в продакшене (если применимо).
Изменения задокументированы и согласованы с политиками безопасности.

Decision tree для первичной диагностики

flowchart TD
  A[Появилось Event ID 4103] --> B{Сообщение указывает на ExecutionPolicy?}
  B -- Да --> C[Проверить Get-ExecutionPolicy]
  C --> D{Политика слишком жёсткая?}
  D -- Да --> E[Изменить на RemoteSigned или Scope Process]
  D -- Нет --> F[Проверить модули и синтаксис]
  B -- Нет --> F
  F --> G{Ошибка импорта модуля?}
  G -- Да --> H[Переустановить/обновить модуль]
  G -- Нет --> I[Проверить права и GPO]
  I --> J{Права/GPO исправлены?}
  J -- Да --> K[Регистрировать и наблюдать]
  J -- Нет --> L[Эскалация к администратору]

Контрольный список для быстрого исправления (шаблон)

Получить текст события и копию сообщения.
[ ] Воспроизвести проблему локально с -Verbose и -Debug.
[ ] Проверить Get-ExecutionPolicy.
[ ] Проверить доступность и версию модулей (Get-Module -ListAvailable).
Проверить права доступа к файлам и ресурсам.
Проверить GPO, применяющие настройки PowerShell.
Применить правку и подтвердить устранение (см. Критерии приёмки).

Когда это не поможет: контрпримеры

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

Безопасность и соответствие

Не отключайте ExecutionPolicy на рабочих системах без одобрения. ExecutionPolicy — инструмент защиты, а не полноценная система безопасности.
Для централизованного контроля используйте GPO и аудит через SIEM.

Заключение

Event ID 4103 сам по себе часто информационный, но подробности события указывают на причину: политика исполнения, модули, права или конфигурация. Системный подход — собрать контекст, воспроизвести проблему, проверить ExecutionPolicy и модули, затем исправить и верифицировать — обычно решает большинство случаев.

Важно: любые изменения конфигурации должны быть задокументированы и согласованы с политиками безопасности организации.

Если вам нужна помощь в разборе конкретного сообщения 4103, вставьте текст события и окружение (версию PowerShell, кто запускал, пример команды) — можно пройти шаги вместе.

И ещё: если вы столкнулись с Event ID 158, у нас есть руководство с пошаговыми инструкциями по нему — оно может быть полезно при параллельной диагностике.