Как найти сервер лицензий 1с в сети

23.04.14 – 11:06

Есть 1С, берущая лицензии с неизвестного сервера (в “справке” указан сетевой ключ 100 лицензий). Читал, что нужно глянуть 475 порт в netstat’e. Не нашел его использование там. Поставил Алладин-монитор – он видит несколько серверов лицензий, но они на 5 и 20 лиц, а на 100 не видит. Как его найти?

1 – 23.04.14 – 11:08

несколько подсетей? Алладин без правки nethasp.cfg покажет только сервера в той же подсети.

2 – 23.04.14 – 11:08

3 – 23.04.14 – 11:09

(0) поднять бухгалтерские документы и выяснить кто покупал ключ на 100 лицензий. Если никто не покупал, сделать вывод…

4 – 23.04.14 – 11:12

(3) ену увидит он по документам что ключ покупали и что? вопрос-то останется.

5 – 23.04.14 – 11:18

6 – 23.04.14 – 11:19

Может программные лицензии?

7 – 23.04.14 – 11:21

>>в “справке” указан сетевой ключ 100 лицензий

там всё указыватеся, что когда-либо было

8 – 23.04.14 – 11:36

9 – 23.04.14 – 11:38

>>Нашел админа, который знает, получил ответ – нужно в NetHasp’e принудительно прописывать сервак.

Гениальное знание…

>>Все равно остался вопрос – откуда моя тестовая 1С-ка берет ключи

она берёт оттуда, где видит ключ (в твоей подсети), то что видит аладин монитор.

Что в спарвке указано – не то, ниже промотай, там список длинный.

10 – 23.04.14 – 11:45

11 – 23.04.14 – 11:47

(10) с чистым нетхасп, видимо берёт из 20-ти, который видит аладин монитор

Общеизвестно, что для работы в 1С требуется лицензия. Фирмой 1С поставляются различные ключи защиты: локальные и сетевые. Локальный ключ может быть использован только на одном компьютере, имея вид привычной нам флешки.

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

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

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

Скачать Alladin HASP License Manager для Windows x64 и x32 можно по ссылке.

Для правильной работоспособности менеджера нужно произвести некоторые предварительные настройки. Файл, где вы будете их производить называется nhsrv.ini. Чаще всего его можно найти по адресу «C:Program FilesAladdinHASP LM», если менеджер лицензий установлен в качестве приложения. В противном случае (установлен как сервис) он будет в системном каталоге операционной системы.

Откройте найденный вами файл в любом текстовом редакторе, например, в блокноте и добавьте туда строку:

NHS_IP_LIMIT = 192.168.*.*

Вместо звездочек вы можете проставить любое число от 0 до 254. Так же, если оставить знаки «*», это будет означать, что лицензии будут «видеть» все компьютеры в сети, адрес которых начинается с 192.168.

Например, если в файле nhsrv.ini у вас указана надстройка NHS_IP_LIMIT = 192.168.1.*, то лицензии будут доступны только компьютерам с ip в диапазоне от 192.168.1.0 до 192.168.1.254.

Настройки на клиентских ПК

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

При запуске 1С на пользовательском ПК, программа обращается с запросом на предоставление лицензии по адресу, указанному в файле nethasp.ini. Найти его можно в папке «conf» каталога, куда установлена платформа 1С. В нашем случае адрес следующий: «d:Program Files (x86)1cv8conf».

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

В данном случае подразумевается, что сервер лицензий расположен по адресу 192.168.0.4.

Дано: сервер, на котором активированы лицензии 1С (или планируется устанавливать лицензии на нем и использовать его в качестве сервера лицензирования), а также имеются сервера, где установлены 1С кластеры, которым требуются лицензии.
Задача: распределение 1С лицензий по разным серверам (кластерам). Например, если на сервере лицензирования активирована одна лицензия на 50 пользователей, то нужно, чтобы этими лицензиями могли пользоваться различные 1С серверы/кластеры.

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

В данной статье и в видео будут следующие условные наименования серверов:
Сервер лицензирования – SRV-DB1
Сервер 1С (с установленным кластером) – SRV-NODE-B

Содержание статьи:

• Как получать лицензии с другого сервера (сервера лицензирования)
• Как настроить сервер лицензирования
• Как активировать лицензию на сервере лицензирования

Как получать лицензии с другого сервера (сервера лицензирования)
Если сервер лицензирования (SRV-DB1) уже существует и настроен, то настройка любого другого сервера 1С (в этом примере, SRV-NODE-B) на получение лицензий с сервера SRV-DB1 делается довольно легко. Подробнее смотрите видео ниже.
Краткое описание (все действия выполняем в локальном кластере на 1С-сервере (SRV-NODE-B)):

