Будут ли конфликтовать USB-ключ на 10 пользователей и USB-ключ на сервер предприятия при установке на один компьютер?

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

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

Природа взаимодействия ключей разных серий

Проанализируем главный вопрос: почему одни ключи работают вместе, а другие — нет? В системе защиты 1С:Предприятие используется технология HASP от компании SafeNet (ныне Thales). Ключи разделяются по так называемым «сериям». Основное правило гласит: на одном компьютере (в одной операционной системе) не могут полноценно функционировать два сетевых ключа одной серии.

Однако клиентский ключ и серверный ключ относятся к принципиально разным категориям:

  1. Клиентский ключ (сетевой): Относится к серии ORGL8. Он предназначен для раздачи лицензий пользователям по сети через специальную службу — HASP License Manager.
  2. Серверный ключ (локальный): Предназначен для разрешения запуска самого процесса сервера 1С (ragent, rmngr, rphost). Он не раздает лицензии пользователям и опрашивается сервером напрямую.

Выясним причину отсутствия конфликта: поскольку клиентский ключ (серия ORGL8) и серверный ключ (например, серия ENSR8 для 32-битного сервера или EN8SA для 64-битного) имеют разные программные идентификаторы серий, драйвер ключа и операционная система различают их без каких-либо затруднений. Они будут стабильно работать в портах одного системного блока.

Визуальная идентификация и маркировка ключей

Посмотрим на аппаратную часть. Чтобы не запутаться в ключах, необходимо знать их цветовую маркировку и надписи на металлическом разъеме. Рассмотрим основные типы:

Важно помнить, что если вы попытаетесь вставить два фиолетовых ключа (например, на 10 и 20 пользователей), система увидит только один из них. Но фиолетовый и красный/зеленый ключи — это абсолютно разные устройства с точки зрения логики защиты.

Особенности работы службы HASP License Manager

Разберем, как программное обеспечение взаимодействует с этими ключами. Для функционирования сетевого клиентского ключа на 10 пользователей на сервере обязательно должен быть установлен и запущен HASP License Manager. Эта служба сканирует USB-порты, находит ключ серии ORGL8 и начинает «вещать» о наличии свободных лицензий в сеть.

В то же время, серверный ключ (на 1С:Предприятие) работает иначе. Процесс сервера 1С обращается к нему напрямую через драйвер AKS HASP. Ему не нужен License Manager. Таким образом, даже на уровне программных интерфейсов эти два ключа используют разные пути обращения к драйверу. Конфликт исключен, так как драйвер HASP изначально спроектирован для поддержки множества одновременно подключенных ключей разных серий.

Когда конфликты все-таки возникают?

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

Если у вас уже есть ключ ORGL8 на 10 пользователей и вы докупаете еще один ключ ORGL8 на 5 пользователей, то при подключении обоих в один сервер возникнет проблема. HASP License Manager подхватит только один из них (обычно тот, что имеет меньший адрес на шине USB или был инициализирован первым). В итоге вместо 15 лицензий вы получите только 10 или 5.

Как решить такую задачу, если ключи все же одной серии? Разберем варианты:

  1. Разнос по разным ПК: Установить второй ключ на другой компьютер в сети и запустить там свой экземпляр HASP License Manager.
  2. Виртуализация: Использование гипервизоров (ESXi, Hyper-V, Proxmox). Мы можем «пробросить» (USB Passthrough) один ключ в одну виртуальную машину, а второй — в другую.
  3. Обмен ключа: Самый правильный способ с точки зрения лицензионной чистоты 1С — произвести апгрейд (обмен с доплатой) двух ключей на один ключ большей емкости (например, на 20 пользователей).

Тонкая настройка через nethasp.ini

Чтобы ускорить запуск программы и гарантировать, что клиентские сессии будут забирать лицензии именно с нашего сервера, проанализируем настройку конфигурационного файла nethasp.ini. Этот файл находится в папке conf каталога установки 1С на рабочих станциях пользователей.

Рассмотрим пример настройки секции [NH_COMMON] и [NH_TCPIP] для жесткой привязки к серверу с ключом:


[NH_COMMON]
NH_TCPIP = Enabled

[NH_TCPIP]
NH_SERVER_ADDR = 192.168.1.100 ; IP-адрес сервера, где стоит ключ на 10 лиц.
NH_PORT_NUMBER = 475
NH_TCPIP_METHOD = TCP
NH_USE_BROADCAST = Disabled

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

Приоритеты выбора лицензий

Важно понимать, в каком порядке 1С ищет лицензию при запуске. Если на сервере или компьютере пользователя установлено несколько видов защиты, система следует жесткому алгоритму:

  1. Сначала проверяется наличие программной лицензии (файлы .lic) на локальном компьютере.
  2. Затем ищется локальный USB-ключ (синий).
  3. Далее выполняется поиск многопользовательского ключа в сети через License Manager.
  4. Если используется серверный вариант, сервер 1С сам может раздавать лицензии из своего состава (если это настроено в параметрах информационной базы).

Таким образом, наличие серверного ключа в порту сервера никак не мешает клиенту сначала попытаться найти локальный ключ или программную лицензию, и только потом обратиться к нашему сетевому ключу на 10 пользователей.

Резюме

Подведем итог нашему анализу: USB-ключ на 10 пользователей и ключ на сервер предприятия конфликтовать не будут. Вы можете смело устанавливать их в один сервер. Это стандартная схема работы для тысяч предприятий. Главное — убедиться, что на сервере установлен актуальный драйвер защиты и запущен менеджер лицензий для корректной работы клиентского ключа.

← На главную