Рубрика: Exchange

Как выясняется, со странными проблемами сталкиваюсь не только я ;)
Несколько лет назад я сам столкнулся с подобной проблемой: при отправке сообщения в mailenabled общую папку от имени внутреннего пользователя, пользователь в ответ получает:
550 5.2.0 STOREDRV.Deliver: The Microsoft Exchange Information Store service reported an error. The following information should help identify the cause of this error: "MapiExceptionNotAuthorized
Вроде бы, очевидная и частая проблема, когда для отправки и папку обязательна аутентификация, а входящая почта исходит от анонимного отправителя (любая внешняя почта, собственно). Вот только ситуация-то была ровно обратной:

  1. Сам отправитель является хозяином папки
  2. Права «анонимного пользователя» = Author
  3. Права «по умолчанию» = Author
  4. Папка не требует обязательной аутентификации отправителей
  5. Сообщение от любого внешнего источника в папку доставляется корректно. При этом несущественно, через какой smtp коннектор получена почта (внешний анонимный или внутренний с аутентификацией отправителя).
  6. Проблема наблюдается только для какого-то ряда внутренних отправителей, на первый взгляд совершенно несвязанных друг с другом (разные департаменты, различные полномочия, большой разброс времени создания учетной записи)

И даже более того: после создания новой mailenabled общей папки и внимательного назначения для нее прав, была проведена серия тестов:

  1. Письмо с smtp адресом отправителя изнутри организации, возвращается с NDR.
  2. Письмо с smtp адресом отправителя извне, ложится в папку.
  3. Если добавить пользователю произвольный внешний smtp адрес, а затем отослать письмо с этим адресом отправителя. То на основной адрес пользователя сваливается NDR.
  4. Действо из предыдущего пункта совершенно безболезненно проходит с отправкой на адреса почтовых ящиков пользователей организации.

Учитывая то, что тестирование проводилось в том числе для свежесозданных пользователей... Впору было начинать верить в происки к потусторонних сил.

Читать полностью »



В проектах по миграции почтовых систем с одной версии Exchange на другую, иногда приходится сталкиваться с, так сказать, последствиями чужих недоработок.
Согласно политике организации, максимальное количество получателей сообщения должно быть установлено в 30 адресатов, кроме нескольких пользователей, которым должно быть разрешена отсылка любому количеству получателей.

Данные требования были удовлетворены путем установки глобального значения Recipient Limits равного 30 и явного указания заведомо большого (15000) разрешенного количества адресатов в свойствах тех пользователей, с которых ограничение необходимо снять. Собственно говоря, данная конфигурация является полностью логичной...при использовании почтового сервера Exchange 2003.

В архитектуре же Exchange 2010 (на самом деле, насколько я помню, уже начиная с Exch2007) логика работы иная.
Читать полностью »



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

Связка Exchange и Outlook вполне разумно, что уже давно используется исключительно в двух вариациях: со включенной функцией кэширования и с выключенной. Оба варианта использования имеют свои недостатки: при выключенном кэшировании возникает излишняя нагрузка на сервер, а при включенном кэшировании объемного ящика — могут быть серьезные проблемы с производительностью на стороне клиента (в особенности, если на стороне клиента активизирован плагин для антивирусной проверки корреспонденции). Это, кстати, тот самый вариант, когда Best Practices поставщика оказываются малопригодны в конкретной рабочей среде.

Читать полностью »



В проектах по миграции с Exchange 2003 на более свежие версии, грешен, я и сам очень часто люблю ввернуть упоминание о том, что «администрирование устаревшей версии почтовой системы базируется на графических утилитах, не позволяя гибко решать поставленные задачи».
Суть в том, что это несовсем верно ;)

Читать полностью »



Крайне подробная документация по установке нового продукта и миграции с предыдущих версий содержится на сайте technet.
И я крайне рекомендую тщательнейшим образом перечитать всю документацию размещенную там перед тем, как браться за настройку и управление продуктом в производственном окружении.
Ниже даже не обзор особенностей новой версии почтового сервера, а скорее, соображения о специфических действиях для миграции на нее и сравнении конфигураций.

Читать полностью »



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

Читать полностью »



Как правило, проблема возникает ровным счетом обратная: как через OWA позволить пользователям работать с содержимым Public Folders на Exchange.
Но проблема эта уже давно не стоит и выеденного яйца: с выходом SP1 для Exchange Server 2007 у пользователей OWA Premium появилась такая возможность. При этом все отлично работает и при публикации доступа через ISA Server.
Но что, если есть необходимость ограничить данный доступ? К примеру, у одного моего клиента появилась потребность в найме нескольких удаленных сотрудников, которым необходимы полноценные ящики в текущей почтовой организации, но достаточно нежелателен доступ к содержимому общих папок, доступному для всех штатных сотрудников.

Читать полностью »



20 Апр 2009

Я несколько раз встречал вопрос, какое средство лучше использовать для составления отчетов по Exchage 2007. Да, собственно говоря, ничего более того, что предоставляет сам вендор.
Существует свободно распространяемый инструмент под названием LogParser, который можно скачать на сайте Microsoft. Но, правда, конечно, он требует некоторого приложения усилий для своего использования, пятью кликами мышкой здесь действительно не обойтись. Зато, должен заметить, не требуется ни дополнительных капиталовложений, ни нарушения лицензии на использования средств сторонних разработчиков. Всего лишь нужен не слишком ленивый системный администратор и четкое понимание, какой именно отчет необходимо сформировать.

Читать полностью »



Cluster NTLM security

Автор: admin
16 Апр 2009

При причине того, что групповая политика обновляется не единомоментно, даже, казалось бы, тщательно проверенное на совместимость изменение политики может иметь неожиданные последствия.
Дело в том, что для обоих нод кластера опции безопасности Minimum session security for NTLM SSP должны быть изначально идентичны. То есть, если аккуратно включить «Require NTLMv2 session security» и «Require 128-bit encryption», то первая нода, получившая обновление политики безопасности, немедленно будет выкинута из кластера. Хотя, казалось бы, ничто не должно препятствовать тут же установить более безопасную сессию между двумя серверами, поддерживающими все указанные опциональные NTLM флаги.