1. В рабочие серверы добавляем сервер лицензирования (SRV-DB1).
2. В блоке рабочего сервера SRV-DB1 добавляем две функциональности в требования назначения функциональности.
3. В блоке рабочего сервера SRV-NODE-B добавляем две функциональности в требования назначения функциональности.
4. На локальном кластере делаем полное применение требований функциональности.
5. Перезагружаем службу 1С.

После этого сервер SRV-NODE-B начнет получать лицензии с сервера SRV-DB1. Т.е. как серверные, так и клиентские лицензии нужно активировать на сервере лицензирования (о том, как активировать читайте ниже).

Посмотреть, как это делалось, можно в следующем видео-ролике:

Подробное описание:
(все действия выполняем в локальном кластере на 1С-сервере (SRV-NODE-B)):
1) В рабочие серверы добавляем сервер лицензирования (SRV-DB1):

В итоге будет два рабочих сервера SRV-NODE-B и SRV-DB1:

2) В блоке рабочего сервера (сервера лицензирования) SRV-DB1 добавляем две функциональности в требования назначения функциональности.

Функциональности должны быть именно в указанной последовательности.
Добавляем сначала:
Любой объект требования (Для всех) – Не назначать

Затем:
Сервис лицензирования – Назначать

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

3) В блоке рабочего сервера кластера SRV-NODE-B также добавляем две функциональности в требования назначения функциональности.

Функциональности должны быть именно в указанной последовательности.
Добавляем сначала:
Сервис лицензирования – Не назначать

Затем:
Клиентское соединение с ИБ – Назначать

Этим мы говорим, что этот сервер готов отвечать на клиентские вызовы, но лицензии он не содержит.

4) На локальном кластере делаем полное применение требований функциональности.

5) Перезагружаем службу 1С.

Также нужно не забыть про настройки локального FireWall – на сервере 1С (SRV-NODE-B) разрешить входящие-исходящие соединения для сервера лицензирования (SRV-DB1).

Как мы делали сервер лицензирования?
Первоначально у нас был один виртуальный сервер, на котором был установлен 1С кластер. На нем были активированы программная серверная лицензия и программная лицензия на 50 пользователей (соответственно в кластере в информационной базе было указано, чтобы клиентские лицензии выдавались с сервера).
Затем понадобился перенос сервера на другую физическую площадку и было также решено выделить под кластер более производительную виртуальную машину. Поэтому существующий сервер оставили в качестве сервера лицензирования, и создали новый виртуальный сервер под 1С кластер.
Как из обычного сервера сделать сервер лицензирования? Если на нем не будут подключаться информационные базы и он будет использоваться только для лицензий, то в дополнению к вышеуказанным инструкциям нужно сделать только одно действие: удалить локальный кластер на сервере лицензирования (не саму программную серверную компоненту 1С, а именно локальный кластер в оснастке кластера, чтобы в списке кластеров было пусто – это видно на скриншотах и видеоролике, что на сервере лицензирования нет кластеров):

Если это сделать, то сервер лицензирования не будет “отъедать” серверную лицензию (т.е. ему самому вообще никаких лицензий не нужно, он только их хранит для других серверов).

Как активировать лицензию в случае сервера лицензирования?
Для этого на клиенте в любой базе (хоть локальной) зайти в конфигуратор, перейти на интерфейс ввода лицензии, нажать Дополнительно и ввести адрес сервера лицензирования.

Активация ключа на сервере:

В этом случае активация произойдет на сервере лицензирования.
После можно проверить, появился ли файл лицензии в папке на сервере (рекомендуется записать, что за файл – эта информация может понадобиться при восстановлении лицензии – см. статью Восстановление по пин-коду).

UPDATE 16.07.2019
Обнаружилась одна неприятная особенность. По крайне мере быстро решить эту проблему не смогли.
Не удается получить лицензии с выделенного сервера лицензирования в случае, если на серверах стоят платформы разной разрядности (битности).
В нашем случае на сервере лицензирования установлена платформа x64 и с этого сервера успешно получают программные серверные и клиентские лицензии два других сервера с 1С-кластерами, на которых также установлена платформа x64.
На третьем  кластере установлена платформа x86, по причине того, что он использует аппаратный серверный ключ, предназначенный только для x86 1с-сервера. Клиентские лицензии он брал по сети с аппаратного ключа.
Было решено настроить его на получение программных клиентских лицензий с сервера лицензирования по аналогии с другими серверами. Однако при абсолютно такой же настройке кластер ни в какую не захотел получать лицензии.
При подключении клиентам выдавалось сообщение: Поиск лицензии в сервисе лицензирования: Ошибка вызова сервиса лицензирования: Не найдено ни одного сервера с размещенным сервисом serviceName=LicenseService.
Пришлось вернуться к использованию аппаратного ключа с клиентскими лицензии на этом x86 кластере.

