можно ли заблокировать поиск аппаратного сервером (8.3), установленного на том же сервере физически, что и сам сервер 1с, что бы не раздавать лицензии сервером 1с, но при этом сам сервер 1с остается на раздаче софтовых лицензий.
а аппаратный ключ забирают клиенты через nethasp.

(0)

(1)+ Поднять виртуалку на сервере, пробросить туда USB ключ
Он перестанет видеться сервером 1С
В виртуалке поднять и настроить HASP Licence Manager
Через NETHASP.INI и NHSRV.INI настроить запрет для сервера и разрешение для клиентов

(0) Самый лучший вариант перенести ключ на другую машину и запретить к ней доступ по сети серверу 1с.

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

(2) этот сценарий я рассматриваю, как запасной если не получится на локальном сервере запретить. получается сервер 1с обращается к ключу через драйвер напрямую?
попутный вопрос, у меня софтовые лицензии связаны (привязка при активации) с хаспом, при таком раскладе (отдельный сервер + запрет в INI) если сервер 1с перестанет их видеть (для раздачи), софтовые тоже отвалятся ?

(4) >получается сервер 1с обращается к ключу через драйвер напрямую?

всё верно
и нет каких-то настроек, которые бы запретили это серверу делать, кроме как полностью отключить раздачу лицензий сервером, но тогда и программные перестанут раздаваться

>софтовые лицензии связаны (привязка при активации) с хаспом, при таком раскладе (отдельный сервер + запрет в INI) если сервер 1с перестанет их видеть (для раздачи), софтовые тоже отвалятся ?

программные отвалятся, т.к. сервер не сможет проверить привязку,
надо будет перепривязать к параметрам сервера

(0) а в чем цель затеи?
по алгоритму сервер начнёт раздавать лицензии с ключа в последнюю очередь,
1. сначала клиенты будут пытаться получить лицензию с ключа сами от HASP LM,
2. потом сервер будет раздавать программные лицензии,
3. и только если закончатся все лицензии доступные предыдущими способами сервер начнёт раздавать с ключа, а в этом момент на ключе свободных лицензий скорее всего уже не будет, т.к их выберут клиенты от HASP LM

(6) цель затеи оптимизировать распределение ключей
сейчас есть 3 софтовые лицензии и 1 хардовая.
юзеры (бОльшая часть) сидят на терминалках. лицухи все активированы на сервере 1с (физическом) там же торчит ключ.
сталкиваюсь с тем что у меня все наоборот - сервер раздает лицензии с хардового ключа в "неоптимальном" варианте. алгоритм мне до конца не понятен. приведу пример, утром я вырубаю раздачу лицензии сервером, и ребутаю службу хаспа. единственный способ получения лиц через LM, потом когда ключ исчерпывается, я включаю раздачу сервером - пошла раздача софтовых. получается картина, например, 80% выдано через LM , остальные сервером. но со временем эта картина меняется, баланс уходит в сторону раздачи сервером в т.ч. с хаспа.

(7) программные лицензии привязаны к "железу" или к аппаратному ключу?

(7) почему постепенно "съезжает" на выдачу лицензий сервером понятно - это универсальный вариант, который обеспечивает получение лицензий клиентом при любом способе подключения и с любого источника (как с программной лицензии, так и с USB), а в следующий раз (в соответствии с алгоритмом поиска лицензии) сначала выполняется попытка получения лицензии из того файла программной лицензии или ключа защиты HASP, откуда лицензия была получена при последнем успешном подключении...
описание алгоритмов поиска лицензий для разных сценарев есть здесь https://www.online-ufa.ru/content/articles/1c-license-search/

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

(10)>к аппаратному многопользовательскому ключу.

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

(10)>а можно привязать к серверному ?

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

(12) чем больше ответов тем больше вопросов)...
я правильно Вас понимаю, что от того какого вида ключ участвует в привязке меняется схема раздачи лицензии ?

а как клиенты могут использовать лицензию "сами"? у меня терминалка (rds ферма из кучи терминалок) и сервер 1с физически разные платформы. я полагаю что клиенты по рдп могут получать только через сервер.

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

Все не читал. Снять флаг "раздавать лицензии сервером" уже предлагали?
PS: Прочитал.

(13)>я правильно Вас понимаю, что от того какого вида ключ участвует в привязке меняется схема раздачи лицензии ?

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

>клиенты по рдп могут получать только через сервер.

если лицензия на терминальном сервере, то сначала клиенты будут пытаться получить ее сами, а не от сервера 1С

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

