Ознакомьтесь с нашей политикой обработки персональных данных
  • ↓
  • ↑
  • ⇑
 
Записи с темой: 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

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: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

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

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, Этот безумный мир

10:52 

Limits.

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

And I push her to the limit
to see if she will break.
---
(c) Pink Floyd - Take it Back

Согласно политике почта сотрудников, покинувших компанию, не удаляется. Она перемещается из оперативной базы данных в специально выделенную, это снижает нагрузку на сервер. Лимитов на почтовые ящики нет. Пока нет, скоро будут, ибо размеры оперативной базы лично меня уже пугают. Буквально вчера перемещал хороший такой ящичек на 4 Гб весом, смотрю, какие папки перемещаются, сколько писем в них. 19 с плюсом тысяч сообщений, 6 тысяч из них находятся в папке Удаленные. Хочется сказать матерно, но сдержусь. Больше всего повеселил тот факт, что последней была перемещена папка "Важное", в которой находилось всего 14 писем. 14. важных. писем. Из более чем 19 тысяч. Получается, что вся остальная масса сообщений - есть ненужный балласт. Полагаю, после такого есть, над чем подумать.
Люди, пожалуйста, если у вас нет ограничений на размер почтового ящика на работе - не стоит хранить в нем переписку буквально за все время вашей работы. Пожалейте ваших админов, пожалейте ваши серверы, пусть даже вы их никогда не видите, и они железные. Чем больше база писем, тем она медленнее и неповоротливее. Тем хуже она будет проходить резервирование, и тем больше шансы на то, что в случае краха восстановить ДЕЙСТВИТЕЛЬНО важные письма не удастся. Пожалуйста, подумайте над этим.

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

21:50 

Море между городами - по колено, океан между континентами - по пояс.

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

Любопытная история. Как всегда - разбор полетов письма, почему не доходит до адресата. Все началось с получения отбойника вот такого вида:
**********************************************
** THIS IS A WARNING MESSAGE ONLY **
** YOU DO NOT NEED TO RESEND YOUR MESSAGE **
**********************************************
В общем-то, все просто и понятно. Письмо задержано, повторная попытка его доставить все таки будет. Проблема в том, что письмо срочное. Выискиваем номер телефона компании, в которую это письмо улетело, и начинаем выцарапывать информацию.
Приятный женский голос в трубке сказал, что по проблеме вряд ли что сказать сможет, ибо не в курсе, но может переключить на специалиста. Ну что же, спасибо, подожду. Разговор со специалистам позабавил. Суть в том, что письмо ушло на ящик login@domain.ru. На что с той стороны после минутного раздумья (видимо тоже у кого-то справлялся человек, что и как) был задан вопрос: А откуда вы узнали о существовании этого адреса?
Опа! Вот что б я еще знал, откуда наш сотрудник его узнал. На том конце меня просвещают, что все электронные адреса компании имеют вид login@domain.com, так что можно продублировать письмо, и оно должно дойти до места назначения. Благодарность за информацию и вежливое прощание. Стороны беседой удовлетворены.
А дальше - дальше трубку к уху и вызванивать сотрудника, где и как на адрес в RU домене напали. Ответ порадовал. Девушка на телефоне в той компании, куда письмо летит до сих пор, сообщила, что можно прислать информацию на адрес %login%. А на уточнение по поводу полного адреса был получен ответ вида: "ну %login%, а после собачки - как всегда". Поскольку звонили по России, легко предположить, что и адреса будут российские. Вот и полетело письмо "на деревню дедушке Константин Макарычу".
Люди, когда диктуете кому-то электронный адрес - диктуйте его полностью. Всегда. Это может сократить кучу времени и нервов в дальнейшем.

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

12:06 

Exchange 2007 CAS

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

Вчерашний день был из разряда "Срыв покровов". Обсуждалось расположение серверов Exchange 2007 в сети, кто и в каком сегменте сети будет стоять. В голове прочно сидит положение о том, что сервер переднего плана располагается в DMZ. Копаю материалы по установке Client Access Server, который заменяет собой сервер переднего плана. После захода по ссылке: technet.microsoft.com/en-us/library/bb232184.as... волосы встали дыбом. Да и не только у меня. Ключевым моментом статьи было следующее:

