Проверяем версию платформы на сервере 1С

Точную версию сервера 1С показывает путь к исполняемому файлу службы «Агент сервера 1С:Предприятия». Откройте services.msc, в свойствах службы посмотрите поле «Путь к исполняемому файлу» — в нём будет каталог вида 8.3.24.1548. Это и есть релиз платформы, под которым работает сервер.

Важно не путать два понятия. Версия сервера 1С — это релиз платформы, запущенный агентом кластера (ragent) и рабочими процессами (rphost). Версия клиента в окне «О программе» может быть другой: обновили клиентскую машину, а серверный кластер остался на старом релизе — обычная ситуация. Поэтому версию нужно смотреть именно на сервере, а не на рабочем месте пользователя.

Способ зависит от того, к чему есть доступ. С рабочего стола сервера быстрее всего через свойства службы, по SSH на Linux — через путь запущенного процесса, с клиентской машины напрямую версию сервера не получить — только косвенно, через совместимость консоли или утилиты rac. Полный номер релиза везде выглядит одинаково — 8.3.24.1548.

Самый быстрый способ — путь к службе агента сервера

Агент сервера ragent запускается как служба Windows. Её путь жёстко привязан к каталогу релиза, поэтому путь = версия.

1. Нажмите Win+R, введите services.msc, Enter.
2. Найдите службу, в названии которой есть «Агент сервера 1С:Предприятия 8.3».
3. Откройте её двойным кликом → вкладка «Общие» → поле «Путь к исполняемому файлу».

Увидите строку вида:

"C:\Program Files\1cv8\8.3.24.1548\bin\ragent.exe" -srvc -agent -port 1540 ...

Номер 8.3.24.1548 — это версия сервера.

То же быстрее достаётся из командной строки. Сначала найдите точное имя службы, затем запросите её конфигурацию:

sc query state= all | findstr /i "1C 1cv8"
sc qc "<имя службы>"

В выводе sc qc строка BINARY_PATH_NAME содержит тот же каталог с номером релиза.

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

Версия в свойствах файлов ragent.exe и rphost.exe

Если путь к папке 1cv8 вы уже знаете, номер релиза читается прямо из свойств бинарника.

• ragent.exe — агент сервера, один на рабочий сервер.
• rphost.exe — рабочий процесс, именно он исполняет код; его версия = версия, под которой реально крутятся сеансы.

Через проводник:

1. Откройте каталог bin нужного релиза, например C:\Program Files\1cv8\8.3.24.1548\bin.
2. Правый клик по rphost.exe → «Свойства» → вкладка «Подробно».
3. Поля «Версия файла» и «Версия продукта» покажут полный номер.

Через PowerShell — одной строкой, без мышки:

(Get-Item 'C:\Program Files\1cv8\8.3.24.1548\bin\rphost.exe').VersionInfo.ProductVersion

Версия продукта и версия файла у бинарников платформы совпадают и выглядят как 8.3.24.1548.

Проверка через консоль администрирования серверов

Консоль «Администрирование серверов 1С Предприятия» — это оснастка MMC. Она сама привязана к конкретному релизу платформы и лежит в каталоге bin этого релиза. Подключиться к агенту сервера получится только консолью подходящей версии — это косвенный, но надёжный признак.

Что сделать:

1. Запустите консоль (ярлык «Администрирование серверов 1С Предприятия») или откройте 1CV8 Servers.msc.
2. Разверните узел центрального сервера, кластер, «Рабочие серверы» и «Рабочие процессы».
3. Если список рабочих процессов rphost отображается без ошибок — консоль совместима с версией агента.

Точный номер релиза консоль в списке не печатает. Поэтому порядок такой: убедились, что консоль подключилась, а сам номер взяли из пункта «О программе» самой консоли (меню оснастки) либо из пути ragent/rphost по способам выше.

Утилита rac: подключение к кластеру из командной строки

rac — консольный клиент администрирования. Он работает через сервер администрирования ras и удобен, когда графической консоли нет. Как и остальные бинарники, rac.exe лежит в bin конкретного релиза, поэтому запуск из нужного каталога уже означает его версию.

