Переход на новые версии технологической платформы «1С:Предприятие» — это стандартная задача для системных администраторов и программистов, особенно когда этого требуют новые релизы конфигураций (например, тяжелых ERP-систем или отраслевых решений). Однако на этом пути часто возникают неожиданные технические препятствия. Одним из наиболее неприятных сюрпризов в свое время стала критическая ошибка лицензирования под номером 10206613. В результате этого сбоя пользователи внезапно теряли доступ к базам данных с сообщением об отсутствии лицензии, а системные администраторы обнаруживали, что рабочие файлы программных лицензий самопроизвольно изменили свое расширение на .oldlic.
В этой статье мы подробно разберем природу данной ошибки, выясним, почему она возникает, какие версии платформы ей подвержены, и рассмотрим практические методы борьбы с этой проблемой: от ручного восстановления до написания автоматизированных скриптов мониторинга.
Для начала проанализируем штатный механизм работы программной защиты «1С». Когда вы активируете лицензию по новому пин-коду взамен старого (например, при изменении параметров компьютера или при обновлении лицензии), платформа должна пометить старый файл как недействительный. Для этого система защиты переименовывает старый файл с расширением .lic в формат .oldlic. Это нормальное поведение системы, предотвращающее конфликты дублирования лицензий.
Однако в версиях платформы, подверженных ошибке 10206613, этот механизм срабатывал ложно. Сбой происходил при одновременном соблюдении следующих условий:
.lic).При высокой нагрузке или одновременном запуске нескольких сеансов пользователей возникало так называемое «состояние гонки» (race condition). Служба «Агент сервера 1С» и клиентские сессии пытались одновременно обратиться к одному и тому же файлу лицензии для проверки. Система защиты ошибочно интерпретировала этот конкурентный доступ как попытку повторной активации лицензии на другом оборудовании. В результате срабатывал защитный триггер, и легитимный рабочий файл программной лицензии переименовывался в .oldlic, полностью блокируя работу пользователей.
Рассмотрим важный нюанс, который часто вводит в заблуждение администраторов при тестировании. В файловом режиме работы клиентское приложение «1С» обращается к файлу лицензии напрямую с локального компьютера пользователя. В этом сценарии служба сервера «1С:Предприятия» не задействована, следовательно, отсутствует конкуренция за файлы лицензий на стороне сервера. Именно поэтому на тестовых файловых базах данная ошибка никогда не воспроизводится, а в клиент-серверных («клиент-сервер») вариантах она может парализовать работу всей компании.
Самым надежным и фундаментальным решением является обновление технологической платформы до версий, в которых разработчики фирмы «1С» исправили этот внутренний дефект механизма защиты. Ошибка была официально устранена в следующих ветках платформ:
Если ваша конфигурация требует минимальную версию платформы (например, 8.3.13.1690), не стоит устанавливать именно этот минимальный релиз, так как в нем ошибка лицензирования еще присутствует. Всегда выбирайте наиболее стабильный и исправленный финальный релиз в рамках требуемой ветки платформы.
Бывают ситуации, когда оперативное обновление платформы невозможно по организационным или техническим причинам (например, требуется длительное тестирование доработанной конфигурации). Рассмотрим подробные обходные пути, которые успешно применялись на практике.
Если пользователи начали массово жаловаться на отсутствие лицензии, необходимо выполнить ручную реанимацию файлов:
C:\ProgramData\1C\licenses в ОС Windows или каталог /var/1C/licenses в ОС Linux.20231231120000_20240101150000.oldlic..lic. При этом имя файла можно сократить до исходного вида (например, оставить только уникальную левую часть до знака подчеркивания: 20231231120000.lic).services.msc.Чтобы не заниматься ручным переименованием при каждом сбое, настроим автоматический скрипт. Мы можем создать задачу в планировщике Windows, которая будет каждые несколько минут сканировать папку с лицензиями и возвращать им правильное расширение.
Рассмотрим пример скрипта на языке PowerShell:
$LicensePath = "C:\ProgramData\1C\licenses"
Get-ChildItem -Path $LicensePath -Filter *.oldlic | ForEach-Object {
$OldFile = $_.FullName
$NewName = $_.Name -replace '\.oldlic$', '.lic'
$NewFile = Join-Path -Path $LicensePath -ChildPath $NewName
# Проверяем, существует ли уже файл с таким именем, чтобы избежать ошибок конфликта имен
If (-not (Test-Path -Path $NewFile)) {
Rename-Item -Path $OldFile -NewName $NewName -Force
Write-Host "Файл $OldFile успешно восстановлен в $NewName"
} Else {
# Если файл .lic уже существует, удаляем старый .oldlic, предварительно сделав резервную копию
Remove-Item -Path $OldFile -Force
}
}
Этот скрипт можно сохранить с расширением .ps1 и запускать через Планировщик задач Windows от имени системы (SYSTEM) с интервалом в 1–5 минут.
Если ваш сервер «1С» работает под управлением ОС Linux, используем аналогичный Bash-скрипт:
#!/bin/bash
LIC_DIR="/var/1C/licenses"
for file in "$LIC_DIR"/*.oldlic; do
if [ -f "$file" ]; then
new_file="${file%.oldlic}.lic"
if [ ! -f "$new_file" ]; then
mv "$file" "$new_file"
echo "Восстановлен файл лицензии: $new_file"
else
rm "$file"
fi
fi
done
Данный скрипт достаточно прописать в планировщик cron для выполнения с нужной частотой.
В некоторых случаях простого переименования файлов оказывается недостаточно, так как платформа блокирует повторное использование лицензии на уровне своего локального кэша сессий. Если после переименования ошибка сохраняется, выполним очистку файлов состояния:
C:\ProgramData\1C\1cv8)..pfl, которые отвечают за привязку лицензий и сессий сетевых подключений. К ним относятся файлы с именами 1cv8conn.pfl и conn8211.pfl.Поскольку проблема возникает из-за одновременного размещения серверной и многопользовательской клиентской лицензии в одной директории, мы можем физически разнести их места хранения. Рассмотрим два варианта:
%APPDATA%\1C\1Cv8\licenses. В этом случае серверная лицензия останется на сервере, а клиенты будут использовать свои локальные ключи, минуя раздачу лицензий сервером приложений.Проанализировав все возможные варианты, мы рекомендуем как можно скорее запланировать обновление технологической платформы до актуальных стабильных релизов. Использование скриптов автоматического переименования отлично подходит в качестве временного «костыля» при аварийных ситуациях, но стабильная и бесперебойная работа систем автоматизации бизнеса гарантируется только корректно работающими механизмами платформы.