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

Что такое аппаратный ключ и программная лицензия

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

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

Обычный рассматриваемый вариант — привязка программной лицензии к компьютеру. В документации предусмотрена и привязка программной лицензии к доступному HASP-ключу в соответствующем сценарии. Поэтому окончательную схему определяют по поставке и мастеру активации: наличие файла не всегда означает именно привязку к параметрам ВМ.

Способ защиты не определяет функциональность конфигурации. Бухгалтерия КОРП, клиентская лицензия платформы КОРП и USB-ключ — разные понятия. Предметное сравнение программ — в статье о Базовой, ПРОФ и КОРП.

Сравнение в эксплуатации

Это эксплуатационные различия, а не рейтинг «старое против нового». Выбор зависит от доступности нужной поставки, архитектуры и регламента обслуживания. Не следует обещать, что USB всегда проще переносить, а программная защита всегда беспроблемно переживает миграцию ВМ.

Конкурентная лицензия, рабочее место и лицензия сервера — разные понятия

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

Практически полезно разделить три вопроса: что лицензируется, где получается лицензия и что считается потребителем. Способ защиты USB/файл — четвёртый вопрос; он не заменяет первые три.

Правильная формулировка: «клиентские лицензии выдаются сервером 1С, поэтому каждый лицензируемый сеанс в этой схеме занимает одно место». Формулировка «серверная лицензия расходуется на каждый сеанс» смешивает два разных продукта.

Например, стандартная лицензия на сервер разрешает работу сервера на соответствующем компьютере; требуемые клиентские места приобретают отдельно. При нескольких рабочих серверах, специальных серверных поставках и уровнях ПРОФ/КОРП проверяют отдельные условия. Это не основание покупать одну серверную лицензию на каждого бухгалтера.

Модель локальной и серверной программной выдачи описана в информационном письме 1С №12454. Это исходное описание механизма: старые цены и ассортимент из письма нельзя использовать как текущие. Действующие общие условия сверяют по FAQ производителя.

Несколько экземпляров 1С: когда одна лицензия, а когда несколько

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

Терминальный режим здесь принципиален. Однопользовательская программная лицензия в описанной локальной терминальной схеме обслуживает один терминальный сеанс, внутри которого можно запускать несколько экземпляров. Многопользовательская программная лицензия на терминальном сервере может обслуживать соответствующее число терминальных сеансов с несколькими приложениями внутри каждого. Из этого не следует, что одна локальная лицензия лицензирует весь RDS-сервер на любое число вошедших людей.

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

В Windows локальный учёт также зависит от сеанса ОС: запуск приложения интерактивно и запуск из службы могут относиться к разным сеансам и требовать отдельного места. Поэтому автоматическую обработку, запущенную отдельным клиентом из службы, нельзя объявлять бесплатным «фоновым заданием» только по её названию.

Технический учёт и договорные права различаются. То, что штатный HTTP-сервис или фоновое задание не запрашивает клиентское место, не разрешает организовать через него произвольное число нелицензированных рабочих мест. Пользовательский доступ через внешнюю панель или посредника отдельно проверяют по правилам мультиплексирования: уменьшение числа прямых подключений само по себе не уменьшает требуемых прав. FAQ 1С, раздел о мультиплексировании.

Для аппаратных клиентских ключей тоже учитывают их вид и путь получения лицензии. Нельзя механически переносить на все USB-ключи таблицу программной защиты или правила серверной выдачи. Руководство администратора разграничивает эти механизмы.

Подробности программного учёта: раздел 10.3.4 «Учёт клиентских лицензий» руководства администратора, особенно подразделы о клиент-серверном, веб- и терминальном режимах. Каталог документации 1С; рекомендации 1Ci по выбору вида лицензии.

Как рассчитать необходимое количество лицензий

1. Сначала определить схему каждого потока

