Лицензирование 1С: программные ключи, сервер лицензий и СЛК без сюрпризов

Лицензирование 1С: программные ключи, сервер лицензий и СЛК без сюрпризов

Лицензии 1С — тема, где ошибка обнаруживается в самый неподходящий момент: при переезде на новый сервер, после замены материнской платы или в первый рабочий день после праздников. Разберём, как устроена привязка, что реально ломает лицензию, как правильно построить сервер лицензирования и почему СЛК отраслевых решений живёт по своим правилам.

Три вида лицензий и зачем различать их с первого дня

В обиходе всё называют «ключами», хотя это три разных сущности с разной логикой отказа.

Аппаратные ключи HASP — физические USB-устройства. Живучие, переносятся между машинами вместе с флешкой, не боятся смены железа. Минус один, но существенный: в виртуальной среде их надо пробрасывать, а при живой миграции ВМ между хостами проброс отваливается. На новых поставках их фактически не осталось, но у клиентов с историей встречаются регулярно.

Программные лицензии — файл, привязанный к параметрам конкретной машины. Это сейчас основной вариант. Активируются пин-кодом, пин-код одноразовый, но в комплекте их обычно несколько.

СЛК — система лицензирования и защиты конфигураций от «1С-Рарус» и ряда других вендоров отраслевых решений. Отдельный сервис, отдельная служба, отдельные ключи. Живёт параллельно основному лицензированию 1С и ломается независимо от него.

Практический смысл различения простой: когда пользователь говорит «не хватает лицензий», ответ зависит от того, какая из трёх систем споткнулась. Мы первым делом спрашиваем, что именно написано в сообщении — формулировки у них разные, и по ним диагноз ставится за минуту.

К чему привязывается программная лицензия

Это главный вопрос, потому что от ответа зависит, переживёт ли лицензия обслуживание сервера.

При активации платформа снимает набор характеристик машины и превращает их в отпечаток. В расчёт идут имя компьютера, параметры материнской платы, процессора, сетевых адаптеров, объём и разметка дисков, версия ОС. Точный алгоритм не публикуется, но поведение известно по практике.

Что обычно проходит безболезненно:

  • добавление оперативной памяти;
  • обновления Windows, включая накопительные;
  • добавление второго диска;
  • смена IP-адреса.

Что ломает лицензию почти гарантированно:

  • переименование компьютера;
  • замена материнской платы или процессора;
  • смена сетевой карты, включая замену виртуального адаптера с E1000 на VMXNET3;
  • переустановка ОС;
  • клонирование виртуальной машины — у клона другой UUID.

Последний пункт стоит подчеркнуть. Развернули копию боевой ВМ для теста — и получили две машины, одна из которых потеряла лицензию. Мы в регламенте прописываем: тестовый контур поднимается только из бэкапа с обязательным переименованием, и лицензии в нём отдельные, учебные.

При изменении параметров машины лицензия не исчезает мгновенно — платформа даёт возможность переактивировать её тем же пин-кодом ограниченное число раз. Именно поэтому пин-коды нужно хранить, а не выбрасывать конверт после первой установки.

Привязка программной лицензии 1С к оборудованию
Программный ключ считает параметры машины: часть можно менять безболезненно, часть — нет

Где хранить пин-коды и почему это не мелочь

Самая частая дорогая заявка по лицензиям звучит так: «сервер поменяли, 1С не запускается, где пин — никто не знает».

Регистрационные данные привязаны к учётной записи владельца на портале 1С. Если внедрение делал подрядчик десять лет назад и регистрировал на себя, восстановление превращается в переписку с сопровождением, доверенности и недели ожидания.

Что мы делаем при приёме клиента на поддержку:

  1. Проверяем, на кого зарегистрирован программный продукт. Если не на клиента — инициируем перерегистрацию сразу, а не когда припечёт.
  2. Собираем все пин-коды и регистрационные номера в хранилище паролей, в отдельную запись с приложенными сканами.
  3. Выгружаем список активированных лицензий с сервера — их файлы лежат в C:\ProgramData\1C\licenses.
  4. Фиксируем, сколько лицензий какого типа есть, чтобы при росте штата не выяснять это в аврале.

