← На главную
При получении бесплатной комьюнити-лицензии (лицензии разработчика) многие разработчики и администраторы сталкиваются с непредвиденной проблемой: рабочие базовые конфигурации перестают открываться в штатном режиме и начинают стартовать под лицензией разработчика. Разберем по шагам, почему возникает данный конфликт, какие риски он несет для рабочих баз и как правильно настроить совместное использование лицензий в одной операционной системе.
Выясним причину конфликта лицензий
Проанализируем механизм поиска лицензий платформой «1С:Предприятие». По умолчанию файл комьюнити-лицензии после активации сохраняется в общедоступных системных каталогах, например C:\ProgramData\1C\licenses или в каталогах пользовательского профиля AppData\Local\1C\1Cv8\licenses.
При запуске любой информационной базы платформа сканирует эти папки в строгом порядке. Обнаружив комьюнити-лицензию, платформа автоматически использует её, перекрывая встроенную защиту базовой конфигурации. Штатного графического переключателя приоритета лицензий в платформе не предусмотрено, поэтому запуск базовых версий начинает происходить с ограничениями лицензии разработчика.
Чем опасен запуск базовых баз под комьюнити-лицензией?
Рассмотрим риски, с которыми можно столкнуться при таком перехвате лицензии:
- Потеря цифровой подписи базовой конфигурации: Базовая лицензия работает исключительно с неизмененной конфигурацией поставщика. Если запустить базу под лицензией комьюнити и случайно снять ее с поддержки (или внести изменения в структуру), цифровая подпись конфигурации аннулируется. Вернуть базу к работе под стандартной базовой лицензией будет невозможно — она сможет открываться только под комьюнити или коммерческими лицензиями ПРОФ/КОРП.
- Ограничения сеансов: Комьюнити-лицензия накладывает жесткие рамки: не более 3 одновременных клиентских сеансов, 1 сеанс веб-клиента и 1 мобильный клиент.
- Зависимость от интернета: Лицензия разработчика выдается на короткий срок (7 дней) и требует непрерывного автопродления через серверы лицензирования. При сбое сети или блокировке серверов запуск учетных баз будет заблокирован.
- Лицензионные условия: Использование комьюнити-лицензии для ведения реального производственного, бухгалтерского или управленческого учета напрямую нарушает условия соглашения.
Способ 1. Разнесение лицензий по разным версиям платформы
Разберем основной и самый быстрый практический способ, который решает проблему без сторонних утилит. Идея заключается в том, чтобы убрать комьюнити-лицензию из общих каталогов и поместить её в каталог конкретной установленной версии платформы.
- Очищаем общие каталоги: Перейдем в папки
C:\ProgramData\1C\licenses, а также в каталоги профиля %LOCALAPPDATA%\1C\1Cv8\licenses и %APPDATA%\1C\1Cv8\licenses. Найдем файл комьюнити-лицензии (файл с расширением .lic) и вырежем его оттуда.
- Помещаем лицензию в каталог конкретной платформы: Установим или выберем отдельный релиз платформы, предназначенный исключительно для разработки (например, более старую или, наоборот, отдельную тестовую версию). Скопируем файл лицензии разработчика в подкаталог конфигурационных файлов этой версии:
C:\Program Files\1cv8\[НомерВерсии]\bin\conf.
- Настраиваем запуск информационных баз: Откроем окно запуска «1С:Предприятие». Для каждой рабочей базовой конфигурации откроем диалог изменения параметров, нажмем кнопку Далее и в поле Версия 1С:Предприятия жестко пропишем номер той версии, в каталоге которой нет файла комьюнити-лицензии.
- Для баз разработки укажем номер версии, в папку
bin\conf которой был помещен файл лицензии разработчика, либо запустим исполняемый файл 1cv8.exe напрямую из этой папки.
Теперь платформа, запуская базовую базу под «чистой» версией, не найдет комьюнити-лицензию ни в общих каталогах, ни в своем локальном каталоге bin\conf, и штатно использует встроенную базовую лицензию.
Способ 2. Изоляция через отдельного пользователя операционной системы
Рассмотрим альтернативный вариант, исключающий взаимное влияние систем защиты с помощью средств разграничения прав операционной системы.
- Создадим в операционной системе отдельную локальную учетную запись Windows (например,
Developer).
- Убедимся, что в общесистемном каталоге
C:\ProgramData\1C\licenses отсутствуют файлы комьюнити-лицензии.
- Выполним вход под учетной записью
Developer и активируем комьюнити-лицензию, указав в мастере привязку только к текущему пользователю. Файл защиты сохранится в профиле этой учетной записи: C:\Users\Developer\AppData\Local\1C\1Cv8\licenses.
- Повседневный бухгалтерский и управленческий учет в базовых конфигурациях ведем под основной учетной записью пользователя ОС, а задачи разработки и экспериментов выполняем под профилем
Developer. Так как профили пользователей изолированы, базовая лицензия в основном сеансе не перехватывается.
Способ 3. Использование виртуализации или официального комплекта
Проанализируем варианты, когда требуется максимальная надежность и полное исключение человеческого фактора:
- Виртуальная машина: Развернем отдельную виртуальную среду (Hyper-V, VirtualBox) и установим платформу с комьюнити-лицензией внутри нее. Это гарантирует 100% изоляцию контуров разработки и боевого учета.
- Комплект разработчика: При регулярной разработке и поддержке рабочих конфигураций удобным вариантом является приобретение официального «1С:Предприятие 8. Комплект специалиста по разработке и внедрению». Он предоставляет полноценную лицензию уровня ПРОФ, не имеющую ограничений комьюнити-версии по числу сеансов и периодическому автопродлению через интернет.