Забавная штука, этот лотус.
Судя по документации, локальный клиент при авторизации на сервере сравнивает хэши политик, если они разнятся, клиент обновляет/заменяет локальную политику с помощью тулзы Dyncfg.exe, которую разрабы не рекомендуют запускать самостоятельно.
Хотя есть еще один способ типа обновления политик: "IBM предлагает другой способ запуска - в персональной адресной книге нужно удалить документ "Preferences" (Actions => Remove Address Book Preferences)." - костыли, они везде. Собственно, на автомате при авторизации никакого обновления настроек в нужном мне месте не происходит. Хотя на клиенте 8,5 при обновлении ручками в безопасности ECL, он все-таки подхватывает явную политику. А на 7 клиенте, при таком способе политики, он все-равно выдает оповещение о безопасности.
В чем принципиальная разница между способом применения политики к юзверю. Документально я наткнулся на два способа: в доке политике и в персональном доке.
И теперь самое интересный вопрос: каков же принцип отката назад всех изменений. Предлагается такая функция: clear any assigned policies... работает очень веселым способом: если политика применена в персональном документе, тупо ставится пустое поле, в другом случае вообще ругается, что политика не применена. Забавно еще, что политика все-равно остается примененной на локальной машине, учитывая факт, что по хэшу политики все-равно не обновляются. Опять тут IBM предлагает костыль: политику на политику.
С организационной политикой все на первый взгляд проще, можно выбрать при регистрации (собственно по докам не понятно, то ли это для статических настроек, то ли для динамических). Остановило одно, юзвери уже зареганы, а документации по переопределению сертификатов для id`шки мне на глаза не попалось. Хотелось бы, конечно, узнать поподробнее об этом.
