Мониторинг программных лицензий. Проблема обнаружения ключа клиентом

• Tutorial

Во многих компаниях в качестве основной платформы автоматизации используется 1С. Так повелось и у нас. Однако процесс становления платформы был произведен без должного подхода, в связи с чем сначала у нас было 5 ключей защиты на 95 лицензий, затем появилось еще 3 физических ключа на предоставление еще 50 клиентских лицензий для 3-х юридических лиц. Ситуация дурацкая, так как каждый ключ по нормальному требует отдельных хост, а подходящих для этого серверов становилось все меньше, а маячащее увеличение количества пользователей и, следовательно, покупки новых ключей, заставило меня задуматься над альтернативным решением, позволяющим избежать лишней информационной нагрузки на наши сервера и вообще сделать систему с ключами более гибкой и, желательно, более устойчивой.

Выбор системы

Система виртуализации

В качестве системы визуализации был выбран esxi 5.1. Выбран за неплохую поддержку переброски USB устройств и потому что кроме ESX я разбираюсь только в Hyper-V, переброску устройств который не поддерживает.

Для переброски USB устройств в ESX, железо гостевой системы должно быть не ниже версии 7. Тогда появится возможность добавить USB контроллер и примаппить USB устройство в гостевую систему. Еще есть момент по поводу поддержки. Официально VMware поддерживает только определенный список устройств. И он не очень то большой. Однако рядовые ключи защиты Aladdin, похоже, будут поддерживаться. Список поддерживаемых устройств есть на официальном сайте . А описание требований и положений по береброске USB в гостевую систему есть также на официальном сайте, в базе знаний .

Есть и альтернативные способы проброски USB ключей в виртуальную среду, да и в физическую тоже. Это устройства и ПО так называемое USB over IP. Программные продукты в данном случае не очень интересно рассматривать, а вот железные в этом случае неплохо себя показывают. Самый яркий представитель, всем известный AnywhereUSB с 14-ю портами. Устанавливается в стойку, имеет два интерфейса и два входа питания (имеет ли реально два блока питания, я не знаю:)). Устройство всем хорошо, но стоит в среднем 60 тысяч рублей, что плохо укладывалось в наш бюджет.

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

Операционная система и драйвера HASP

В качестве ОС я выбрал Debian. Почему? Да просто так. По сути в этой конфигурации можно взять любой любимый дистрибутив. Но Debian мне всегда нравится стабильностью и хорошим репозиторием.

В качестве драйверов берется достаточно популярный пакет от компании Etersoft . Взять скомпилированный пакет для своего дистрибутива можно на FTP сервере компании: ftp.etersoft.ru/pub/Etersoft/HASP/stable .
После установки пакета появляется служба haspd , которая и управляет работой ключа.

Настройка и проверка

Какой-то дополнительной настройки все это не требует. Ключ начинает работать практически из коробки.
Проверяем. Для проверки работоспособности в комплекте имеется программа haspdemo . При успешной идентификации ключа и начала работы, программа выведет что-то подобное в консоль:

LOCALHASP_ISHASP: Result: 1

Using Passwords 15213 - 28875
LOCALHASP_HASPSTATUS: API version number is 8.0
port number 201
Key type: HASP4 M4
LOCALHASP_HASPGENERATION: OK, HASP4 is connected.
LOCALHASP_HASPNETSTATUS: connected key is HASP4 Net 20
MEMOHASP_HASPID: 436444258 (decimal), 0x1a039c62 (hex)

