Как правильно организовать лицензирование 1С при совместном использовании RDP и веб-сервера

← На главную

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

Основы лицензирования: платформа и конфигурации

Проанализируем базовый принцип: в системе 1С лицензируется в первую очередь платформа. Для легальной работы нам необходимо обеспечить выполнение двух условий. Во-первых, наличие «Основной поставки» для каждой используемой конфигурации (например, 1С:Бухгалтерия или 1С:Управление торговлей). Во-вторых, наличие достаточного количества клиентских лицензий для пользователей.

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

Различия в подсчете лицензий: RDP против веб-сервера

Выясним причину, по которой способ подключения критически влияет на расход лицензий. Это один из самых важных моментов при планировании бюджета.

Терминальный сервер (RDP): В этом режиме лицензия обычно выдается на терминальную сессию (если используются программные многопользовательские лицензии или сетевой USB-ключ, раздаваемый сервером). Это означает, что в рамках одной RDP-сессии пользователь может запустить и Бухгалтерию, и УТ, и еще несколько баз, израсходовав при этом всего одну лицензию.
Веб-сервер (Apache/IIS): Здесь механизм меняется. Если публикация настроена так, что лицензии раздает сам веб-сервер, то каждый запуск базы в новой вкладке браузера или отдельном окне тонкого клиента будет поглощать отдельную лицензию. Если пользователь одновременно откроет две разные базы по HTTPS, система спишет две лицензии.

Для управления этим поведением в файле настроек публикации default.vrd существует специальный параметр. Рассмотрим пример структуры этого файла:


<point xmlns="http://v8.1c.ru/8.2/virtual-resource-system"
       xmlns:xs="http://www.w3.org/2001/XMLSchema"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       base="/MyBase"
       ib="File="C:\Bases\MyBase";">
    <standardOdata enable="false"/>
    <publish>
        <licensing>true</licensing>
    </publish>
</point>

Если параметр licensing установлен в значение true, веб-сервер сам ищет и выдает лицензии. Если false — лицензию должен найти сам клиент (например, если на локальном компьютере пользователя установлен USB-ключ или активирована программная лицензия).

Выбор защиты: Программные лицензии против USB-ключей

Проанализируем ситуацию с выбором носителя лицензии. У каждого типа есть свои критические особенности.

Программные лицензии (пин-коды):

Они удобны тем, что не требуют физических портов. Однако они жестко привязываются к параметрам сервера. К ним относятся: имя машины, версия ОС, серийный номер материнской платы, процессор, объем оперативной памяти и сетевые адаптеры. Если вы решите увеличить RAM на виртуальной машине, лицензия «слетит», и потребуется активация резервного пин-кода. Посмотрим на практику: обычно в комплекте идет 3 пин-кода. Если они закончатся, новые выдаются Центром лицензирования 1С по запросу, если вы сможете обосновать причину апгрейда сервера.

Аппаратные ключи (USB):

Главный плюс — мобильность. Ключ можно переткнуть в другой сервер без переактивации. Однако есть нюансы:

Однопользовательские USB-ключи не работают в RDP-сессиях.
Для работы многопользовательского сетевого ключа на сервере должен быть запущен HASP License Manager.
При использовании виртуализации (Hyper-V, VMware) проброс USB-порта часто работает нестабильно, что может потребовать покупки сетевых USB-хабов.

Комбинирование разных типов лицензий

Часто возникает вопрос: можно ли использовать одновременно и USB, и программные лицензии? Ответ — да, но нужно учитывать приоритеты поиска, которые заложены в платформу 1С:Предприятие. Разберем последовательность, по которой система ищет лицензию:

Локальный USB-ключ (вставленный непосредственно в ПК).
Локальная программная лицензия.
Сетевой USB-ключ (через поиск по сети с помощью HASP LM).
Многопользовательская программная лицензия на сервере 1С.

Чтобы ускорить этот процесс и избежать «зависаний» при запуске, мы рекомендуем редактировать файл nnhasp.ini. В нем стоит жестко прописать IP-адрес сервера, где установлен USB-ключ, чтобы клиент не сканировал всю сеть широковещательными запросами.


[NH_COMMON]
NH_TCPIP = ENABLE

[NH_TCPIP]
NH_SERVER_ADDR = 192.168.1.100 ; Адрес вашего сервера с ключом
NH_TCPIP_METHOD = TCP
NH_USE_BROADCAST = DISABLE

Оптимизация работы и решение проблемы печати

Посмотрим на ситуацию с производительностью. Использование веб-сервера (Apache) вместо прямого RDP часто оправдано экономией оперативной памяти на сервере, так как не создается полноценная графическая сессия Windows для каждого пользователя. Однако при работе через обычный браузер часто возникают проблемы с печатью чеков или этикеток — это связано с механизмами безопасности браузеров и промежуточным формированием PDF.

Проанализируем решение: вместо браузера используйте Тонкий клиент 1С, настроенный на подключение по HTTP/HTTPS. Это даст вам лучшее из двух миров: Экономию ресурсов сервера (как в вебе), но при этом прямой доступ к локальному оборудованию и принтерам пользователя (как в RDP или локальной работе). В этом случае драйверы принтеров работают на локальной машине, что устраняет задержки печати.

Подведем итог. Для настройки надежной системы лицензирования в связке RDP + Web нам потребуется: Основные поставки для юридической чистоты, клиентские лицензии (лучше многопользовательские программные для гибкости или USB для надежности при смене железа) и грамотная настройка публикации базы с учетом того, кто будет раздавать лицензии — сервер или клиентские станции.