Jump to content
Vintik

Vipnet client 3.2.11.19855 - сброс выбора МЭ - кто то решил?

Recommended Posts

Здравствуйте.

Скоро думаю все на 4-ю перейдут и на новые ошибки будем искать ответы,

но всё же кто не будь решил проблему сброса выбора настроек МЭ в сборке 3.2.11.19855 ?

 

Share this post


Link to post
Share on other sites

Я ставлю клиента под учеткой админа, вроде количество слетаний настроек поменьше стало. Но это не панацея.

Share this post


Link to post
Share on other sites

Все СЗИ ставятся от уч. записи с правами администратора, но это не помогает.

Даже если у пользователя полные права - это значение всё равно переводится обратно на "Координатор".

Где то может это поправить в "ini" 0 на 1, но где это не найду. 

Share this post


Link to post
Share on other sites

Неужели не кто не использует дефектную версию  3.2.11.19855  и не сталкивается с этой проблемой?

Подскажите тогда где прописывается настройка DYN_AP:SRV

В инструкции про это есть, на форуме видел, что советовали в ЦУСе прописать, а где конкретно то?

Share this post


Link to post
Share on other sites

Нашёл вроде :-) Это пишется там где типа IP писать.

Share this post


Link to post
Share on other sites
Провёл несколько эксперементов с версией 3.2.11.19855 и пришёл к выводу,
что в ней случайно или специально сделано так, что эта версия клиента выбирает
настройки сети, которое разрешено было в ЦУС, даже если у Клиента максимальные привилегии.
Временно можно выбрать любое значение, но после перезапуска Клиента настройки
возвращаются в то значение, которое было при получении из ЦУС.
 
Видел, что
- в инструкции написано надо прописать DYN_AP в ЦУС и это будет по умолчанию выбираться..
- на форуме у вас в одной из веток кто то спрашивал про такое же и видно там другие сборки,
ответ тот же - прописать...
 
! Заметил, что если передать данные через ЦУС, приписав DYN_AP, то сборка 19855 отлично
принимает данные и после этого всегда принимает Динамику.
(но там где это нужно, не кто этого делать не будет..)
! То же самое при проверки было на демо ключах, где было прописано значение DYN
и в новом ключе ещё дополнительные настройки.
 
На проверки со сборкой 3.2.11.21139 (с сайта предоставляется) она принимает значение
настройки из DST (где прописан IPLIRADR.DOC), но потом, при изменении в ней значения
выбора МЭ, после перезапуска Клиента он не сбрасывает настройки и не принимает первоначальное
значение, как сборка 19855 (и других версиях с такой же проблемой).
 
При использовании демо ключа заметно (19855):
- До запуска затирается файл ipliradr.do$ и потом создаётся на основании IPLIRADR.DOC
и ещё каких то источников, новый файл. Если изменить значение в IPLIRADR.DOC в ручную,
то они "передадутся" в ipliradr.do$ (бывает не корректно, если не оставить пустую строку после..),
но в Клиенте эти значения не примутся, т.к. сверка идёт ещё где то.
 
Думаю что это всё же "тестовый сбой" который должен был ограничивать Випнет Клиенты на которых
выдано ограничение, но получилось, что правило сработало на всех и исправляется новой сборкой.

Share this post


Link to post
Share on other sites

Возможно совпадение, но при по другой причине, в теме 

т.е. когда начинается сбой с IE и другими приложениями, производил рекоменд. от пользователей действия и по мимо того, что заработало то, что "ломал" Випнет, перестали слетать настройки, но возможно это совпадение и причина устранения в другом. 

На ОС W 7 Pro x86 со всеми обновлениями, установил CSP 4. После этого установил Client 3.2 (сборка 19855 в которой слетали настройки) и они перестали слетать.

Проверил по той же схеме на ОС XP х86 для проверки, но там это не помогло, потому возможно совпало и причина устранения я в другом.

Share this post


Link to post
Share on other sites

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

Я прописывал  DYN_AP возможно на клиента, а это на сеть. На клиента надо было писать DYN

И по цифрам самой сети мог ошибиться. Сейчас перепроверил и даже как то странно заработало вроде, но стабильного решения нет, надо проверять на живом клиенте :-) 

Ниже примеры

HHHH00010000 17 DYN_AP
HHHH00010003 17 DYN

тут HHHH это номер сети потом 00010000 - это тоже из ДСТ всё видно и если заканчивается 0 то значит на всю сеть, потому там именно написано DYN_AP

а уже где 3 - это сам клиент и на него надо DYN

Ну и как написано через 17

И тогда вроде 19855 может будет норально всегда динамику выбирать, но - если из ЦУС что то не пришлют.

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

Share this post


Link to post
Share on other sites

Всё. Ура получилось. Надо в итоге править do$ и писать DYN

Теперь всё отлично!!!

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

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

и по всей России, бедные пользователи  системы "АИСТёнков" вынуждены выбирать - настройки - данамика.....

Но кто бы им ещё сказал, что та кривая сборка ещё бывает из за того что там коорд. по умолчанию, выбирает не тот МЭ и потом

имея другие IP (после выбора динамики) не способна их выбрать т.к. это второй косяк этой сборки - вот и и тог.

На днях что то обновилось и сегодня позвонили 2 клиента по одной и той же причине... и таких случаев уже видел не мало.

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

\ И вот тут немного стыдно за продукт, как можно так накосячить, не одна сотня мучается с этим (я слашал и другие регионы так же..)

и после этого потом ФСБшники удивляются, если вдруг увидят где то не ту сборку - "а что это вы?" и как объяснить - да вот А-ТО.\ :wub:

Share this post


Link to post
Share on other sites
В 25.11.2016в18:34, Vintik сказал:

Всё. Ура получилось.

 Vintik, можно подробнее как именно удалось решить проблему?

Share this post


Link to post
Share on other sites
1 час назад, denis.r сказал:

 Vintik, можно подробнее как именно удалось решить проблему?

Её не то, что на 100% удалось решить, но хотя бы уже на 80% снизить вероятность её частого и каждодневного появления.

Ответ я отписал от 20 октября, если там не понятно то повторю ещё раз.

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×

Important Information

By using this site, you agree to our Terms of Use.