если у вас лицензии раздает только сервер 1С, всегда и всем клиентам, то можно привязать к серверному ключу,
НО если бы лицензии раздавал только  сервер 1С, то такой проблемы не должно было возникнуть вовсе и проблема с "баланс уходит в сторону раздачи сервером" в (7) мне непонятна, о каком балансе тогда речь?

я так и не понял (6) а в чем цель затеи?
у вас не хватает лицензий?

(13) программные лицензии нельзя раздавать ("на клиента") через некий менеджер (аля HASP License Manager)
только "на сеанс" через сервер 1С (или модуль расширения веб-сервера)
или напрямую получают ("на клиента") с компа где запущен клиент 1С

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

(16) да, не хватает, когда лицензии аппаратного ключа раздает сервер 1с, сгорает бонус одновременного запуска нескольких 1с под одной лицензией. а таких, кто запускает много 1с прилично.

(17) все верно, у меня 10 терминалок в ферме а ключей 3.

(18) так если лицензии раздает сервер 1С:Предприятия, то лицензия ВСЕГДА выдается на каждый запуск, программная или USB и способ подключения в этом случае значения не имеет

(20) верно, а если лицензию выдает LM, то лицензия выдается на сессию. при наличии на сервере включенной опции "разрешать выдачу лицензии" и видимости сетевого ключа в сети какую лицензию получит клиент ? с сервера 1с или с LM ? согласно алгоритмам которые в сети в т.ч. по вашей ссылке, у меня все лицензии должны быть выданные сервером,
"...В соответствии с алгоритмом сначала будут использоваться программные лицензии и только потом аппаратные ключи."
, но я наблюдаю другую картину.
я ведь правильно понимаю что лицензия с префиксом "Клиент..." в таблице "сеансы" в консоли кластера это лицензия полученная через LM ?

(21)>при наличии на сервере включенной опции "разрешать выдачу лицензии" и видимости сетевого ключа в сети какую лицензию получит клиент ? с сервера 1с или с LM ? согласно алгоритмам которые в сети в т.ч. по вашей ссылке, у меня все лицензии должны быть выданные сервером,

читайте внимательнее
как будет осуществляться поиск лицензий в вашем случае я уже написал еще в (6):

1. сначала клиенты будут пытаться получить лицензию с ключа сами от HASP LM,
2. потом сервер будет раздавать программные лицензии,
3. и только если закончатся все лицензии доступные предыдущими способами сервер начнёт раздавать с ключа

(22) как то противоречиво все. в (6) вы пишите одно а в (9) даете ссылку где все наоборот. хорошо, допустим, это:

>1. сначала клиенты будут пытаться получить лицензию с ключа сами от HASP LM,

...работает, то как тогда объяснить наличие выданных лицензий с хаспа сервером в оптовом количестве?

(23)>как то противоречиво все. в (6) вы пишите одно а в (9) даете ссылку где все наоборот

всё по алгоритму:

3.Порядок поиска клиентской лицензии при запуске клиент-серверной базы...
3.1. На компьютере с клиентским приложением:

- Выполняется поиск по сети многопользовательского ключа HASP, доступного с помощью программы HASP License Manager

3.2. На компьютере менеджера кластера, на который назначен сервис сеансовых данных:
- Выполняется поиск программных лицензий на компьютере менеджера кластера сервера "1С:Предприятия";
- Выполняется поиск ключей HASP, установленных на компьютере менеджера кластера сервера "1С:Предприятия";

всё как 1, 2, 3 в (6)

(23)>как тогда объяснить наличие выданных лицензий с хаспа сервером в оптовом количестве?

это сложнее,
скорее всего виноват первый пункт во всех сценариях:

- Выполняется попытка получения лицензии из того файла программной лицензии или ключа защиты HASP того же типа (серия, сетевой или локальный), откуда лицензия была получена при последнем успешном подключении;

почему лицензии "перетекают" на раздачу сервером описал в (9)

Winnie Buh, не подскажите где найти этот журнал ?

Рекомендуется размещать файл nhsrv.ini, если это необходимо, в каталоге, в котором размещается исполняемый файл HASP License Manager. Проверка того, что HASP License Manager нашел и прочитал файл конфигурации, можно с помощью журнала Activity Log/Server Activity Log.

(26) Перенеси уже ключ на другую машину, сервер его не будет раздавать.

правда все равно нельзя будет однозначно заставить (в общем случае) конкретных пользователей получать лицензии с ключа, а некоторых с сервера 1с

