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

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

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

Причины проблемы: почему терминал не видит локальный ключ?

Для начала разберем техническое различие аппаратных ключей защиты HASP. Они делятся на несколько типов, и понимание этих отличий — ключ к решению нашей задачи:

  1. Локальные (однопользовательские): Имеют фиолетовый цвет и маркировку H4 M1. Предназначены для установки непосредственно в ПК пользователя, который физически сидит за монитором.
  2. Сетевые (многопользовательские): Обычно красного цвета, маркируются как NET5, NET10 и т.д. Позволяют раздавать лицензии по локальной сети.
  3. Серверные: Имеют маркировку ENSR8. Нужны исключительно для работы службы сервера 1С:Предприятия.

Выясним причину, по которой однопользовательский ключ отказывается работать в нашей схеме. Главная проблема заключается в том, что драйвер защиты HASP при работе в терминальной сессии (RDP) намеренно блокирует доступ к локальному ключу на программном уровне. Это жесткое лицензионное ограничение 1С: однопользовательский ключ — это одно физическое рабочее место. Терминальный сеанс считается «удаленным», даже если вы подключаетесь к тому же самому серверу, в который физически установлен USB-ключ.

Кроме того, служба раздачи лицензий HASP LM (License Manager) вообще не работает с локальными фиолетовыми ключами. Она их просто игнорирует, поэтому получить лицензию с такого ключа ни по сети, ни в рамках терминальной сессии невозможно.

Как решить проблему с лицензиями в терминале?

Разберем основные методы решения, которые помогут запустить 1С без ошибок лицензирования в среде RDP.

1. Замена ключа на многопользовательский (сетевой)

Самое правильное и надежное решение, которое в итоге помогло автору исходного вопроса. Если вы планируете работать через RDP, вам необходим сетевой аппаратный ключ (на 5, 10, 20 и более пользователей). При установке такого ключа в сервер, необходимо обязательно запустить службу HASP License Manager. Именно она будет выдавать лицензии терминальным клиентам. Без запущенной службы сетевой ключ будет восприниматься системой как локальный и также будет заблокирован в RDP.

2. Проверка настроек запуска базы

Если сетевой ключ установлен, драйверы и HASP LM запущены, но база все равно пишет об отсутствии лицензии, проверим настройки стартера 1С. В окне запуска выделите нужную базу, нажмите "Изменить", дважды нажмите "Далее". Убедитесь, что установлена галочка «Использовать аппаратную лицензию (ключ защиты)». Если она снята, платформа даже не попытается опросить USB-порты и службу HASP, пытаясь найти только программные (пин-кодовые) лицензии.

3. Тонкая настройка файла конфигурации

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

Пример настройки секции в файле:


[NH_TCPIP]
NH_SERVER_ADDR = 192.168.1.50
NH_USE_BROADCAST = Disabled
NH_TCPIP_METHOD = TCP

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

Дополнительные технические нюансы

Проанализируем еще несколько важных аспектов, о которых нужно помнить системному администратору при работе с аппаратными ключами:

  1. Консольные сессии: В старых версиях Windows Server можно было подключиться через команду mstsc /console (или /admin), попадая в так называемую «нулевую сессию». Тогда драйвер думал, что мы сидим за локальным ПК, и фиолетовый ключ работал. В современных версиях Windows Server и новых релизах платформы 1С этот метод закрыт.
  2. Конфликты одинаковых ключей: Если вы воткнете в один сервер или установите в одной локальной сети два ключа одной серии (например, два красных ключа по 10 пользователей), платформа 1С увидит только один из них (первый ответивший). Их емкость не суммируется! Для расширения количества рабочих мест нужно использовать ключи разных серий либо комбинировать аппаратные и программные лицензии.
  3. Виртуализация: Если ваш сервер 1С — это виртуальная машина (Hyper-V, VMware), вам потребуется настроить USB Passthrough (проброс USB-устройства в ВМ). Практика показывает, что стандартные средства гипервизоров могут работать нестабильно, приводя к «отвалам» ключа под нагрузкой. Надежным решением в корпоративной среде является использование физических сетевых USB-концентраторов (технология USB-over-IP).

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

← На главную