• ↓
  • ↑
  • ⇑
 
Записи с темой: ms exchange (список заголовков)
11:07 

Mailflow

В Dash'e под Chronostasis'ом.

Слежение за тем, как ходит почта от одного адресата к другому - занятие весьма интересное. Интерес там представляют ошибки, если таковые имеются. Совсем недавно пришлось разбираться с уникальным случаем в моей практике.
Ситуация: звонок сотрудника А с сообщением о проблеме: его письма доходят до стороннего человека Б. Но когда Б нажимает кнопку "ответить" и отправляет ответ, письмо уходит в ящик сотрудника В, о котором Б не имеет никакого понятия.
Вот такая вводная, дальше идет собственно разбор полетов.
Первое - ключевыми словами здесь для меня явились Б нажимает кнопку "ответить", это действительно важно. Те, кто использовал в своей практике почтовик The Bat, и помнят, как там настраиваются учетные записи почты, меня поймут. Для непосвещенных объясню. В The Bat можно менять значение поля Reply-to. Это поле содержит в себе тот адрес, на который будут отсылаться ответы на пришедшее письмо. Если объяснять на пальцах, получится следующее:
Вы настраиваете учетку на работу с адресом 1@1.ru, это ваш основной адрес. В поле Reply-to ставите другой: 2@2.ru. Все. Ответы на все письма (именно ответы), будут идти к вам на адрес 2@2.ru, в то время как в поле From будет светиться по-прежнему 1@1.ru.
Навскидку я не смогу придумать примеров использования этой схемы, но если ее реализовали, стало быть кому-то это было нужно.
Второе - по уверению сотрудника А, человек Б использует веб-интерфейс Яндекса.
Третье - у нас на предприятии The Bat не используется, стало быть поле Reply-to можно списывать со счетов, тем более, что по-умолчанию оно содержит в себе основной адрес, а я не помню, чтобы хоть для кого-то когда-то его меняли специально.
Четвертое - после проверки учетной записи А выяснилось, что никаких пересылок, перенаправлений и тому подобного добра не установлено. Почта ДОЛЖНА приходить в почтовый ящик А.

Что ж, проводим следственный эксперимент. Отсылаю тестовое письмо с ящика А на свой собственный, расположенный на стороннем сервере. Письмо приходит. Давлю кнопку "ответить", вбиваю "Тест" в тело сообщения, жму "Отправить". Письмо падает в ящик А, как ему и положено. Уведомляю сотрудника, что с его учетной записью все в порядке, и он может спокойно отсылать почту. А сам думаю, ЧТО было не так.
Для того, чтобы письмо попало в какой-либо ящик вообще, необходимо, чтобы в этом письме было хоть одно упоминание адреса, куда это письмо доставить надо. В тексте письма нигде ящик В не встречался, но ведь текст - это еще далеко не все.
Опять же - спасибо почтовику The Bat и его полезнейшей функции Исходное Сообщение. Знаем, помним, любим. Благо, мой сторонний ящик поддерживает эту возможность - открываю код сообщения и в поиск вбиваю адрес ящика В. Нашелся. Угадайте, где. В ПОДПИСИ СОТРУДНИКА А!
В подписи по стандарту компании указывается электронный адрес каждого сотрудника. Обычно это ссылка почтового стандарта mailto:. Как правило пользователи не в курсе, что ссылка состоит из двух частей - текста ссылки и цели ссылки. В нашем случае текстом в подписи был прописан ящик А, а целью был ящик В. После того, как это было замечено в коде письма, все стало ясно.
Вот честно, я бы очень, ОЧЕНЬ хотел посмотреть на человека Б, который утверждал, что отсылал ответ на письмо А, используя функцию "Ответить". НЕ ИСПОЛЬЗОВАЛ ОН ЕЕ, ни разу. Он тупо клацал мышкой на ссылке в конце письма от А, а ссылка, как выяснилось, была битой.
И второй вопрос - кто и как настраивал распроклятую подпись у сотрудника А? Этого узнать, к сожалению, не удалось, хотя обычно сотрудники сами себе подписи ваяют...

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

@музыка: Rian Farish - Breakthrough

@темы: MS Exchange, Этот безумный мир

22:37 

Categorizer

В Dash'e под Chronostasis'ом.

Нет в мире справедливости. Стоило вылечить сеть от Conficker'a, заболел сам. В итоге сегодня весь день оклемываюсь от температуры под 38. Вроде восстановился.
Но запись, в общем-то, не этому посвящена. Посвящена она проблеме, которая занимает меня уже порядочное время. Имя ей - Exchange Categorizer.
Категоризатор, как его иногда переводят, это механизм Exchange, где письмо проходит проверку на спам, вирусы и тому подобную дребедень. Проблема в том, что влиять на этот процесс никак нельзя, а логов, по которым можно судить о процессе "категоризирования" ;) - у Exchange не допросишься. Ну да где человек ни пропадал, правильно сказано, что мечом и добрым словом можно добиться большего, чем просто добрым словом. В роли меча на этот раз выступает реестр.
Message Submitted to Categorizer - then ends - Клац!
Хорошая вещь в статье указана. Суть в том, что при помощи обычной оснастки можно задать уровень протоколирования операций категоризатора от нуля (полное отсутствие логов) до пятерки (максимальный уровень). Но там же указано, что на категоризатор это не оказывает никакого воздействия. Для того, чтобы вывести поганца на чистую воду, нужно лезть в реестр и ковырять тамошние значения, выставляя уровень аж в 7 (Field engineering), который из оснастки недоступен. С этого момента в логах системы в журнале "Приложения" будут доступны сообщения об ошибках несчастного категоризатора. А уж их можно использовать для определения проблемы и поиска решений.

