Перевод работы пользователей «1С:Предприятие» в терминальный режим (RDP) — это популярное решение, позволяющее централизовать базу данных, повысить скорость работы (особенно для файловых баз) и упростить администрирование. Однако на этапе миграции системные администраторы часто сталкиваются со спецификой лицензирования «1С». Попытка просто запустить программу в сессии удаленного рабочего стола при наличии стандартного физического USB-ключа нередко приводит к ошибке: «Информационная база не найдена» или «Не обнаружен ключ защиты программы».
В этой статье мы подробно рассмотрим, почему возникают проблемы с аппаратными ключами в терминальном режиме, разберем возможные варианты перехода с 5 на 7 (и более) пользователей, проанализируем правила апгрейда лицензий и изучим современные механизмы защиты, внедренные в платформу «1С:Предприятие».
Для начала разберем типичную техническую проблему, описанную пользователями: на сервере локально «1С» работает, но при попытке запустить хотя бы одну RDP-сессию система выдает ошибку защиты. Выясним причину этого поведения.
Дело в том, что по умолчанию однопользовательские аппаратные USB-ключи защиты HASP (серии H4) физически блокируют работу в терминальных сессиях. Платформа «1С» накладывает жесткое ограничение: если запуск происходит внутри сессии удаленного рабочего стола (RDP), локальный однопользовательский ключ игнорируется. Это сделано для предотвращения нелегального использования одной локальной лицензии множеством пользователей через терминальный сервер.
Если же у вас используется сетевой многопользовательский ключ (например, на 5 пользователей — обычно он красного цвета), то для его работы по сети (и в RDP в частности) обязательно должен быть запущен специальный сетевой менеджер лицензий — HASP License Manager (служба hlserver). Без корректной настройки этой службы и конфигурационных файлов терминальный сервер просто не сможет «достучаться» до USB-порта, в который вставлен ключ, так как среда RDP изолирует сессии пользователей друг от друга.
Кроме того, помните важное правило аппаратной защиты «1С»: два аппаратных ключа одной серии (например, два сетевых ключа по 5 пользователей) не будут работать на одном физическом компьютере. Терминальный сервер увидит только один из них (выбранный случайно операционной системой). Чтобы использовать их одновременно, их физически нужно разносить по разным компьютерам в локальной сети.
Рассмотрим рабочие стратегии перехода с имеющегося 5-пользовательского физического ключа на работу 7 пользователей в терминальном режиме. У нас есть три основных пути решения этой задачи.
Вариант 1. Сохранение физического ключа на 5 пользователей и докупка программных лицензий
Мы оставляем имеющийся USB-ключ на 5 рабочих мест на сервере (или другом ПК в сети) и докупаем две дополнительные однопользовательские программные лицензии (пин-коды). При этом на терминальном сервере необходимо будет настроить раздачу как аппаратных лицензий (через менеджер лицензий HASP), так и активировать программные файлы лицензий (формата *.lic).
Минусы: Сложность администрирования. Приоритеты поиска лицензий платформой могут приводить к тому, что программные лицензии будут быстро разбираться, а аппаратные простаивать. Также сохраняется привязка к физическому USB-порту.
Вариант 2. Обмен (апгрейд) физического 5-пользовательского ключа на программный аналог и докупка лицензий
Мы обращаемся к любому официальному партнеру (франчайзи) «1С» и производим обмен аппаратного ключа на комплект из 5 программных лицензий. Взамен сданного USB-накопителя мы получаем конверт с пин-кодами. Одновременно докупаются две дополнительные программные лицензии (или сразу одна лицензия на 2-5 рабочих мест).
Плюсы: Полный отказ от физических USB-портов. Все лицензии становятся однотипными (программными), что существенно упрощает их мониторинг и обновление.
Вариант 3. Комплексный апгрейд до одной лицензии на 10 пользователей (Рекомендуемый)
Наиболее красивое и экономически выгодное решение — сдать имеющийся 5-пользовательский ключ по процедуре апгрейда с доплатой и получить взамен одну программную (или аппаратную) лицензию на 10 пользователей. 1С официально разрешает проводить апгрейд клиентских лицензий по формуле:
Стоимость нового комплекта (10 пользователей) - Стоимость старого комплекта (5 пользователей) + небольшой сервисный сбор
В результате мы получаем единый пул из 10 лицензий, что дает запас на будущее (ведь нам нужно было 7 мест) и избавляет от «зоопарка» разнородных ключей защиты.
Проанализируем крайне важную деталь, о которой упоминали специалисты на форуме. Сделать апгрейд (обмен с доплатой) физического ключа можно только в том случае, если этот ключ приобретался как дополнительная клиентская лицензия. Если данный 5-пользовательский ключ шел в комплекте основной поставки (например, «1С:Бухгалтерия 8. Комплект на 5 пользователей» или «1С:Предприятие 8. Комплект прикладных решений»), то этот ключ является неотделимой частью конфигурации. Сдать его отдельно на апгрейд невозможно. В таком случае единственным выходом будет докупка дополнительных программных лицензий сверх имеющихся пяти.
Если вы используете современную версию платформы «1С:Предприятие», забудьте о старых костылях с установкой сторонних утилит от компании Aladdin. Начиная с версии платформы 8.5.4, архитектура защиты претерпела революционные изменения:
rmlic.exe умеет централизованно раздавать по сети как аппаратные ключи HASP, так и установленные на сервере программные лицензии.МониторингЛицензий и обработка «Управление лицензиями». Теперь администратор может в реальном времени видеть, кто из пользователей занял лицензию, с какого IP-адреса и какую именно базу открыл. Также можно гибко ограничивать количество лицензий для конкретных информационных баз.При переходе на программные лицензии (пин-коды) на терминальном сервере критически важно правильно выбрать режим активации. Комплект лицензий (например, на 10 пользователей) поставляется с возможностью активации разными путями. Разберем разницу:
При этом сценарии мы активируем каждую лицензию отдельно на терминальном сервере для конкретных пользователей Windows (или делаем ее доступной всем пользователям данного компьютера). Это самый экономичный режим для RDP. Лицензия привязывается к сессии пользователя терминала. Внутри своей RDP-сессии пользователь может открыть три, пять или десять разных баз «1С» (например, Бухгалтерию, Зарплату, Управление торговлей) — при этом будет израсходована всего 1 лицензия из общего пула.
Если активировать этот же комплект на сервере приложений «1С:Предприятие» (в клиент-серверном варианте), то лицензии будут выдаваться не на компьютер/сессию, а на каждый запущенный сеанс (подключение). В этом случае, если один бухгалтер в своей RDP-сессии запустит три разные информационные базы, система спишет с сервера 3 лицензии. Это крайне невыгодно при активной работе с несколькими базами одновременно.
Рекомендация для файловых баз в терминале: Всегда активируйте программные лицензии на самом RDP-сервере в режиме «На этот компьютер» с установленной галочкой «Доступно всем пользователям». Это позволит экономить лицензии по первому сценарию (один сеанс RDP = одна лицензия независимо от количества открытых баз).
В современных ИТ-инфраструктурах терминальные серверы практически всегда разворачиваются на виртуальных машинах (Hyper-V, VMware ESXi, Proxmox). Это накладывает серьезные ограничения на выбор средств защиты:
Если вы все же решили использовать сетевые аппаратные HASP-ключи (например, временно оставили старый ключ на 5 пользователей), стандартный широковещательный поиск (NetBIOS broadcast) в сетях с RDP-сервером часто работает медленно или дает сбои. Программа может запускаться по 1-2 минуты, «вывешивая» сессию. Проанализируем, как оптимизировать этот процесс с помощью тонкой настройки конфигурационных файлов.
На стороне терминального сервера (где запускается клиентское приложение «1С») найдите файл nethasp.ini (обычно он находится в каталоге C:\Program Files\1cv8\conf\ или в папке установки драйвера защиты). Нам необходимо жестко прописать адрес менеджера лицензий и отключить лишний поиск:
[NH_COMMON]
NH_TCPIP = ON
[NH_TCPIP]
;; Отключаем широковещательный поиск по всей локальной сети
NH_USE_BROADCAST = OFF
;; Явно указываем IP-адрес компьютера, где установлен USB-ключ
NH_SERVER_ADDR = 192.168.1.150
;; Указываем порт работы менеджера лицензий (по умолчанию 475)
NH_PORT_NUMBER = 475
NH_TCPIP_METHOD = TCP
На стороне компьютера, где физически установлен USB-ключ (сервер лицензий), в файле конфигурации службы nhsrv.ini можно заблокировать несанкционированный разбор лицензий сторонними ПК из вашей локальной сети, оставив доступ только для терминального сервера:
[NHS_IP]
;; Разрешаем выдачу лицензий только для IP-адреса нашего RDP-сервера
NHS_IP_LIMIT = 192.168.1.100
Если на вашем предприятии одновременно используются и USB-ключи, и новые программные лицензии (смешанный тип защиты), важно понимать алгоритм, по которому платформа ищет ключ при запуске. Поиск происходит по следующей строгой схеме:
*.lic в профиле текущего пользователя терминала и в общей папке C:\ProgramData\1C\Licenses).nethasp.ini или новый менеджер лицензий rmlic.exe.Важный нюанс: Так как локальные программные лицензии опрашиваются платформой в первую очередь, пользователи RDP-сервера могут мгновенно «разобрать» все доступные программные лицензии, в то время как свободный сетевой аппаратный ключ HASP останется незанятым. Чтобы сбалансировать нагрузку, используйте специальный параметр запуска в свойствах ярлыка «1С» или в настройках базы: /UseHwLicenses+ (принудительный приоритетный поиск аппаратного ключа) или распределяйте файлы *.lic по индивидуальным подпапкам пользователей Windows, разграничивая права доступа к ним средствами NTFS.