Installation of a Client Access server in a perimeter network is not supported. The Client Access server must be a member of an Active Directory directory service domain, and the Client Access server machine account must be a member of the Exchange Servers Active Directory security group. This security group has read and write access to all Exchange servers within your organization. Communications between the Client Access server and the Mailbox servers within the organization occurs over RPC. It is because of these requirements that installing a Client Access server in a perimeter network is not supported.

Проще говоря, в плане установки CAS DMZ теперь в прошлом, подобная организация сети поддерживаться самим МС не будет. А при PSS звонке первое, что будут рекомендовать - перевести CAS в доверенную сеть. Причиной тому работа CAS с серверами почтовых ящиков через RPC, динамические порты с номерами выше 1024. Так что, лучше этот момент учитывать до того, как организация на базе платформы 2007 будет развернута.

@музыка: стук клавиш

@настроение: рабочее

@темы: MS Exchange

16:08 

Ghosts

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

Привидения. Фантомы, оставшиеся от когда-то существовавших объектов. Подчас их искать довольно утомительно, зато интересно.
Суть ситуации в следующем. При попытке отправки приглашения на встречу через Outlook отправителю приходит уведомление, что данное приглашение не может быть доставлено одному адресату. Вся соль ситуации в том, что этого адресата никто не указывал. Если объяснить на пальцах, то получится, что приглашение было направлено людям A, B, C, D, а не получил приглашение человек Е. Дополнительный разбор полетов (просмотр логов Exchange) показывает, что вместе с основным письмом было направлено еще одно, как раз тому самому Е. Но ни одного следа этого дополнительного письма в ящике отправителя. Забавно, правда? А самое смешное, что учетной записи, куда отсылается второе письмо, уже нет в AD, и само письмо почему-то отправляется не по SMTP-адресу, а по протоколу X400.
Вроде и забавно, но когда с этим сталкивается человек из руководства, становится не до смеха. Это проблема, и ее надо решать.
На первый взгляд все банально - где-то стоит перенаправление. Стоять оно может в следующих местах:
1. Безусловное перенаправление всей почты человека в учетной записи AD
2. Перенаправление писем посредством правила Outlook.
3. Назначение представителей.

Первым делом была проверена учетная запись в AD - все чисто. В представителях тоже ничего не значится. Остается проверка правил Outlook. Заход к пользователю и просмотр правил также ничего не дал - все пусто. В чем же дело?
Ковыряние гугля в первые два дня ничего не дало, но потом все же сообразил, что запрос можно поставить иначе. Вторая же ссылка привела к нужному результату. Все дело в представителях. У Outlook есть особенность, заключающаяся в том, что он не всегда корректно отображает список представителей, даже после того, как они были удалены. В итоге проблема решается следующим образом: через AD назначается представитель, после чего открывается Outlook и уже в нем этот представитель удаляется. Это приводит к полному обновлению информации о представителях в AD и в Outlook, после чего письма привидениям исчезают, равно как и сами привидения.

@музыка: En Voice - Hall of Dreams

@темы: MS Exchange

10:15 

Oneliners

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

Oneliner - сценарий, состоящий из одной строки (one line). Их удобство в том, что для решения какой-то задачи достаточно открыть консоль, набрать нужную команду, запустить ее на выполнение и получить результат. Нет необходимости писать текст скрипта, сохранять его, затем писать команду на вызов этого сохраненного файла. Все просто.

Недавно понял, что нужно привести в порядок в нашем домене ограничения на максимальный размер передаваемого через почту сообщения. У кого-то стоит одно, у кого-то другое, у некоторых вообще десятое. Это неправильно. Два параметра (размер входящего письма и размер исходящего письма) хранятся непосредственно в записях Active Directory, следовательно, вытащить их достаточно просто. Вариантов довольно много, но в итоге я остановился на Powershell и его сторонней оснастке Quest Management Shell. Quest - это отдельный набор команд, облегчающих работу с Active Directory и делающих ее более прозрачной, чем обычные команды Powershell. Сами параметры зовутся так:
SubmissionContLength - размер исходящего сообщения;
DelivContLength - размер входящего сообщения.

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

foreach ($name in get-qaduser -searchroot 'INSERT_ROOT_OF_SEARCH') {set-qaduser $name -objectattributes @{SubmissionContLength='INSERT_VALUE';DelivContLength='INSERT_VALUE'}}