Если Вам понравилась статья, пожалуйста, поставьте лайк, сделайте репост или оставьте комментарий. Если у Вас есть какие-либо замечания, также пишите комментарии.

Помимо драйвера ключа на серверы 1С нужно установить службу менеджера лицензий «HASP License Manager» (HASP LM), которая будет раздавать клиентам 1С подключенный к серверу USB-ключ с клиентскими лицензиями.

HASP LM регистрируется на сервере в качестве системной службы HASP Loader с исполняемым процессом nhsrvice.exe, который открывает прослушиватель на порту TCP 475 и отвечает на запросы клиентов, желающих получить клиентскую лицензию.

Скачать инсталлятор «HASP License Manager» последней версии 8.32.5.40 (May 2008) раньше можно было по ссылке с сайта Центр загрузки Sentinel (thales-sentinel.ru) , но теперь эта ссылка не работает. Поэтому мы выложили данный архивный дистрибутив здесь: Aladdin-HASP-License-Manager-8.32.5.40-May-2008.zip

Для тех у кого есть действующая подписка на ИТС 1С, более старую версию «HASP LM» 8.31 от 2007 года на текущий момент времени можно загрузить с закрытого раздела сайта releases.1c.ru.

Мы в своём примере далее будем использовать инсталлятор «HASP License Manager» последней версии 8.32.5.40.

Распаковываем архив и устанавливаем в свойствах инсталлятора lmsetup.exe режим совместимости Windows Vista (Service Pack 2), а также включаем обязательный режим запуска с правами администратора. Это необходимо сделать для успешной работы инсталлятора в Windows Server 2012 R2/2022.

Запускаем инсталлятор и выбираем вариант установки HASP License Manager в режиме службы:

Установка по умолчанию выполняется в каталог C:Program Files (x86)AladdinHASP LM.

Для своей работы HASP LM использует HASP HL Device Driver, который будет установлен попутно.

После успешной установки драйвера может появится странное окошко, в котором мы должны нажать кнопку ОК, в противном случае процесс установки будет висеть в таком состоянии до бесконечности. Такое поведение было замечено при установке на Windows Server 2012 R2, но не воспроизвелось на Windows Server 2022.

Если современные компоненты Sentinel LDK Run-time были установлены в систему до установки HASP LM, то мы можем получить сообщение об отмене установки драйвера более ранней версии из состава HASP LM.

Данное сообщение не приводит к прерыванию установки HASP LM и является более информирующим, нежели говорящем о проблеме.

В конце установки инсталлятор предложит запустить службу «HASP Loader» (исполняемый путь C:Windowssystem32nhsrvice.exe -service) и предупредит, что HASP ключи уже должны быть подключены нами к серверу.

После окончания процесса установки перейдём в системную оснастку управления службами Windows (services.msc). Убедимся в том, что служба «HASP Loader» успешно запустилась, и открыв её свойства, настроим автоматический перезапуск в случае ошибки.

Помимо этого, после установки HASP LM, в документации рекомендовано исключать основной рабочий процесс службы «HASP Loader» (nhsrvice.exe) из действия механизма Data Execution Prevention (DEP).

Для того, что настроить исключение для DEP, откроем свойства системы, например, через панель управления Control Panel > System > Advanced system settings. Перейдём на вкладку расширенных настроек Advanced, затем в разделе Performance нажмём кнопку Settings

В окне Performance Options выберем вкладку Data Execution Prevention и в случае, если включена опция «Turn on DEP for all programs and services except those I select» (настройка по умолчанию), воспользуемся кнопкой Add и добавим в список исключений путь к исполняемому файлу nhsrvice.exe:

• Путь для 32-битной системы: С:Windowssystem32nhsrvice.exe,

• Путь для 64-битной системы: C:WindowsSysWOW64nhsrvice.exe

После этого служба HASP LM должна работать без проблем на Windows Server 2012 R2/2022.

