← На главную

Многие администраторы и разработчики 1С сталкиваются с загадочным фоновым заданием UpdateConfigurationLicense, которое внезапно появляется в журнале регистрации и вызывает блокировку информационной базы. Особенность этого задания заключается в том, что его невозможно найти в дереве метаданных конфигурации, оно не относится к БСП и не инициируется программным кодом разработчика. В этой статье мы подробно разберем природу этого явления, выясним причины его возникновения и рассмотрим эффективные методы борьбы с сопутствующими ошибками.

Что такое UpdateConfigurationLicense и почему оно возникает

Проанализируем природу этого процесса. UpdateConfigurationLicense — это внутренний системный механизм платформы «1С:Предприятие 8.3», предназначенный для проверки легальности используемой конфигурации. Это не проверка лицензии самой платформы (ключа защиты), а именно верификация подлинности прикладного решения. Рассмотрим ключевые триггеры, запускающие это задание:

1. Обновление конфигурации базы данных: Задание практически всегда инициируется в конце процесса обновления (после нажатия F7 или принятия изменений в конфигураторе). Оно стартует за доли секунды до завершения реструктуризации и может длиться от 15 до 60 секунд.
2. Динамическое обновление: При использовании механизма динамического обновления платформа фиксирует расхождение между версиями конфигурации и запускает проверку для каждого активного сеанса.
3. Работа в режиме «Сервер МИНИ» или файловый вариант: В этих редакциях механизмы защиты работают наиболее агрессивно, хотя задание встречается и в полноценных клиент-серверных вариантах PROF и CORP.
4. Открытый конфигуратор: Существуют наблюдения, что наличие активного сеанса конфигуратора провоцирует повторные запуски этого задания.

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

Разберем ситуацию, которая чаще всего беспокоит специалистов: во время выполнения UpdateConfigurationLicense база становится недоступной. Это происходит потому, что задание пытается монопольно захватить доступ к системным таблицам лицензирования и таблице Config. Если в этот момент ваша система автоматизированного деплоя (CI/CD) или обработчики обновления БСП пытаются выполнить свои действия, возникает критическая ошибка:

«Ошибка разделенного доступа к информационной базе. База данных заблокирована»

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

Решение 1: Настройка доступа к интернету для сервера 1С

Посмотрим на рекомендации технической поддержки 1С. Поскольку задание выполняет проверку через внешние ресурсы, серверу приложений 1С (процессу rphost) необходим стабильный доступ к определенным адресам по протоколу HTTPS (порт 443). Если ваш сервер находится в закрытом контуре, необходимо добавить в «белый список» фаервола следующие хосты:

• https://login.1c.eu
• https://1cv8update.com
• https://portal.1c.ru

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

Решение 2: Использование технологических пауз в сценариях автоматизации

Рассмотрим пример настройки автоматического обновления базы через CI-сервер. Если ваш скрипт падает на шаге запуска обработчиков обновления БСП из-за блокировки UpdateConfigurationLicense, самым простым и действенным методом будет внедрение ожидания. Разберем логику шагов:

1. Обновление конфигурации информационной базы командами /UpdateDBCfg.
2. Обязательная пауза (Sleep) на 60–120 секунд. Этого времени достаточно, чтобы фоновое задание проверки лицензии успело стартовать и успешно завершиться.
3. Запуск базы в режиме «Предприятие» для выполнения дополнительных обработчиков обновления.

Как показывает практика, такая «искусственная» задержка решает проблему в 90% случаев автоматизированного деплоя.

Решение 3: Отказ от динамического обновления и закрытие конфигуратора

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

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

Решение 4: Обновление платформы и исправление багов

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

В релизе 8.3.18.1363 и выше была исправлена ошибка проверки подлинности, которая ошибочно срабатывала на обычных серверных лицензиях (не Мини). Если вы используете версию 8.3.19 или 8.3.20, убедитесь, что установлен последний патч. Например, в версии 8.3.20.1789 была исправлена ошибка, при которой после корректного завершения задания UpdateConfigurationLicense происходил его ошибочный повторный запуск.

Технические нюансы для системных администраторов

Если задание зависло и база остается заблокированной даже после закрытия всех окон, выполните следующие действия для принудительной очистки сеансовых данных:

1. Остановите службу 1C:Enterprise 8.3 Server Agent.
2. Перейдите в каталог описания кластера (по умолчанию C:\Program Files\1cv8\srvinfo\reg_1541).
3. Найдите папку с GUID вашей базы и внутри неё удалите содержимое папки snccntx.
4. Запустите службу сервера.

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

Подведем итог: фоновое задание UpdateConfigurationLicense является неотъемлемой частью современных версий платформы 1С. Его невозможно отключить программно, но его негативное влияние можно свести к минимуму путем правильной настройки сетевого экрана, соблюдением регламентов обновления и использованием актуальных релизов технологической платформы.