Нужно ли переустанавливать сервер 1С при замене аппаратного ключа защиты и почему служба не видит новый ключ?

Системный администратор 1С v8.3 (Управляемые формы) IT и автоматизация бизнеса
← На главную

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

Требуется ли переустановка сервера 1С при смене ключа?

Сразу ответим на главный вопрос: переустанавливать сервер 1С или саму платформу не требуется. Сервер 1С (служба ragent / 1C:Enterprise Server Agent) не привязывается намертво к конкретному серийному номеру аппаратного ключа в момент инсталляции. При запуске и в процессе работы кластер 1С динамически опрашивает локальные USB-порты и драйвер защиты HASP на наличие подходящей серверной лицензии.

Если после физической замены одного ключа на другой служба сервера 1С не стартует или клиентские подключения завершаются ошибкой лицензирования, причина кроется в одном из трех факторов: несоответствие разрядности ключа и сервера, попытка использовать клиентский ключ вместо серверного, либо сбой проброса USB-устройства в виртуальную машину. Рассмотрим каждую причину подробно.

Причина 1. Несовместимость разрядности: 64-битный сервер и 32-битный ключ

Это самая распространенная ошибка при переносе баз. Аппаратные серверные ключи HASP делятся по разрядности и имеют четкую цветовую маркировку:

  1. Зеленый ключ (маркировка SERVER64 / ENSR8) — лицензия на 64-разрядный сервер 1С:Предприятия. Данный ключ универсален: он позволяет запускать как 64-битный, так и 32-битный сервер 1С.
  2. Фиолетовый ключ (маркировка EN4SA) — лицензия на 32-разрядный (x86) сервер 1С:Предприятия. Этот ключ не позволяет запустить 64-разрядную службу сервера 1С.

Если на новый сервер была установлена 64-битная версия платформы 1С (для тестирования использовался зеленый ключ SERVER64), а постоянный ключ компании оказался фиолетовым (32-битным), 64-разрядный сервер 1С откажется работать с таким ключом и выдаст сообщение о том, что лицензия не найдена.

В такой ситуации есть два варианта решения:

  1. Установить 32-разрядную версию сервера 1С:Предприятия (если объем баз и нагрузка позволяют работать в рамках ограничений x86).
  2. Выполнить официальный апгрейд лицензии с 32-разрядного сервера на 64-разрядный или приобрести программную лицензию 1С:Предприятие 8.3 КОРП / ПРОФ Сервер МАКС 64.

Причина 2. Путаница между серверными и клиентскими ключами

Нередко системные администраторы путают серверный ключ с многопользовательским клиентским. Проанализируем типы остальных ключей защиты:

  1. Красные ключи (маркировка NetHZ, NET5, NET10, NET20, NET50, NET100, NET250 и выше) — сетевые клиентские лицензии на определенное количество рабочих мест. Они предоставляют лицензии только для пользовательских сеансов и не содержат лицензии на запуск сервера 1С.
  2. Синие ключи (маркировка H4 M1) — однопользовательские локальные клиентские лицензии. Серверную службу они также не лицензируют.

Важно помнить: серверный ключ HASP (зеленый или фиолетовый) должен быть подключен непосредственно к машине (или проброшен в виртуальную среду), где выполняется процесс ragent.exe / rphost.exe. В отличие от клиентских лицензий, серверную лицензию HASP нельзя раздавать по сети через утилиту HASP License Manager с другого сервера.

Причина 3. Ошибки проброса USB-ключа в гипервизорах и USB-over-IP

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

  1. Привязка по уникальному идентификатору (Device ID / Serial Number): Большинство гипервизоров (VMware ESXi, Proxmox, Hyper-V, KVM) при добавлении USB-устройства в конфигурацию виртуальной машины привязываются не к номеру физического порта, а к конкретному экземпляру устройства (его серийному номеру). При замене временного ключа на постоянный гипервизор теряет связь со старым устройством и автоматически новое не захватывает. Необходимо зайти в настройки виртуальной машины, удалить старый проброс USB и добавить вновь обнаруженный физический ключ.
  2. Программные шлюзы USB-over-IP: Если проброс реализован через сетевые USB-концентраторы (например, AnywhereUSB или специализированный софт), необходимо открыть панель клиента USB-over-IP внутри виртуальной машины и вручную подключить (Connect) новое появившееся устройство.

Пошаговая диагностика ключа в операционной системе

Проанализируем состояние ключа непосредственно на сервере по шагам:

  1. Проверка диспетчера устройств (для Windows): Откроем Диспетчер устройств гостевой ОС. В разделах контроллеров USB или устройств безопасности должны присутствовать компоненты Sentinel HASP Key, Sentinel HL Key и SafeNet Inc. USB Key. На них не должно быть знаков ошибки (код 10, код 43).
  2. Проверка через панель управления Sentinel: При установленном драйвере HASP (Sentinel Runtime) откроем браузер на сервере и перейдем по адресу http://localhost:1947. В меню Sentinel Keys отобразится список подключенных аппаратных ключей. Проверим Vendor ID (для 1С используется код VRNQU / EA4A / 00000038) и перечень активных лицензий (Features).
  3. Перезапуск службы 1С: После успешного обнаружения ключа операционной системой откроем оснастку служб (services.msc) и перезапустим службу Агент сервера 1С:Предприятия.

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

← На главную