Суть проблемы: работаю в клиент серверном режиме - сервер Мини, на нем стоит КЛИЕНТСКИЙ ключ USB к которому привязана программная лицензия сервера. Данная конфигурация позволяла использовать клиентскую лицензию в локальной сети и в Web доступе на обычном компьютере (подключенном к локальной сети или сети интернет). Лицензия выдавалась просто - лицензию подхватывал сервер (одно подключение) и выдавал клиенту на комп без лицензии (установленного ключа или привязанной программной лицензии).
Кроме того это позволяло работать в терминальном режиме (удаленный рабочий стол на сервере). Понятно что ограничения такого использования (одна сессия) есть, но это компенсируется удобством эксплуатации для меня...
Повелся на новую платформу 8.3.21.1508 и тут началось:
1. На данной платформе перестало запускаться 1С Предприятие в режиме RDP - ключ платформа блокирует, а сервер через себя не передает....
2. Разбираться не стал и вернул платформу 8.3.21.1484 на которой не было проблем и тут начался второй акт балета... Обращение из запущенного 1С Предприятия в RDP к COM+ (V83COMConnect) пытается забрать лицензию у сервера и ломается когда ее не находит. Лицензию уже забрал запуск 1С Предприятия из которого пытаюсь просто обратиться к синхронизируемой БД. В сессии просто в настройке синхронизации пытаюсь проверить прямое соединение. Когда это делаю на внешней машине (в локальной сети с ключом) - все нормально, если в этот момент в терминале висит сессия 1С Бухгалтерия - так же сообщает об ошибке. Логи запустил и прикладываю но как их читать и какого хрена V83COMConnect забирает лицензии мне не понятно.
Не помню чтобы такое было ранее когда работал до переустановки платформы, т.е. * назад полностью работоспособность нужную мне не вернул.
Подскажите куда рыть и что смотреть в логах?
Удаленный рабочий стол Windows проверка соединения:
Не удалось подключиться к другой программе: Произошла исключительная ситуация (V83.COMConnector.1): Не обнаружено свободной лицензии!
Поиск лицензии на клиенте:
ORGL8 Локальный, установлен
Поиск лицензии на сервере:
ключ однопользовательский, лицензия получена по http через сервер, локальный запуск запрещен
О Программе
Текущая:
Локальный HASP4 ORGL8 1, выдал сервер
***********, легкий сервер 1/6, *******************************
Информационная база:
Сетевой HASP4 ORGL8 100
Показать
А это на клиенте в локалке:
При запущенном на сервере в удаленном рабочем столе 1С Предприятие (информация по полученной лицензии на странице выше) проверка соединения на клиенте в локальной сети в синхронизации данных между Бухгалтерия и Зарплата – выдает ошибку
Не удалось подключиться к другой программе: Произошла исключительная ситуация (V83.COMConnector.1): Не обнаружено свободной лицензии!
Поиск лицензии на клиенте:
ORGL8 Локальный, установлен
Поиск лицензии на сервере:
ключ однопользовательский, лицензия получена по http через сервер, локальный запуск запрещен
Информация на клиенте (локальная сеть) о лицензиях – стоит аппаратный ключ
Текущая:
Локальный HASP4 ORGL8 1, получило клиентское приложение
***************, легкий сервер 1/6, 29.12.2021 0:00:00, ***********************************
Информационная база:
Сетевой HASP4 ORGL8 100
!!!! Если в терминальном режиме закрыть 1С Предприятие – проверка соединения проходит успешно.
(1) возможно усиление защиты. Судя по описанию, не противоречит лицензионному соглашению.
Судя по настройке, лицензии раздает сервер. Сервер выдает лицензию на каждую клиентскую сессию.
V83.COMConnector это тоже клиентская сессия. И при наличии всего одной лицензии и уже существующего подключения, свободной лицензии не остается.
(20) Не думаю что V83.COMConnector это тоже клиентская сессия, т.к. сразу вопрос - на сервере установлен ТОЛЬКО сервер без клиентской лицензии, клиенты только по локалке со своими ключами локальными - откуда V83ComConnect возьмет клиентскую лицензию для запуска его на сервере (а он должен стартовать на сервере)?
Да и ранее на платформе 1484 все работало нормально - танцы с бубном начались после попытке установки новой платформы и отката назад. Уже напарывался ранее на такую ситуацию с другой платформой (хоть не обновляйся впредь) - тогда спасла переустановка все системы. Похоже все рушится в настройках и как это выявить - ХЗ. Пытаюсь написать в поддержку 1С
На компьютере в локальной сети зарегистрирован класс COM-объектов V83.COMConnector. Стороннее приложение создает COM-объект V83.COMConnector и с его помощью устанавливает внешнее соединение с файловой или клиент-серверной базой, расположенной в этой же сети.
В результате установки такого соединения начинает исполняться модуль внешнего соединения базы. В случае файловой базы код на встроенном языке исполняется на том компьютере, на котором создается объект V83.COMConnector (и в контексте клиента, и в контексте сервера). В случае клиент-серверной информационной базы код в контексте клиента исполняется на том компьютере, где создается COM-объект V83.COMConnector , а код в контексте сервера исполняется на компьютере кластера серверов.
Добавлю - V83COMConnector заведен на служебного пользователя USR1C с паролем, он же указывался 1С при установке полной платформы (с сервером в том числе). В терминал захожу на другого пользователя со всеми правами администратора
Судя по логам у вас на сервере установлен один однопользовательский ключ HASP4 ORGL8, который выдаётся сервером МИНИ только на один сеанс - у вас на самом деле с этого сервера запускается только одна база и только на одном рабочем месте?
(3) Нет, там конечно несколько баз, на по удаленке захожу только на одну. С другими работаем по локалке используя свои локальные ключи на клиентских компах. Я привел во второй цитате информацию о запущенном там клиенте.
С точки зрения лицензионных требований и ограничений - я не выхожу из них. С сервером работают 2-3 пользователя, количество подключений не превышаем... Меня и устраивает ОДИН локальный ключ на сервере - для административных работ с 1С и для отдельных работ только в одной сессии в RDP или удаленно без ключа.
Просто не понятно почему V83COMConnect пытается схватить лицензию и почему раньше не хватал ее - работал до попытки обновить платформу без проблем. А если бы на сервере не было вообще ни одной лицензии для запуска платформы - только чисто сервер?
(4) При любом раскладе лицензия может быть выдана только от МИНИ сервера, даже
при подключении по RDP, т.к. однопользовательский ключ по RDP раздаваться не может.
(5)Так и происходит - в информации о программе, запущенной в RDP это и говорится. Но не понимаю при чем это - я же не запускаю что-то еще - V83ComConnect - внутренний интерфейс 1С
У меня сервер на запуск клиента выдает лицензию на ОДНО подключение в RDP через себя - это и написано в О программе.
Я не запускаю в RDP локального клиента - только сетевого. Локальный конечно лицензию не увидит, а сетевой видит через сервер Мини
(12) Вот и меня интересует - как? И нужна ли ему лицензия? Если да, то как разруливается ситуация - V83COmConnect ставится на сервере, а платформа для запуска клиента - на клиентской машине
(13) У вас ключ и COMConnector на одной и той же машине, поэтому в теории проблемы быть не должно. Попробуйте перерегистрировать comctrl.dll, перегрузить сервер с очисткой сеансовых данных.
(14) dll перегистрировал неоднократно. И пересоздавал ручками ComConnect. С контролем что зарегистрировано спецутилитой regdllview-64.
А как очистить сеансовые данные на сервере?
(15) Файлы сеансовых данных snccntx имеют расширение *.dat (например, snccntx.000098F1.dat), которые хранятся на машине с сервером 1С:Предприятие в каталоге вида C:\Program Files\1cv8\srvinfo\reg_<номер порта>\snccntx<GUID> (например: C:\Program Files\1cv8\srvinfo\reg_1541\snccntx12a3b456-cdb7-89f0-1dc2-3ab456f7890b)
Прежде чем удалять файлы сеансовых данных необходимо остановить службу сервера 1С.
(16) Не помогло. Не подскажите как убедиться сколько лицензий использовано? Чо-то смущает информация консоли кластера в графе лицензии - такое впечатление что все захвачены
(18) Я о других лицензиях - на подключения к серверу. Консоль кластера не показывает (как я понимаю) клиентские лицензии (которые мне недостает). Хотелось бы видеть подвисшие сеансы...
У сервера мини нет отдельных лицензий по количеству возможных подключений. Там просто лицензия сервера. А ограничение идет просто по количеству одновременно подключенных.
(21) Это понятно - там типа 5+1 подключение и они встроены в сервер (их не нужно покупать и нет возможности докупать). Вопрос про контроль их использования на подключение - смущают последние цифры в рабочих процессах консоли кластера "6 6". Уверен что не так давно отражалось в том числе и "1 6". ЧТо значат эти цифры? Не оказывается ли что "сервер сошел с ума" и считает что ограничение на подключение уже выбрано? И именно поэтому не пускает V83ComConnect (хоть и пишет об отсутствии иных лицензий)?
(24) Если быть совсем точным у меня ПРОЯВЛЯЕТСЯ проблема сообщением об отсутствии клиентской лицензии для запуска сессии - это учитывая что в этом процессе переплетается работа клиента, сервера и V83COMConnect. А что ее вызывает из этой схемы взаимодействия - ХЗ. Вот и пытаюсь в разные стороны смотреть...
Как вариант можно попробовать убрать все настройки сервера (удалить кластер), но пока не знаю как это сделать. После удаления всей платформы и переустановки ее заново при запуска администратора кластера вижу кластер (сервер) со всеми старыми настройками. Так же пугает не потребуется ли переустановка IIS после удаления кластера...
(26) Автор в терминале запускает клиента и сом-коннектор. 1 пользовательский hasp так не работает и лицензию выдает сервер 1С, а вторую - на коннектор так уже не даст.
Еще полгода назад он с этой темой приходил, я ему подсказал решение: программная лицензия, так как 0 сеанс его не устроил, но он все еще питает надежды, что обойдет ограничения ключа.
(27) Я написал выше - в прошлый раз достаточно было все снести на компьютере и переустановить ОС и 1С - и все проблемы ушли. Я все это время так работал без проблем. Программная лицензия не дает уверенности в решении проблемы - никто не может гарантировать что потратив деньги на лицензию я не получу при очередной переустановке проблему такого же плана. Более того - такая лицензия не будет передаваться пользователю как "сетевая" например при доступе через WEB (сейчас передается). Поэтому и стремлюсь разобраться - это глюки или ограничения лицензирования. Поддержка 1С при моем прошлом обращении подтвердила законность использования такой схемы работы, я не смог с поддержкой довести дело до конца т.к. переустановив ОС и 1С ошибку "потерял" и просимые ими логи выслать не смог. В тот раз так же было обновление платформы.
Почему Вы уверены что ComConnector ДОЛЖЕН забирать лицензию клиента? Я уже написал выше "Как быть если на машине сервера развернут ТОЛЬКО сервер-мини и клиентские лицензии не ставились - работа клиента с использованием локальных клиентских лицензий на клиентских компьютерах?" Такая схема работа прямо прописана у 1С.
Да и на этой платформе у меня все работало пока не попытался обновиться до 1508.
(34) Если на сервере установлена только лицензия на сервер, то клиент при запуске будет искать клиентскую лицензию локально на клиентской машине или по сети от HASP LM (в случае, если используется многопользовательский аппаратный ключ от 5-ти пользователей).
(36) И сейчас такое происходит - только V83COMConnect то на сервере стартует а не на клиенте. Мы же сейчас говорим о том где будет брать ComConnect лицензию для своего старта. А на сервере никаких клиентских лицензий нет - они установлены ТОЛЬКО на машине клиента...
Я же и писал про ошибку на клиентской машине при обращении к ComConnecte на сервере при НАЛИЧИИ на рабочей машине ключа. Это в тот момент когда клиентская лицензия сессии на сервере захвачена стартовавшим там 1С Предприятие. Т.е. ситуация опять один в один...
(42) Вы про какую машину говорите - про клиента? Уточняйте пожалуйста при ответе, а то не понятно т.к. речь о распределенной программно-аппаратной структуре где на клиенте ТОЛЬКО клиентская часть, а сервер на выделенной машине только с сервер Мини.
Если речь про клиентскую машину, то у меня НЕ берет с клиентского ключа лицензии COMConnect - лезет на сервер и говорит об ошибке... Я это выкладывал изначально в своем посте
Если речь про клиентскую машину, то у меня НЕ берет с клиентского ключа лицензии COMConnect - лезет на сервер и говорит об ошибке... Я это выкладывал изначально в своем посте
V83COMConnect не обязательно запускается из 1С. V83COMConnect позволяет подключиться к базе из любого стороннего приложения, которые может работать с ним.
Можно из программы на С++ (и т.д) делать подключение. И сторонняя программа ничего не должна знать про получение лицензий. Вот он и берет лицензию с сервера при соединении.
Вы запускаете стороннее приложение и выполняете в нем действия, приводящие к установлению внешнего соединения с информационной базой. В результате запускается COM-сервер, который и исполняет код на встроенном языке.
По сути comcntr.dll это и есть клиент. Сервер мини отрабатывает только серверную часть (со всеми сопутствующими задачами) и возможность раздавать клиентские ключи.
(41) Но 1С предусматривает такую схему работы и в 1С ИТС это прописано - сервер мини на выделенной машине, клиентские лицензии ТОЛЬКО локальные на компьютерах в сети. Как это вяжется с Вашим мнением? Да и лицензия у меня не халявная а опаченная - лишних лицензий нет. У меня три клиентских лицензии и я только тремя пользователями могу работать
(48) Так ограничений то нет - эту схему работы 1С официально анонсировал на ИТС. По Вашим же словам такая схема работать не будет - ComConnect не будет работать...
(51) На клиенте НЕТ COMControll - даже Dll не ставится если Вы установите только клиента на рабочей машине...
Поставьте на клиенте только тонкого клиента и посмотрите Bin
(32) Тогда поясните еще как по Вашему мнению спасет программная клиентская лицензия если вход по RDP блокирует множественное обращение к ней? Получает 1С Предприятие при запуске сессии в RDP захватил эту ЕДИНСТВЕННУЮ лицензию - что тогда сможет получить V83COMConnect? Я эту ситуацию и сейчас пытаюсь решить... ИМХО ситуация один в один...
(38) (37) Давайте на "сам дурак" не переходить. Я озвучивая конкретные ситуации, прописанные 1С
Давайте не отвлекаться на программную/аппаратную лицензию, тем более что 1С ограничивает Вас и не дает обратиться в RDP повторно к лицензии.
Сейчас для простоты рассматриваем упрощенную схему работы - на машине сервера ТОЛЬКО сервер мини, клиенты на клиентских машинах в сети со своими лицензиями, привязанными к клиентским компьютерам. Как будет работать COMConnect и откуда брать лицензии?
рассматриваем упрощенную схему работы - на машине сервера ТОЛЬКО сервер мини, клиенты на клиентских машинах в сети со своими лицензиями, привязанными к клиентским компьютерам. Как будет работать COMConnect и откуда брать лицензии?
В этом случае COMConnect надо запускать на клиентской машине, а не на сервере.
(46) Так тонкий клиент - обращение должно вроде идти на сервере. Тем более что у меня лицензии за клиенте не блокируются - я там могу запустить любое количество сессий - зачем тогда за лицензией ComConnecta лезет на сервер, почему не обращается к моему ключу на локальной машине? ИМХО не вяжется...
(53) У него сейчас это все одно, и он в сообщениях изготавливает сферического коня в вакууме, в бессмысленной надежде, что мы что-то скрываем как сделать, что бы у него все заработало.
Автор - чудес не бывает.
(35) Поясняю - при подключении по RDP программная лицензия может быть получена клиентом самостоятельно, а не от сервера 1С. Если же используется однопользовательский аппаратный HASP, то лицензия может быть выдана только сервером 1С, т.к. однопользовательские ключи при подключении по RDP не раздаются.
(66) Пишите пожалуйста конкретно - что "Конечно" - информация из монитора кластера? Если да, то это не клиентские лицензии а лицензии на подключение к серверу. Они и у меня отражаются в том числе и на регламентные работы их куча...
Мы обсуждаем два вида лицензий - на подключение к серверу (что показывает монитор кластера) и клиентские - насколько я понимаю их алладином нужно смотреть (сетевые). Как в моем случае смотреть использование клиентских лицензий по локальным ключам не знаю...
(67) Это вообще-то не МИНИ, а обычный сервер 1С. У него нет понятия лицензия на подключение к серверу. Поэтому именно клиентские лицензии и отображаются. И com тоже ее получает.
(30) да зачем мне этого желать? А если по сути - это зависит от того как написан код обработки ошибки ведь это происходит не в одной программе а в "трех соснах" и достаточно не полностью детализировать код ошибки от "одной и сосен" и получим...
Сервер через себя передает лицензию на ОДНО подключение либо в RDP, либо без ключей на клиентах в WEB доступе или доступе по локалке. Второй конечно уже не войдет (например RDP уже забрал, с WEB или ЛВС даст отлуп).
Я спокойно захожу на клиенте с ключом и параллельно висящим клиенте в RDP. Но если клиент с ключом в этот момент попытается запустить V83ComConnect (он запускается на сервере как я понимаю) попадаю на то же самое - нет лицензии. Об этом вторая цитата выше
Для эксперимента попробуйте для этой базы отключить выдачу лицензии сервером, потом запустите 1С на сервере не по RDP, а через TeamViewer или AnyDesk и проверьте, стартует ли V83.COMConnector
ИМХО использование клиентского COMConnector в клиент серверной работе - не подтвердилось. Поставил на клиентской машине с клиентским ключом V83ComConnect - все равно лезет на сервер и там пытается взять лицензию - дает ту же ошибку на клиенте что и выкладывал ранее.
Сейчас не смог зайти в клиента на RDP - сообщило что нет лицензии. Перезапуск сервера (закрыл агента/открыл агента без перезагрузки машины) проблему снял. ВИдно где-то какой-то мусор пишется при использовании клиентских лицензий.
Сейчас не смог зайти в клиента на RDP - сообщило что нет лицензии. Перезапуск сервера (закрыл агента/открыл агента без перезагрузки машины) проблему снял.
Подвисание лицензии при RDP - это частая "болячка".
(62) Нет не пробовал. Но я заходил туда не терминалом а с клавиатуры и монитора - все работает без проблем. Т.е. по ключу все распознается и отрабатывает. Запускаю любые сессии и обмен проверяю. Вы полагаете будет разница через теамвьювер?
(64) Нет, разницы не будет. Если была возможность запустить локально без RDP, то это тоже самое, что через TeamViewer или AnyDesk (предложил на случай, если нет физического доступа к серверу).
Если при запуске непосредственно на сервере все запускается, то 100% проблема в алгоритме выдачи лицензии при подключении по RDP.
Однопользовательский ключ при локальном запуске дает запустить на рабочем месте несколько сеансов (в том числе и COMConnector), но если лицензия с этого ключа была выдана сервером 1С, то локальные сеансы уже запустить будет невозможно (в том числе и COMConnector).
(69) Ну не запускаю я дополнительные локальные сеансы и никто по сети не запускает - это домашняя сеть в которой у клиентов локальные USB ключи. Тем более что данные "О программе" и говорят что лицензия запущенному клиенту выдана, я не запускаю дополнительного клиента и основываюсь на этой информации:
https://its.1c.ru/db/metod8dev/content/3596/hdoc И вижу что с КЛИЕНТАМИ там происходит как написано. Нет там ничего про обмен с использованием внутрисистемных вызовов ComConnector
ИМХО это внутренний механизм обмена системы (вернее я использую ТОЛЬКО внутренний (синхронизации Зарплаты и Бухгалтерии). С чего бы 1С требовать с меня дополнительную лицензию? Находясь в RDP на сервере вижу в мониторе кластера как крутятся масса регламентных заданий по моим всем базам - они же так же через ком вызовы запускаются. Все РАНЕЕ и происходило так как описано и никакие лицензии для ComConnector не требовалось - полгода так работал. Я же не запускал ДВЕ сессии (двух клиентов). Что произошло сейчас - ХЗ.
Автор игнорирует мои сообщения и продолжает верить, что ComConnector это не клиент, а "внутренний механизм обмена системы". И ему бесполезно это доказывать даже прямыми ссылками на документацию. Про web клиента наверно тоже не стоит говорить (это к вопросу про механизм лицензирования).
То что раньше работало, а при обновлении платформы перестало... про закрытие дыры лицензирования не принимает.
(72) Дайте ссылку на документацию 1С. Пока только Ваши представления об этой документации звучат. То же и об оценке информации что Вы видите в своем мониторе кластера - это ВАШЕ восприятие ситуации. Вы имеете на это восприятие право - но это не является фактом (я про восприятие)
ЗЫ. Я ни разу не заявляю что мое восприятие ситуации - ИСТИНА. Я пытаюсь разобраться. Вам легче - Вы картину в свое голове создали - я пока еще нет....
(73) spacecraft - авторитетнейший участник этого форума. Сколько я видел его сообщений - ошибок в сообщениях не наблюдал. ОнлайнУфа по лицензированию часто пишет и здесь и на партнерском - сомневаться в его суждениях не приходится. И главное мы все трое должны пишем одно и тоже. И только у вас свое мнение, которое не подтверждается сложившейся ситуацией именно у вас.
(74) Ни в коем случае не пытаюсь усомниться в компетенциях указанных Вами товарищей. Просто я полагаю, что ни у одного из них нет такого варианта использования клиент-серверного вариант. А у меня ЕСТЬ. И их высказывания принимаю и анализирую, но уж простите как истину в последней инстанции не принимаю - нет оснований. Опыт и аналогии их ценны - не оспоримо...
Если речь про ССЫЛКУ - мечтаю ее увидеть....
ЗЫ. ОнлайнУФА Неоднократно помогал в решении моих проблем...
(76) Я когда зашел в эту тему и написал свой первый пост, причем не автору, а ОнлайнУфа, не сомневался что все закончится как и полгода назад. Ну что ждем еще полгода?
Кстати вы можете поехать на эти выходные в Москву, зайти в гостиницу Космос, поймать в кулуарах Сергея Нуралиева и получить из первых рук ответы на вопросы лицензирования в различных ситуациях.
(77) Да, стою перед дилеммой - плюнуть и переустановить все на компе с нуля и с большой вероятностью получить положительный результат как полгода назад, или выяснить а в чем проблема чтобы еще раз через полгода не возвращаться к тому же. И да, я полгода назад ее решил ТУПО не разобравшись в чем было дело...
Останавливает не переустановка (ну два дня потрачу), а то что с большой вероятностью проблема вернется...
Отрицание проблемы не есть ее решение...
(75) Ну так читайте это сообщение БУКВАЛЬНО. Что Вы там там видите о лицензировании? Вы опять свое восприятие этого сообщения описываете. Ну ни разу это не доказательство того что требуется лицензия... Там всего лишь говорится о передаче управления внутри нескольких объектов... Более того моя беспроблемная эксплуатация в течении полугода такой связки противоречит Вашей интерпретации из этого документа... А вот теперь возвращаемся к ссылке на ЛИЦЕНЗИРОВАНИЕ которую я привел выше и в ней вилим подтверждение возможности работы в той схеме что я описал. И заметьте ни разу там о ВНУТРЕННИХ механизмах не говорится. Сом вызовы в 1С и не только в 1С используются во многих местах - это и обмен с оборудованием, и обмен в офисными документами и многое другое... Сом вызовы это механизм Windows которые использует 1С (и не только 1С)... По большому счету DLLка это просто библиотека стандартных процедур с возможностью обращаться к ним из программы...
Более того, поднимите глаза выше в своей отсылке на ИТС и увидите - фоновые задания которые так же относятся к внешним и которые и сейчас РАБОТАЮТ без проблем - запускаю консоль кластера и вижу периодическое выполнение кучи фоновых заданий...
Ну так читайте это сообщение БУКВАЛЬНО. Что Вы там там видите о лицензировании?
Для начала, был ответ на это: "Не думаю что V83.COMConnector это тоже клиентская сессия".
В статье говориться:
В случае клиент-серверной информационной базы код в контексте клиента исполняется на том компьютере, где создается COM-объект V83.COMConnector , а код в контексте сервера исполняется на компьютере кластера серверов. Это не достаточно для признания, что это клиентская сессия?
А вот теперь возвращаемся к ссылке на ЛИЦЕНЗИРОВАНИЕ которую я привел выше и в ней вилим подтверждение возможности работы в той схеме что я описал. И заметьте ни разу там о ВНУТРЕННИХ механизмах не говорится.
Снова ваше ошибочное суждение, что V83.COMConnector это не клиент, а некий внутренний механизм.
И теперь перечитайте ту статью, что сами и приводили. Там что-то про Тонкий клиент сказано, или может про Толстый клиент? Да там даже про web клиент ничего не сказано. Там просто Клиент. А учитывая, что даже для web клиента не все соответствует... ну понимаете?
Сом вызовы в 1С и не только в 1С используются во многих местах - это и обмен с оборудованием, и обмен в офисными документами и многое другое... Сом вызовы это механизм Windows которые использует 1С... По большому счету DLLка это просто библиотека стандартных процедур с возможностью обращаться к ним из программы...
Вы отличаете просто СОМ объекты, от одного конкретного V83.COMConnector ? Про него речь ведем.
comcntr.dll не используется при создании СОМ объекта excel или word. Там свои библиотеки используются.
Короче, смешали все в кучу.
То что раньше работало, а при обновлении платформы перестало... про закрытие дыры лицензирования не принимает.
Какое нафик "закрытие дыр" если я поставил ранее работающий вариант из ранее скаченной платформы. Т.е. была беспроблемная платформа 1484, установленная из дистрибутива, который хранился у меня, я скачал и поставил новую платформу 1508, потом ее снес и опять поставил из старого дистрибутива платформу 1484. Все перестало работать. Как Вы полагаете возможность "закрытия дыр" в чем выражается? Дыры в чем?
(80) 1. COMConnector требует наличия свободной клиентской лицензии, о чем вы сами написали в своём первом сообщении:
Не удалось подключиться к другой программе: Произошла исключительная ситуация (V83.COMConnector.1): Не обнаружено свободной лицензии!
2. При подключении по RDP лицензия с однопользовательского HASP ключа на сервере может быть выдана только сервером 1С.
3. Если лицензия с однопользовательского ключа уже была выдана сервером 1С при запуске клиента по RDP, то COMConnector запускаемый на сервере получить лицензию от этого ключа уже не может, о чем так же есть в вашем первом сообщении:
Поиск лицензии на клиенте:
ORGL8 Локальный, установлен
Поиск лицензии на сервере:
ключ однопользовательский, лицензия получена по http через сервер, локальный запуск запрещен
Как у вас это работало ранее сказать сложно.
Может подключались не по RDP (например нулевая сессия в консоли), может COMConnector запускался с другой машины или фоновым по расписанию, может в сети был доступен сетевой ключ, может что-то ещё, но с одного однопользовательского ключа лицензия одновременно не может быть выдана и серверу 1С и COMConnector.
(82) Я описывал сообщения об ошибках, которые получал. НО НЕ УТВЕРЖДАЛ что требуется лицензия для обращения к ComConnect. Это не является доказательством того что проблема в свободной клиентской лицензии 8-) Это всего лишь говорит о качестве кода большой системы который писал программист для анализа проблемы.
Более того, требование такой лицензии как уже выше писал ПРОТИВОРЕЧИТ концепции лицензирования 1C - и приводил пример когда это проявляется ЯВНО (отдельно сервер, отдельно клиент). Исходя из своего опыта эксплуатации таких систем (я не только про 1С). ПРЕДПОЛАГАЮ что проблема в ином, тем более что поддержка 1С соглашалась в переписке со мной в апреле что такая работа как у меня возможна и просили данные для анализа... Как написал выше данные выслать им не смог т.к. проблему решил ТУПО перестановкой компа....
Пока поддержка не подтвердит необходимость лицензии на клиента на машине с сервером мини, или не увижу в документации что для обращения ВНУТРИ сессии к внешним данным через COMConnect требуется дополнительная лицензия уж позвольте оставаться при своем мнении...
ЗЫ. Есть теория восприятия Гельмгольца и я считаю такое общение как сейчас важным для осознания механизма работы 1С и поиска решения
После перехода с 8.3.19.1467 на платформу 8.3.21.1508 появились зависания 1С, какая то из баз всячески перестает запускаться, висит окно запуска 1С. Сделаешь рестарт службы 1С, на какое то время восстанавливается, но потом в течении дня снова проявляется проблема. Кто то сталкивался с подобным поведением 1С?
В Настройке кластера 3 рабочих сервера 1С 1)Клиентские соединения 2)Сервер Лицензирования КОРП 3)Сервер для исполнения фоновых задание. Такое подозрение что распределение между рабочими серверами перестает работать.
(85)
у нас проблема один-в-один как у вас. Скорее всего проблема действительно из-за лицензий. Они у нас были криво установлены. И слетели. Пришлось восстанавливать лицензии в 1С и откатиться до предыдущей версии платформы. После этого мы сделали отдельный сервер лицензирования. Будем опять штурмовать платформу 8.3.21.1508.
Как советовали, создал отдельную тему по 8.3.21.1508 и ее щепетильности к лицензиям. Может кто-то тоже столкнулся с такой проблемой? Поделитесь, пожалуйста, опытом:
8.3.21.1508 (как и все 8.3.21.****) зарекомендовала себя не щепетильностью к лицензиям, а зависанием сервера при входе новых пользователей, если сервер нагружен.
Откатывайтесь к 8.3.20.* или наоборот ставьте сразу 8.3.22.1603, в которой баг должны были поправить.
(121)
Да, спасибо, воспользуемся Вашим советом, п. 1 (* до 8.3.20) уже выполнили. Теперь сделаем накат до 8.3.22.1603
Думаю, проблему зависания должны побороть т.к. баг должны были исправить разработчики платформы. Да и мы сложа руки не сидели - поломали лицензии, восстановили их, сделали сервер лицензий.
Систему не переставлял, Снес 1С, удалил все папки 1С отовсюду (Пользователь, ProgramData и т.п.) Установил последнюю платформу 22.1603. Проблемы ушли. Поддержка 1С ушла в туман, попытка обратиться с конкретным вопросом по лицензированию - завершилась отсылкой на предыдущее обращение с пожеланием ждать ответа.
Короче - пока работаю, но и обойти терминал так же нашел как - монитор позволяет подключиться к двум компам - переключаюсь.
Вот проверка подключения в терминале
(89) Про какие три сеанса речь? Скажите как запустить - попробую. Но в RDP я не запускаю больше одного сеанса 1С Предприятие
Вот скрин:
В ЛВС на машине с локальным ключом USB запущен клиент, в RDP запущен клиент в котором запущена проверка связи с третьей базой (вызом V83COMConnect). Ошибок нет. К серверу подключены 8 баз, но запускаются конечно не все - сервер мини на 5+1 подключений. У меня в этой строке в графе лицензии не меняется ничего в зависимости от запущенных сессий. Напомню - стоит три аппаратных ключа - на рабочих 2х станциях и на сервере. Программная лицензия сервера привязана к ключу а не к компу...
ЗЫ. С точки зрения логики лицензирования для меня данная работа системы ожидаема. Ни в коем случае не пытаюсь рассуждать о V83COMConnect - не мой уровень компетенций. Я пытаюсь только разобраться...
Поддержка так же говорила что это процесс, который запускается в режиме административной консоли и должен брать лицензию. Но на конкретные вопросы постоянно путались какие лицензии - сервера на подключение, клиента, и под конец договорились что нужно ДВЕ лицензии клиента для работы в RDP (независимо на ключе или программные). Начал задавать вопросы по правилам лицензирования - замолчали и видно ушли думать...
ЗЫ.ЗЫ. Как закончится эпопея с поддержкой - инфу выложу. Но пока инфы нет...
(91) Выкладываю скрин. Пояснения т.к. не нашел как скрыть не нужные колоник:
1 строка - comconnector - лицензии СЕРВЕРА не клиента
2 строка - локальный клиент в ЛВС из которого запущен ComConnector
3 строка - клиент в RDP сессии который получил лицензию клиента через сервер.
Такая работа мне понятна и такую ожидал.
ЗЫ. Однако в данной платформе по-прежнему остаются подвисшие сессии и без перезапуска сервера (через агента - остановить/запустить) - клиент в RDP не хочет ИНОГДА стартовать. Может кто знает как с этим бороться? Online-UFA про такую проблему писал - решение интересно есть? Может как-то не так выходим из сессий?
Может кто по логам подскажет - что это значит? Это норма или нужны какие-то права кому-то?
14:11.567126-0,EXCP,0,process=rphost,OSThread=5620,Exception=9db1fa37-b455-4f3f-b8dd-7de0ea7d6da3,Descr="src\backbas\src\ClientStorageImpl.cpp(499):
9db1fa37-b455-4f3f-b8dd-7de0ea7d6da3: Ошибка доступа к файлу 'C:\ProgramData\1C\1cv8\1cv8connN.pfl'. 5(0x00000005): Отказано в доступе. : src\core\src\files.cpp(498): 5(0x00000005): Отказано в доступе. "
что это значит? Это норма или нужны какие-то права кому-то?
process=rphost,OSThread=5620,Exception=9db1fa37-b455-4f3f-b8dd-7de0ea7d6da3,Descr="src\backbas\src\ClientStorageImpl.cpp(499):
9db1fa37-b455-4f3f-b8dd-7de0ea7d6da3: Ошибка доступа к файлу 'C:\ProgramData\1C\1cv8\1cv8connN.pfl'. 5(0x00000005): Отказано в доступе
Дословно это значит, что у rphost нет доступа к файлу 1cv8connN.pfl.
Для начала проверьте какие права на папку C:\ProgramData\1C\1cv8\ у пользователя, от которого запускается Агент сервера 1С:Предприятия 8.3
(92) Я догадываюсь что это значит дословно 8-) Вопрос про то - у всех так или только у меня? О каком пользователе идет речь - USR1C? Какие ему нужны права? Ошибка доступа может быть просто фактом обращения к данному файлу 1С дважды - сам себя блокирует...
На папку доступ у администраторов и пользователя-администратора под которым логинюсь в систему - есть полный, у пользователя USR1C - особые разрешения (не знаю какие - 1С пользователя сам создал). Кстати как посмотреть что это за "особые разрешения"?
А вот на файл который создан внутри папки 1С и на который ругается - в правах USR1C не фигурирует.
На машине в ЛВС права на данную папку - у пользователя под которым вхожу - особые разрешения, у администраторов - полный доступ (USR1C не создавал там).
Ответил выше - речь о пользователе, от которого запускается Агент сервера 1С:Предприятия 8.3, если еще точнее - рабочий процесс rphost.exe. Как он у вас называется я не знаю, от кого у вас запускается rphost.exe - это см. у себя сами в диспетчере например.
(94) Спасибо, попробую. Я при установке указывал стандартного 1С клиента USR1C. Директория создавалась самим 1С (предыдущие ручками удалял), эти права только у меня не назначались 1С или это типовой гюк?