Как правильно рассчитать и настроить клиентские лицензии 1С на терминальном сервере: 20 или 80?

При переходе компании на терминальный режим работы (RDP) перед системными администраторами и руководителями ИТ-отделов неизбежно встает вопрос расчета и приобретения клиентских лицензий «1С:Предприятие». Ситуация, описанная на форуме, классическая: имеется терминальный сервер, сервер приложений 1С на базе MS SQL и 20 активных пользователей, которым одновременно нужен доступ к четырем различным информационным базам (например, две базы «1С:Бухгалтерия», одна «1С:Зарплата и управление персоналом» и одна «1С:Управление торговлей»).

Если обратиться к неквалифицированным менеджерам фирм-франчайзи, можно получить пугающий ответ: «В клиент-серверном варианте лицензируется каждое подключение. Раз у вас 20 пользователей и 4 базы, вам нужно покупать 80 лицензий!». Давайте разберем по шагам, почему этот ответ ошибочен, как на самом деле платформа 1С производит подсчет лицензий в терминальной среде, и как настроить систему так, чтобы легально обойтись покупкой всего 20 лицензий вместо 80.

Понимаем разницу: два режима подсчета лицензий в 1С

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

1. Режим «На компьютер / На пользователя» (per user / per computer). При таком подходе лицензия выделяется на конкретное рабочее место (в случае терминала — на уникальную RDP-сессию пользователя). Пользователь внутри своего терминального сеанса может запустить неограниченное количество баз 1С, открыть десятки окон «1С:Предприятия» (как тонкого, так и толстого клиента) — при этом со счета будет списана ровно одна клиентская лицензия.
2. Режим «На сеанс» (per session). В этом режиме лицензируется каждый факт запуска клиентского приложения. Если один и тот же сотрудник открывает базу «1С:Бухгалтерия» и базу «1С:Управление торговлей», система расходует две лицензии из общего пула. Если он откроет четыре базы — спишется четыре лицензии. Именно по такому принципу лицензии раздает сервер приложений 1С или веб-сервер при публикации баз по HTTP.

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

Сценарий 1. Использование программных лицензий на терминале

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

Чтобы получить экономию по схеме «один пользователь RDP = одна лицензия», нам необходимо выполнить активацию лицензий определенным образом:

1. Запустите платформу «1С:Предприятие» на терминальном сервере от имени администратора.
2. Перейдите в меню конфигуратора или запустите базу в режиме предприятия. При отсутствии лицензии система сама предложит ее получить. Нажмите кнопку «Получить лицензию».
3. Введите регистрационный номер комплекта и многопользовательский пин-код.
4. На этапе выбора компьютера для привязки обязательно выберите вариант «На этот компьютер».
5. В окне выбора пользователей обязательно укажите параметр «Всем пользователям данного компьютера».

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

C:\ProgramData\1C\1Cv8\Conf\

Когда пользователи заходят на сервер по RDP и запускают тонких или толстых клиентов 1С, сама платформа на их виртуальных рабочих местах обращается к этому файлу напрямую. Локальный сеанс 1С сам считывает лицензию из папки общего доступа. Платформа распознает, что запуск происходит в рамках уже существующей терминальной сессии текущего Windows-пользователя, группирует подключения и расходует только 1 лицензию на всю RDP-сессию. Таким образом, для 20 сотрудников вам потребуется купить ровно 20 программных лицензий.

Важное предупреждение: Ни в коем случае не активируйте в свойствах баз на сервере 1С настройку Разрешить выдачу лицензий сервером 1С. Если эта опция включена, сервер приложений перехватит инициативу и начнет самостоятельно раздавать лицензии из общего пула по схеме «на сеанс», что моментально заблокирует работу пользователей при исчерпании 20 лицензий.

Сценарий 2. Использование аппаратных (USB) ключей защиты

