На компьютере стоит однопользовательский ключ USB - опознается, драйвер ставится, горит красным светом :)

Запускаю базу- любую, хоть файловую, хоть клиент- серверную - лицензия используется сетевая

прописываю дополнительные параметры запуска /UseHwLicenses+

- то же самое.
В настройках использовать аппаратную лицензию (ключ защиты) - галка стоит
Платформа 8.3.11.3034

Как можно заставить использовать локальный USB ключ?

Можно в настройках нетхасп прописать неверный адрес,чтобы сервер ключей не виделся.

Этот способ , наверное, все же экзотика.

Помню, я в таком случае в настройках брандмауэра блокировал обращение к сетевому ключу. А иначе - лезет первым делом в сеть.

(2) ну или прописать, чтобы не лез в сеть. Тогда он на локальном компе увидит

(0) а клиентский ПК к серверу случаем не по RDP подключается?

Нет, не по рдп

(5) не, это неважно. Если у него прописан сетевой ключ уже, то ни в какую не хочет. Обращается к сетевому и всё тут. Только хирургическим путем. В нетхасп запретить.

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

(8) сработал .Ура!

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

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

(10)-(11)
комп на ночь выключался, использование локального ключа осталось.

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

у меня нет только варианта клиент- серверной базы без выдачи лицензии - проверить не на чем.

Хз зачем ты все это пишешь. Все логично.
Вопрос сформулируй, если есть.

(13) Я так понимаю, что не устраивает порядок поиска лицензий. Сейчас сначала ищется сетевой ключ, потом локальный. А способа сделать иначе, кроме как через недоступность сетевого ключа, просто нет.

"Сейчас сначала ищется сетевой ключ, потом локальный" // Алгоритм поиска немного другой, и описанный тобою сценарий - просто частный случай для определенного стечения обстоятельств.
И в общем случае сначала всегда ищется локальный ключ. Если он всегда доступен.

(15) Неоднократно наблюдал именно описанное мной поведение. Сначала ищется сетевой, потом локальный. Локальный ключ разумеется доступен, ибо воткнут постоянно.

Ты просто неправильно выражаешь то, что наблюдал

+(15) Возможно, что запросы на ключи идут одновременно по всем направлениям, а не последовательно, и если получен ответ от нетхаспа раньше, чем от локального драйвера - используется он.

С тобой все ясно, к тебе вопросов больше нет

(17) Как это? Есть комп с локальным ключом. Он в сети, на сервере менеджер лицензий. И вот при запуске 1с хватается сетевой ключ. Проверял через aksmon.exe. Если отрубить доступ по сети к ключу через брандмауэр виндовс - используется локальный ключ нормально.

Не знаю о чём вы спорите так, как никто из спорщиков толком не уточняет свою ситуацию (кто раздаёт лицензии, тонкий/толстый клиент, блин даже платформу не озвучивают)

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

В документации пишется что ищется сначала локальный .
Локальный ключ воткнут , не вытаскивается. Как он бывает недоступен?

(20) Это конечно же не является доказательством твоего утверждения "Сначала ищется сетевой, потом локальный". В общем случае поведение мною описано, и оно противоположное.

(22) В том и дело, что на сарае написано "...", а там дрова лежат. Подсистема лицензирования 1с, особенно что касается аппаратной защиты, крива до невозможности.

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

(21) начни с начала (0) . Спора нет. есть вопрос

(22) мой вопрос о том, что это не так.

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

(27) мой вопрос о том, что это не так

(28) См. (19)

(28) Как ищется аппаратный ключ?

(30) И без вас есть с кем поговорит

Просто блокируйте доступ к нетхаспу, если есть локальный ключ. Другого способа нет.

(28) нет, к способу поиска аппаратного тоже относится. У нас такая ситуация была. Два ключа, сетевой и локальный, оба аппаратные. Но локальный только что купили и вставили в комп. Всё равно она тупо продолжает брать сетевую лицензию, по накатанной, может у нее в кеше где-то это записано. И плюет на документацию.

"плюет на документацию" // Можешь ссылку / фрагмент, с которым тебе кажется, что поведение не соответствует описанному?

(26) Sorry, это я не Вам писал.

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

(35) ну там ни веб-камеры ничего не было. Записи не вели. Это на удаленном офисе, купили новый ключ, вставили. Какой фрагмент?

(37) Документации. "плюет на документацию" ты пишешь.

(38) это я взял у (22). Мы переписываемся с (22) и (25). (22) пишет что в документации так, я ему отвечаю, что у меня не такю

(34) "Всё равно она тупо продолжает брать сетевую лицензию" - имхо, такое поведение нормально, это описано в документации. При запуске сначала делается попытка по последнему, ранее использованному, удачному подключению лицензии.

(39) Витиевато. Так и не понял, считаешь ли ты наблюдаемое тобою поведение не соответствующим документации или не считаешь. Ну да ладно.

(офф)
В (22) есть тонкий "нюанс" - автор спрашивает "Как он бывает недоступен?". Термин "недоступен" - это интересный термин :) Это несколько иное, чем "не использован". Даже "не используется" - это другой нюанс, оттенок, другой вопрос...

PS: да, я такой, буквоед и зануда временами :)

(41) ну у меня нет времени искать в документации, самому проверять. Если люди пишут, я верю. Они же уже посмотрели.

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

Конечно же можно попробовать очистить кэши базы - но мы же не ищем лёгких путей.

И да, не принимайте серьёзно мою манеру общения на свой счёт.

(44) всё-таки лучше в нетхасп-ини отключить поиск сетевого ключа. Тогда не будет ситуации как в (10)

"Алгоритм поиска лицензий при запуске «1С:Предприятие» 8.3"
http://tavalik.ru/algoritm-poiska-licenzij-pri-zapuske-1spredpriyatie-8-3/ с картинками :)

(46) Угу. Можно даже драйвер защиты в 1С не устанавливать/снести.

(48) объяснение (0) - первым идет поиск по последнему удачному подключению.

Запрети поиск сетевых ключей, пусть видит только локальный

(50) "Доктор, это был вопрос?"(цы). Да, не исключено. Попытка по последнему удачному подключению - она безусловная впереди проверки настроек.

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

Вот как-то вот так.