Перенос 1С: где искать программную лицензию и HASP-ключ

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

Сначала определите тип лицензии 1С

Я разделяю три ситуации, которые в разговорах часто сваливают в одну. Программная лицензия — файл, полученный после активации по регистрационному номеру и PIN-коду. Аппаратная защита — USB-ключ: он может быть локальным для одного компьютера или сетевым, рассчитанным на выдачу лицензий нескольким рабочим местам. Отдельно существует программный лицензирующий сервис платформы. Он не превращает один тип защиты в другой и не «видит» любой ключ просто потому, что работает на том же сервере.

Есть тонкость, на которой ломается простое противопоставление «программная лицензия против HASP». В мастере 1С программную лицензию можно связать не только с параметрами компьютера, но и с доступным HASP-ключом. Это всё равно программная лицензия со своим PIN и файлом, просто объект привязки другой. А сетевой HASP4 Net учитывает аппаратные ключи отдельно. В документации 1С для него описаны варианты подсчёта пользователей менеджером HASP или сервером платформы. Поэтому смотрите на фактический комплект и способ защиты, а не на цвет пластика и не на привычное название службы.

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

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

Порт 475 — не универсальный ответ

Порт 475 относится к классическому Aladdin HASP License Manager. В руководстве Aladdin он указан как стандартный IP-порт менеджера; там же предусмотрены TCP и UDP. Если у вас именно этот стек и менеджер слушает порт по умолчанию, правила сети настраивают для соответствующих протоколов между клиентом или сервером 1С и узлом с ключом. Не нужно открывать порт всему интернету: ограничьте правило локальными подсетями и конкретными узлами, которым действительно нужен ключ.

Но современные Sentinel LDK используют TCP и UDP на порту 1947. Название HASP осталось в путях и названиях компонентов, а поколение менеджера могло измениться. Поэтому надпись «HASP» сама по себе не доказывает, что нужен 475. Сверьте пакет драйвера, службу, документацию именно к ключу и настройки на клиентской стороне. Я видел, как старую памятку переносили на новую установку без проверки: правило на 475 было аккуратным, бесполезным и совершенно уверенным в себе.

Проверяйте путь по узлам, а не только факт доступности порта с администратора. Сначала убедитесь, что ключ виден на машине менеджера и служба запущена; затем проверьте настройки поиска удалённого менеджера на клиенте; после этого проверьте разрешённый TCP/UDP-трафик и журналы брандмауэра. Обычный ping подтверждает лишь базовую IP-связность. Telnet проверяет только TCP и не скажет ничего про UDP. Балансировщик не является штатной заменой менеджеру ключа: не вводите его в схему, если документация вашего продукта прямо этого не требует. Если HASP уже виден, а соединение с кластером не устанавливается, отдельно проверьте ошибку подключения к серверу 1С.

Кейс: что обнаружилось при переезде офиса

В условном кейсе проектный офис «Модульная линия» — 20 рабочих мест — перенёс сервер 1С:Предприятия 8.3 и базу PostgreSQL в другой дата-центр. После переключения часть пользователей увидела сообщение, что лицензия не найдена. По черновому сценарию, сначала проверяли базу и кластер, а затем выяснили, что на старом узле был сетевой USB-ключ, но в план переноса попала только папка программных лицензий. На новом узле не оказалось менеджера для аппаратного ключа. Это разные вещи: копирование файлов не перенесло физический ключ, а перенос базы не установил лицензионный менеджер.

В такой ситуации я останавливаю массовые попытки запуска и выясняю, где ключ сейчас, какой это тип HASP и какой драйвер/менеджер требуется. Затем на целевом узле устанавливаю подходящий компонент из поставки или актуального пакета 1С/Thales, подключаю ключ и проверяю его локально. Документация 1С описывает установку драйвера haspdinst.exe с параметром -i; для сетевого ключа драйвер не требуется на каждом клиентском компьютере, где сам USB-ключ не подключён. Инсталлятор lmsetup.exe из старых инструкций нельзя механически считать верным для любого современного поколения ключа.

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

Как перенести программную лицензию

Программная лицензия привязывается к выбранным параметрам компьютера либо к HASP-ключу. При переносе на другой узел файлы .lic нельзя просто скопировать: документация 1С для выделенного сервера лицензирования прямо говорит, что перенос в этом смысле выполняют повторным получением лицензии с резервным PIN-кодом. Перед началом проверьте комплект PIN-кодов, регистрационные данные и выбранный способ первичной активации. Для восстановления понадобятся те же данные владельца; доступность PIN-кода и возможность повторного получения должны быть подтверждены до отключения старого узла.

Если лицензия была привязана к параметрам машины, изменение этих параметров может потребовать восстановления. При активации на новом сервере в клиент-серверном режиме указывают целевой сервер лицензирования; файл лицензии создаётся там и привязывается к его параметрам, а не к компьютеру, с которого запустили мастер. Для Windows документация платформы приводит каталог %ALLUSERSPROFILE%\1C\licenses у пользователя, от имени которого работает сервер 1С; это обычно не повод без проверки прописывать один путь для всех установок. На Linux каталог и служебная учётная запись отличаются.

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

Что проверить до переключения пользователей

Я готовлю перенос как короткий контрольный список. Сначала фиксирую тип и количество лицензий, объект привязки, владельца ключа и место хранения PIN-кодов. Затем выясняю, какой сервер выдаёт лицензии и каким способом к нему обращаются рабочие места. Для сетевого HASP отдельно записываю поколение менеджера и фактический порт; для программной лицензии — кто её активировал, где лежит файл и какие регистрационные данные нужны для восстановления. В план также входит физический перенос USB-ключа: он должен быть у ответственного, а не раствориться между коробкой с кабелями и списанным сервером.

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

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

Резервирование: что реально можно обещать

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

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

Я проверяю резервирование практическим сценарием: кто обнаружит отказ, где лежат резервные PIN и документы, кто имеет доступ к ключу, сколько занимает предусмотренное восстановление и как пользователи узнают о переключении. Затем сохраняю схему и результаты проверки вместе с планом миграции. Это скучнее, чем нарисовать две коробки со стрелкой «авария — нет», зато после сбоя не приходится выяснять, что резервный сервер есть, а ключ к нему никто не подключал. Для малого офиса честный регламент восстановления обычно полезнее неподтверждённого обещания нулевого простоя.

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