Пара слов о том, что он делает.
foreach - это команда, которая выполняет определенный набор действий с каждым объектом какой-либо выборки. в общем случае она записывается так:
foreach (selection) {sсriрt}
где selection - это выборка, а sсript - то самое действие (или несколько действий), которые нужно произвести с объектами выборки.
$name - переменная, хранящая в себе имя пользователя.
get-qaduser - одна из ключевых команд сценария. она вытаскивает из Active Directory полную информацию о пользователе, чье имя хранится в переменной $name
-searchroot - модификатор, задающий область поиска. Сюда нужно подставить путь к ветке в Active Directory, в которой сценарий будет искать нужного нам пользователя. Формат записи: 'OU=TestOU,DC=Domain,DC=com'

Таким образом, первая часть сценария создает выборку объектов Active Directory, у которой нужно будет сменить пару свойств. Непосредственно сменой свойств занимается вторая часть скрипта, заключенная в фигурные скобки.
set-qaduser $name - изменить параметры учетной записи, имя которой указано в переменной $name,
-objectattributes @{SubmissionContLength='INSERT_VALUE';DelivContLength='INSERT_VALUE'} - здесь задается, что именно меняеть, как раз те самые два параметра. Следует обратить внимание, что набор параметров заключается в фигурные скобки.

@темы: MS Exchange, PowerShell, Scripting

18:26 

Oneliners #2

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

Возникла сегодня интересная задачка: узнать, у кого из пользователей нашего домена стоит перенаправление почты на древнючий ящик. Лет тому ящику уже много, пора бы это дело и снять. Решение оказалось простым:
$user = (get-qaduser 'USERNAME').directoryEntry.DistinguishedName; get-qaduser -oa @{altrecipient = "$user"}
Входной параметр - имя того пользователя, на которого поставлено перенаправление. Выход - список пользователей, которые заваливают несчастный ящик своими сообщениями.
Конечно, можно было бы огульно сменить у всех в домене параметр altrecipient на NULL, но это порушило бы нужные перенаправления (а их немало).
Самым любопытным здесь является параметр {altrecipient = "$user"}. Переменную $user нужно обязательно заключать в парные кавычки. Именно в парные. Без них команда будет ошибочной, потому что переменная не распознается. Если же заключить переменную в одинарные кавычки - в скрипт вместо значения переменной будет передано ее имя.

@темы: PowerShell, MS Exchange

12:42 

Office Communicator 2007 + Outlook

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

При развертывании клиента Office Communication Server 2007 R2 столкнулся со следующей проблемой. Клиент нормально стартует, показывает список контактов, но говорит о том, что не может интегрироваться с моей учетной записью Outlook. Выглядит это вот так:
"There was a problem connecting to Microsoft Office Outlook. Your Outlook profile is not configured correctly. Contact your system administrator with this information."
Как было замечено на том же social.microsoft.com: the problem is... i'm system administrator. В результатах выдачи гугля много решений, и ковыряние реестра, и переустановка всего Office, и перенастройка профиля пользователя. Однако в большинстве случаев идут отписки, что ничто из этого не помогает. Как быть?
На одном из форумов нашлось решение, которое помогло лично мне. Оно до безобразия простое:
1. Закрыть Outlook и Communicator;
2. Выполнить в командной строке fixmapi.exe;
3. Снова запутить Outlook и Communicator.

После этого ошибка исчезла, коммуникатор смог предоставить весь функционал работы с Outlook.

@музыка: En Voice - Orange Moon

@темы: MS Exchange

20:32 

MS Exchange 2003 Log files

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

