← На главную

В процессе администрирования клиент-серверных информационных баз 1С:Предприятие системные администраторы часто сталкиваются со странным поведением системы лицензирования. Локальный запуск тонкого или толстого клиента непосредственно на сервере приложений под учетной записью администратора проходит без каких-либо замечаний — программа успешно подхватывает файл программной лицензии .lic. Однако при попытке пользователей подключиться к этой же базе со своих рабочих станций через тонкий клиент система выдает ошибку: «Ошибка программного лицензирования. Ошибка привязки программной лицензии к компьютеру».

В тексте ошибки при этом указывается, что ключевые параметры оборудования (например, BIOS_0, CPU_0) после получения лицензии якобы были изменены или удалены. Давайте детально проанализируем, почему возникает эта проблема, как функционирует механизм опроса оборудования платформой 1С и какими способами можно восстановить работоспособность системы без повторной активации пин-кодов.

Выясняем первопричину: почему локально работает, а по сети нет?

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

1. Локальный запуск на сервере: Когда вы запускаете сеанс 1С непосредственно на сервере (например, через службу удаленных рабочих столов RDP), лицензию запрашивает само клиентское приложение. Оно выполняется в контексте вашей учетной записи (как правило, с правами локального администратора). Клиентское приложение напрямую обращается к инструментарию управления Windows — WMI (Windows Management Instrumentation), без проблем считывает характеристики процессора, материнской платы и BIOS, сопоставляет их с файлом лицензии в каталоге C:\ProgramData\1C\licenses и успешно запускается.
2. Запуск через тонкий клиент с рабочей станции: В этом сценарии рабочая станция пользователя обращается к серверу приложений 1С. Серверный процесс rphost пытается самостоятельно выделить лицензию из пула доступных файлов на сервере и передать ее клиенту. Однако процесс rphost функционирует под служебной учетной записью (по умолчанию это ограниченная учетная запись usr1cv8). Если у этой системной учетной записи нет достаточных прав на опрос WMI или реестра операционной системы, WMI возвращает процессу пустые или искаженные значения параметров оборудования. Платформа 1С интерпретирует это как критическое изменение конфигурации сервера и блокирует выдачу лицензии по сети.

Разберем по шагам практические методы устранения данной неисправности.

Решение 1. Сброс кэша привязки оборудования (удаление файла 1cv8conn.pfl)

Часто в процессе эксплуатации виртуального сервера или после обновления операционной системы платформа «запоминает» некорректные или устаревшие параметры привязки. Чтобы заставить систему заново перечитать характеристики оборудования, выполним сброс конфигурационного кэша подключений. Для этого выполним следующую последовательность действий:

1. Откроем оснастку управления службами Windows (services.msc).
2. Найдем службу «Агент сервера 1С:Предприятия» (например, 1C:Enterprise 8.3 Server Agent) и остановим ее. Важно: все активные сеансы пользователей при этом будут прерваны.
3. Перейдем в системный каталог хранения общих данных платформы. Обычно он расположен по пути: C:\ProgramData\1C\1cv8\ (для старых версий платформы путь может выглядеть как C:\ProgramData\1C\1cv82\).
4. Найдем в этой директории конфигурационный файл с именем 1cv8conn.pfl. Этот файл отвечает за кэширование параметров привязки лицензий и сетевых соединений.
5. Удалим файл 1cv8conn.pfl (или переместим его в другую папку в качестве резервной копии).
6. Снова запустим службу «Агент сервера 1С:Предприятия».

При запуске служба сервера 1С автоматически создаст новый чистый файл 1cv8conn.pfl и выполнит повторный опрос оборудования, что в большинстве случаев решает проблему «залипших» ошибок привязки.

Решение 2. Проверка и восстановление репозитория WMI

Если сброс кэша не помог, проанализируем состояние службы инструментария управления Windows (WMI). Если база данных WMI повреждена, она может возвращать неполные параметры процессора или BIOS при запросах от службы 1С. Проверим целостность репозитория:

1. Запустим командную строку cmd от имени Администратора.
2. Выполним команду для проверки целостности базы данных WMI: winmgmt /verifyrepository
3. Если в ответ система выдает сообщение о том, что репозиторий поврежден (WMI repository is inconsistent), запустим процесс восстановления: winmgmt /salvagerepository
4. После успешного завершения восстановления перезапустим службу WMI и службу сервера приложений 1С.

Решение 3. Настройка прав учетной записи usr1cv8 для опроса WMI

Если база данных WMI исправна, но служба сервера 1С по-прежнему не может считать данные железа, необходимо предоставить права для учетной записи usr1cv8 на доступ к пространству имен WMI. Рассмотрим, как это сделать:

1. Нажмем сочетание клавиш Win + R, введем команду wmimgmt.msc и нажмите Enter.
2. В открывшейся оснастке нажмем правой кнопкой мыши на элемент «Управление WMI (локальный компьютер)» и выберем пункт «Свойства».
3. Перейдем на вкладку «Безопасность».
4. Раскроем дерево папок и выберем пространство имен Root\CIMV2, после чего нажмем кнопку «Безопасность» под списком.
5. Добавим в список пользователей учетную запись, под которой запускается сервер 1С (обычно это локальный пользователь usr1cv8).
6. В столбце «Разрешить» установим флажки напротив пунктов «Выполнить методы», «Включить учетную запись» и «Удаленный запуск». Нажмем «Применить».
7. Перезапустим службу сервера приложений 1С.

Решение 4. Стабилизация параметров виртуальной машины

Как видно из текста ошибки автора темы, тип системы определяется как Virtual Machine. Виртуальные среды на базе Hyper-V, VMware или KVM требуют соблюдения строгих правил настройки для стабильной работы программного лицензирования 1С. Проверим следующие параметры на хосте виртуализации:

• Динамическая память: Настоятельно рекомендуем отключить использование динамической памяти (Dynamic Memory) для гостевой операционной системы с сервером 1С. Выделите фиксированный объем ОЗУ. При динамическом изменении памяти 1С может посчитать, что изменилась аппаратная конфигурация компьютера, и заблокирует лицензию.
• Сетевой адаптер: Убедитесь, что виртуальному сетевому адаптеру назначен статический MAC-адрес. При динамическом распределении MAC-адресов первая же перезагрузка виртуальной машины или ее миграция на другой узел кластера приведет к изменению сетевого идентификатора, что мгновенно аннулирует привязку лицензии.
• Режим совместимости процессоров: Если ваша виртуальная машина работает в кластере высокой доступности и может мигрировать между физическими серверами, включите в настройках процессора виртуальной машины «Режим совместимости» (Processor Compatibility Mode). Это скроет специфические инструкции новых CPU и зафиксирует единый виртуальный идентификатор процессора для гостевой ОС.

Решение 5. Привязка программной лицензии к аппаратному HASP-ключу

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

При этом типе привязки платформа 1С проверяет не изменяемые параметры железа (процессор, BIOS, диски), а уникальный идентификатор USB-ключа HASP. Если ключ на месте, лицензия будет считаться валидной.

Важные нюансы привязки к HASP:

• Для выполнения такой привязки при получении лицензии (активации пин-кода) на этапе выбора компьютера привязки необходимо выбрать вариант «К ключу защиты HASP». При этом на сервере должен быть физически установлен и доступен хотя бы один рабочий ключ HASP (например, ключ на 1 рабочее место, многопользовательский ключ или ключ сервера).
• Привязка требует наличия свободного слота лицензии на ключе в момент проверки. Как показывает практика, проверка привязки к ключу HASP занимает 1 свободную лицензию буквально на 1 секунду, а сама проверка выполняется не чаще, чем один раз в 20 секунд.
• Если вы используете сетевой ключ HASP через менеджер лицензий (HASP License Manager), программные лицензии, активированные на сервере с привязкой к этому ключу, будут корректно работать без необходимости настройки дополнительных служб раздачи ключей.

Мы подробно разобрали все ключевые причины сбоев программного лицензирования в клиент-серверной среде. Последовательное выполнение предложенных шагов — от очистки файла 1cv8conn.pfl до детальной настройки прав учетной записи службы 1С — позволит вам гарантированно решить проблему сетевого доступа пользователей к лицензиям без необходимости тратить драгоценные пин-коды для повторной активации.