Запуск 1С как службы: настройка и проверка

Запуск 1С как службы Windows — стандартный способ организовать постоянную работу сервера 1С:Предприятия или агента сервера без необходимости держать открытой пользовательскую сессию. Служба стартует автоматически при загрузке операционной системы, работает в фоновом режиме и не зависит от того, вошёл ли кто-то в систему. Это критично для серверных развёртываний, где базы должны быть доступны пользователям круглосуточно.

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

Важно понимать различие двух сценариев. Первый — служба агента сервера 1С, которая обслуживает клиент-серверные информационные базы. Второй — запуск отдельных фоновых процессов (например, регламентных заданий файловой базы) через планировщик задач Windows, что формально службой не является, но решает похожую задачу автономной работы. Дальше разберём оба подхода, их ограничения и способы проверки результата.

Когда служба действительно нужна, а когда нет

Служба агента сервера 1С обязательна в клиент-серверной архитектуре: именно она принимает подключения клиентов, управляет рабочими процессами и взаимодействует с СУБД. Без запущенного агента пользователи не смогут открыть базу, размещённую на кластере. Поэтому на продуктивном сервере служба всегда настраивается с автоматическим типом запуска.

Для файловых баз служба сервера не требуется — там достаточно общего сетевого доступа к каталогу с базой. Однако возникает смежная задача: регламентные задания и фоновые обработки в файловом режиме выполняются только при запущенном сеансе. Здесь вместо службы применяют планировщик задач Windows, который по расписанию запускает толстый или тонкий клиент с параметрами командной строки.

Не стоит регистрировать службу «на всякий случай» на рабочей станции разработчика: лишний постоянно работающий процесс занимает память и держит открытыми порты. На тестовых машинах разумнее запускать агент вручную как приложение, когда он реально нужен.

Регистрация службы агента сервера 1С вручную

Ручная регистрация выполняется утилитой ragent.exe, которая находится в каталоге bin установленной версии платформы, например C:\Program Files\1cv8\<версия>\bin. Командная строка запускается от имени администратора, иначе регистрация завершится ошибкой доступа.

Типовая команда регистрации службы выглядит так:

"C:\Program Files\1cv8\8.3.22.1750\bin\ragent.exe" -instsrvc -usr .\USR1CV8 -pwd ПарольУчётнойЗаписи -port 1540 -regport 1541 -range 1560:1591 -d "C:\Program Files\1cv8\srvinfo"

Ключ -instsrvc указывает на регистрацию службы, -usr и -pwd задают учётную запись, под которой она будет работать, -port, -regport и -range определяют сетевые порты агента, менеджера кластера и диапазон рабочих процессов. Параметр -d задаёт каталог реестра кластера, где хранятся настройки баз. Удаление службы выполняется той же командой с ключом -rmsrvc.

Если при установке платформы была отмечена опция создания службы, повторная ручная регистрация не нужна — достаточно проверить, что служба «Агент сервера 1С:Предприятия» присутствует в оснастке services.msc и находится в состоянии «Работает».

Выбор учётной записи для службы

По умолчанию установщик предлагает создать отдельного пользователя USR1CV8. Это оправдано: служба получает ровно те права, которые нужны агенту, и не зависит от паролей реальных сотрудников. Запуск от имени учётной записи администратора домена — распространённая, но небезопасная практика: компрометация службы даёт атакующему максимальные права в инфраструктуре.

Учётной записи службы необходимы права на каталог srvinfo (полный доступ), на временные каталоги и, при использовании Windows-аутентификации в СУБД, соответствующие права на сервере баз данных. Если агент стартует, но рабочие процессы падают, первым делом проверяют права именно этой учётной записи.

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

Настройка автозапуска и восстановления

После регистрации откройте оснастку services.msc, найдите службу агента сервера 1С и проверьте тип запуска. Для продуктивного сервера он должен быть «Автоматически». Вариант «Автоматически (отложенный запуск)» полезен, когда служба зависит от СУБД на той же машине: отложенный старт даёт SQL-серверу время подняться раньше агента.

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

Дополнительно проверьте зависимости службы. Если кластер 1С и СУБД размещены на одном сервере, имеет смысл настроить зависимость службы агента от службы СУБД через реестр или команду sc config, чтобы порядок загрузки был гарантирован.

1. 1
   Откройте командную строку от имени администратора
2. 2
   Перейдите в каталог bin нужной версии платформы
3. 3
   Выполните ragent -instsrvc с параметрами портов, учётной записи и каталога srvinfo
4. 4
   Откройте services.msc и убедитесь, что служба появилась
5. 5
   Установите тип запуска «Автоматически» и настройте восстановление при сбое
6. 6
   Запустите службу и проверьте подключение клиентом к базе

Проверка результата и контрольные точки

Факт регистрации службы ещё не означает работоспособность кластера. Проверка выполняется в несколько этапов: состояние службы, прослушивание портов, реальное подключение клиента.

Состояние службы смотрят в services.msc или командой sc query. Прослушивание портов проверяют командой netstat -ano | findstr 1540 — процесс ragent должен слушать порт агента, а rphost — порты из заданного диапазона. Финальная проверка — запуск клиента 1С и открытие базы через кластер: только это подтверждает, что вся цепочка работает.

Альтернатива: планировщик задач для файловых баз

Когда сервер 1С не используется, автономную работу обеспечивает планировщик задач Windows. Создаётся задача, которая запускает 1cv8.exe с параметрами: режим ENTERPRISE, путь к базе, имя и пароль пользователя, а также ключ запуска внешней обработки или выполнения регламентных заданий.

В свойствах задачи включают опцию «Выполнять вне зависимости от регистрации пользователя» и при необходимости «Выполнять с наивысшими правами». Учётная запись задачи должна иметь доступ к каталогу файловой базы по сети, если база лежит на другом компьютере.

Ограничение подхода: запущенный сеанс 1С занимает лицензию и требует, чтобы на машине была установлена платформа. Кроме того, при сбое сеанса задача не перезапустит его сама — это контролируют отдельно, например повторным запуском по расписанию.

Типичные ошибки и ограничения

Чаще всего проблемы возникают не при регистрации службы, а при её эксплуатации после изменений в инфраструктуре. Зная типовые сценарии, диагностика занимает минуты вместо часов.

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

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

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