@музыка: Koto - From the Dawn of Time

@темы: MS Exchange

21:58 

Files and Space

В Dash'e под Chronostasis'ом.

Можно сказать, экзамен выдержал. Очередная проблема с Exchange, хоть и предвиденная, очередная серия экспериментов в VM перед применением решения. Очередные выходные на работе, что вообще-то было в последний раз больше года назад, историю про перенос того же почтовика в Балте в расчет не беру.
Суть проблемы - свободное место. Оно просто кончилось. Фраза "И время мы измеряем в мегабайтах" стала ключевой на всю прошедшую неделю. Раскладка такова: 3 базы по 150 Гб, и еще две по 80 Гб. Плюс папка логов, но это уже сущие мелочи по сравнению с тремя первыми колоссами. Места под них было выделено еще на этапе проектирования сервера и его структуры - как раз 450 Гб, отдельный диск для логов, и отдельный диск для бекапов. Господа удавы, заявляю, время можно измерять в мегабайтах, особенно когда каждый день у тебя начинается с проверки, а сколько же там свободного места осталось. И постоянные мысли - дотянуть бы до выходных, потому что выключить Exchange в рабочий день нереально. А выключать придется. Дотянули. На момент начала работ места там оставалось без малого 500 Мб. Критика, да и только.
Суть действий - перебить RAID-массив на внешнем хранилище, конфисковав место от первой файлопомойки и даровав почтовику еще 1.9 Тб. Это убьет файлопомойку, но она нам уже не так нужна, почта важнее. Сказано, сделано - в 11 часов субботы базы почтовика были выключены.
Сама по себе процедура подготовки перенесения баз не так уж и сложна. Вкратце ее можно обрисовать следующим образом:

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

- проверка состояния баз программой eseutil
Eseutil /mh
Проверять нужно каждый файл. На этом этапе интересуют параметры
State: Clean Shutdown (чистое отключение)
Log Required: 0-0 (0x0-0x0) (непримененные логи)
О состояниях чистого или грязного отключения и непримененных логах мне уже писать доводилось. Из личного опыта: в состоянии чистого отключения непримененных логов нет.

После отключения баз и проходит их перемещение туда, где они и будут жить, перемещаются файлы *.edb и *.stm. Опять же из личного опыта: базы в чистом отключении при переносе не требуют для себя ни перемещения логов, ни перемещения chk-файла всей группы хранения. Это добро будет создано заново. Тем не менее, наличие резервной копии - ОБЯЗАТЕЛЬНОЕ условие для проведения операции в целом, мало ли что.

В общем и целом, большую часть времени (что в субботу, что в воскресенье) мы провели тупо медитируя на прогресс-бар перемещения баз. Шутка ли, полтерабайта тащить из одного каталога в другой. Да еще прибавить к этому время на переразбиение RAID - но это уже ночью, слава всему святому, что за ночь эта операция прошла успешно. Объясню, почему.
На время работ с внешним хранилищем базы надо куда-то девать. Тащить их по сети в режиме Ethernet 100 - убиться, скорость нас будет тормозить. Поэтому решили содрать их на USB харды. Две штуки по 400 Гб нам хватит. Подключили два харда, слили на них базы (вся суббота на это и ушла), после чего поставили на Expand RAID-массив. И вот тут наши челюсти на пол и упали. Скорость расширения массива - 1% за полчаса. Прикинули - 100% за 50 часов, это получится, что только к понедельнику, к вечеру, и то не факт, у нас завершится подготовка массива. А ведь в понедельник почта уже должна работать.
Кто-то может предложить, а почему эти базы за ночь не слить куда-то в сеть и подключить их по сети к самому Exchange. Отвечу, когда-то давно у меня тоже такая мысль была, но Экс - штука весьма разборчивая. Его базы могут храниться только на DAS-устройствах. DAS - Directly Attached Storage. В эту категорию попадают собственно обычные харды, устройства, подключенные через SCSI-интерфейс, и USB устройства. Из этого многообразия у нас было все, но:
1. Хард самого сервера - это SCSI диск на 45 гигов.
2. SCSI-хранилище - оно сейчас как раз в стадии переразбиения.
3. USB-харды. Дааа, вот тут интересно, поскольку уже на полном серьезе прорабатывали возможность поднятия Exchange "на флешках". Подобной жести у меня в жизни еще не было, и в самом страшном кошмаре не снилось. Почему кошмар? USB-хард, подключенный по проводу к серверу - не шибко надежен. А о том, что случается, когда сервер Exchange вдруг во время работы теряет связь с почтовыми базами, я уже тоже писал, кажется.
В общем и целом, в воскресенье я шел на работу в полной уверенности, что этот кошмар прорвется в жизнь. Нет, повезло, массив переразбился, свободное место получено, можно и заливать базы назад.
Дальнейшее - тривиально: определение того, где будет лежать каждая база, подключение баз в оснастке Exchange, небольшая донастройка всего хозяйства (переименование групп хранения, небольшая их переконфигурация), проверка работоспособности почты.

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