Потихоньку прихожу в себя от сегодняшней мозголомки. Умом понимаю, что такие проблемы, как эта, надо ценить и коллекционировать. Когда становится бессильным даже гугл - that's a challenge. Впрочем, обо всем по порядку.
Итак, есть задание - перенести базы с одной системы хранения данных (назовем ее ареной), на другую такую же систему. Первая арена предназначена под тотальный апгрейд и переконфигурацию. Обе арены подключены к серверу Exchange, разделы сконфигурированы и видны, как диски. Все готово для переноса, процедура которого весьма обыденна - нужно отмонтировать нужную базу данных и перебросить ее файлы в нужный каталог. С этим проблем не возникло никаких. База успешно поднимается, лежа уже в новой папке на новой арене.
После копирования файлов базы было решено сразу же завершить копирование группы хранения, в которой эта база находится. Это включает в себя перенесение chk-файла и файлов логов группы. Сказано, сделано. Подготовлены каталоги, отдана команда на перенесение одного, потом другого. Все успешно. Курсор мыши зависает над пунктом Mount Database. Один щелчок кнопкой, и...
Произошла внутренняя ошибка обработки. Попробуйте перезапустить диспетчер Exchange System Manager или службу Microsoft Exchange Information Store, или обе службы.
Код события: c1041724
Exchange System Manager


Первый звонок о том, что что-то пошло совсем не так, как планировалось. О перезапуске Information Store речи не идет, downtime будет не запланированным, отчего по голове не погладят. Первым делом смотрим в логи. Computer Management, Event log, Application...

Description: "Information Store Unable to read the header of logfile Exx.log. Error -530

Много непечатного. Очень много. Потому что весь интернет с MS во главе при такой ошибке дают два варианта действий: либо восстановление из бекапа, либо... eseutil /p, о котором мне писать уже доводилось. Спасибо, не надо, это долго. Да, я знаю, что у меня проблема с базой, но это не основная база, потому есть время на размышления.
Первым делом предпринял попытку вернуть логи назад... к моему великому удивлению - база примонтировалась и спокойно заработала без каких-либо ошибок. Мистика. Повторное отключение и перенос на новую арену. Результат описан выше. Снова возвращаю логи в исходную папку. Работает. Мистика дважды. Ради интереса переношу логи на системный раздел сервера Exchange - все работает. Возвращаю назад и логи, и базу (копия осталась в исходной папке) и ложусь спать, потому что время на тот момент было уже два часа ночи (работал из дома).
По приходу на работу утром предпринимаю еще одну отчаянную попытку переместить логи на новое место, только создал для этого тестовую группу хранения с тестовой базой внутри. Как легко догадаться, за ночь ситуация лучше не стала. База отключена, состояние - Clean Shutdown, то есть для ее работы логи в принципе не нужны. Что ж, копирую их в безопасное место, после чего уничтожаю их на новой арене, проверив, что сам Exchange будет их искать там. Расчет был на то, что даже если файлы и портятся при копировании, сервер просто создаст новые логи на новом месте. Это вполне допустимо, если есть резервная копия (она есть). Хотя и непонятно, почему при обратном копировании все работает, ведь файлы могут быть повреждены. К моему великому удивлению, логи создались на новой арене без проблем и вся база данных успешно примонтировалась.
Следующая стадия эксперимента - перенесение этих новых логов с новой арены в какую-нибудь папку на старой. Неудача. Та же самая ошибка, и то же самое восстановление работоспособности после перенесения их в их "место рождения", то есть на новую арену. Ради интереса переношу их на системный раздел, ожидая увидеть ошибку. Не ошибся.
Получается очень интересная ситуация. Логи, созданные вне новой арены, можно таскать куда угодно, но только не на новую арену. Логи же, созданные на новой арене, можно таскать как угодно на этой арене, но вне ее база работать отказывается. Чувство, что файлы на арене кодированы, но никто никакой кодировкой не занимается.
Дальше идет несколько часов курения гугла, всевозможных манов, форумов и им подобного. И везде одно и то же - бекап, eseutil. В голове третий вариант об отказе от старых логов для всех групп хранения и создании их на новой арене. Но это неправильно, потому что в прошлый раз при перенесении баз ничего подобного не было.
Под конец дня решил повнимательнее присмотреться к логу, который выдается, как сбойный. Файл как файл, MD5-хэши одни и те же, значит он не меняется и речи о повреждении не идет. Тогда что мешает? Unable to read the header of logfile. Но это Information Store не может прочитать. А что если взглянуть на файл под микроскопом?
eseutil /ml exx.log