Дополнительно может оказаться полезным добавление процесса HASP LM (nhsrvice.exe) в исключения антивирусного ПО.

Также обратите внимание на то, что инсталлятор HASP LM в ходе установки добавляет в Windows Firewall два правила, разрешающих входящий трафик на порт 475 для протоколов TCP и UDP с любых удалённых адресов. Можно подправить эти правила, например, сузив область адресов, с которых клиенты могут обращаться за лицензией ключей HASP.

Здесь может возникнуть соблазн отключить правило для протокола UDP и ориентироваться в дальнейшей настройке только на работу с протоколом TCP. Однако стоит помнить несколько важных моментов:

• Утилита Aladdin Monitor работает только по протоколу UDP (порт 475) и не позволит мониторить состояние ключей, если в HASP LM протокол UDP выключен или порт UDP 475, прослушиваемый HASP LM, блокируется брандмауэром Windows.

• Есть информация, что платформа 1Сv8 работает с ключами только по протоколу UDP, однако можно попытаться заставить использовать её TCP, но для этого потребуется и на стороне клиента и на стороне сервера HASP LM включать поддержку устаревшего протокола NetBios over TCP/IP (свойства сетевого адаптера > свойства протокола TCP/IP > Properties > Advanced > WINS). На наш взгляд, оно того не стоит.

В общем случае, если сеть между клиентами и сервером HASP LM функционирует нормально, то отказываться от использования протокола UDP в пользу TCP не имеет особого смысла. Подробней об этом можно почитать в старой инструкции Working_with_HASP_and_1C.pdf
 

Чтобы настроить на сервере основную службу «HASP Loader» потребуется отредактировать конфигурационный файл nhsrv.ini.

Так как в нашем случае HASP LM установлен как служба, то, для вступления изменений в силу, настроенный конфигурационный файл nhsrv.ini из каталога установки C:Program Files (x86)AladdinHASP LM нужно будет скопировать в каталог C:WindowsSysWOW64 (для 32-бытных ОС – C:WindowsSystem32) и выполнить перезапуск службы HASP Loader .

Отредактируем на сервере файл следующим образом (приведены только незакомментированные строки):

nhsrv.ini

[NHS_SERVER]
 
NHS_USERLIST    = 1000    ; maximum number of concurrent logins
                          ; to this LM (default=250, max = 65520)
NHS_SERVERNAMES = APP41   ; server names to match the name a client
                          ; requests (max 6 names, max 7 chars/name)
NHS_HIGHPRIORITY = no     ; run LM at high priority (default=no)
 
[NHS_IP]
 
NHS_USE_UDP      = enabled  ; enabled or disabled (default: enabled)
NHS_USE_TCP      = enabled   ; enabled or disabled (default: enabled)
NHS_IP_portnum   = 475       ; IP port number (default: 475 (IANA registered))
 
[NHS_IPX]
 
NHS_USE_IPX       = disabled ; enabled or disabled (default: enabled)
 
[NHS_NETBIOS]
 
NHS_USE_NETBIOS   = disabled  ; enabled or disabled (default: enabled)

Как видно, в секции основных настроек сервера в параметре NHS_USERLIST мы увеличили количество допустимых клиентских сессий с 250 до 1000. В параметре NHS_SERVERNAMES мы задали короткое имя этого сервера (это полезно делать, когда в сети больше одного HASP LM). Ну и наконец, в параметрах NHS_USE_IPX и NHS_USE_NETBIOS мы отключили старые неиспользуемые протоколы.

После того, как настроенным таким образом файл скопирован в системный каталог Windows, нужно перезапустить службу менеджера лицензий HASP LM, например, с помощью PowerShell:

Get-Service "HASP Loader" | Restart-Service

После этого с помощью утилиты netstat убедимся в том, что в системе прослушивается порт 475 по протоколу TCP и UDP:

netstat -na | findstr 0:475

Теперь на нашем сервере мы можем запустить утилиту Aladdin Monitor и убедиться в том, что в нём доступна информация о клиентском ключе HASP. Однако, стоит учесть то, что информация о клиентском ключе будет недоступна, пока к ключу не установлено клиентских соединений.

Позже, после развёртывания кластера серверов 1С и настройке клиентов, утилита Aladdin Monitor пригодится нам для анализа ситуации с получением клиентскими экземплярами 1С:Предприятие клиентских лицензий.

Дополнительные источники информации:

• Установка HASP LM на Linux:

Проверено на следующих конфигурациях:

Автор первичной редакции:
Алексей Максимов
Время публикации: 10.03.2023 12:47