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

[Vintik 0]

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

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

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

 

[Vanish1990 0]

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

[Vintik 0]

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

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

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

[Vintik 0]

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

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

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

[Vintik 0]

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

[Vintik 0]

Провёл несколько эксперементов с версией 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$ (бывает не корректно, если не оставить пустую строку после..),

но в Клиенте эти значения не примутся, т.к. сверка идёт ещё где то.

 

Думаю что это всё же "тестовый сбой" который должен был ограничивать Випнет Клиенты на которых

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

[Vintik 0]

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

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

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

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

[Vintik 0]

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

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

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

Ниже примеры

HHHH00010000 17 DYN_AP
HHHH00010003 17 DYN

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

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

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

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

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

[Vintik 0]

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

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

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

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

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

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

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

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

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

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

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

[denis.r 0]

В 25.11.2016в18:34, Vintik сказал:

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

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

[Vintik 0]

1 час назад, denis.r сказал:

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

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

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