Типовой порядок (сервер администрирования слушает порт 1545):

rac 127.0.0.1:1545 cluster list

Команда выведет список кластеров с их идентификаторами. Если подключение прошло — версия вашего rac совместима с агентом сервера.

Полезные команды, в которых можно быть уверенным:

• rac cluster list — список кластеров.
• rac session list --cluster=<uuid> — активные сеансы.
• rac process list --cluster=<uuid> — рабочие процессы с их PID и портами.

Отдельной команды «показать версию платформы» у rac нет. Полный список доступных команд и параметров смотрите через rac help — не подставляйте параметры наугад. Номер релиза проще взять из пути к rac/ragent.

Что о версии подскажут журнал и лог Windows

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

1. Откройте «Просмотр событий» (eventvwr.msc).
2. Перейдите в «Журналы Windows» → «Приложение».
3. Отфильтруйте по источнику, относящемуся к 1С (в названии источника встречается «1C» или «1cv8»).
4. Откройте запись о запуске или об ошибке рабочего процесса — в описании нередко указан полный номер версии.

Второй источник — технологический журнал сервера (настраивается файлом logcfg.xml). В его записях о работе процессов тоже фигурирует версия, но включать технологический журнал только ради номера релиза избыточно: события в «Просмотре событий» дают ту же информацию без настройки.

Версия PostgreSQL и версия сервера 1С — не одно и то же

Частая путаница: администратора просят «узнать версию 1С сервера», а он отдаёт версию СУБД. Это разные вещи.

Версию PostgreSQL легко получить SQL-запросом:

SELECT version();

Запрос вернёт строку вида PostgreSQL 15.4 ... — это версия сервера баз данных, а не платформы 1С.

Номер релиза платформы 1С в самой базе PostgreSQL напрямую не хранится. В базе лежат данные и структура конфигурации, формат которых зависит от платформы, но прочитать из таблиц номер вида 8.3.24.1548 нельзя. Поэтому версию сервера 1С всё равно определяют по службе, файлам ragent/rphost или консоли — способами выше. SQL-запрос по базе отвечает на другой вопрос — «какая СУБД под 1С».

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

Определение версии на Linux и в Docker

На Linux платформа ставится в каталог с номером релиза, поэтому путь снова равен версии.

Стандартное расположение бинарников:

/opt/1cv8/x86_64/8.3.24.1548/

Там же лежат ragent, rphost, rac, ras. Самый надёжный приём — посмотреть путь уже запущенного процесса, он покажет точный релиз работающего агента:

ps -ef | grep -E 'ragent|rphost' | grep -v grep

В строке будет полный путь к бинарнику вместе с номером версии. Службу systemd можно найти так:

systemctl list-units 'srv1cv8*'

Имя юнита и путь в его описании тоже содержат релиз. Если установлено несколько версий — список каталогов в /opt/1cv8/x86_64/ покажет все доступные релизы:

ls /opt/1cv8/x86_64/

В Docker принцип тот же, только команды выполняются внутри контейнера:

docker exec <контейнер> ls /opt/1cv8/x86_64/
docker exec <контейнер> ps -ef | grep -E 'ragent|rphost'

Нередко версия вынесена и в тег образа (например, ...1cv8-server:8.3.24.1548) — проверьте docker ps и docker inspect <контейнер>. Но тег задаёт тот, кто собирал образ, поэтому надёжнее убедиться по пути внутри контейнера, а не доверять названию.

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

Зачем сверять версию клиента и сервера

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

Общее правило простое: клиентское приложение и сервер должны работать на одном релизе платформы. Если клиент новее сервера (или наоборот), при подключении вы можете получить сообщение о несовместимости версий и предложение обновить клиента. Поэтому, узнав версию сервера, тем же способом посмотрите версию клиента — через «О программе» в запущенном приложении.

Сравнивайте релизы строго по номеру сборки, без слов «старше» и «младше». Запись 8.3.24.1548 читается так:

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

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