Всем доброго времени суток! В нашей организации стоит сервер, в нем стоят 4 HASP-ключа: 1 с серверной лицензией, 2 ключа на 5 рабочих мест, 1 ключ на 10 рабочих мест. Клиентские ПК никак не хотят брать лицензии с ключей на 5 рабочих мест (с ключа на 10 кое-как берёт, через раз), собственно очень часто пользователям вылетает, что нет лицензий. Как настроить так, чтоб лицензии брались со всех ключей? Вообще возможно ли это?
Прикрепленные файлы:




По теме из базы знаний
- Подключение из Windows7 к удаленной ИБ 1C8
- Установка ключей защиты КАТРАН для конфигурации 1с 8.1 "Автоматизированный сервисный центр"
- Установка терминального сервера на базе Ubuntu Server 12.04 LTS 64-bit для работы c платформой 1C 8.3.
- Распространение nethasp.ini групповыми политиками
- PostgreSQL + 1С Сервер + Windows Server 2012 R2
Найденные решения
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(3) При установке нескольких клиентских HASP ключей одной серии в одну машину работать должен только один из них, рандомно.
Все ключи от 1 до 100 рабочих мест относятся к одной и той же серии ORGL8. Исключение составляют только ключи на 300 и 500 рабочих мест.
А сервером 1С еще интереснее - он не будет раздавать лицензии с третьего ключа, даже если их разнести по разным машинам.
Все ключи от 1 до 100 рабочих мест относятся к одной и той же серии ORGL8. Исключение составляют только ключи на 300 и 500 рабочих мест.
А сервером 1С еще интереснее - он не будет раздавать лицензии с третьего ключа, даже если их разнести по разным машинам.
По сабжу - можете поменять два клиентских HASP ключа на программные лицензии (или все три ключа 5+5+10 на одну программную на 20 раб.мест), тогда сможете все лицензии установить на один сервер, у программных нет подобного ограничения по установке нескольких лицензий на одной машине.
(11) только не забывайте, что через NetHasp License Manager, как у вас на картинке показано, аппаратный ключик раздается одна лицензия на один компьютер пользователя, и не важно, сколько у пользователя запущено баз. Даже если у пользователя открыто две-три базы одновременно, через HASP LM потребляется одна-единственная лицензия.
А когда вы обменяете свои аппаратные ключи на программные лицензии, то (если вы их (программные) поставите на сервер и будете раздавать через сервер) то у вас будет потребляться одна лицензия на одну базу. То есть, если у пользователя будет открыто две-три базы одновременно, то и потребляться будет соответственно две-три программные лицензии.
Любят франчи об этом нюансе умалчивать. :)
Соответственно, в качестве примера, предположим, у вас сейчас 20 пользователей. (по количеству ключей hasp). Каждый пользователь открывает три базы одновременно. Соответственно, всего открыто 60 баз. Теоретически (если аппаратные ключи разнести на разные компьютеры и раздавать раздельно с трех компов каждый через свой HASP LM), то ваших ключей 5+5+10 хватит на всех.
А вот если обменять на программные и раздавать их (программные) через сервер, то вам понадобится 60 (шестьдесят!) программных лицензий.
Если у вас есть компьютеры, которые работают в режиме как пользователи, а в остальное время им ключи не нужны, то я бы просто оставил один ключик на 10 пользователей на сервере и раздавал его через HASP LM, как и раньше, а остальные два 5-ти пользовательских поставил бы раздельно каждый на отдельный [привилегированный] пользовательский компьютер и раздавал бы их каждый через свой HASP LM раздельно. К примеру, бухгалтерия работает в режиме с 9 до 18 пн-пт, а в остальное время ключи им не нужны. То я бы поставил 5-ти пользовательский на комп главбуха и раздавал бы его отдельно для бухгалтерии через отдельный HASP LM. Все настраивается через nethasp.ini.
Вариантов много, самый плохой (в смысле по цене) вариант - это если вам вам может понадобиться программных лицензий значительно больше, чем сейчас аппаратных.Нет, сам по себе вариант то нормальный (обменять аппаратные на программные), только по цене может быть значительно дороже.Тут надо посчитать, сколько вам может понадобиться программных лицензий.
Но ведь может и не понадобиться сверх имеющихся 20.
Я же вашу ситуацию не знаю. Может, у вас нет по три открытых базы на каждого пользователя :)
А когда вы обменяете свои аппаратные ключи на программные лицензии, то (если вы их (программные) поставите на сервер и будете раздавать через сервер) то у вас будет потребляться одна лицензия на одну базу. То есть, если у пользователя будет открыто две-три базы одновременно, то и потребляться будет соответственно две-три программные лицензии.
Любят франчи об этом нюансе умалчивать. :)
Соответственно, в качестве примера, предположим, у вас сейчас 20 пользователей. (по количеству ключей hasp). Каждый пользователь открывает три базы одновременно. Соответственно, всего открыто 60 баз. Теоретически (если аппаратные ключи разнести на разные компьютеры и раздавать раздельно с трех компов каждый через свой HASP LM), то ваших ключей 5+5+10 хватит на всех.
А вот если обменять на программные и раздавать их (программные) через сервер, то вам понадобится 60 (шестьдесят!) программных лицензий.
Если у вас есть компьютеры, которые работают в режиме как пользователи, а в остальное время им ключи не нужны, то я бы просто оставил один ключик на 10 пользователей на сервере и раздавал его через HASP LM, как и раньше, а остальные два 5-ти пользовательских поставил бы раздельно каждый на отдельный [привилегированный] пользовательский компьютер и раздавал бы их каждый через свой HASP LM раздельно. К примеру, бухгалтерия работает в режиме с 9 до 18 пн-пт, а в остальное время ключи им не нужны. То я бы поставил 5-ти пользовательский на комп главбуха и раздавал бы его отдельно для бухгалтерии через отдельный HASP LM. Все настраивается через nethasp.ini.
Вариантов много, самый плохой (в смысле по цене) вариант - это если вам вам может понадобиться программных лицензий значительно больше, чем сейчас аппаратных.Нет, сам по себе вариант то нормальный (обменять аппаратные на программные), только по цене может быть значительно дороже.Тут надо посчитать, сколько вам может понадобиться программных лицензий.
Но ведь может и не понадобиться сверх имеющихся 20.
Я же вашу ситуацию не знаю. Может, у вас нет по три открытых базы на каждого пользователя :)
(9) От разрядности сервера зависит? Есть, например, 2 сервера. Один - x64, другой - x32. Железный ключ клиентских лицензий будет работать на оба сервера. А программный клиентский только с сервером аналогичной разрядности?
Может проще раскидать ключи по разным ПК и изменить nethasp.ini на ПК?
Может проще раскидать ключи по разным ПК и изменить nethasp.ini на ПК?
(13)
Если пользовательские ключи (клиентские лицензии) раздаются через HASP LM и потребляются конечными пользователями, то сервера (что 64, что 32) тут вообще ни с какого бока. Вот от слова вообще. Клиент запустился, получил лицензию от HASP LM (один раз!), и неважно, какую (какие) базы запускает этот клиент - хоть от 64х сервера, хоть от 32х сервера, хоть локально лежащую у клиента на компе базу - не колышет. Клиентская лицензия получена на комп, получена от HASP LM, и используется для всех подключений этого клиента ко всем базам. За одним исключением - подключения через браузер. Там по-любому веб-сервер лицензиями заведует.
Нет, конечно, если [от великого ума] аппаратные ключи раздавать через сервер 1С, а не через HASP LM... Ну это необходимо в случае, когда у тебя пользователи подключаются откуда из внешней сети (из интернета) и доступа к локальной сети (точнее к HASP LM) не имеют. В противном случае (если у тебя все компы в одной локальной сети и не подключаются к базам через браузеры) раздавать аппаратный ключ через сервер 1С, а не через менеджер лицензий LM - бессмысленно, я даже скажу - вредно Не имеет смысла в этом варианте просто так тратить аппаратные лицензии в случае подключения к нескольким базам одновременно.
Есть, например, 2 сервера. Один - x64, другой - x32. Железный ключ клиентских лицензий будет работать на оба сервера.
Вот вообще по барабану на сервера.
Если пользовательские ключи (клиентские лицензии) раздаются через HASP LM и потребляются конечными пользователями, то сервера (что 64, что 32) тут вообще ни с какого бока. Вот от слова вообще. Клиент запустился, получил лицензию от HASP LM (один раз!), и неважно, какую (какие) базы запускает этот клиент - хоть от 64х сервера, хоть от 32х сервера, хоть локально лежащую у клиента на компе базу - не колышет. Клиентская лицензия получена на комп, получена от HASP LM, и используется для всех подключений этого клиента ко всем базам. За одним исключением - подключения через браузер. Там по-любому веб-сервер лицензиями заведует.
Нет, конечно, если [от великого ума] аппаратные ключи раздавать через сервер 1С, а не через HASP LM... Ну это необходимо в случае, когда у тебя пользователи подключаются откуда из внешней сети (из интернета) и доступа к локальной сети (точнее к HASP LM) не имеют. В противном случае (если у тебя все компы в одной локальной сети и не подключаются к базам через браузеры) раздавать аппаратный ключ через сервер 1С, а не через менеджер лицензий LM - бессмысленно, я даже скажу - вредно Не имеет смысла в этом варианте просто так тратить аппаратные лицензии в случае подключения к нескольким базам одновременно.
(13)
А клиентские лицензии вообще разрядности не имеют. Это просто клиентские лицензии. На минуточку, их (программные лицензии) можно же активировать и на каждый пользовательский комп отдельно. И неважно, какие базы ты будешь запускать на таком компе. Хоть лежащие на 32х сервере, хоть на 64х сервере.
А хочешь - вообще файловые, лежащие локально на этом пользовательском компе [с одной активированной программной лицензией]. Причем тут разрядность? сервера?
А программный клиентский только с сервером аналогичной разрядности?
А клиентские лицензии вообще разрядности не имеют. Это просто клиентские лицензии. На минуточку, их (программные лицензии) можно же активировать и на каждый пользовательский комп отдельно. И неважно, какие базы ты будешь запускать на таком компе. Хоть лежащие на 32х сервере, хоть на 64х сервере.
А хочешь - вообще файловые, лежащие локально на этом пользовательском компе [с одной активированной программной лицензией]. Причем тут разрядность? сервера?
(15) мне не понятна Ваша экспрессия:
Ну, и у ТС ничего не сказано про "подключения через браузер".
Технология использования программной защиты 1С поддерживается для платформы 1С:Предприятие 8.2, начиная с версии 8.2.13, и для платформы 1С Предприятие 8.3. Для версий 1С Предприятие 8.1 или 8.0 следует использовать аналогичные лицензии 1С 8 с аппаратной защитой HASP.
Ну, и у ТС ничего не сказано про "подключения через браузер".
(16)
Если программную лицензию можно использовать вообще безотносительно сервера, локально на одном компе - о какой разрядности (сервера) вообще может идти речь?
Это что у Вас за вопрос, о чем:
мне не понятна Ваша экспрессия:
А вот мне абсолютно непонятен Ваш вопрос про разрядность программной клиентской лицензии (да еще в привязке к разрядности сервера). :)))
Если программную лицензию можно использовать вообще безотносительно сервера, локально на одном компе - о какой разрядности (сервера) вообще может идти речь?
Это что у Вас за вопрос, о чем:
"А программный клиентский только с сервером аналогичной разрядности?"
(22) Я тоже против обмена USB на программные без необходимости.
В данном конкретном кейсе можно раскидать клиентские ключи по разным машинам в сети, как советует I love pivo, но работать это будет только в случае, если все пользователи будут запускать базы Толстым/Тонким клиентом 1С + есть техническая возможность на клиентских ПК получить лицензию самим от HASP LM, а не от сервера 1С. Если же лицензии будет раздавать сервер 1С:Предприятия, то третий ключ он никак не увидит.
В данном конкретном кейсе можно раскидать клиентские ключи по разным машинам в сети, как советует I love pivo, но работать это будет только в случае, если все пользователи будут запускать базы Толстым/Тонким клиентом 1С + есть техническая возможность на клиентских ПК получить лицензию самим от HASP LM, а не от сервера 1С. Если же лицензии будет раздавать сервер 1С:Предприятия, то третий ключ он никак не увидит.
(24)
Нет, ты не озвучил этот вариант в этой ветке первым
Ты нагло спионерил это вариант у меня, потому что я первый в этой ветке сказал еще в [12]
А все, что после этого - наглый плагиат в этой ветке.
Именно такой вариант я и озвучил - раскидать ключи по ПК.
Нет, ты не озвучил этот вариант в этой ветке первым
Ты нагло спионерил это вариант у меня, потому что я первый в этой ветке сказал еще в [12]
Теоретически (если аппаратные ключи разнести на разные компьютеры и раздавать раздельно с трех компов каждый через свой HASP LM), то ваших ключей 5+5+10 хватит на всех..
А все, что после этого - наглый плагиат в этой ветке.
(20)
Я некрофилией не занимаюсь :)))
1С уведомила о прекращении поддержки 1С:Предприятия 8.1 с апреля 2011 года (последняя версия 8.1.15.14, выпущена в октябре 2009).
Я понимаю тех, кто до сих пор сидит на 7.7. Переписанная в хлам ТИС 7.7 работает и прекрасно работает.
7.7 радикально отличается от 8.х и иногда переход на 8.х требует просто колоссальных затрат и тупо экономически невыгоден.
Но я откровенно не понимаю тех, кто сидит на 8.1. Платформа 8.1 - это всего
лишь промежуточная в шеренге платформ 8.х (от 8.0 до 8.5), и зачем на ней промежуточной до сих пор сидеть - хоть убей, не знаю.
Ваш вопрос чисто теоретический и вдобавок из области некрофилии, отвечать на него - хм...Как я уже сказал - некрофилией не страдаю.
Подумать только - привести в пример платформу, которая умерла 1/7 часть столетия назад. А ведь совсем скоро (время пролетит не заметишь) будет и четверть века, как эта платформа снята с поддержки. Для IT-технологий такая древность - это все равно что мезозойская эра для археологов.
есть сервер 1С Предприятие 8.1
Я некрофилией не занимаюсь :)))
1С уведомила о прекращении поддержки 1С:Предприятия 8.1 с апреля 2011 года (последняя версия 8.1.15.14, выпущена в октябре 2009).
Я понимаю тех, кто до сих пор сидит на 7.7. Переписанная в хлам ТИС 7.7 работает и прекрасно работает.
7.7 радикально отличается от 8.х и иногда переход на 8.х требует просто колоссальных затрат и тупо экономически невыгоден.
Но я откровенно не понимаю тех, кто сидит на 8.1. Платформа 8.1 - это всего
лишь промежуточная в шеренге платформ 8.х (от 8.0 до 8.5), и зачем на ней промежуточной до сих пор сидеть - хоть убей, не знаю.
Ваш вопрос чисто теоретический и вдобавок из области некрофилии, отвечать на него - хм...Как я уже сказал - некрофилией не страдаю.
Подумать только - привести в пример платформу, которая умерла 1/7 часть столетия назад. А ведь совсем скоро (время пролетит не заметишь) будет и четверть века, как эта платформа снята с поддержки. Для IT-технологий такая древность - это все равно что мезозойская эра для археологов.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот