Администрирование системы защиты «1С:Предприятие 8.3» в смешанных инфраструктурах (где одновременно используются и программные лицензии, и аппаратные HASP-ключи) часто преподносит неприятные сюрпризы. Типичная ситуация: физический сервер под управлением Windows Server работает стабильно, никаких изменений в комплектующие не вносится, однако 1С регулярно заявляет об изменении конфигурации компьютера (ссылаясь на параметры SSD-дисков) и блокирует программные лицензии. Ситуация усугубляется, когда при попытке привязать программную лицензию к аппаратному ключу HASP система периодически теряет связь с защитным ключом, из-за чего пользователи массово не могут войти в базы.
В этой статье мы подробно проанализируем причины возникновения обеих проблем, разберем скрытые механизмы работы защиты 1С и предоставим пошаговые инструкции по окончательному устранению этих сбоев.
Для привязки программных лицензий платформа 1С:Предприятие собирает сведения о ключевых компонентах сервера (материнская плата, процессор, сетевые адаптеры, операционная система и дисковая подсистема). Запрос этих данных происходит через службу инструментария управления Windows — WMI (Windows Management Instrumentation). На физических серверах (особенно современных моделях с NVMe-накопителями) ложное определение изменения конфигурации дисков обычно связано со следующими факторами:
Для исправления работы дисковой подсистемы и WMI выполним следующие шаги:
Во-первых, настроим схему электропитания Windows Server. Откроем панель управления, перейдем в раздел электропитания и установим профиль «Высокая производительность» (High Performance). В дополнительных параметрах профиля полностью запретим отключение жестких дисков (значение: 0) и отключим энергосбережение в разделе «PCI Express -> Управление питанием состояния связи» (Link State Power Management -> Off).
Во-вторых, проверим целостность базы данных WMI. Запустим командную строку от имени администратора и выполним следующую команду:
winmgmt /verifyrepository
Если в ответ система сообщит, что база данных WMI повреждена, выполним операцию восстановления:
winmgmt /salvagerepository
Связывание программной лицензии с уникальным ID аппаратного HASP-ключа — отличный способ избежать «слёта» активации при изменении железа сервера. Однако этот механизм содержит критически важную недокументированную особенность, о которой часто не знают даже специалисты компаний-франчайзи.
Рассмотрим детально алгоритм проверки такой привязки платформой 1С:
Для контроля наличия ключа привязки в сети сервер лицензирования 1С каждые 20 секунд выполняет фоновую проверку. Для этого он пытается на 1 секунду занять ровно 1 свободную лицензию на привязанном ключе HASP. Если в этот момент на ключе исчерпаны абсолютно все лицензии (например, все 5 лицензий на ключе заняты активными пользователями), фоновая проверка завершается ошибкой. Платформа считает, что ключ HASP удален из системы, и мгновенно деактивирует привязанную программную лицензию.
Другая проблема — наличие нескольких одинаковых ключей в сети. Если у вас установлено несколько сетевых ключей (например, два ключа по 5 лицензий), служба 1С опрашивает их методом широковещательного запроса (Broadcast). Если ключ с ID NNN временно перегружен или недоступен из-за микросекундного сетевого лага, служба натыкается на соседний ключ с ID MMM. Так как ID найденного ключа не совпадает с тем, что прописан в файле программной лицензии .lic, лицензия блокируется.
Решить эту проблему можно жесткой изоляцией опроса HASP-ключей. Проанализируем настройки файла конфигурации менеджера лицензий nethasp.ini на сервере, где лежат файлы лицензий. Откроем файл nethasp.ini (обычно он располагается в папке C:\Program Files\1cv8\conf\ или в папке с платформой) и пропишем жесткую адресацию:
[NH_COMMON]
NH_TCPIP = Enabled
NH_NO_AUTODETECT = Yes
[NH_TCPIP]
NH_SERVER_ADDR = 192.168.1.50 ; Укажите точный IP-адрес компьютера, где физически установлен целевой ключ HASP
NH_USE_BROADCAST = Disabled
Этим мы запретим службе 1С искать ключи по всей локальной сети широковещательными пакетами и направим ее строго на сервер с нужным ключом. Также для стабилизации работы программных лицензий на сервере 1С в файле конфигурации rmlic.cfg необходимо прописать параметр AssociationAddress, который будет жестко привязывать адрес менеджера лицензий.
Если параметры физического сервера продолжают нестабильно определяться платформой 1С, лучшим решением будет вынос службы лицензирования на отдельный узел кластера (так называемый «сервер лицензирования»). Это может быть небольшая виртуальная машина или отдельный ПК, конфигурация которого стабильна и не меняется.
Разберем по шагам, как настроить кластер 1С для работы с выделенным сервером лицензирования:
AppLicenseServer). Установим на него платформу 1С и перенесем туда все файлы программных лицензий с расширением .lic.LicenseService).AppLicenseServer и добавим противоположное правило:
LicenseService).После выполнения этих настроек все запросы пользователей на получение программных лицензий будут перенаправляться на стабильный сервер AppLicenseServer, а основной рабочий сервер баз данных сможет перезапускаться, менять параметры дисков NVMe и обновлять драйверы без какого-либо риска слёта активации.
В процессе экспериментов с привязками к HASP и изменением оборудования кэш лицензирования платформы может забиться некорректными отпечатками. Для полного сброса и чистой переустановки выполним следующие действия:
Остановим службу 1C:Enterprise 8.3 Server Agent. Перейдем в каталог %systemdrive%\ProgramData\1C\1cv8\ (для Windows Server это обычно C:\ProgramData\1C\1cv8\) и удалим все конфигурационные файлы соединений, имеющие маску имени 1cv8conn*.pfl.
Удаление файлов .pfl сотрет информацию о старых неуспешных попытках привязки лицензий к оборудованию, после чего служба сервера 1С сможет заново корректно проинициализировать имеющиеся лицензии из файлов .lic при запуске.
Среди системных администраторов и даже франчайзи распространен миф о том, что обменять несколько программных лицензий на одну общую многопользовательскую невозможно. На самом деле в прайс-листе Фирмы 1С существует официальная процедура консолидации и апгрейда клиентских лицензий.
Вы имеете полное право официально сдать через любого партнера 1С несколько программных и аппаратных лицензий (например, 10 + 5 + 5 пользовательских ключей) и взамен получить одну многопользовательскую программную лицензию на 50 пользователей. Стоимость этой процедуры рассчитывается по стандартной формуле апгрейда: вы оплачиваете разницу в стоимости приобретаемой лицензии и сдаваемых номиналов плюс небольшой фиксированный сбор за проведение операции. Это радикально решает проблему администрирования «зоопарка» разнородных ключей защиты.