Разделите обычные ПК, веб-клиентов, RDS и подключения администраторов. Для каждого потока запишите фактический источник и единицу учёта. Не складывайте количество компьютеров, людей и сеансов, как будто это одинаковые величины.

2. Снять одновременный пик, а не сумму запусков за день

Для конкурентного пула оценка строится так: требуемый объём = максимум одновременного потребления данного пула + согласованный резерв. Для локальных однопользовательских лицензий считают компьютеры либо терминальные сеансы в применимой схеме; свободное место на одном обычном ПК не становится автоматически общим местом для другого.

Наблюдение должно захватывать закрытие месяца, несколько рабочих баз, Конфигуратор и используемые внешние подключения. Фоновые задания и обычные серверные HTTP-сервисы не добавляют как будто это люди; COM и другие отдельные виды работы проверяют по своим правилам.

3. Пример для одной команды в трёх архитектурах

Допустим, одновременно работают 12 сотрудников, и каждый открывает Бухгалтерию и ЗУП двумя отдельными приложениями. Считаем только эти подключения, без скрытых дополнительных потребителей.

Если к конкурентному потреблению 24 места добавили обоснованный резерв 4 места, целевая потребность — 28. Это результат расчёта, а не обещание наличия коробки «на 28»: комплектование делают по актуальным поставкам и возможности их совместного использования. Нельзя округлить 24 до 20 только потому, что такой комплект удобнее купить.

4. Проверить на реальном рабочем цикле

Откройте согласованное число приложений, посмотрите выдачу, закройте часть и проверьте возврат мест. Повторите с теми базами и путями, которые будут использоваться. Зависшие или отключённые терминальные сеансы требуют разбора: разрыв RDP-соединения не обязательно завершает приложения.

Число процессов rphost, строк списка соединений или фоновых заданий нельзя само по себе принимать за число расходуемых клиентских мест. Для принятия решения нужны вид подключения и фактическая информация о лицензии.

Первая активация: что решить до ввода PIN

1. Определить место выдачи. Локальный компьютер, сервер 1С или другая предусмотренная схема.
2. Проверить точный комплект. Назначение лицензии, число мест, уровень и варианты активации.
3. Подготовить данные владельца. Сохранить сведения в том виде, в котором они будут введены.
4. Убедиться в стабильности целевого узла. Не активировать рабочую лицензию случайно на временной ВМ или ноутбуке установщика.
5. Получить лицензию штатным мастером. В предусмотренном режиме с доступом к Центру лицензирования либо через файл запроса/ответа.
6. Проверить реальное использование. Запустить нужный клиент или сервер и зафиксировать источник полученной лицензии.

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

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

Порядок получения и восстановления приведён в инструкции 1С. Пример интерфейса первого запуска есть в официальной инструкции к поставке; ограничения Базовой версии из этого документа нельзя переносить на все продукты.

Файл .lic: где искать и почему его наличия недостаточно

Установка файла под учётной записью администратора не гарантирует, что его видит служба 1С. Важны контекст запуска, пути поиска, конфигурационные файлы и права. У клиента на рабочем столе и серверного процесса могут быть разные домашние каталоги.

При привязке к компьютеру документация описывает среди значимых характеристик параметры ОС и оборудования: процессора, платы, памяти, сетевых адаптеров и дисков. Полный состав и правила сравнения нужно брать для своей версии и ОС. Не каждое добавление устройства обязательно нарушает привязку; нельзя применять правило «любая замена требует нового PIN» без разбора конкретного изменения.

Среди используемых платформой общих каталогов встречаются %ProgramData%\1C\licenses в Windows и /var/1C/licenses в Linux. Это не полный перечень путей и не указание копировать туда все найденные лицензии. Полный порядок поиска смотрят в руководстве администратора своего релиза, в разделе о расположении программных лицензий.

Пример PowerShell для просмотра метаданных файлов в одном известном каталоге:

$licenseDir = Join-Path $env:ProgramData '1C\licenses'
if (Test-Path -LiteralPath $licenseDir) {
    Get-ChildItem -LiteralPath $licenseDir -Filter '*.lic' -File |
        Select-Object Name, Length, LastWriteTime
}

Пример Linux для того же класса проверки:

# Только список файлов и права; это не проверка действительности
ls -ld /var/1C/licenses
find /var/1C/licenses -maxdepth 1 -type f -name '*.lic' -ls

Обе команды только показывают состояние. Они не подтверждают соответствие привязки и не показывают, выдана ли лицензия нужному процессу. Не редактируйте содержимое .lic, не раскладывайте одну активированную лицензию по нескольким узлам и не удаляйте файлы при первой ошибке.

USB-ключ: драйвер, локальная доступность и сетевой менеджер

Для аппаратной защиты сначала определяют точный тип ключа: какой компонент он лицензирует и предполагается ли сетевое использование. Ключ серверной лицензии не превращается в сетевой запас клиентских мест; наличие USB-устройства не доказывает наличие нужной лицензии.

1. Проверить обнаружение устройства ОС. Порт, подключение, питание и отсутствие нестабильного USB-хаба.
2. Проверить драйвер. Нужна поддерживаемая комбинация ключа, ОС и версии защиты, а не случайный пакет из интернета.
3. Проверить менеджер, если он требуется схемой. Служба запущена, ключ распознан, доступные места видны.
4. Проверить сетевой путь. От фактического потребителя до нужного узла защиты, включая VPN/VLAN и firewall.
5. Проверить выдачу платформой. Именно нужное приложение получило подходящую лицензию.

В Windows можно начать с просмотра подходящих устройств и служб; названия различаются:

Get-PnpDevice -PresentOnly |
    Where-Object { $_.FriendlyName -match 'HASP|Sentinel' } |
    Select-Object Status, Class, FriendlyName

Get-CimInstance Win32_Service |
    Where-Object { $_.DisplayName -match '1C|1С|HASP|Sentinel' } |
    Select-Object Name, State, StartName

Пустой результат фильтра не доказывает отсутствие устройства или службы: проверьте реальные наименования и диспетчер устройств. В Linux при установленной утилите пригодится lsusb. Эта проверка тоже не заменяет работу приложения с ключом.

Порядок установки драйвера и ограничения его управляющего интерфейса описываются в руководстве администратора конкретного релиза; каталог документации 1С. Не включайте удалённое управление и сетевые функции, которые не требуются проекту.

Сетевой HASP: пример явного адреса и ловушка TCP-проверки

В схеме с классическим HASP License Manager параметры клиента могут задаваться в nethasp.ini. Пример ниже относится именно к этому механизму, а не ко всем поколениям Sentinel и не к программным лицензиям. Сначала сохраните существующий файл и выясните, какой экземпляр приложения читает его.

[NH_COMMON]
NH_TCPIP=Enabled
[NH_TCPIP]
NH_SERVER_ADDR=192.0.2.15
NH_PORT_NUMBER=475
NH_TCPIP_METHOD=UDP
NH_USE_BROADCAST=Disabled

Адрес из диапазона документации заменяют реальным IP менеджера. Смысл примера — явный узел вместо широковещательного поиска. Для описанного HASP-механизма используется UDP; поэтому успешный или неуспешный Test-NetConnection -Port 475 проверяет TCP и не является доказательством состояния UDP-выдачи.

Если проблема появляется только через маршрутизатор или VPN, проверяют разрешённый UDP-путь и фактический обмен пакетами, а не открывают все порты. У другого менеджера могут быть другие протоколы и настройки. Сверяйте раздел настройки HASP в документации своего релиза; перечень документации — на сайте 1С:ИТС.

При нескольких ключах дополнительно изучают поддерживаемую схему совместного использования. Нельзя обещать, что любые два USB-ключа, подключённые в один компьютер, автоматически сложат все свои возможности.

Виртуальные машины, терминальный сервер и выделенный сервис

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

