В своей первой статье я показал, как Вы можете редактировать страницу Logon.asp, чтобы входить в систему, просто используя username вместо [email protected] (UPN) и domain\username. Я получил несколько прекрасных отзывов от разных администраторов Exchange, уже использующих подобные методы, а моя идея этой статьи заключалась в том, чтобы обеспечить Вас несколькими улучшенными фрагментами кода, которые я получил.
Скрипт, который я предоставил в Части 1, не поддерживал опцию позволения пользователям определять domain/username(только username), таким способом устраняется головная боль пользователей, которые не осведомлены о сделанном изменении и, соответственно, не способны войти в систему. Оба скрипта, показанных в статье, не забывают об этой проблеме, вставляя дополнительную строку кода. Кроме того, скрипт 1 (который лично я считаю очень элегантным и хорошо отшлифованным) также решает проблему входа в систему, которую могут испытывать пользователи, использующие броузер Firefox и др. (см. Рис. 1).
Чтобы узнать, как привести в исполнение скрипты, представленные в этой статье, пожалуйста, обратитесь к первой части статьи Скрипт 1 (от Андреаса Уоберга (Andreas Warberg), Дания)
Скрипт 2 (от Евгения Брусиловского, Россия):
Соображения по применению пакетов обновления (Service Packs) и хотфиксов (HotFixes) Exchange
Применение пакета обновления Exchange 2003 обычно перекрывает Logon.asp файл, значит, Вы потеряете любую модификацию, сделанную в нём, поэтому Вы должны всегда помнить, что надо сделать резервную копию файла перед установкой пакета обновления. То же самое касается некоторых из выпущенных хотфиксов, соответствующая MS KB статья обычно предупреждает Вас о том, какие Exchange файлы заменяются.
Предупреждение:
Знайте, что применение хотфикса, включённого в MS KB статью: 883543 —The S/MIME control does not load in OWA when you are running the Exchange Server 2003 OWA client on a Windows XP Service Pack 2-based computer изменяет Logon.asp файл таким образом, что скрипт в первой статье и оба скрипта в этой не будут работать вообще, значит, пользователи не будут в состоянии войти в систему(logon). Я переиздам статью, когда узнаю больше об этой специфической проблеме.
Соображения по использованию ISA Server 2004
Если Вы уже осуществили или планируете установить ISA Server 2004 в Вашем окружении, Вы должны иметь в виду, что ISA Server 2004 имеет возможность создания своей собственной страницы аутентификации основанной на формах, чтобы пре-аутентифицировать Ваших OWA пользователей (предотвращение достижения неправомочными подключениями Вашего OWA сервера), см. Рис. 2 ниже:
Если Вы хотите воспользоваться этим средством, Вы НЕ должны включать средство аутентификации основанное на формах на Вашем внешнем(front-end) или внутреннем(back-end) OWA сервере. Как Вы, возможно, предположили, это означает, что Вам следует осуществлять вышеуказанные скрипты на ISA 2004 Server, а НЕ на OWA сервере.