Файлы лицензий, кстати, стоит забэкапить. Восстановить их на ту же машину после переустановки платформы — рабочий сценарий, он экономит одну попытку активации.

Сервер лицензирования: зачем он нужен даже на одном сервере

Многопользовательская лицензия может быть активирована прямо на сервере 1С, и она раздаётся клиентам автоматически. Работает. Но есть нюанс, ради которого мы часто выносим лицензирование отдельно.

Если лицензии активированы на прикладном сервере, то любая операция с этим сервером — переезд, замена железа, пересоздание ВМ — заодно бьёт по лицензиям. Отдельная маленькая машина, которая занимается только раздачей лицензий, эту связь разрывает.

Такой сервер — это та же служба 1C:Enterprise 8.3 Server Agent, поднятая на минимальной ВМ (2 vCPU, 4 ГБ) без баз. Клиенты находят его через файл nethasp.ini или через настройку в списке баз.

[NH_COMMON]
NH_TCPIP = Enabled
[NH_TCPIP]
NH_SERVER_ADDR = 192.168.10.15
NH_PORT_NUMBER = 475

Файл кладётся в каталог conf платформы на рабочих станциях. Раздавать его удобно групповой политикой — тогда при переезде сервера лицензий достаточно поменять одну строку централизованно.

Стоит ли городить это на офис из десяти человек? Нет. От двадцати пяти-тридцати рабочих мест — уже оправданно, особенно если сервер 1С виртуальный и его планово переносят между хостами.

СЛК: отдельная жизнь отраслевых решений

Если у клиента стоит отраслевое решение — управление автосервисом, общепит, медицина, — почти наверняка там СЛК. И она ведёт себя иначе.

СЛК — это отдельная служба защиты, которая слушает свой порт (по умолчанию 9099) и раздаёт лицензии на конфигурацию, а не на платформу. У неё свой менеджер, свой веб-интерфейс на http://localhost:9099 и свои ключи.

Три вещи, которые важно знать заранее:

Версия СЛК привязана к версии конфигурации. Обновили отраслевое решение — может потребоваться обновить и сервер СЛК. Обратная совместимость есть не всегда, и обнаруживается это уже после обновления, когда пользователи не могут войти.

Служба СЛК стартует медленнее сервера 1С. После перезагрузки бывает окно в минуту-полторы, когда 1С уже поднялась, а лицензий ещё нет. Пользователи, зашедшие в это окно, получают ошибку. Лечится настройкой зависимости служб либо отложенным стартом.

Аппаратные ключи СЛК тоже существуют, и в виртуальной среде их приходится пробрасывать через USB-over-IP. Это отдельная точка отказа, которую надо мониторить.

У клиента-автосервиса мы разбирали случай: раз в две-три недели утром половина рабочих мест не пускала в программу. Оказалось — плановая перезагрузка хоста виртуализации по расписанию обновлений, ВМ поднималась, USB-проброс восстанавливался с задержкой, служба СЛК стартовала без ключа. Решилось переносом окна обновлений и настройкой перезапуска службы по таймеру.

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

Что делать, когда лицензий не хватает

Сообщение «Не найдена лицензия» и «Превышено количество лицензий» — разные истории, и путать их не стоит.

СимптомВероятная причинаПервое действие
Не найдена лицензия у всех сразуслетела серверная лицензия либо не стартовала службапроверить каталог licenses и службу
Не найдена лицензия у одноголокальная лицензия на станции, сменилось железопереактивировать или перевести на сервер
Превышено количествореально кончились свободные лицензиисписок сеансов в консоли кластера
Кончаются к обеду, утром хватаетмёртвые сеансы не освобождаютсятайм-аут неактивности, разрыв сеансов