Удержание стабильных параметров узла лицензирования и вынос соответствующей функции — варианты архитектуры. При этом сервис лицензирования 1С и сетевой HASP License Manager — разные механизмы. Возможность их использования и назначения проверяют по версии платформы и лицензиям.

Для терминальной работы выясняют, где находится лицензия и как считаются отдельные сеансы ОС и запуски приложений. Наличие одного RDS-сервера не означает одну клиентскую лицензию на всех работающих через него людей. Схема должна быть отражена в паспорте и проверена при нужной конкурентности.

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

Три разных операции: восстановить, заменить или сменить защиту

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

Как заменить неисправный аппаратный ключ 1С

1. Подтвердить неисправность. Проверить подключение, другой исправный порт, поддерживаемый драйвер и менеджер. Отсутствие места в пуле или ошибка сети не доказывают поломку ключа.
2. Идентифицировать изделие. Записать назначение, регистрационный номер продукта, доступные обозначения ключа и схему его использования. Сделать фотографии маркировки для закрытого обращения.
3. Подготовить документы. Регистрационную карточку либо документы электронной поставки, сведения о владельце, описание отказа и контакт ответственного.
4. Обратиться к обслуживающему партнёру 1С или в поддержку по продукту. Получить актуальный бланк заявления и перечень требуемых приложений. Не отправлять оригинальный ключ на случайный адрес без согласованного порядка.
5. Согласовать временную работу. Выяснить, предусмотрен ли обменный ключ или иной разрешённый вариант на период замены. Наличие и условия такой помощи не считаются автоматическими.
6. Передать ключ и документы по согласованной процедуре. Зафиксировать акт/опись передачи, идентификаторы и статус обращения. При отсутствии ключа это уже другой сценарий.
7. Получить и проверить замену. Сверить назначение и число мест, работу драйвера/менеджера, серверный запуск и клиентские подключения.
8. Обновить реестр. Отметить старый ключ как заменённый, связать новый с заявкой и документами, проверить прекращение временной схемы.

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

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

Как восстановить программную лицензию и получить резервный PIN

Если потерян файл, но компьютер не изменился

1. Выясните, действительно ли файл утрачен, а не скрыт в другом каталоге или недоступен новой учётной записи.
2. Подготовьте регистрационный номер, использованный PIN и точные данные владельца из исходной активации.
3. Откройте штатный мастер получения лицензии и выберите восстановление. В предусмотренном сценарием вопросе укажите, что параметры компьютера не изменились.
4. Получите лицензию для прежних параметров и проверьте доступность нужному приложению или службе.

Если компьютер или значимые параметры изменились

1. Зафиксируйте причину: перенос, замена оборудования, восстановление ВМ или другое изменение привязки.
2. Подготовьте прежние регистрационные данные и подходящий неиспользованный резервный PIN. Число и назначение кодов смотрите в документах своей поставки.
3. В мастере восстановления укажите изменение параметров и выполните предусмотренный порядок с резервным кодом. Запрос формируется для целевого узла, где будет работать лицензия.
4. Если автоматическое получение недоступно, используйте разрешённый файловый запрос/ответ. Не формируйте запрос на постороннем ПК вместо целевого.
5. Проверьте результат под реальной учётной записью, затем внесите новый статус кодов и узла в защищённый учёт.

Если резервные коды закончились

Обращаются в Центр лицензирования в порядке, указанном в действующей инструкции: сообщают регистрационный комплект, использованный код, причину повторного получения и требуемые сведения/файл запроса. Дополнительный PIN не считают гарантированно и мгновенно выданным: правообладатель проверяет историю использования и соблюдение условий.

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

После восстановления лицензия не должна продолжать использоваться на старом узле вопреки условиям. Сохранённая резервная копия файла и право одновременно эксплуатировать второй компьютер — разные вещи. Штатные действия описаны в инструкции получения программных лицензий и рекомендациях 1Ci.

