Как очистить старые данные о клиентских лицензиях в окне «О программе» 1С

← На главную

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

Различие между текущей лицензией и историей информационной базы

Прежде всего, проанализируем структуру окна «О программе». Информация в разделе лицензирования делится на два принципиально разных блока:

Текущая: — здесь отображается лицензия, которая была получена сеансом в момент запуска. Именно эта запись определяет легитимность текущей работы. Если здесь указан файл или сетевой ключ, значит, система работает корректно.
Информационная база: — это так называемая «историческая справка». 1С записывает сведения обо всех лицензиях, которые когда-либо использовались для доступа к этой конкретной базе данных. Даже если ключ был извлечен год назад, информация о нем может остаться в этом списке.

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

Очистка истории лицензий через SQL-запрос

Поскольку 1С хранит историю лицензий непосредственно в таблицах базы данных, самым эффективным (хотя и радикальным) методом является прямое редактирование таблиц на уровне СУБД (PostgreSQL или MS SQL). Информация о лицензиях хранится в системной таблице Params.

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

Обязательно создадим резервную копию базы данных перед выполнением любых операций.
Зайдем в консоль управления СУБД (например, pgAdmin для PostgreSQL или SQL Server Management Studio для MS SQL).
Выполним запрос на удаление соответствующей записи.

Для PostgreSQL или MS SQL запрос будет выглядеть следующим образом:


DELETE FROM Params
WHERE FileName = 'v8.SystemLicenseHistory'
OR Name = 'v8.SystemLicenseHistory';

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

Программный способ очистки истории

Если прямое вмешательство в SQL нежелательно, рассмотрим вариант использования встроенного языка 1С. Мы можем создать внешнюю обработку и программно удалить записи из хранилища настроек. Проанализируем пример кода, который обращается к системным параметрам:


Процедура ОчиститьИсториюЛицензий() Экспорт
    // Удаляем данные из стандартного хранилища системных настроек
    КлючОбъекта = "Общее/ИсторияЛицензийСистемы";
    СтандартноеХранилищеНастроек.Удалить(КлючОбъекта, , );
    Сообщить("Операция завершена. Перезапустите программу.");
КонецПроцедуры

Стоит отметить, что эффективность этого метода может зависеть от версии платформы, так как в некоторых релизах доступ к v8.SystemLicenseHistory через штатные механизмы ограничен.

Почему старые лицензии появляются снова?

Иногда после очистки администраторы замечают, что старые данные (например, на 500 пользователей, которых никогда не было в организации) возвращаются. Разберем, откуда «прилетает» эта информация.

Основным источником является файл конфигурации .cf. Когда разработчик сохраняет конфигурацию в файл на своем компьютере, платформа может включить слепок его лицензий в метаданные. При последующем обновлении вашей рабочей базы через «Сравнить и объединить» или «Загрузить конфигурацию из файла», эта «чужая» история переносится в вашу таблицу Params. К сожалению, штатного способа запретить этот перенос при обновлении не существует, поэтому после крупных обновлений от сторонних поставщиков процедуру очистки SQL может потребоваться повторить.

Особенности работы с несколькими USB-ключами HASP

В процессе настройки лицензий часто возникает вопрос: почему сервер «не видит» два красных USB-ключа (например, на 10 и 20 пользователей), воткнутых в один сервер? Проанализируем ограничения драйвера HASP License Manager:

Ограничение по серии: Драйвер может обслуживать только один ключ одной серии (например, ORGL8) на одном физическом сервере. Если воткнуть два ключа, будет виден только один из них.
Решение: Для использования нескольких USB-ключей их необходимо разнести на разные физические серверы. На каждом сервере должен быть запущен свой License Manager.
Настройка подключения: Чтобы сервер 1С видел оба ключа, на стороне сервера необходимо отредактировать файл nnhsproto.ini (или nethasp.ini), указав IP-адреса обоих машин, где установлены ключи.

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

Итоги

Мы рассмотрели природу возникновения «фантомных» лицензий в окне «О программе». Помните, что данные в разделе «Информационная база» носят справочный характер и не влияют на производительность или доступность программы. Однако, если чистота интерфейса критична, используйте SQL-запрос для очистки таблицы Params, предварительно убедившись в наличии актуального бэкапа.