LOCALHASP_ENCODEDATA: OK.
53 C1 F1 AF | EC 16 C3 15 | 35 31 E4 7F | 9B D0 90 9F
AA BA 8C 80 | 1E 22 29 E2 | 92 7E 04 56 | DA 70 7B 63 [.....")..~.V.p{c]
23 B4 9B E6 | 2F 17 | | [#.../.]

NETHASP_READBLOCK: Failed: Return status: 10

Главное поле: LOCALHASP_ISHASP: Result: 1 . Сообщающее, что все впорядке. Далее написано и про то, какой ключ вставлен.

Однако если есть какая-то проблема, то сообщение выводится покороче:

This is a simple demo program for the HASP4 key
Copyright Aladdin Knowledge Systems Ltd.

LOCALHASP_ISHASP: Failed: status = -100

При том по сути все равно что происходит с ключом, он может быть не вставлен, служба может быть не запущена или еще что-то. Я пока видел только два значения LOCALHASP_ISHASP. Это либо: Result: 1 , либо: Failed: status = -100 . И последнее всегда соответствовало неработоспособности, а первое всегда означало, что все ОК. Документации к этому пакету я не нашел, по этому узнать какие еще есть статусы не получилось.

С ключом разобрались. Надо не забывать, что в мониторе ключей ваш новоиспеченный ключ появится только тогда, когда с него будет взята хотя бы одна лицензия. Тогда aladdin monitor покажет ту информацию, которую он обычно показывает: это типа ключа, количество взятых лицензий, всего лицензий, кто именно забрал лицензию и таймаут.
Форсировать это достаточно просто, достаточно указать в клиентском nethasp.ini руками новый менеджер лицензий. Но о настройке клиента чуть-чуть позже.

С этого момента можно считать первоначальную задачу выполненной. Теперь мы можем создать параллельно несколько виртуалок, в количестве, соответствующем количеству имеющихся физических ключей. Ресурсы такие виртуалки потребляют, естественно, копеечные.

Проблемы и решения

Единая точка отказа

Первая проблема, которая создается и у всех на виду, это создание точки отказа. Если до этого ключи были распределены по различным серверам и отказ больше одного ключа практически исключен, то в данном случае отказ работы физического сервера может повлечь за собой отказ от работы всей системы 1С, т.к. клиенты будут отваливаться в течение, по-моему, 600 секунд и через непродолжительное время отвалятся все и не смогут вернуться в систему. Что последует за таким инцидентом можно не рассказывать. Вариантов решения два и направлены в разном направлении. Первое решение это использование отказоустойчивой конфигурации ESX. Однако это целесообразно, если в вашей компании эта система уже развернута и уже выполнен ряд требования для поддержания работоспособности при отказе любого компонента. Другое решение более тривиальное:
Мы создаем группу A записей в DNS нашей компании. Например, key1, key2, key3 и так далее. Вносим DNS имена в nethasp.ini клиентов, распространяем файл с помощью групповой политики. Таким образом мы получаем достаточно гибкую структуру доступа. В этом случае после обнаружения существенной проблемы с виртуальным сервером esx, можно оперативно переместить ключи на любые другие сервера, в т.ч. на рабочие станции любых сотрудников. Параллельно заменяем A записи на новые. В течение некоторого времени кеш на клиентах закончится и они снова смогут взять себе новую лицензию и продолжить работу.
Рекомендую прописать обратные DNS записи для ключей, иначе aladdin monitor не будет показывать имя хоста, а покажет только ID менеджера лицензий, что не очень удобно.
Если в вашей компании и во все используется широковещательный метод доставки ключей, то все упрощается и при перемещении ключа на другой хост в пределах широковещательного домена ни как не скажется на работе.

Отваливаются ключи

Есть такая, достаточно распространенная проблема. Ключи отваливаются. При том никакой особенной связи замечено не было. Это происходит на разные контроллерах, даже на разных хостовых системах. Когда я переносил ключи и временно разместил их в другом месте под управлением VMware Player, отваливание ключей происходило часто. Выражается это достаточно тривиально. При запросе haspdemo , появляется строка LOCALHASP_ISHASP: Failed: status = -100 . Хотя ключ вставлен и обнаруживается. dmseg показывает не до конца понятные строки: usb 2-2.1: usbfs: USBDEVFS_CONTROL failed cmd aksusbd rqt 192 rq 139 len 8 ret -110
Решается проблема также тривиально, как и выглядит - рестартом сервиса. Но осадочек остается и пока это не выполнить, сервер раздавать ключи не будет. Так как хочется, что бы система работала безотказно, было решено написать скрипт, который бы сам восстанавливал работу менеджера лицензий. Так, с помощью друга, был написан скрипт, который запускает haspdemo и пытается понять, нормальный ли статус возвращается или нет:
[ "`haspdemo | sed -n "s/^LOCALHASP_ISHASP.* \(\-\?*\)$/\1/p"`" == "-100" ] && service haspd restart
Далее этот скрипт вставляется в запуск по CRON каждую минуту и все. Даже если в вашей системе не будет наблюдаться проблема отваливающихся портов, данный скрипт, думаю, не помешает.

Проблема обнаружения ключа клиентом

И такая есть проблема. Заключается она в том, что клиент после потери ключа может не захотеть взять новый ключ. Также это проблема может выражаться и в других проявлениях. Например, если вы заменили пути к ключам в файле nethasp.ini, то клиентское приложение может вполне бодро продолжать сообщать о том, что ключей никаких нет и не видел никогда. Если к такой реакции быть не готовым, то проблема становится очень неприятной и начинаешь судорожно проверять работу всей системы и крыть матом 1С-ников, ибо все работает, но вот ГлавБух или, как назло, Генеральный, войти в 1Ску сейчас не может по непонятной причине и ты чувствуешь себя идиотом, вместо того, что бы быстро решить проблему. Однако помогало пока довольно простое решение. Необходимо очистить кеш 1С из профиля пользователя. В свое время я находил отдельный файл, который отвечает за эту информацию, на забыл какой:(

Ключи могут просто перестать работать

Против отказа оборудования ни кто не застрахован. И эти жалкие ключи тоже могут перестать работать. И самое важное в данном случае узнать об этом как можно раньше. Для этого мы будем использовать систему мониторинга Zabbix. Безусловно, разворачивать ее только для мониторинга за ключами бессмысленно, однако если заббикс уже стоит, то почему бы не прикрутить к нему и мониторинг за состоянием ключей.
Для этого нам нужно прописать собственный скрипт в файл настроек агента. Ищем файл конфигурации установленного zabbix_agent, называется он zabbix_agentd.conf. Открываем его и добавляем строку

UserParameter=hasp.status,haspdemo | grep "^LOCALHASP_ISHASP" | sed "s/^.* \(\-\?*\)$/\1/g"

Это позволит по команде собрать цифровое значение в поле LOCALHASP_ISHASP . В самом заббиксе все добавляется уже примитивно, создаем Item для нужного хоста или шаблона, в качестве Type указываем Zabbix agent, в качестве параметра key указываем hasp.status . Тип значения - float . При желании создаем триггер, по которому вам будет присылаться письмо или смска о том, что ключ не работает. Триггер этот лучше настроить таким образом, что бы требовал как минимум 2х срабатываний и покрывал время, которое требуется скрипту автовосстановления, который описывался выше, иначе будут появляться ложные сообщения о проблемах с ключем.
При верной настройке только при полной неработоспособности ключа вам будет приходить уведомление о проблемах.

Бонус

Для меня оказалось сюрпризом, но многие действительно не знают, что можно заставить клиентские части 1С искать ключи по указанным IP адресам, используя TCP или UDP соединение. Действительно, многие настраивают инфраструктуру так, что бы в каждом широковещательном домене было достаточное количество ключей. Это дикость. Для тех, кто еще не в курсе вот краткая инструкция:
Для управления доступа к hasp ключу, на клиенте есть файл nethasp.ini. Находится он в папке \conf каталога 1С. Нас интересует секция . В этом разделе нам нужно раскомментировать или создать следующие параметры:

• NH_SERVER_ADDR. Здесь мы указываем список DNS имет или IP адресов серверов с менеджером лицензий через запятую.
• NH_USE_BROADCAST. Ставим значение в Disabled.
• NH_TCPIP_METHOD. По-умолчанию используется метод UDP. Можно поменять на TCP, но в целом в этом нет серьезной необходимости.

Еще момент по поводу отображения ключей в aladdin monitor. Вопреки расхожему мнению, свободными лицензиями являются не только те лицензии, которые отсутствуют в виде занятых в aladdin monitor, но и те, у которых в поле Timeout стоит 0. Значения обычно пропадают в течение 36-и часов, но все равно лицензии считаются свободными.

В завершение

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

• Tutorial

Во многих компаниях в качестве основной платформы автоматизации используется 1С. Так повелось и у нас. Однако процесс становления платформы был произведен без должного подхода, в связи с чем сначала у нас было 5 ключей защиты на 95 лицензий, затем появилось еще 3 физических ключа на предоставление еще 50 клиентских лицензий для 3-х юридических лиц. Ситуация дурацкая, так как каждый ключ по нормальному требует отдельных хост, а подходящих для этого серверов становилось все меньше, а маячащее увеличение количества пользователей и, следовательно, покупки новых ключей, заставило меня задуматься над альтернативным решением, позволяющим избежать лишней информационной нагрузки на наши сервера и вообще сделать систему с ключами более гибкой и, желательно, более устойчивой.

Выбор системы

Система виртуализации

В качестве системы визуализации был выбран esxi 5.1. Выбран за неплохую поддержку переброски USB устройств и потому что кроме ESX я разбираюсь только в Hyper-V, переброску устройств который не поддерживает.

Для переброски USB устройств в ESX, железо гостевой системы должно быть не ниже версии 7. Тогда появится возможность добавить USB контроллер и примаппить USB устройство в гостевую систему. Еще есть момент по поводу поддержки. Официально VMware поддерживает только определенный список устройств. И он не очень то большой. Однако рядовые ключи защиты Aladdin, похоже, будут поддерживаться. Список поддерживаемых устройств есть на официальном сайте . А описание требований и положений по береброске USB в гостевую систему есть также на официальном сайте, в базе знаний .

Есть и альтернативные способы проброски USB ключей в виртуальную среду, да и в физическую тоже. Это устройства и ПО так называемое USB over IP. Программные продукты в данном случае не очень интересно рассматривать, а вот железные в этом случае неплохо себя показывают. Самый яркий представитель, всем известный AnywhereUSB с 14-ю портами. Устанавливается в стойку, имеет два интерфейса и два входа питания (имеет ли реально два блока питания, я не знаю:)). Устройство всем хорошо, но стоит в среднем 60 тысяч рублей, что плохо укладывалось в наш бюджет.

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

Операционная система и драйвера HASP

В качестве ОС я выбрал Debian. Почему? Да просто так. По сути в этой конфигурации можно взять любой любимый дистрибутив. Но Debian мне всегда нравится стабильностью и хорошим репозиторием.

В качестве драйверов берется достаточно популярный пакет от компании Etersoft . Взять скомпилированный пакет для своего дистрибутива можно на FTP сервере компании: ftp.etersoft.ru/pub/Etersoft/HASP/stable .
После установки пакета появляется служба haspd , которая и управляет работой ключа.

Настройка и проверка

Какой-то дополнительной настройки все это не требует. Ключ начинает работать практически из коробки.
Проверяем. Для проверки работоспособности в комплекте имеется программа haspdemo . При успешной идентификации ключа и начала работы, программа выведет что-то подобное в консоль:

LOCALHASP_ISHASP: Result: 1

Using Passwords 15213 - 28875
LOCALHASP_HASPSTATUS: API version number is 8.0
port number 201
Key type: HASP4 M4
LOCALHASP_HASPGENERATION: OK, HASP4 is connected.
LOCALHASP_HASPNETSTATUS: connected key is HASP4 Net 20
MEMOHASP_HASPID: 436444258 (decimal), 0x1a039c62 (hex)

LOCALHASP_ENCODEDATA: OK.
53 C1 F1 AF | EC 16 C3 15 | 35 31 E4 7F | 9B D0 90 9F
AA BA 8C 80 | 1E 22 29 E2 | 92 7E 04 56 | DA 70 7B 63 [.....")..~.V.p{c]
23 B4 9B E6 | 2F 17 | | [#.../.]

NETHASP_READBLOCK: Failed: Return status: 10

Главное поле: LOCALHASP_ISHASP: Result: 1 . Сообщающее, что все впорядке. Далее написано и про то, какой ключ вставлен.

Однако если есть какая-то проблема, то сообщение выводится покороче:

This is a simple demo program for the HASP4 key
Copyright Aladdin Knowledge Systems Ltd.

LOCALHASP_ISHASP: Failed: status = -100

При том по сути все равно что происходит с ключом, он может быть не вставлен, служба может быть не запущена или еще что-то. Я пока видел только два значения LOCALHASP_ISHASP. Это либо: Result: 1 , либо: Failed: status = -100 . И последнее всегда соответствовало неработоспособности, а первое всегда означало, что все ОК. Документации к этому пакету я не нашел, по этому узнать какие еще есть статусы не получилось.

С ключом разобрались. Надо не забывать, что в мониторе ключей ваш новоиспеченный ключ появится только тогда, когда с него будет взята хотя бы одна лицензия. Тогда aladdin monitor покажет ту информацию, которую он обычно показывает: это типа ключа, количество взятых лицензий, всего лицензий, кто именно забрал лицензию и таймаут.
Форсировать это достаточно просто, достаточно указать в клиентском nethasp.ini руками новый менеджер лицензий. Но о настройке клиента чуть-чуть позже.

С этого момента можно считать первоначальную задачу выполненной. Теперь мы можем создать параллельно несколько виртуалок, в количестве, соответствующем количеству имеющихся физических ключей. Ресурсы такие виртуалки потребляют, естественно, копеечные.

Проблемы и решения

Единая точка отказа

Первая проблема, которая создается и у всех на виду, это создание точки отказа. Если до этого ключи были распределены по различным серверам и отказ больше одного ключа практически исключен, то в данном случае отказ работы физического сервера может повлечь за собой отказ от работы всей системы 1С, т.к. клиенты будут отваливаться в течение, по-моему, 600 секунд и через непродолжительное время отвалятся все и не смогут вернуться в систему. Что последует за таким инцидентом можно не рассказывать. Вариантов решения два и направлены в разном направлении. Первое решение это использование отказоустойчивой конфигурации ESX. Однако это целесообразно, если в вашей компании эта система уже развернута и уже выполнен ряд требования для поддержания работоспособности при отказе любого компонента. Другое решение более тривиальное:
Мы создаем группу A записей в DNS нашей компании. Например, key1, key2, key3 и так далее. Вносим DNS имена в nethasp.ini клиентов, распространяем файл с помощью групповой политики. Таким образом мы получаем достаточно гибкую структуру доступа. В этом случае после обнаружения существенной проблемы с виртуальным сервером esx, можно оперативно переместить ключи на любые другие сервера, в т.ч. на рабочие станции любых сотрудников. Параллельно заменяем A записи на новые. В течение некоторого времени кеш на клиентах закончится и они снова смогут взять себе новую лицензию и продолжить работу.
Рекомендую прописать обратные DNS записи для ключей, иначе aladdin monitor не будет показывать имя хоста, а покажет только ID менеджера лицензий, что не очень удобно.
Если в вашей компании и во все используется широковещательный метод доставки ключей, то все упрощается и при перемещении ключа на другой хост в пределах широковещательного домена ни как не скажется на работе.

Отваливаются ключи

Есть такая, достаточно распространенная проблема. Ключи отваливаются. При том никакой особенной связи замечено не было. Это происходит на разные контроллерах, даже на разных хостовых системах. Когда я переносил ключи и временно разместил их в другом месте под управлением VMware Player, отваливание ключей происходило часто. Выражается это достаточно тривиально. При запросе haspdemo , появляется строка LOCALHASP_ISHASP: Failed: status = -100 . Хотя ключ вставлен и обнаруживается. dmseg показывает не до конца понятные строки: usb 2-2.1: usbfs: USBDEVFS_CONTROL failed cmd aksusbd rqt 192 rq 139 len 8 ret -110
Решается проблема также тривиально, как и выглядит - рестартом сервиса. Но осадочек остается и пока это не выполнить, сервер раздавать ключи не будет. Так как хочется, что бы система работала безотказно, было решено написать скрипт, который бы сам восстанавливал работу менеджера лицензий. Так, с помощью друга, был написан скрипт, который запускает haspdemo и пытается понять, нормальный ли статус возвращается или нет:
[ "`haspdemo | sed -n "s/^LOCALHASP_ISHASP.* \(\-\?*\)$/\1/p"`" == "-100" ] && service haspd restart
Далее этот скрипт вставляется в запуск по CRON каждую минуту и все. Даже если в вашей системе не будет наблюдаться проблема отваливающихся портов, данный скрипт, думаю, не помешает.

Проблема обнаружения ключа клиентом

И такая есть проблема. Заключается она в том, что клиент после потери ключа может не захотеть взять новый ключ. Также это проблема может выражаться и в других проявлениях. Например, если вы заменили пути к ключам в файле nethasp.ini, то клиентское приложение может вполне бодро продолжать сообщать о том, что ключей никаких нет и не видел никогда. Если к такой реакции быть не готовым, то проблема становится очень неприятной и начинаешь судорожно проверять работу всей системы и крыть матом 1С-ников, ибо все работает, но вот ГлавБух или, как назло, Генеральный, войти в 1Ску сейчас не может по непонятной причине и ты чувствуешь себя идиотом, вместо того, что бы быстро решить проблему. Однако помогало пока довольно простое решение. Необходимо очистить кеш 1С из профиля пользователя. В свое время я находил отдельный файл, который отвечает за эту информацию, на забыл какой:(

Ключи могут просто перестать работать

Против отказа оборудования ни кто не застрахован. И эти жалкие ключи тоже могут перестать работать. И самое важное в данном случае узнать об этом как можно раньше. Для этого мы будем использовать систему мониторинга Zabbix. Безусловно, разворачивать ее только для мониторинга за ключами бессмысленно, однако если заббикс уже стоит, то почему бы не прикрутить к нему и мониторинг за состоянием ключей.
Для этого нам нужно прописать собственный скрипт в файл настроек агента. Ищем файл конфигурации установленного zabbix_agent, называется он zabbix_agentd.conf. Открываем его и добавляем строку

UserParameter=hasp.status,haspdemo | grep "^LOCALHASP_ISHASP" | sed "s/^.* \(\-\?*\)$/\1/g"

Это позволит по команде собрать цифровое значение в поле LOCALHASP_ISHASP . В самом заббиксе все добавляется уже примитивно, создаем Item для нужного хоста или шаблона, в качестве Type указываем Zabbix agent, в качестве параметра key указываем hasp.status . Тип значения - float . При желании создаем триггер, по которому вам будет присылаться письмо или смска о том, что ключ не работает. Триггер этот лучше настроить таким образом, что бы требовал как минимум 2х срабатываний и покрывал время, которое требуется скрипту автовосстановления, который описывался выше, иначе будут появляться ложные сообщения о проблемах с ключем.
При верной настройке только при полной неработоспособности ключа вам будет приходить уведомление о проблемах.

Бонус

Для меня оказалось сюрпризом, но многие действительно не знают, что можно заставить клиентские части 1С искать ключи по указанным IP адресам, используя TCP или UDP соединение. Действительно, многие настраивают инфраструктуру так, что бы в каждом широковещательном домене было достаточное количество ключей. Это дикость. Для тех, кто еще не в курсе вот краткая инструкция:
Для управления доступа к hasp ключу, на клиенте есть файл nethasp.ini. Находится он в папке \conf каталога 1С. Нас интересует секция . В этом разделе нам нужно раскомментировать или создать следующие параметры:

• NH_SERVER_ADDR. Здесь мы указываем список DNS имет или IP адресов серверов с менеджером лицензий через запятую.
• NH_USE_BROADCAST. Ставим значение в Disabled.
• NH_TCPIP_METHOD. По-умолчанию используется метод UDP. Можно поменять на TCP, но в целом в этом нет серьезной необходимости.

Еще момент по поводу отображения ключей в aladdin monitor. Вопреки расхожему мнению, свободными лицензиями являются не только те лицензии, которые отсутствуют в виде занятых в aladdin monitor, но и те, у которых в поле Timeout стоит 0. Значения обычно пропадают в течение 36-и часов, но все равно лицензии считаются свободными.

В завершение

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

Вопрос: Мониторинг программных лицензий

Добрый день.
Windows server 2008 + SQL server + Сервер 1С 8.2.
На сервере установлены программные лицензии 10 шт + 5шт = 15 шт.
Максимальное кол-во одновременно работающих пользователей - 13 шт.
База одна. Соответственно пользователи запускают только один экземпляр программы.
Иногда некоторые пользователи не могут зайти в 1с (не обнаружен ключ защиты программы). Случайно выяснилось, что пользователи снова могут зайти, если 1с-ку перезапустит один конкретный пользователь. Соответственно, как я понимаю, этот пользователь в ходе своей работы расходует более одной лицензии.
Вопрос: как отследить какие лицензии куда ушли и как бороться с такими зависшими лицензиями?

Ответ:

Хорошая обработка, нужная! Но не работает)
{ВнешняяОбработка.МониторингЛицензий.МодульОбъекта(53)}: {ВнешняяОбработка.МониторингЛицензий.МодульОбъекта(23)}: Ошибка при вызове конструктора (COMОбъект): -2147221005(0x800401F3): Недопустимая строка с указанием класса
ВызватьИсключение ОписаниеОшибки();

Может кто-то смог вылечить?

Вопрос: Проблема с программными лицензиями на сервере 1с

Здравствуйте уважаемые форумчане! Подскажите пожалуйста, если кто сталкивался, как быть в такой ситуации.
Изначально: была база 1с КА 1.1, 1с 8.2, платформа 8.2.19.130, файловая на терминальном сервере. На самом сервере был установлен ключ на 10 пользовательских лицензий и 5 программных лицензий (файл лицензии лежал в C:\ProgramData\1C\1Cv82\conf). Пользователи работали через терминальные сессии.
Стало: перевели на клиент-серверный вариант (1с сервер х64, платформа 8.3.8.2054), субд Postgres, пользователи работают напрямую со своих рабочих мест. Компьютеры получают лицензию по сети с сервера.
Проблема состоит в том, что 1с сервер не видит программные лицензии. Файл лицензии копировал в папку conf сервера (C:\Program Files\1cv8\conf), в папку лицензий (C:\Program Files\1cv8\8.3.8.2054\licenses - хотя и понимаю, что тут лицензия храниться не должна), а также в папку платформы по таким же путям (C:\Program Files (x86)\1cv8\conf, C:\Program Files (x86)\1cv8\8.3.8.2054\licenses).
Насколько я почитал в интернетах, то программные ключи ищутся и подхватываются в первую очередь, поэтому должно работать...
Но посещают меня грустные мысли, что при установке программной лицензии на 5 пользователей, что-то "вшилось" в регистр, что связывает её с изначальной схемой, на 1с 8.2, и что не видит сервер 8.3. Т. к. на программной лицензии придётся новый пин-код активировать, прошу помощи, подскажите, действительно ли дело в этом??

Ответ:

При активации программных лицензий файл создается не один. Лучше всего написать по адресу, мне ответили в течении получаса по вопросу деактивации лицензии. Предложили найти и удалить все файлы 2*.lic и все файлы conn8211.pfl (или 1Сv8conn.pfl, если версия 8.3). Соответственно Вам как минимум все эти файлы нужно переместить, но никто не скажет поможет ли, поэтому я бы написал им письмо. Из-за неверных действий пакет лицензий может попасть в черный список.

Вопрос: Программная лицензия и COM-соединение

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

Ответ: Превышено максимальное количество пользователей, разрешенное файлом программной лицензии.

Вопрос: Как узнать какой файл (.lic) соответсвует какой программной лицензии?

Здравствуйте. На сервере установлено две программные лицензии (должны быть установлены). Но я вижу что раздается только одна. В C:\Users\1C_admin.1C8\AppData\Local\1C\1cv82\conf находится 3 файла:2014*****.lic в одном из них если через текстовый просмоторщик открыть написано наверху (сами программные лицензии номера 8100*****):

На компьютере server1 используются две копии одного и того же файла программной лицензии: file://C:/ProgramData/1C/1Cv82/conf/2014*****.lic и file://C:/Users/1C_admin.1C8/AppData/Local/1C/1Cv82/conf/2014*****.lic

Хотя эта папка пуста.
Папка C:\Users\All Users\1C\1Cv82\conf также пуста.
Может эту надпись удалить тогда начнет все раздаваться?

И самое главное смотрю через консоль администрирования ключ сервер 8100 - это программный ключ. А что за ключ ORGL8 Сет 20 - что это за ключ? Программный или аппаратный? Я думаю программный но почему тогда Сервер а не клиент?

Ответ:

Неужели никто не знает как по файлу.lic узнать какая это лицензия (соответствие лицензии.lic номеру из регистрационной карточки)?

Вопрос: Хитрости выдачи программных лицензий сервером 1С

Всем привет!
Друзья, подскажите пожалуйста по лицензиям, есть некоторые не понятные моменты для меня.
На сервере активирована программная лицензия на 10 пользователей. На сервере стоит сервер 1С, база на SQL и терминальный сервер.
Выдача лицензий происходит следующим образом (может это не точно, если не прав поправьте).
1. Если у пользователя на своем локальном компьютере стоит платформа и он по сети соединяется с базой 1с на сервере, то на каждый запущенный экземпляр программы, сервер ему отдает одну лицензию. То есть если пользователь у себя запустит 10 баз, то лицензий на сервере не останется.
2. Если пользователь подключается по RDP то сервер отдает ему одну клиентскую лицензию и пользователь сможет запускать неограниченное количество экземпляров программы (баз).
Главный вопрос, сработает ли второй пункт, если пользователь будет подключаться к терминальному серверу по RDP, там будут активированы программные лицензии но сервера 1с не будет? В терминале у него будет стоять платформа но без сервера 1с. Обязательно ли чтобы срабатывал пункт два, на сервере терминалов должен быть сервер 1с?

Ответ:

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

Вопрос: Не раздаются клиентские программные лицензии

День добрый.

Создал кластер 1С (8.3.7.1759) и сервер лицензирования. Действовал по этой инструкции. (). На сервер лицензирования активировал многопользовательскую программную лицензию. Если запускаю клиента 1С прямо на сервере лицензирования - то он нормально получает программную лицензию. Из любых других мест, если подключаемся к базе на этом кластере, -выдается аппаратная лицензия. Файл лицензии лежит здесь C:\ProgramData\1C\licenses

Ответ:

Доступ на чтение есть. Назначение функциональности добавил на сервер лицензирования. Галочка использовать аппаратный ключ не стоит.. И все равно получает железную лицензию...

--- Объединение сообщений, 28 дек 2015 ---

OKarlov сказал(а):

Проверьте еще зарегистрированную ошибку

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

Нажмите, чтобы раскрыть...

Кластер новый- на нем пока только 1 база. Никто не работает. Настройка сейчас 8 баз, 128 соединений на процесс.

Вопрос: Проблема с переносом программной лицензии 1С 8.3 на новый сервер

Добрый день.

В компании был один физический сервер 1С 8.3 с файловыми базами бухгалтерии. На нём стояли программные лицензии.

Закупили лицензии на 1с ERP:

1.на платформу для 20 человек
2.на конфигурацию 3 .на сервер 1 с Так же купили новый стоечный сервер, установили на него платформу 1С 8.3, развернули тестовую базу ERP, установили программные лицензии - всё ок.

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

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

Ответ: Супер благодарю!

Вопрос: v7: 1С 7.7 ТиС - могла ли быть программная лицензия?

Столкнулся с ТиС 7.7 локальной без аппаратного ключа защиты. Насколько помню у ТиС 7.7 не было поставок с программной лицензией? Помню на 7-ке были какие-то продукты с активацией по словам из книги - нужно было найти слово на такой-то странице и тогда происходила активация, то есть без ключа защиты. Но вроде-бы это были какие-то отраслевые решения, насколько помню. Коробка с анкетой, дискетами и книгами есть, а вот ключа нигде нет. Правда на ПК нет порта LPT, возможно поэтому его в свое время не поставили, и куда-то затеряли. Но все-таки хотелось-бы убедиться, что ТиС с программной активацией не было, только с аппаратной? Вдруг я просто всегда ранее с аппаратными сталкивался.

Ответ:

Добрый день!
На сервере установлено 2 программных лицензии на 20 подключений каждая. Закончились лицензии не с того ни с сего, хотя через монитор подключенных пользователей смотрю - всего 19 соединений.
Как можно узнать сколько лицензий используется. От алладина программка хорошая но работает только с USB ключами.
Спасибо.

Ответ:

"через монитор подключенных пользователей смотрю - всего 19 соединений" - это через какой монитор вы видите выданные программные лицензии?