Обмен USB на программную защиту и обратный переход

Это изменение комплекта/способа защиты через поставщика, а не преобразование файла пользователем. Исторический порядок такого обмена описан фирмой 1С; актуальную доступность, комплект документов, оплату и временную схему подтверждают до работ. Цены и сроки из старых писем в текущий расчёт не переносят.

1. Указать точный продукт, регистрационный комплект, тип защиты и цель: виртуализация, отказ USB-инфраструктуры, централизация или иная причина.
2. Получить подтверждение допустимого направления обмена и условия по этой поставке.
3. Подать заявление и документы. Если меняются регистрационные номера или состав лицензий, это должно быть видно в оформлении.
4. Согласовать передачу прежних носителей, деактивацию/прекращение использования программных файлов и работу на время обмена.
5. Получить новый комплект и выполнить его штатную установку/активацию на правильном узле.
6. Сверить выдачу, количество мест, работоспособность сервера и снятие старых/временных механизмов с эксплуатации.

При обратном переходе программная → аппаратная защита старые PIN и обслуживание прежнего комплекта могут прекращаться по условиям обмена. Это не операция, которую следует обещать как свободно обратимую. Разделение одной программной лицензии на несколько самостоятельных комплектов тоже решают оформленным обменом, а не копированием .lic.

Несколько ключей 1С: совместная работа или объединение в один

Например, компания сначала купила USB-лицензию на 5 мест, затем программную на 5, а позже ещё одну на 10. Теперь хочется упростить обслуживание: один узел выдачи или вообще один ключ. Это разные задачи. Совместно использовать приобретённые лицензии можно без превращения их в один новый комплект; получить вместо них одну лицензию — отдельная процедура обмена. Файлы .lic не склеивают, а места на USB-ключе самостоятельно не перепрограммируют.

Если все лицензии программные

Для общей выдачи сервером 1С не обязательно менять несколько программных лицензий на одну: официальная документация допускает установку нескольких программных лицензий на сервер. При этом сохраняются их собственные регистрационные сведения и файлы. Централизация выдачи — не объединение PIN и не создание одного файла с суммой мест.

Вначале проверьте, что уже активировано: многопользовательские лицензии для серверной выдачи или отдельные локальные лицензии. Перемещение локальных активаций на общий сервер не выполняют простым копированием файлов; для выбранной схемы применяют предусмотренное получение или восстановление. Если цель — именно один регистрационный комплект вместо нескольких программных, не обещайте обычный обмен «ПРОФ на ПРОФ»: у этой процедуры есть ограничения по виду защиты. Запросите у партнёра допустимый вариант для конкретных поставок.

Если аппаратных ключей несколько

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

Если набор смешанный: USB и программные лицензии

Смешанная эксплуатация поддерживается платформой: менять защиту только ради совместной работы не обязательно. Если нужен один новый ключ, подают заявку на обмен. В опубликованном порядке 1С предусмотрен обмен смешанного набора клиентских лицензий на одну лицензию с аппаратной или программной защитой. Это не универсальное разрешение объединять любые продукты и уровни. Основание — письмо 1С №17670; действующие условия, зачёт и доступность нужной поставки подтверждают перед заказом.

Практический пример: отдельно приобретённые клиентские лицензии на 5 + 5 + 10 мест дают исходный объём 20. Можно запросить обмен на один комплект на 20 мест, а при росте нагрузки — на больший номинал. Это заявка на согласование, а не гарантированный результат для любого набора. Лицензию на сервер, право на Бухгалтерию и ключ СЛК в эти 20 клиентских мест не включают.

Как провести объединение через партнёра

