Как запускать службу Windows при входе пользователя

Если речь о настоящей службе Windows, сначала настройте её запуск через диспетчер служб; привязка к входу нужна только тогда, когда запуск действительно зависит от входа пользователя. Ниже показываю, как выбрать вариант, вызвать Start-Service из Планировщика и проверить результат без сомнительных ключей Bypass.

Служба и программа пользователя — разные вещи

В Windows службой управляет диспетчер служб. Она запускается под заданной учётной записью и может работать до входа человека в систему. Поэтому фраза «служба не видит профиль» часто указывает не на поздний запуск, а на неверную архитектуру: службе поручили задачу пользовательской программы. Если приложению нужен рабочий стол, личные настройки или сетевой диск, сначала выясните, можно ли отделить эту зависимость. Служба не становится интерактивной только потому, что кто-то вошёл в Windows.

В условном примере ООО «Гранит-Плюс» я начинаю с инвентаризации на одной рабочей станции: точное имя службы, её учётная запись, тип запуска, зависимости и ресурс, к которому она обращается. Это короткая проверка до изменений: она показывает, нужна ли настройка службы на старте компьютера или отдельное действие после входа. Если причина затрагивает всю рабочую станцию, мы можем провести поддержку Windows-инфраструктуры, но сначала я фиксирую исходное состояние, а не включаю всё подряд.

Сетевой диск Z: — не надёжная точка интеграции для службы. Буква может существовать только в сеансе того пользователя, который её подключил; служба работает в собственном сеансе и с собственными правами. Microsoft прямо рекомендует службе обращаться к сетевому ресурсу по UNC-пути и от имени учётной записи, у которой есть разрешения. Если приложение не умеет работать без личного профиля, настройка автозапуска службы эту проблему не исправит.

• Фоновая служба — запуск через диспетчер служб.
• Программа конкретного пользователя — запуск при его входе.
• Сетевой ресурс — UNC-путь и права нужной учётной записи.

Выберите запуск при старте или при входе

Если служба нужна постоянно, настройте её штатный тип запуска. Сначала проверьте имя и состояние, затем меняйте параметр в повышенной сессии PowerShell: команда Set-Service меняет тип старта, а Start-Service запускает остановленную службу сейчас. Для примера ниже замените ExampleService точным свойством Name из Get-Service. Automatic означает запуск операционной системой при старте; это не обещание, что сеть или пользовательский профиль уже готовы.

Get-Service -Name 'ExampleService' | Select-Object Name, Status, StartType
Set-Service -Name 'ExampleService' -StartupType Automatic
Start-Service -Name 'ExampleService'

Отложенный автоматический запуск тоже относится к старту системы, а не к входу определённого пользователя. Он не заменяет проверку готовности внешнего ресурса. Если службе требуется другая служба, настраивают зависимость; если ей нужен удалённый ресурс, проверяют сетевой доступ под её учётной записью. Случайная задержка в десять секунд может сработать сегодня и не сработать завтра — часы не являются проверкой готовности.

В базе знаний есть конкретный пример для Exchange: службы MSExchangeIMAP4 и MSExchangeIMAP4BE настраивают на автоматический старт через Set-Service в Exchange Management Shell и затем проверяют их состояние. Это хороший пример корректного уровня настройки — параметры самих служб, а не пользовательский Run. Если службы компонента Windows Server нет в списке, сначала проверьте установленную роль командой Get-WindowsFeature; нужные роли и компоненты устанавливают через Install-WindowsFeature. Это не способ запуска при входе, а отдельная проверка установки.

• Постоянная фоновая работа — Automatic.
• Запуск по входу — задача с триггером At log on.
• Нет службы в списке — проверьте компонент и его установку.

Подготовьте скрипт с проверкой и журналом

Скрипту нужны точные имена служб и обработка двух исходов: служба уже работает или её удалось запустить. Если имя ошибочное, Get-Service должен сообщить об этом, а не превратить ошибку в пустой статус. Блок try/catch записывает сбой в журнал, чтобы дежурный видел текст исключения. Пример ниже рассчитан на Планировщик, который запускает его от имени SYSTEM; для другого контекста измените каталог журнала и проверьте права на запись.

param(
    [string[]]$ServiceName = @('ExampleService')
)

$logDir = Join-Path $env:ProgramData 'ITFresh'
$logFile = Join-Path $logDir 'StartServices.log'
New-Item -Path $logDir -ItemType Directory -Force -ErrorAction Stop | Out-Null

foreach ($name in $ServiceName) {
    try {
        $service = Get-Service -Name $name -ErrorAction Stop
        if ($service.Status -eq 'Running') {
            $result = 'already running'
        } else {
            Start-Service -Name $name -ErrorAction Stop
            $service = Get-Service -Name $name -ErrorAction Stop
            $result = $service.Status.ToString()
        }
    } catch {
        $result = 'ERROR: ' + $_.Exception.Message
    }
    $line = '{0:u} [{1}] {2}' -f (Get-Date), $name, $result
    Add-Content -LiteralPath $logFile -Value $line -Encoding utf8 -ErrorAction Stop
}

Строка ExampleService — заглушка, а не имя реальной службы. Получите точное имя в оснастке «Службы» или через Get-Service и подставьте его в массив. Если служб несколько, перечислите их через запятую. Start-Service не исправляет неверный пароль служебной учётной записи, отключённый тип запуска или сломанную зависимость: такие причины нужно разбирать отдельно.

При запуске от SYSTEM журнал попадёт в каталог ProgramData, а сам файл скрипта должен быть доступен этой учётной записи на чтение. Обычным пользователям не выдавайте право изменять файл, если его запускает SYSTEM с высокими правами: иначе подмена содержимого даст чужому коду тот же уровень доступа. Для теста откройте журнал после запуска и проверьте как успешный статус, так и ошибку на заведомо неправильном имени. Затем удалите тестовую запись.

Привяжите запуск к Планировщику заданий

Для запуска именно при входе используйте Планировщик заданий. Создайте задачу, а не простую задачу, и укажите триггер «При входе в систему». В действии выберите powershell.exe; в аргументах задайте -NoProfile -File "C:\Scripts\StartServices.ps1". В поле «Начать в» укажите C:\Scripts, если скрипт использует относительные пути. Скопируйте файл в этот каталог и проверьте, что выбранная учётная запись может его читать.

Если задача должна лишь запустить фоновую службу при событии входа, выберите учётную запись SYSTEM и триггер для любого пользователя. Отметьте запуск с наивысшими правами, а в настройках укажите не запускать новый экземпляр, пока предыдущий работает: это снимает гонку при нескольких входах. Такая задача не получает профиль вошедшего пользователя и не видит его подключённые диски. Если нужна пользовательская программа, настройте запуск от имени пользователя в интерактивном сеансе; не подменяйте этим механизмом управление службой.

Обычный ключ реестра HKCU\Software\Microsoft\Windows\CurrentVersion\Run запускает программу при входе конкретного пользователя, но не гарантирует точное время старта или порядок относительно других программ. Длина данных команды ограничена, а запись не превращает процесс в службу и не добавляет ему прав администратора. Реестр подходит для простого пользовательского приложения; когда нужны учётная запись, условия, повторная политика и журнал запуска, Планировщик даёт нужные настройки. Практический разбор запуска PowerShell через планировщик есть в статье про скрипт в Планировщике.

Параметр -ExecutionPolicy Bypass не добавляйте автоматически. Он не выдаёт разрешение на запуск службы и не устраняет ошибку пути или доступа. Сначала проверьте действующую политику командой Get-ExecutionPolicy -List и следуйте настройке компьютера; для управляемых скриптов выбирайте согласованный способ хранения и подписания. В задаче оставьте -NoProfile, чтобы результат не зависел от профиля PowerShell пользователя.

• Триггер: «При входе в систему».
• Действие: powershell.exe с параметром -File.
• Учётная запись и права: по требуемому контексту.
• Одновременно: не запускать второй экземпляр.

Проверьте результат и только потом тиражируйте

В условном примере ООО «Гранит-Плюс» проверка остаётся измеримой и не обещает несуществующих секунд: одна тестовая рабочая станция, одна служба и два последовательных входа. В задаче указаны триггер «При входе», учётная запись SYSTEM и файл C:\Scripts\StartServices.ps1; журнал находится в %ProgramData%\ITFresh\StartServices.log. При первом запуске ожидается новая попытка старта и итоговый статус, при повторном — запись already running. Только после этого я переношу задачу на следующий компьютер и сравниваю результат.

Сначала запустите задачу вручную из Планировщика и проверьте последнюю строку журнала. Затем выйдите из системы и войдите снова; убедитесь, что задача запустилась в нужном контексте, а служба стала Running. Если задача сообщает об успехе, а приложение всё равно не работает, проверяйте прикладной журнал и реальный доступ к нужному ресурсу. Для профиля пользователя полезно сначала исключить отдельную проблему входа, например временный профиль Windows. Статус службы и исправность приложения — две разные проверки.

Системные события можно отфильтровать штатной командой PowerShell. Ищите запись по времени, источнику Service Control Manager и имени нужной службы, а не делайте вывод по одному коду. Ошибка 1053 означает, что служба не ответила на запрос запуска или управления в отведённый срок; сама по себе она не говорит, что надо менять таймаут в свойствах. Сверьте учётную запись службы, зависимости, её собственный журнал и права на файлы. Если причина в разрешениях или автоматизации домена, полезен также материал про PowerShell-автоматизацию для AD.

Get-WinEvent -FilterHashtable @{
    LogName = 'System'
    ProviderName = 'Service Control Manager'
    StartTime = (Get-Date).AddMinutes(-15)
} | Select-Object TimeCreated, Id, LevelDisplayName, Message

Записывайте для каждого компьютера имя службы, её учётную запись, тип старта, путь к скрипту и результат контрольного запуска. Не раскатывайте задачу сразу на весь парк: сначала одна машина, затем небольшая группа, потом остальные. При проблеме сравните настройки и время события с журналом скрипта. Такой порядок отделяет ошибку сценария от отказа самой службы; ни один ключ реестра не может гарантировать готовность профиля, сети и приложения одновременно.

• Проверьте один компьютер и одну службу.
• Сверьте первый и повторный запуск.
• Сопоставьте журнал скрипта с журналом System.
• Только после проверки расширяйте развёртывание.

Частые вопросы