Переход на современную 64-разрядную операционную систему и использование терминального доступа часто сопровождается техническими сложностями, связанными с системой защиты 1С. Типичная ситуация: на самом сервере программа запускается без проблем, но пользователи, подключающиеся через удаленный рабочий стол (RDP), получают ошибку "Не обнаружен ключ защиты программы". Давайте разберем эту проблему подробно, проанализируем причины и выработаем надежный алгоритм решения.
Разберем, почему стандартная установка 1С часто дает сбой в среде Windows Server 2008 R2. Основная причина кроется в механизмах изоляции терминальных сессий. Когда 1С запускается локально на консоли сервера, она может обращаться к драйверу ключа напрямую. Однако в RDP-сессии программная среда ограничена. Если менеджер лицензий не настроен должным образом, 1С пытается найти "локальный" ключ внутри сессии и, естественно, его не находит.
Проанализируем ключевые факторы, препятствующие обнаружению ключа:
Как показывает практика, наиболее надежный способ решить проблему — выполнить чистую установку компонентов в строго определенном порядке. Рассмотрим этот алгоритм, который помог автору темы на форуме:
После такой установки проверим наличие процессов hasplms.exe в диспетчере задач. Они должны быть запущены от имени системы.
Если переустановка не помогла или вы не хотите переустанавливать систему, проанализируем настройки сетевого обмена. Основным инструментом здесь выступает файл nethasp.ini. Он находится в папке bin/conf (или просто в bin) каталога установки платформы 1С.
Посмотрим, как правильно сконфигурировать этот файл, чтобы 1С "видела" ключ в терминальной сессии. Нам необходимо принудительно указать программе, где искать ключ, не полагаясь на автоматический поиск. Откройте файл блокнотом и отредактируйте секцию [NH_TCPIP]:
[NH_COMMON]
NH_TCPIP = Enabled
[NH_TCPIP]
;; Указываем конкретный IP-адрес сервера, где установлен ключ
NH_SERVER_ADDR = 127.0.0.1
;; Или используйте локальный IP сервера в сети, например:
;; NH_SERVER_ADDR = 192.168.1.5
;; Отключаем широковещательный поиск для ускорения
NH_USE_BROADCAST = Disabled
;; Указываем порт по умолчанию (475)
NH_TCPIP_METHOD = TCP
Важный нюанс: Использование 127.0.0.1 в терминальной сессии оправдано, так как ключ физически находится на том же сервере, где исполняется код 1С. Это заставляет программу обращаться к локальной службе hasplms через сетевой стек, обходя ограничения сессии.
Выясним, установлена ли на вашем Windows Server 2008 R2 роль "Remote Desktop Session Host" (Сервер узла сеансов удаленных рабочих столов). Без этой роли сервер работает в режиме "удаленного администрирования" (лимит 2 подключения), и многие механизмы перенаправления ресурсов могут работать некорректно.
Если вы устанавливаете ПО на терминальный сервер, всегда используйте специальный режим. Выполните в командной строке (cmd) от имени администратора:
change user /install
После этого запустите установку драйверов или платформы. По завершении верните систему в обычный режим:
change user /execute
Проанализируем ситуацию, когда порт 475 кажется закрытым. Как упоминалось в сообщении автора, команда telnet 192.168.1.5 475 выдавала ошибку. Это явный признак того, что либо служба HASP LM не запущена, либо брандмауэр блокирует трафик.
Выполним следующие шаги для проверки порта:
Рассмотрим маркировку ключей, так как это влияет на выбор драйвера и настроек. В обсуждении упоминались ключи ORG8L, ORG8A, ORG8B. Напомним краткую справку по маркировкам:
Если у вас используется красный сетевой ключ на 5 пользователей (H4 NET5 ORG8L), он должен обслуживаться менеджером лицензий. Если же 1С требует "Ключ защиты сервера", а у вас его нет (используется файловая версия или 32-битный сервер), то ошибка будет другой. В нашем случае проблема именно в клиентских лицензиях в терминальной сессии.
Подводя итог, можно сказать, что стабильная работа 1С с сетевым HASP-ключом на Windows Server 2008 R2 x64 в режиме терминала достижима при соблюдении трех условий: работа HASP LM как службы, явное указание IP-адреса в nethasp.ini и использование актуальных драйверов, установленных отдельно от платформы. Эти шаги позволяют обойти изоляцию RDP-сессий и обеспечить бесперебойный доступ пользователей к программе.