1. Составить список исходных продуктов. Для каждого указать регистрационный номер, владельца, ПРОФ/КОРП, номинал, защиту и происхождение: отдельная покупка или часть основной поставки/бандла.
2. Описать целевую схему. Один физический ключ, несколько программных лицензий на одном сервере или новая единая поставка; необходимое число мест, узел выдачи и потребители.
3. Получить подтверждение применимости обмена. Партнёр проверяет регистрацию, документы, условия сопровождения и ограничения. Включённые в бандл права нельзя произвольно выделить для такого обмена; отдельно проверяют уровни ПРОФ/КОРП.
4. Согласовать расчёт и непрерывность работы. Зафиксировать цену новой поставки, зачёт сдаваемых лицензий, услуги, сроки и порядок временного лицензирования. Сумма мест сама по себе не даёт цену; исторические таблицы зачёта не заменяют текущий расчёт.
5. Оформить сдачу и прекращение старого использования. Передать требуемые документы и аппаратные носители; для программной защиты выполнить согласованный порядок вывода старых лицензий. Замена не создаёт второй законный пул поверх первого.
6. Проверить новый комплект и обновить учёт. Повторить рабочий пик с нужными базами, проверить выдачу и освобождение мест; записать связь старых и новых регистрационных данных, документы и местонахождение ключа.

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

Варианты совместной работы, обмена и ограничения бандлированных поставок приведены в официальном FAQ 1С, раздел V. У СЛК и отраслевых лицензий собственный порядок: объединение клиентских лицензий платформы не объединяет защиту конфигурации.

Перенос лицензии: порядок до остановки старого сервера

1. Инвентаризировать поставку. Тип, назначение, число мест, регистрационные документы и текущий источник выдачи.
2. Сохранить данные первоначальной активации. Они могут потребоваться в точности, включая сведения о владельце.
3. Подготовить законный способ восстановления. Проверить резервные PIN и порядок обращения за дополнительным кодом, если имеющихся недостаточно.
4. Подготовить целевой узел. ОС, платформа, драйверы при необходимости, учётные записи, сеть и каталоги.
5. Согласовать переключение. Когда старый узел прекращает использование лицензии и как исключается параллельное использование одной привязки.
6. Выполнить штатную процедуру. Перенос доступа к аппаратному ключу либо получение/восстановление программной лицензии по своей поставке.
7. Принять результат. Проверить рабочие места, сервер, повторный запуск и документировать изменения.

Копия файла .lic не равна переносу права на другой компьютер. Если привязка другая, простой перенос файла не заменяет восстановление. И резервный PIN — не дополнительное купленное рабочее место.

Не расходуйте новые PIN, пока не выяснена причина отказа. Ошибка доступа к каталогу и реальное изменение привязки требуют разных исправлений. Штатный порядок и необходимые данные описаны в руководстве по регистрации.

Лицензирование конфигурации: почему ключ платформы не решает всё

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

У отраслевого продукта может одновременно требоваться: законная основная поставка платформы/решения, клиентские лицензии платформы, серверная лицензия для клиент-серверной архитектуры и отдельные лицензии конфигурации. Часть позиций может уже входить в комплект — тогда их не покупают повторно, но подтверждают документами.

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

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

Что такое СЛК и чем она отличается от лицензирования платформы

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

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

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

Описание механизма: официальная карточка СЛК; пример использования параметров версии и срока — материал об отраслевых конфигурациях. Демо- и промолицензии могут иметь собственные ограничения; они не являются заменой рабочей поставки.

Установка и активация СЛК 3.0: последовательность

1. Взять совместимый дистрибутив из поставки продукта. Версии сервера, клиентской компоненты и конфигурации должны соответствовать документации решения.
2. Назначить узел сервера СЛК. Продумать постоянный адрес, учётную запись службы, доступность для реальных потребителей и резервирование.
3. Установить сервер и нужные компоненты. Драйвер аппаратного ключа требуется для соответствующей схемы, а не вместо активации программного ключа.
4. Открыть консоль сервера. В документированных поставках СЛК 3.0 встречается адрес http://localhost:9099 на самом узле. Фактический порт и адрес могут быть изменены.
5. Активировать продуктовый ключ. В разделе установки лицензий вводят код активации и предусмотренные данные владельца; выбирают носитель согласно поставке. Возможны автоматический запрос или файловый обмен с Центром лицензирования СЛК.
6. Настроить защищённое решение. Указать реальный сервер СЛК, порт и параметры, требуемые конфигурацией.
7. Проверить ключ и потребление. Ключ активен, продукт соответствует, места доступны, защищённые функции выполняются с рабочих мест.