Если ваша компания отдает предпочтение физическим носителям, то использование аппаратных ключей NetHASP (красного цвета) значительно упрощает задачу администрирования. Эти ключи работают через сетевой протокол и распределяют лицензии с помощью службы HASP License Manager.

Рассмотрим, как ведет себя аппаратный ключ на терминальном сервере:

• Драйвер защиты и служба менеджера лицензий HASP умеют аппаратно отслеживать ID терминальных сессий пользователей на сервере.
• Когда пользователь открывает первую базу 1С, его RDP-сессия запрашивает лицензию у менеджера. Менеджер лицензий помечает, что для данного ID сессии выдана одна лицензия.
• При открытии этим же пользователем второй, третьей и четвертой баз 1С платформа видит, что для текущей терминальной сессии лицензия уже активна, и не запрашивает новые слоты из USB-ключа.

Таким образом, использование аппаратного сетевого ключа на 20 пользователей гарантирует работу всех 20 сотрудников с любым количеством информационных баз без риска перерасхода лицензий.

Однако здесь существуют важные системные нюансы:

1. Запрет локальных однопользовательских ключей. Однопользовательские аппаратные ключи (синего цвета) защищены разработчиком от использования в терминальном режиме. Если вы вставите такой ключ непосредственно в USB-порт сервера, зашедшие по RDP пользователи просто не увидят его. Для терминалов подходят исключительно многопользовательские красные ключи HASP.
2. Конфликт ключей одной серии. Вы не можете установить на один сервер или в одну локальную сеть два сетевых аппаратных ключа одной серии (например, два ключа серии ORGL8 на 10 и 20 пользователей). Система увидит только один из них (обычно с меньшим номиналом). Если вам потребуется расширить количество пользователей, придется делать апгрейд ключа у дистрибьютора с доплатой или использовать программные ключи, которые отлично суммируются друг с другом на одном сервере.

Для правильной маршрутизации запросов к аппаратному ключу на терминальном сервере рекомендуется явно настроить конфигурационный файл nethasp.ini, находящийся в каталоге установки платформы 1С. Пример оптимальной настройки файла для ускорения поиска ключа по протоколу TCP/IP:

[NH_COMMON]
NH_TCPIP = Enabled

[NH_TCPIP]
NH_SERVER_ADDR = 192.168.1.100 ; IP-адрес ПК, где установлен USB-ключ
NH_PORT_NUMBER = 475
NH_TCPIP_METHOD = UDP

Сценарий 3. Работа через веб-сервер и тонкий клиент по HTTP/HTTPS

Ситуация кардинально меняется, если часть из ваших 20 пользователей планирует работать вне терминального сервера напрямую через интернет, используя веб-клиент (в браузере) или тонкий клиент, подключенный к базе по протоколу HTTP через веб-серверы Apache или IIS.

В этом случае экономия «одна сессия — одна лицензия» перестает работать по умолчанию:

• Веб-сервер не имеет доступа к RDP-сессиям удаленных компьютеров сотрудников и не может идентифицировать их аппаратные ID.
• Лицензирование в данном случае происходит исключительно силами веб-сервера или сервера приложений 1С. Каждое открытое окно браузера или сессия тонкого клиента запрашивает отдельную лицензию у сервера приложений.
• Если удаленный пользователь запустит 3 базы через браузер, сервер спишет ровно 3 лицензии из общего пула. При таком режиме вам действительно может потребоваться до 80 лицензий.

Как минимизировать затраты при работе по HTTP?

Проанализируем доступные варианты решения проблемы:

1. Организация VPN-каналов. Вместо публикации баз наружу через веб-сервер, настройте для удаленных сотрудников защищенное VPN-подключение к офисной сети. В таком случае тонкий клиент на домашнем компьютере пользователя сможет напрямую обращаться к сетевому менеджеру лицензий HASP License Manager по порту 475. Для домашнего компьютера пользователя выделится одна аппаратная лицензия, в рамках которой он сможет запускать несколько баз 1С без перерасхода.
2. Локальная активация лицензий на клиентских ПК. Если у вас есть программные однопользовательские лицензии, вы можете активировать их непосредственно на физических компьютерах сотрудников. Тогда запущенный на домашнем компьютере тонкий клиент будет использовать собственную локальную лицензию и не станет нагружать общий пул лицензий сервера.