Результат огорошил:
Operation terminated with error -546 (JET_errLogSectorSizeMismatch, the log file sector size does not match the current volume's sector size)

О таком я не слышал никогда. Чтобы лог файл не мог прижиться на новом устройстве, размер сектора которого отличается от размера сектора диска, где лог был создан. Эксперимента ради рассмотрел живой лог и на старой арене, и на новой. Результат сказал обо всем:
Env Log Sec size: 512 - на старой.
Env Log Sec size: 4096 - на новой.

Разделы и на одной арене, и на другой, создавались без меня. И никто не придал значения параметру Sector Size в настройках слайсов рейд-массива, сомневаюсь, что сам бы это сделал. Однако, значение это имеет, и довольно большое. Проблема лишь в том, что массив перебивать уже нельзя.
В итоге все же решили остановиться на варианте создания новых логов, это будет быстрее. И как всегда, бекап, бекап, бекап.
До сути проблемы докопались, это уже хорошо. Урок и полезная информация на будущее. Надеюсь, что кому-то она сэкономит много нервных клеток.

@музыка: Fowler and Branca - Windy Sky

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

16:29 

Exchange Mailbox Permissions

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

"Не удается открыть набор папок."
С этими словами, наверняка, хоть раз сталкивался любой из администраторов Exchnage. Когда Outlook пользователя, до какого-то момента исправно работавший, вдруг выдает подобное сообщение, становится несколько неуютно. И как всегда, сама ситуация возникает именно в тот момент, когда почта пользователю нужна просто до зарезу, чуть ли не многомиллионных контракт горит.
В моей практике на текущем месте работы это происходило дважды. У разных сотрудников, с ящиками в разных базах данных (только сервер один). Сами базы в порядке, сервер - тоже. Никаких дополнительных проблем нет, у всех все замечательно. Кроме одного бедолаги.
Думал, что проблема заключается в том, что компьютер по каким-то причинам не может до сервера достучаться - как бы не так, все отлично видно. Решил проверить права на этот ящик - тоже все в порядке. SELF на месте, все службы и сервисные учетки - аналогично. Я до сих пор не могу понять, откуда у меня возникла мысль удалить учетную запись SELF из списка доступа, после чего восстановить ее в правах, но именно это и позволило сотруднику получить доступ к своему ящику и продолжать работать, как ни в чем ни бывало.
Когда подобная ситуация повторилась с другим (через пару недель после первого инцидента), помогло ровно то же самое. Что ж, буду иметь в виду на будущее.

@музыка: Australis - Vanishing point

@темы: MS Exchange

23:16 

Exchange 2003 OWA и кириллические учетные данные.

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

Весьма любопытный случай.
Один из сотрудников жалуется на то, что из дома не может попасть на свой почтовый ящик - система просто не принимает его учетные данные. Провожу тест у себя, сбрасывая пароль на стандартный для таких случаев - все отлично срабатывает. Ну не иначе где-то ошибся человек.
Раз, второй, третий... Умом понимаю, что что-то не так. Ну не может человек настолько упорно набирать пароль неправильно. Тем не менее, проблема заглохла, больше звонков длительное время не поступало.
Недавно эта неприятность снова голову подняла, но уже с другим сотрудником. Этот поступил умнее, пришел в отдел лично. Лично набрал свой пароль на консоли администратора - не пускает. Прямо тут же меняем ему пароль на стандартный - все проходит на ура. Сотрудник меняет пароль на свой собственный - и тут же получает отлуп. Как так?! Посмеялись, потом начали размышлять, что и к чему. В глаза бросился тот факт, что тестовый пароль на английском языке, а сотрудник свой набирал на русском. И задавал его на русском. То есть мы пришли к тому, что OWA по какой-то ей ведомой причине не принимает национальные символы в пароле. Ладно, рекомендовали сотруднику использовать англоязычный пароль, а для себя пометили задачку в выполнению, но не как горящую.
Сегодня все же дошли руки до поднятия ручного Exchange 2003 SP2. Настраиваю OWA, меняю у тестового пользователя пароль на кириллический, жму Enter - и я в ящике этого пользователя. Все чудесатее и чудесатее (с).
Форумы молчат. Есть упоминания о том, что имеется проблема в случае кириллических логинов, но здесь другой случай. На яндекс в подобных вопросах уже давно не надеемся, гугл разводит руками. Полчаса вдумчивого сравнения конфигурации... Затем мысль - а что у нас с настройками регионов и кодовых таблиц. На самом деле региональные настройки не так важны, нам деньги не мерять. А вот кодовые таблицы - это уже любопытно. Оказалось, что на боевом сервере в настройках кодировок для non-Unicode приложений стоит английский язык, на тестовом же сервере - русский. Ну что же - смена на русский на боевом, перезагрузка... Долгие 3 минуты ожидания, смена пароля тестового доменного пользователя, заход на OWA... Success!!!
Exchange 2003 SP2 и настройки не-Юникод приложений - такого я представить себе не мог. Теперь представляю.
Еще одна поставленная галочка, еще один случай в копилку. Надеюсь, кому-то эта запись сэкономит немало времени в подобной ситуации.

UPD. Если конфигурация Exchange 2003 включает в себя два сервера, front-end и back-end, менять кодовую таблицу нужно на front-end-сервере.

@музыка: Rise Against - Help Is On The Way Shift 2 Remix

@настроение: Shocked

@темы: Security, MS Exchange

15:27 

Oneliners #3 - Перенаправление писем

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

Захотелось посмотреть, а у кого и куда стоит перенаправление почтовых писем в AD. И заодно подсчитать количество таких записей. Компоненты этого скрипта известны - get-qaduser, конвейеры, оператор вывода write-host. Основная сложность в том, что ключевой параметр altrecipient, в котором и хранится информация о цели перенаправления почты, в конвейер просто так не выводится, на выходе получаем пустые значения. Немного поковырявшись в справке по командлету get-qaduser находим ключ -IncludeAllProperties. Данный параметр заставляет команду get-qaduser выбрать из AD всю информацию о пользователе, по-умолчанию этого не происходит. Вторая сложность - по конвейеру нельзя передать конструкцию вида $_.altrecipient оператору write-host. Следовательно, приходится сначала упаковывать требуемые нам значения в переменные, а потом через write-host выводить на экран значения этих переменных. Одновременно в цикле можем подсчитать, сколько таких пользователей нашлось.
Суммируя всю эту информацию, скрипт принимает следующий вид:
get-qaduser -includeallproperties -oa @{altrecipient='*'} | %{$name = $_.name;$alt=$_.altrecipient;$i=$i+1;write-host $name" -> "$alt};write-host $i;$i=0

@музыка: Faun - Iduna

@темы: PowerShell, MS Exchange

00:24 

Largest mailbox ever seen...

В Dash'e под Chronostasis'ом.
Вот задумайтесь, какой самый большой почтовый ящик (электронная почта) вам приходилось в вашей жизни видеть? Вот что довелось узреть мне:

При условии, что число в третьем столбце - это не байты, а килобайты, становится страшно. А потом сотрудники удивляются, почему это Outlook начинает периодически показывать сообщение о том, что программа "пытается получить данные с сервера", и зависать.
Ах, да, мы же клиенто-ориентированная компания (просто клиентами для IT-отдела являются сами же сотрудники). Все для них, все ради них, все для их удобства. Если меня сейчас читает кто-то из руководящего состава какой-либо компании - мой вам совет: когда ваш системный администратор положит на стол проект по введению квот на почтовые ящики (если их еще нет), прислушайтесь к его словам. Это только по неопытности кажется, что предельные размеры ящиков - зло, на самом деле пользы от них намного больше, чем неудобства. Это не прихоть IT отдела, это суровая необходимость.
К слову сказать, после очистки от всего шлака, объем того ящика резко уменьшился до 1.2 Гб. Только вот на размер почтовой базы данных это не повлияет, к сожалению. Для уменьшения базы ее нужно дефрагментировать в offline-mode, а это полноее ее отключение где-то на полдня.

@музыка: Frank Borell - Wake Up in Paradise (Dream Spirit Mix)

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

02:17 

Oneliners #5 - Mailboxes of Fired Users

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

В продолжение записи, опубликованной ранее.
Как известно, при блокировании учетной записи сотрудника, в почтовый ящик этого человека почта продолжать поступать будет. Это не by design, такая логика работы в Exchange 2003 была включена в одном из обновлений, а в версиях 2007 и выше - уже по-умолчанию. И вроде как это даже разумно. Потому что далеко не всегда после увольнения сотрудника известно, кто будет его замещать, а переписку терять нельзя.
Но буквально недавно было поставлено условие - почтовые ящики уволенных сотрудников (которые не удаляются, равно как и учетные записи), не должны принимать никаких сообщений. Ведь на то эти учетные записи и заблокированы. Что ж, принимая во внимание тот факт, что такая мера хоть в некоторой степени остановит рост баз, всецело за. И в общем-то, оно и было сделано ранее - путем подставновки минимального и максимального разрешенного размера письма. Ага, равного нулю. И во время проверки выяснилась любопытная вещь: письма при такой настройке как проходили, так и проходят.
Неладно что-то в датском королевстве. Начинаем играть с параметрами и приходим к выводу, что если вместо нуля подставить любое целое число - ограничение работает. Ставим ноль - письма проходят как сквозь масло.
Что ж, можно, конечно, поставить в качестве ограничения 1 килобайт, но это как-то претит. Что можно еще сделать? А можно, например, сделать так, что почтовый ящик будет способен принимать письма только от себя самого. И поскольку учетная запись заблокирована, никто письмо послать не сможет. Точнее, сможет, но отправителю придет отбойник, что и требуется. Как реализовать?

$userDN = (get-qaduser $user).directoryEntry.DistinguishedName;set-qaduser -identity $user -oa @{authOrig = "$userDN"}
где в переменной $user хранится, например, логин увольняющегося человека (в моем случае он берется из заранее заготовленного расстрельного списка), а переменная $userDN получает значение атрибута DistinguishedName нужной нам учетной записи. Атрибут authOrig (разрешенный отправитель) в качестве значения хранит именно DN какой либо-либо учетной записи.
Ну а что же делать, если надо обработать пару сотен таких учетных записей? Как вариант - использование цикла foreach:

foreach ($user in (get-qaduser -disabled) {$userDN = (get-qaduser $user).directoryEntry.DistinguishedName;set-qaduser -identity $user -oa @{authOrig = "$userDN"}}
Буквально: для каждого элемента коллекции, полученной из выборки всех заблокированных учетных записей домена выполнить указанную выше команду.

@музыка: DA - Forest Runners

@темы: MS Exchange, PowerShell, Scripting

13:47 

Cached Addresses

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

Время от времени попадаются заявки о том, что письмо, отправленное через Outlook, не может достичь адресата. Но самое любопытное в подобных проблемах - адрес указан верно, и более того, перед глазами исходное письмо от того человека, которому письмо и пишем. В чем же проблема?
Ключом к пониманию ситуации является вот такая ошибка на сервере Exchange:

Event Type: Information
Event Source: MSExchangeTransport
Event Category: Categorizer
Event ID: 6015
Date: 13.12.2011
Time: 13:03:50
User: N/A
Computer: Server-Name
Description:
Categorizer is NDRing a recipient with address SMTP:mailto:recipient@domain.tld with reason code 0xc004054d ().

For more information, see Help and Support Center at go.microsoft.com/fwlink/events.asp.
Data:
0000: 4d 05 04 c0 M..À

Как видим, была попытка отправить письмо по несуразному адресу SMTP:mailto:recipient@domain.tld. Хорошо, создаем новый бланк письма, руками вбиваем recipient@domain.tld, отправляем. А через пару-тройку минут получаем отлуп от сервера, что не удалось письмо доставить и ту же самую ошибку в логе приложений на сервере. В чем же проблема?
А заключается она в кэше ранее набранных адресов. Лежит этот файл по следующему пути:
%USERPROFILE%\Application Data\Microsoft\Outlook\< OutlookConfigurationName >.NK2
Outlook - довольно умная программа, вместо набранного руками верного адреса подставила тот, что уже давно попал в кэш. И в итоге письмо летит в никуда. Выходом является очистка сбойной записи из кэша. Чем чистить? Идем на www.nirsoft.net/, стаскиваем оттуда мелкую утилитку под названием NK2Edit и с ее помощью смотрим все внутренности кэша. Интересующая нас запись будет обладать не типом SMTP, как все нормальные, а типом MAILTO. Удалять или править запись - вопрос личных предпочтений.

@темы: MS Exchange

15:57 

Outlook 2007 - Outlook 2010 Transition

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

Наверное, тег MS Exchange в этой записи не совсем к месту, но пусть будет. В будущем будет проще самому находить запись, если еще понадобится.
Итак, преамбула. Пользователь работает на компьютере под управлением старушки Windows XP 32 bit и Office 2007 с прямым подключением к серверу Exchange. В Outlook настроено порядка 20(!) конфигураций, и да, они все используются.
Фабула - сотруднику меняют компьютер и ставят ящичек под управлением Windows 7 x64 с Office 2010 на борту. Одновременно с этим включается Outlook Cached Mode.
А теперь разбор прошедшего полета под названием 2007->2010.
Поскольку администраторы - люди достаточно ленивые (множество скриптов тому лучшее подтверждение), и я не исключение, то воссоздавать на новом компьютере все это множество конфигураций руками - выше моих сил. Благо, относительно недавно довелось узнать, где Outlook хранит всю информацию о конфигурациях, место их дислокации - реестр:
HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\

И там уже множество кустов, по кусту на конфигурацию. Хватаем корневой Profiles, экспортируем его в reg-файл, который позже применяется на другой машине. Эта операция меня выручала уже неоднократно и сбоев не было.
Далее сотрудник открывает свою рабочую конфигурацию, в ней все хорошо. Открывает любую из побочных и нарывается на прекрасное: Outlook не может открыть файл по следующему пути C:\Program Files(x86)\Microsoft Office\Office14\%ConfigurationName%.ost
Где-то на этом месте должен быть смайлик с кодом *shocked*. Зачем офисному приложению, которое никак язык не повернется назвать "диким" (ибо MS же!!!) лезть в программный каталог для хранения пользовательских файлов.
Первое действие - скорее импульсивное, нежели продиктованное хоть каким-то рассуждением - если мы имеем ошибку записи ost-файла (кэша почтового ящика), то стоит этот кэш порубить, тем более, что конфигурация побочная, ее кэшировать бессмысленно. Однако, к нужному результату это не привело, ошибка как была, так и осталась. Уже ради интереса дал сотруднику временно права на запись в этот каталог (да простят меня коллеги-администраторы за подобный шаг). Логично, что все конфигурации заработали. Да, они посоздавали файлы-болванки для кэшей почтовых ящиков, но полностью их стаскивать на локальный диск не стали. Уже хорошо, уже можно работать.
В ходе увлекательной беседы с Cybeon (кстати, за определение "недостаточно правоверный виндузятник" спасибо отдельное, добавлю в self-intro :) ) пришли к выводу, что где-то в недрах конфигурации сохранен путь, по которому таки должен сохраняться ost-файл в случае включения Cached Mode. Но где? Все, что касается описания конфигурации и ее параметров, сосредоточено в том самом кусте реестра, указанном выше. Но ни намека на пути там не видно. Однако, небольшое гугление открыло всю глубину моей неправоты. Эти пути там есть, просто они закодированы: Клац!
Я не знаю, чем руководствовались в Редмонде, когда приняли решение о кодировании практически всех параметров конфигурации (безопасность, что ли), но забот они тем самым добавили изрядно.
Но несмотря на все эти изыскания так и не стало понятно, почему Outlook делает попытку сохранения именно в программный каталог. Пока что единственное предположение - в момент создания конфигурации в ней был сохранен путь вида C:\Documents and Settings\%USERNAME%\Application Data\Microsoft\Outlook, а в ОС Vista и выше этого пути не существует. Бедный почтовик, нарвавшись на подобное, решил сбросить все в место, о котором знает наверняка, именно программную папку, куда доступ обычной учетной записи на запись запрещен. К чему это привело - описано выше.
Ну и самое главное - как теперь побыстрее выправить эту ситуацию. Пуск, Панель управления, сменить представление с "Категории" на "список" (иначе настройку почты днем с огнем не сыскать), Почта (32-бит), Конфигурации. Далее выбрать нужную сбойную, Свойства, Файлы данных, Параметры, Вкладка Дополнительно, кнопка Настройка файлов автономных папок. И да, именно там мы и увидим, что в качестве расположения файла выбрана программная папка. Нажать кнопку Не использовать, после чего закрыть все открытые окна до списка конфигураций. И так - все два десятка. В любом случае быстрее, чем создавать их заново.

@музыка: Scooter - Faster Harder Scooter

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

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

главная