Администрирование нескольких различных версий серверов «1С:Предприятие» на одном физическом или виртуальном сервере под управлением операционной системы Windows — это классическая задача для системных администраторов, разработчиков и тестировщиков. Подобная необходимость часто возникает при постепенном переходе на новые релизы платформы, тестировании доработок конфигураций или поддержке устаревших баз данных, которые по техническим причинам невозможно перевести на актуальные версии платформы.
Однако при установке нескольких серверов 1С на одну машину администраторы неизбежно сталкиваются с проблемой: стандартная консоль администрирования MMC (файл 1CV8 Servers (x86-64).msc) отказывается подключаться к серверу старой версии, выдавая ошибки о несовместимости версий клиента и сервера. Это происходит потому, что операционная система Windows жестко привязывает компоненту администрирования к последней установленной версии библиотеки radmin.dll через реестр.
В этой статье мы подробно разберем причины возникновения этой проблемы и рассмотрим несколько практических способов ее решения — от классической правки реестра до современных альтернативных инструментов администрирования.
Для начала проанализируем, почему стандартные средства регистрации утилит администрирования дают сбой. Консоль администрирования серверов 1С представляет собой оснастку Microsoft Management Console (MMC). Сама оснастка общается со службами кластера 1С через COM-компоненту, которая содержится в библиотеке radmin.dll (находится в каталоге bin каждого релиза платформы).
При инсталляции нового релиза платформы установщик регистрирует свою версию radmin.dll в системном реестре Windows по фиксированным идентификаторам классов (CLSID). В результате операционная система перенаправляет любые вызовы MMC-консоли на новую библиотеку. Когда мы пытаемся подключиться к старому серверу, новая библиотека выдает ошибку несоответствия версий. Стандартный запуск утилиты регистрации из меню «Пуск» или использование стандартных скриптов RegMSC.cmd часто не решает проблему, особенно в многопользовательских терминальных средах.
Рассмотрим наиболее надежный и проверенный на практике способ автоматизации, который позволяет переключать версии утилиты администрирования «на лету» без необходимости перезагрузки сервера или повторной ручной регистрации библиотек.
Суть метода заключается в создании персональных файлов реестра (.reg) для каждой версии платформы и управляющих командных файлов (.cmd), которые будут быстро вносить изменения в реестр непосредственно перед запуском консоли MMC.
Разберем этот процесс по шагам.
Шаг 1. Создание файлов конфигурации реестра (.reg)
Для каждого релиза платформы нам необходимо создать свой reg-файл. Создадим текстовый файл, например, с именем 8.3.21.1607.reg, и внесем в него следующие параметры конфигурации (обязательно замените пути к платформе на актуальные для вашей системы):
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{A42674D4-2D97-4988-A81D-2C113CC42A95}\InprocServer32]
@="C:\\Program Files\\1cv8\\8.3.21.1607\\bin\\radmin.dll"
"ThreadingModel"="Both"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{803144C8-17E6-4926-86C5-C195B6D226D4}\InprocServer32]
@="C:\\Program Files\\1cv8\\8.3.21.1607\\bin\\radmin.dll"
"ThreadingModel"="Both"
Создадим аналогичный файл для другой версии, например, 8.3.22.1709.reg:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{A42674D4-2D97-4988-A81D-2C113CC42A95}\InprocServer32]
@="C:\\Program Files\\1cv8\\8.3.22.1709\\bin\\radmin.dll"
"ThreadingModel"="Both"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{803144C8-17E6-4926-86C5-C195B6D226D4}\InprocServer32]
@="C:\\Program Files\\1cv8\\8.3.22.1709\\bin\\radmin.dll"
"ThreadingModel"="Both"
Обратите внимание: идентификаторы CLSID {A42674D4-2D97-4988-A81D-2C113CC42A95} и {803144C8-17E6-4926-86C5-C195B6D226D4} остаются неизменными для разных версий платформы 1С 8.3. Меняется только путь к целевой библиотеке radmin.dll.
Шаг 2. Создание командных файлов запуска (.cmd)
Теперь создадим исполняемые bat/cmd-файлы, которые будут применять соответствующий файл реестра в тихом режиме и сразу открывать оснастку MMC.
Пример командного файла для запуска консоли версии 8.3.21.1607:
regedit /s "C:\Program Files\1cv8\common\8.3.21.1607.reg"
mmc /s "C:\Program Files\1cv8\common\1CV8 Servers (x86-64).msc"
И аналогичный командный файл для запуска консоли версии 8.3.22.1709:
regedit /s "C:\Program Files\1cv8\common\8.3.22.1709.reg"
mmc /s "C:\Program Files\1cv8\common\1CV8 Servers (x86-64).msc"
Разместив эти ярлыки на рабочем столе, мы получаем возможность запускать параллельно консоли нужных версий серверов без рутинных манипуляций в консоли управления ОС.
Рассмотрим альтернативный метод ручной настройки, который помогал администраторам решать проблемы совместимости оснасток. Данный способ основан на подмене служебного файла локализации в общем каталоге платформы 1С.
C:\Program Files\1cv8\common.1ceunt.dll и временно переименуем его (создадим резервную копию).bin той версии платформы 1С, консоль которой мы планируем запустить (например, C:\Program Files\1cv8\8.3.21.1607\bin).1ceunt.dll и вставим его в общую папку C:\Program Files\1cv8\common.Этот способ рабочий, но он обладает существенным недостатком: при необходимости частого переключения между версиями серверов вам придется постоянно выполнять данные действия вручную.
Проанализируем стандартные средства платформы. В каталоге bin каждого релиза поставляется файл RegMSC.cmd, предназначенный для регистрации утилиты администрирования. Содержимое этого файла по умолчанию выглядит следующим образом:
regsvr32 /n /i:user radmin.dll
Выясним причину, почему этот скрипт часто не работает. Ключ /n указывает утилите regsvr32 не запускать стандартную регистрацию класса в глобальной ветке реестра HKEY_LOCAL_MACHINE, а ключ /i:user передает управление функции DllInstall для внесения записей в ветку текущего пользователя HKEY_CURRENT_USER. Это сделано для того, чтобы пользователи без прав локального администратора могли регистрировать консоль под себя.
Однако в серверных средах и терминальных сессиях Windows Server этот механизм часто дает сбой, приводя к неполной регистрации классов COM. Чтобы исправить эту ситуацию, рекомендуется модифицировать скрипт.
Если регистрация выполняется от имени обычного пользователя, измените строку на:
regsvr32 /i:user radmin.dll
Если у вас есть права локального администратора компьютера и вам требуется зарегистрировать утилиту глобально для всех пользователей системы, используйте классическую прямую регистрацию библиотеки:
regsvr32 radmin.dll
Использование оснастки MMC (файлов с расширением .msc) и бесконечная борьба с регистрацией библиотек radmin.dll в реестре Windows уходят в прошлое. К тому же, этот метод принципиально не применим, если серверы 1С разворачиваются под управлением операционных систем семейства Linux.
Разберем современную и технологичную альтернативу — администрирование с помощью сервера администрирования (RAS) и консольного клиента (RAC). Этот механизм поставляется штатно со всеми актуальными версиями платформы 1С:Предприятие 8.3.
Преимущества архитектуры RAS/RAC:
Посмотрим на примере, как настроить управление серверами с использованием этой технологии.
Каждая версия сервера 1С должна иметь свою запущенную службу RAS (утилита ras.exe), которая слушает свой уникальный сетевой порт. Зарегистрируем службы RAS для двух установленных серверов 1С через командную строку от имени администратора:
Для первого сервера (версия 8.3.21.1607, порт RAS — 1545):
sc create "1C:Enterprise 8.3.21.1607 RAS" binPath= "\"C:\Program Files\1cv8\8.3.21.1607\bin\ras.exe\" cluster --port=1545" start= auto
Для второго сервера (версия 8.3.22.1709, порт RAS — 2545):
sc create "1C:Enterprise 8.3.22.1709 RAS" binPath= "\"C:\Program Files\1cv8\8.3.22.1709\bin\ras.exe\" cluster --port=2545" start= auto
Запустим созданные службы. Теперь для администрирования этих серверов мы можем использовать консольную утилиту rac.exe из соответствующих каталогов платформ, обращаясь напрямую по портам служб RAS:
rac [команда] localhost:1545
rac [команда] localhost:2545
Более того, для визуального управления вы можете воспользоваться сторонними кроссплатформенными графическими GUI-интерфейсами администрирования 1С (написанными на Java или интегрированными в среду 1C:EDT). Они подключаются к запущенным портам RAS без каких-либо конфликтов версий библиотек на вашем компьютере.
Если вы решили развернуть несколько независимых служб серверов 1С на одном компьютере, решение проблемы с консолью администрирования — это лишь половина дела. Чтобы ваши серверы работали стабильно, не мешали друг другу и не привели к потере данных, строго следуйте следующим правилам:
1. Полная изоляция каталогов данных кластера (параметр -d)
По умолчанию агент сервера 1С хранит реестр кластера, информацию о базах данных и сессиях в папке C:\Program Files\1cv8\srvinfo. Если запустить две разные службы сервера 1С без явного переопределения этого каталога, обе службы начнут одновременно писать данные в один и тот же файл реестра 1cv8wsrv.lst. Это неизбежно приведет к краху обеих служб и повреждению метаданных кластера.
При создании второй службы сервера обязательно указывайте уникальный каталог данных с помощью параметра -d. Посмотрим на пример корректной регистрации службы через утилиту sc.exe:
sc create "1C:Enterprise 8.3.22.1709 Agent" binPath= "\"C:\Program Files\1cv8\8.3.22.1709\bin\ragent.exe\" -srvc -agent -regport 2541 -port 2540 -range 2560:2591 -d \"D:\1C_Data\srvinfo_8_3_22\"" start= auto
2. Тщательное разделение сетевых портов
Каждая запущенная служба сервера 1С должна занимать свой собственный уникальный пул сетевых портов. Убедитесь, что порты не пересекаются:
-port): по умолчанию 1540. Для второго сервера укажите, например, 2540.-regport): по умолчанию 1541. Для второго сервера укажите 2541.-range): по умолчанию 1560:1591. Для второго сервера выделите непересекающийся диапазон, например, 2560:2591.3. Разделение системных пользователей операционной системы
Для обеспечения безопасности и предотвращения конфликтов блокировок файлов кэша и временных данных, настоятельно рекомендуется запускать разные службы серверов 1С от имени разных локальных пользователей ОС Windows (например, создать пользователей USR1CV8_1 и USR1CV8_2). Обязательно предоставьте созданным пользователям права «Вход в качестве службы» в локальных политиках безопасности Windows Server и полные права на чтение/запись к их соответствующим каталогам данных кластера.
Если ваша ИТ-инфраструктура активно развивается, рекомендуем рассмотреть современный подход к развертыванию серверов 1С — контейнеризацию с помощью Docker.
Вместо ручного создания множества служб Windows, изменения системного реестра и постоянного контроля портов, каждая версия сервера 1С изолируется внутри собственного Docker-контейнера. Это позволяет запускать на одном физическом сервере любое количество серверов 1С любых версий. Конфликты реестра и библиотек radmin.dll в такой архитектуре отсутствуют в принципе, так как каждый контейнер работает в своей собственной изолированной операционной среде.