← На главную

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

Выясняем причину: почему одна база работает, а другая — нет

Первым делом проанализируем поведение сервера приложений 1С:Предприятия. На первый взгляд кажется нелогичным, что серверная лицензия может быть «частично неисправной». Однако технически это объясняется несколькими механизмами:

1. Кеширование состояния лицензии: Сервер приложений 1С не выполняет проверку привязки к железу ежесекундно. Если в рабочей базе в момент изменения конфигурации оборудования или системного сбоя уже были активные пользователи, сервер может удерживать текущую сессию и считать лицензию валидной до тех пор, пока все пользователи не выйдут из базы или не будет перезапущена служба ragent.
2. Различные настройки выдачи лицензий: Проверим параметры каждой информационной базы в консоли администрирования серверов 1С. В свойствах базы есть важный флаг «Разрешить выдачу лицензий сервером». Если в одной базе он включен, а в другой выключен, механизмы поиска лицензий будут принципиально разными. Одна база может успешно забирать клиентскую лицензию через HASP License Manager с USB-ключа, установленного в сети, а вторая — требовать именно программную лицензию, привязанную к локальному серверу.
3. Разделение сеансов: В некоторых случаях рабочая база может использовать программные лицензии, уже «захваченные» ранее запущенными процессами rphost, тогда как новая база пытается инициировать новый процесс или создать новый сеанс, инициируя полную проверку лицензионного файла.

Анализ аппаратной привязки программной лицензии

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

Разберем, какие именно изменения «железа» могут привести к аннулированию лицензии:

• Дисковые накопители: Список всех установленных дисков и их файловые системы. Даже добавление виртуального диска в системе виртуализации (Hyper-V, VMware) или изменение буквы раздела может сделать лицензию невалидной.
• Оперативная память: Изменение объема ОЗУ (даже если планка памяти просто вышла из строя или была добавлена новая) воспринимается системой как смена компьютера.
• Сетевые параметры: Имя компьютера, MAC-адреса всех сетевых адаптеров. Особенно внимательно стоит относиться к динамическим MAC-адресам в виртуальных средах.
• Материнская плата и процессор: Замена или изменение серийных номеров этих компонентов мгновенно блокирует доступ.
• Версия ОС: Обновление версии Windows или Service Pack также входит в контрольную сумму.

Пошаговый алгоритм диагностики и решения проблемы

Если мы столкнулись с ситуацией «одна база работает, другая — нет», выполним следующие действия:

Шаг 1. Проверка текущих лицензий в работающей базе

Зайдем в работающую базу под правами администратора и перейдем в меню Справка — О программе (или Информация — О программе). В разделе «Лицензия» внимательно изучим, какая именно лицензия используется: программная или аппаратная (USB), клиентская или серверная, и какой файл лицензии задействован. Это даст понимание того, на что именно стоит ориентироваться при поиске ошибки во второй базе.

Шаг 2. Проверка настроек в консоли администрирования

Откроем консоль администрирования серверов 1С и проанализируем параметры информационных баз:

• Убедимся, что для обеих баз настройки «Использование аппаратной лицензии» и «Разрешить выдачу лицензий сервером» идентичны.
• Если используется USB-ключ, проверим, видит ли его сервер. Отсутствие записи о локальном USB-ключе в логах может означать проблему с драйвером HASP или самим ключом.

Шаг 3. Очистка временных файлов лицензий

Иногда система может «залипнуть» на некорректных данных о лицензировании. Рассмотрим методику очистки файлов настроек .pfl:

1. Остановим службу 1C:Enterprise 8.3 Server Agent (ragent).
2. Перейдем в каталог C:\ProgramData\1C\licenses (для Windows) или в профиль пользователя, под которым запускается служба сервера.
3. Найдем файлы с расширением .pfl. Эти файлы содержат кешированную информацию о лицензиях.
4. Переместим их в резервную папку или удалим. Это заставит систему при следующем запуске заново просканировать доступные ключи и пересчитать контрольные суммы оборудования.
5. Запустим службу сервера 1С.

Шаг 4. Повторная активация лицензии

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

Работа с USB-ключами (HASP)

Если в системе используются аппаратные ключи, но база их не видит, проанализируем файл nethasp.ini. Выясним, не задан ли там жестко IP-адрес сервера лицензий, который мог измениться. Также важно помнить, что для многопользовательского ключа на 20 мест, установленного в обычный ПК, обязательно должна быть запущена служба HASP License Manager, иначе другие компьютеры (включая сервер 1С) не смогут получить к нему доступ.

Особенности виртуализации

При работе 1С на виртуальных машинах крайне важно настроить Static RAM вместо Dynamic Memory. Как только гипервизор динамически изменит объем выделенной памяти для экономии ресурсов, контрольная сумма программной лицензии 1С изменится, и вы получите сообщение об отсутствии лицензии. Мы рекомендуем всегда резервировать фиксированный объем ресурсов для серверов 1С.

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