Инновации платформы: Связывание программных лицензий с USB-ключом и Менеджер Лицензий 1С (rmlic)

Рассмотрим две современные технологии, которые значительно облегчают жизнь системным администраторам при развертывании крупных или динамических инфраструктур.

Привязка программных лицензий к аппаратному ключу

Главный недостаток программных лицензий — их высокая чувствительность к изменениям конфигурации сервера. Стоит администратору виртуальной машины на Hyper-V или VMware добавить оперативной памяти, изменить количество ядер процессора или обновить операционную систему — программная лицензия тут же «слетает», требуя ввода нового резервного пин-кода для восстановления работоспособности.

Начиная с версии платформы 8.3.12, разработчики 1С представили элегантное решение: возможность привязки программной лицензии к аппаратному ключу защиты HASP. При активации новой программной лицензии система считывает уникальный внутренний ID подключенного к серверу USB-ключа и привязывает лицензионный файл к нему, а не к параметрам материнской платы или процессора. Теперь вы можете свободно масштабировать виртуальные машины, переносить их между физическими хостами — лицензия останется активной до тех пор, пока сервер видит физический USB-токен.

Новый инструмент: Менеджер лицензий 1С (rmlic)

В современных релизах платформы (начиная с версии 8.5.4) компания 1С предлагает использовать собственный программный компонент — Менеджер лицензий 1С (rmlic). Этот инструмент приходит на смену устаревшей утилите HASP License Manager от компании Aladdin/Thales.

Утилита rmlic регистрируется в системе как самостоятельная служба (поддерживаются как ОС семейства Windows, так и дистрибутивы Linux) и выполняет следующие задачи:

• Централизованный сбор и учет всех доступных в локальной сети программных лицензий (файлов .lic) и аппаратных ключей защиты.
• Гибкое распределение лицензий между серверами кластера и клиентскими компьютерами по внутренним сетевым портам 475 и 1544.
• Исключение конфликтов при наличии нескольких многопользовательских USB-ключей одной серии в пределах одной локальной сети.
• Обеспечение стабильного подсчета лицензий «на устройство» в распределенных сетях со сложной терминальной структурой.

Резюме: Пошаговый алгоритм действий для администратора

Для того чтобы успешно запустить работу 20 пользователей в 4 базах 1С на терминальном сервере и уложиться в рамки 20 купленных лицензий, придерживайтесь следующего чек-листа:

1. Определитесь с типом лицензий. Если покупаете программные лицензии — активируйте их строго на терминальном сервере с параметрами «На этот компьютер» и «Всем пользователям данного компьютера». Не активируйте их на сервере приложений 1С!
2. Если используете аппаратную защиту — убедитесь, что у вас приобретен многопользовательский красный USB-ключ HASP на 20 рабочих мест. Установите службу HASP License Manager на сервере, где физически установлен ключ, и настройте конфигурационные файлы nethasp.ini на терминальном сервере для прямого обращения к службе по IP-адресу.
3. В настройках каждой из 4-х информационных баз в консоли администрирования кластера серверов 1С проверьте параметр Разрешить выдачу лицензий сервером 1С. Он должен находиться в значении «Нет» (Выключен). В этом случае поиск и получение лицензий будут делегированы локальным рабочим местам пользователей внутри RDP-сессий, что гарантирует работу правила «один пользователь = одна лицензия».
4. Для удаленных сотрудников организуйте доступ через VPN, чтобы их тонкие клиенты могли подключаться к общей локальной сети и использовать единый терминальный или аппаратный пул лицензий, избегая неэкономного веб-подключения по HTTP/HTTPS.

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