Консоль 9099 СЛК и UDP 475 классического HASP — разные назначения. Наличие одного доступного порта ничего не говорит о другом механизме. Пример проверки TCP-доступности настроенного сервера СЛК в Windows:

# Замените имя и порт фактическими параметрами СЛК
Test-NetConnection -ComputerName slk.example.internal -Port 9099

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

Порядок с консолью и установкой ключей показан, например, в инструкции «1С:Общепит» 2026 года. Это пример конкретной поставки; настройки других защит 1С-Рарус и иных разработчиков не следует приравнивать к СЛК только по похожему названию.

Файлы платформы и СЛК — не один каталог

Это примеры из соответствующей документации, не полный перечень путей. Копирование .lic платформы в каталог СЛК не активирует отраслевой продукт. Правила привязки, резервных кодов и восстановления СЛК проверяют отдельно; переносить на неё список значимых параметров платформы нельзя.

Пример описания файлов и носителей — инструкция «1С:Отель».

Замена и восстановление ключа СЛК

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

После получения нового кода или носителя активируют именно нужный продукт, проверяют основную и дополнительные лицензии, их совместное расположение и права на защищённые функции. Если продукт требует совместной работы дополнительных ключей с основным, перенос одного из них на другой сервер может не дать ожидаемого результата. Универсальное число «бесплатных резервных активаций СЛК» для всех разработчиков указывать нельзя.

«Лицензия не обнаружена»: диагностика по уровням

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

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

ps -eo user,pid,comm | grep -E 'ragent|rmngr|rphost'

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

Учёт лицензий: что должно оставаться у компании

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

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

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

Копии, резервный сервер и аварийное восстановление

Восстановленная база может быть технически исправна, но недоступна пользователям из-за лицензирования. Поэтому в учение включают не только данные и СУБД, но и получение клиентских и серверных лицензий на целевой площадке.

• Хранить защищённо: документы, данные активации, состояние PIN и описание места выдачи.
• Сохранять копии: файлы лицензий и настройки в составе согласованного защищённого резервирования.
• Не считать копию дополнительной лицензией: клон узла и копия файла не разрешают параллельную эксплуатацию без соответствующих прав.
• Испытывать сценарий: сколько времени займёт обнаружение, переключение, восстановление и запуск пользователей.

Для аппаратного ключа заранее определяют действия при его физическом отказе или утрате. Не обещают мгновенную бесплатную замену без проверки условий. Для программного варианта — порядок восстановления и ответственного с доступом к документам. Если эти сведения есть только у уволившегося администратора, план возврата неполон.

В статье о PostgreSQL для 1С разобраны копирование и возврат данных. Здесь к этому добавляется готовность лицензирования — самостоятельный пункт приёмки.

Что ещё важно при покупке и смене защиты

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

Уровни ПРОФ/КОРП не равны способу защиты. Для отдельных аппаратных лицензий КОРП предусмотрена дополнительная программная активация; нельзя считать, что одного факта подключения ключа достаточно для любой корпоративной функции. Условия зависят в том числе от поставки и даты приобретения.

Совместное использование аппаратной и программной защиты предусмотрено платформой, но не отменяет правил совместимости уровней лицензий и условий конкретного продукта. Отдельные ограничения есть у Базовых версий. Официальная FAQ по лицензированию разграничивает эти вопросы.

Паспорт лицензирования и памятка переноса

Подготовить лицензирование к эксплуатации и переезду

Частые вопросы о ключах 1С