@музыка: Dagda - Anthem Of The Gods

@темы: MS Exchange

19:36 

OWA

В Dash'e под Chronostasis'ом.

Outlook Web Access. Весьма удобная функция в составе Exchange, которая мне рушила мозг на протяжении всей прошлой недели. Знать бы, что решение столь простое.
Вводная. После ввода логина и пароля на сайте OWA творится нечто непонятное. Стили улетели в теплые края, список сообщений не загружается, элементы интерфейса aka кнопки "Создать", "Адресная книга" и т.п. не работают. В общем и целом, вместо удаленного доступа к своему почтовому ящику получаешь кукиш с маслом. Это если в Mozilla Firefox, там до писем достучаться все же можно, хоть и криво. В IE нет даже этого, тупая табличка "Loading..." и ничего больше. Вся эта котовасия началась после установки Service Pack 2.
Самое интересное в том, что не мы одни такие несчастные. Интернет просто пестрит постами на форумах с такой же проблемой. Предлагается и просто огромное количество решений, начиная от простой перезагрузки и заканчивая переустановкой SP2. Ни один не помог. Сброс виртуальных каталогов OWA - безрезультатно. Перерегистрация библиотек, отвечающих за обработку XML - туда же. Что за напасть...
И самое интересное, почему в Mozilla Firefox хотя бы часть функционала работает, в то время как в ослике - вообще ноль.
И только сегодня удалось раскопать статью в базе данных MS о том, почему такое могло произойти. Вот она:
Users receive a "Loading" message when they use OWA to access their mailbox after you apply a hotfix or a service pack to Exchange Server 2003 Клац!
Решение просто тривиально... Скопировать один (!) каталог с одного сервера на другой и забыть об этой проблеме...

В то же время так и не понятно, почему в Огнелисе хоть что-то, но работало...

@музыка: David Arkenstone - River Crossing

@темы: MS Exchange

21:49 

Magical 1008 number

В Dash'e под Chronostasis'ом.

После марафона с еще одним восстановлением почтовых ящиков после вторичной аварии на сервере (многовато их что-то) наконец-то начал разгребать весь бардак по резервированию и архивированию информации с Exchange. И нашел в этом одну загвоздку.
Бекап всей информации у нас длился почти 1.5 суток, это очень много. И завершился он в очередной раз неудачей, что для всех, кроме меня, было уже привычным. Стал разбираться, в чем дело. А дело в том, что в процессе резервирования информации почтовые базы данных отключились, то есть стали недоступными. Ни для админов, ни для пользователей, ни для программы архивации. Попытки выяснить причину полного отключения всех баз вывели меня на вот эту статью в базе знаний MS - Клац!
Суть в следующем - при начале архивации базы последняя блокируется для любых изменений на все время архивирования. Все действия, которые должны быть с базой выполнены, сохраняются в файлах логов, которые получают статус Uncommited - непримененные. В системе есть жестко закодированное ограничение на количество таких логов - 1024 штуки (как всегда - по степени двойки). Однако, если этот лимит достигнут, сохранность баз будет под вопросом. Поэтому, если количество непримененных логов достигает 1008 - Exchange самостоятельно принимает попытку сохранения баз данных от повреждения и выполняет т.н. мягкое отключение, базы переводятся в состояние Clean Shutdown, в котором могут быть снова подключены в любой момент. В противоположность этому есть термин "грязное отключение" (Dirty Shutdown), в состоянии которого подключение базы сопряжено с дополнительными действиями, такими, как приведение ее в согласованное состояние и опять же, приведение ее к состоянию Clean Shutdown.
Что же происходит у нас. После того, как на вторые сутки количество непримененных логов превысило критическую величину, базы отключились. Программа архивации, которая до этого момента исправно сливала информацию в бекап, натыкается на недоступность баз, офигевает от такого поворота дел, и отказывается работать дальше, рапортуя об ошибочном завершении задания. В итоге бекапа фактически нет, а та часть, что уже слилась - непригодна для использования в случае краха.
Единственным методом решения данной проблемы является уменьшение времени, необходимое для выполнения всей процедуры резервирования. А вот как этого добиваться, уже вопрос. Лично я пока решил делать резервные копии всех баз, но по-отдельности - одна база за день, это больше, чем трехкратное снижение объема информации. В понедельник - тестовый запуск. Если отработает - распространяю расписание на всю неделю, после чего останется только распланировать сброс архивных копий на ленту и забыть об этой проблеме.

@музыка: Dan Gibson - Whispering Pines

@темы: MS Exchange

Записная книжка

главная