Четвёртая строка — самая распространённая и самая раздражающая. Пользователь закрыл крышку ноутбука, сеанс висит, лицензия занята. По умолчанию 1С терпит такие сеансы долго.

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

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

Кейс: переезд на новый сервер, который чуть не встал

История короткая, но показательная.

Оптовая компания, 34 рабочих места, база бухгалтерии и торговли на одном физическом сервере 2016 года. Сервер начал сыпать предупреждениями по дискам, клиент купил новый и попросил перенести всё за выходные. Стандартная работа, мы делаем такие переезды регулярно.

В пятницу вечером сняли образ, развернули на новом железе, подняли, проверили. Всё поднялось. Лицензии слетели — ожидаемо, замена платформы и процессора. Достаём пин-коды.

Пин-кодов нет.

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

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

С тех пор проверка регистрационных данных стоит у нас первым пунктом в чек-листе приёма на поддержку — раньше инвентаризации серверов. Потому что серверы можно пересчитать за час в любой момент, а перерегистрацию продукта за час не сделаешь.

Регламент, который снимает 90 % проблем

Собираем всё в короткий список действий, который стоит выполнить один раз и потом просто поддерживать.

  • Программные продукты зарегистрированы на клиента, а не на подрядчика.
  • Все пин-коды и регистрационные номера — в хранилище паролей, со сканами.
  • Каталог licenses входит в бэкап сервера.
  • Перед любой заменой железа или переносом ВМ — проверка, что есть свободная попытка активации.
  • Клонирование боевой ВМ запрещено регламентом; тестовый контур поднимается из бэкапа с переименованием.
  • Тайм-ауты спящих сеансов настроены, лицензии не висят на забытых окнах.
  • Если есть СЛК — её версия зафиксирована рядом с версией конфигурации, служба под мониторингом.
  • На мониторинге: доступность порта сервера лицензий и число свободных лицензий.

Последний пункт стоит отдельного слова. Тревога «осталось меньше трёх свободных лицензий» приходит за неделю до того, как в компанию выйдут двое новых сотрудников и всё встанет. Это дешёвая проба и самая благодарная.

Частые вопросы

Слетит ли программная лицензия при добавлении оперативной памяти?

Как правило, нет. Объём памяти влияет на отпечаток слабо. А вот замена материнской платы, процессора или сетевого адаптера — включая смену типа виртуального адаптера — почти наверняка потребует переактивации.

Можно ли перенести лицензию на новый сервер?

Да, повторной активацией тем же пин-кодом. Число попыток ограничено, поэтому перед переносом убедитесь, что пин-код есть и попытки остались. Файлы старых лицензий лучше сохранить до успешной активации на новом месте.

Нужен ли отдельный сервер лицензирования небольшому офису?

До двадцати рабочих мест обычно избыточно. Смысл появляется, когда сервер 1С виртуальный и его планово переносят, — тогда лицензии перестают зависеть от судьбы прикладного сервера.

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

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

Нужна помощь с проектом?

Специалисты АйТи Фреш помогут с архитектурой, DevOps, безопасностью и разработкой — 15+ лет опыта

📞 Связаться с нами
#1С#лицензии#СЛК#внедрение#поддержка
Комментарии 0

Оставить комментарий

загрузка...

Подпишитесь на рассылку ITfresh

Раз в неделю — практические гайды для руководителя IT и сисадмина: безопасность, 1С, миграции, резервные копии, лайфхаки из реальных проектов.

Реквизиты оператора персональных данных

ООО «АЙТИ-ФРЕШ», ИНН 7719418495, КПП 771901001. Юридический адрес: 105523, г. Москва, Щёлковское шоссе, д. 92, корп. 7. Контакт: info@itfresh.ru, +7 903 729-62-41. Оператор обрабатывает e-mail подписчика в целях рассылки информационных и рекламных материалов до момента отзыва согласия.