(27)
>правда все равно нельзя будет однозначно заставить (в общем случае)

я давно подозревал что 1с использует квантовые алгоритмы, и нельзя однозначно определить будет ли выдана лицензия или нет. все по Шредингеру.

(26) ни разу не пользовался
зачем он понадобился?

(29) да хотел поиграться с настройкой самого HASP LM, но столкнулся с этим загадочным журналом, про который много где написано.

(40) в журнале будет только отметка о прочтении файла nhsrv.ini + если ключ локально на той же машине, где сервер 1С, то настройки HASP LM значения не имеют

(31) так а где найти этот журнал то ?

(32) путь указывается с помощью параметра LOG DIR = конфигурационного файла
по умолчанию здесь
C:\Program Files (x86)\SafeNet\Sentinel HASP Server\Servers\Sentinel HASP Server\logs

(33) у меня даже папки такой нет. файл про который я писал является конфигом службы C:\Windows\system32\nhsrvice.exe.

(34) забей, всё равно там нет ничего полезного,
не припомню, чтобы возникали сомнения в чтении файла nhsrv.ini и для этого нужно было какое-то подтверждение
+ при одном ключе его особого смысла трогать нет (за исключением ключей на 300 и 500 раб.мест)

(35) у меня как раз ключ на 300. просто из принципа уже хотел понять что это за таинственный журнал про который гилев и ко пишут, а найти его нельзя.
P.S. забил
P.P.S. а серверный ключ за пределами физической установки (на другом сервере) должен видеться при активации софтовых лиц ? что бы к нему привязку сделать. У меня не видится.

(37)>у меня как раз ключ на 300

если HASP LM раздаёт с этого ключа все 300 лицензий, а не 250 по-умолчанию, то nhsrv.ini 100% был прочитан

>хотел понять что это за таинственный журнал про который гилев и ко пишут, а найти его нельзя.

это как Неуловимый Джо, никто его поймать не может, т.к. нафиг никому не нужен

>серверный ключ за пределами физической установки (на другом сервере) должен видеться при активации софтовых лиц ? что бы к нему привязку сделать. У меня не видится.

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

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

>нет, серверный ключ локальный, его видно только на той машине, на которой стоит, по сети не раздаётся,
привязать к нему можно только если программную лицензию активировать непосредственно на том сервере, где установлен ключ

понял спасибо

(38) по привязке лицензий к USB советую https://www.online-ufa.ru/content/articles/binding-license-1c-to-usb/
особенно в конце статьи есть "нюансы", рекомендации и FAQ - большинство ответов на поднимавшиеся здесь вопросы там уже были

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

(40)+ Одновременная работа понятно не должна быть возможна
Но можно ли по очереди? С учетом времени освобождения занятых лицензий

(40) в общем случае нет, должна быть ошибка: "Продукт с регистрационным номером 810*******G0 допускает одновременное использование не более 1 пинкодов"
даже если запускать НЕ одновременно
если совсем заблокировать доступ, то перестанет видеть ключ,
можно попробовать пошаманить с настройками фаервола, т.к. поиск аппаратного ключа происходит по UDP 475, а поиск дубля лицензии по UDP 1540

(42) второй пин код не использовали
просто лицензию скопировали

(43) может текст ошибки будет другой, но лицензия все равно должна блокироваться имхо

(44) где и как она блокируется?
сам ключ нельзя - он используется только для привязки
получается у HASP LM есть возможность "полузанятия" ключа по некоему общему идентификатору

(45)>где и как она блокируется?

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

>получается у HASP LM есть возможность "полузанятия" ключа по некоему общему идентификатору

при проверке привязки к ключу проверяется наличие свободной лицензии в HASP LM, лицензия в этот момент занимается на 1 сек., проверка осуществляется регулярно, но не чаще раза в 20 сек. (более точной информации по таймингу проверки в документации нет)

+ будет время и возможность - попробую проверить )
тратить свои лицензии на это как-то не хочется

(46) Вероятно другие (отличные от основного для ключа) Product и Feature
Т.е. изначально предусмотрено что один ключ HASP может использоваться для разных продуктов и видов лицензий (фич)

(48) если речь о возможностях ключей HASP версии Pro, то да, такой функционал в теории у них есть, но это уже аладдиновская история и 1С в своих продуктах такую возможность не использует,
привязка программных лицензий к ID ключей - это свое решение от 1С, которое с функциональностью ключей никак не связано