Ознакомьтесь с нашей политикой обработки персональных данных
  • ↓
  • ↑
  • ⇑
 
Записи с темой: ms exchange (список заголовков)
21:24 

Exchange 2016 - Installation

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

Наконец-то руки дошли. Стряхнул пыль с трехсайтового домена в своей домашней лаборатории, и в одну из бессонных ночей в первом домене воткнул Exchange 2010. Чтобы был. Установка этой версии уже чуть ли не в слепую проводится. А чего там - одна PS-команда, которая все нужные роли воткнет, да пара файлов из раздела Prerequisites. Установка самого почтовика вообще никаких проблем не вызывает, все понятно и ежу.

На следующую бессонную ночь решил во второй сайт установить уже 2016 версию. Прямо в существующую организацию. Сценарий тот же - сначала в Powershell воткнуть все роли, найденные необходимые апдейты, затем сам Exchange. Не тут-то было. Не все апдейты нашлись. Дайте мне еще воооооооооон тот пакет мегов на 600. Ну ладно, чего нам, кабанам? Стащил, посмотрел на него, запустил. А он и говорит - на ЭТОЙ машине я ставиться не буду. Вот зараза. Ладно, где там раздел Prerequisites для этого апдейта? Ага, там еще пяток файлов надо. Ну хорошо, уговорил.

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

Наконец, все необходимые обновки поставлены, можно и за сам Exch приниматься. Запуск, EULA, режим установки, компоненты установки, имя организации Exchange... СТОП! Какое, к чертям, имя организации, если она уже есть? Есть-то есть, но установщик ее не видит в упор.
Ладно, быстрый гуглеж подсказал, что для полной совместимости нужно установить Exchange 2010 Update Rollup 11. Ладно, стащил, поставил. Еще на полчасика делов, еще половина очередной серии.

Повторная попытка поставить 2016 - и у нас все так же спрашивают имя организации. Мда, беда. Ладно, а что там ниже за ошибки? А ниже форменный ад: мы не видим AD. Вообще, никак. При условии, что я сижу под Enterprise-админом. Ну то есть выше уже некуда.
Вспоминаем. Лабу нужно запускать хотя бы один раз в 60 дней. Иначе будет очень много проблем в работе служб AD. Собственно, на это и нарвался. А учитывая, что у меня виртуальные машины все эти 60+ дней не то, что выключены были, а в состоянии паузы висели, представляю, какой у них взрыв мозга был, когда я их "разбудил" в прошлый раз.
Короче говоря, накрылась репликация SYSVOL через DFSR. На контроллере домена в том сайте, куда я пытаюсь воткнуть Exchange 2016, нет ни шары Netlogon, ни шары Sysvol. И это труба. Сначала восстанавливаем SYSVOL (Клац!), затем поднимаем из пыли репликацию (Клац! и смотрим на MaxOfflineTimeInDays). Проверяем, что обе шары появились, что репликация работает как надо, что в AD-Integrated DNS появились все ранее отсутствующие записи, в общем, проверяем всё! Вроде работает.

Снова запускаем установщик Exchange 2016. Чудо, эта зараза наконец-то увидела организацию, смогла выполнить /prepareAD и пошла ставить почтовик. Ура!

@музыка: Dance with the dead - Skeletons in the Attic

@темы: MS Exchange

11:42 

Exchange 2010 Management Scopes

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

Чтобы не потерять.
Области управления Exchange (Management Scopes) - Клац!
Больше всего проблем в RBAC именно с областями. Все остальное настраивается куда легче, сужу теперь уже по собственному опыту.
Ну и да, уже развернутая лаборатория наглядно показала, что кое-кто либо не знал, как настраиваются права, либо просто забил на это дело, отписавшись "это невозможно". Печаль.

@музыка: E.S. Posthumus - Antissa

@настроение: давно же тут записей по Exchange не водилось...

@темы: MS Exchange

12:59 

Windows 2012 R2 + Exchange 2010

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

Да, в некоторых областях я слоупок, и возможность нормально поиграться дома с такой связкой в виртуалках у меня появилась совсем недавно. Что ж, результаты игр просто шикаррррнейшие.

Итак, известно, что E2010 изначально в Win 2012 не жил. Поддержку этой ОС добавили только в редакции E2010SP3. И даже более того. В качестве ОС для E2010SP3 используется обычная Win 2012, не R2. Я долго думал, почему так. Более подкованные коллеги ссылались на какие-то адовые проблемы, и потому вообще предпочитали оставаться аж на Win 2008, только некоторые с большой неохотой мигрировали свои почтовики на Win 2012, но никто - на R2. Ну а поскольку было скучно...

Установка Win 2012 R2 уже давным давно заскриптована по самое не балуйся, клонирование шаблона (да-да, та самая процедура, где на тебя смотрит овца) - и новый сервер готов. Дело за Exchange. Накатываем на него все нужные роли самой Win2012, благо, сделать это можно одной командой:

Попутно втыкаем на сервер еще пакет фильтров (Microsoft Filter Pack) и можно ставить сам почтовик.

В редакции Е2010 он встал вообще без каких-либо проблем, но сразу при запуске управляющей консоли нас ждет просто потрясающее сообщение:
The WinRM client sent a request to an HTTP server and got a response saying the requested HTTP URL was not available. This is usually returned by a HTTP server that does not support the WS-Management protocol. For more information, see the about_Remote_Troubleshooting Help topic.

Приехали. Что только ни предлагалось для решения этой проблемы... И вынести службу IIS, потом вернув ее назад, и изменение настроек самой IIS, и перезапуск виртуальных каталогов. В общем и целом, ничего не помогло. Ну да ладно, не особо велика беда, я знал, на что лез. Вытаскиваем на свет файл с e2010SP3, в котором-то и добавили нормальную поддержку 2012-й линейки Windows. Установщик запустился, добрался до обновления роли Hub Transport... и вылетел с критической ошибкой. Жаль, что я ее не сохранил для истории.

Ну, думаю, не беда. Можно сделать интереснее - удалить Exchange и поставить его уже сразу из пакета e2010SP3. Ок, панель управления, установка/удаление программ, Exchange 2010 - удались! А эксч подумал и сказал - авотфигвам: Some controls aren't valid.

Приехали вторично! То есть ни обновить до конца, ни удалить текущую установку мы не можем. Жаль, не дошли у меня мозги в тот момент попробовать удаление через setup.com /mode:uninstall, хотя и есть подозрение, что результат был бы тем же. Делать нечего. Для верности вывожу этот сервер из домена, после чего просто удаляю к чертям виртуалку и за пару десятков минут разворачиваю новую со всеми нужными настройками, сетями, ролями. А после этого - запускаем на свежем, чистом сервере установщик E2010SP3. Как там дядя Миша говорил - Готовы? Вот что мне этот установщик выдал:

На сервере служб Exchange нет вообще, какой к дьяволу inconsistent? Для верности запустил еще раз - результат тот же. Значит - ошибка стабильна. Вспоминая да-а-а-авнюю установку еще на Windows 2008, даже не R2, таких танцев с бубном даже в мыслях себе не мог представить.

Что ж, шаманство продолжается. В сети нахожу упоминание о том, что неплохо было бы вынести из ADSI любые упоминания об Exchange, если это первая установка (а по сути так и должно быть). ADSIEdit.msc мне! Вычищаем оттуда все, что касается Exchange, за исключением раздела Schema - эту сущность без крайней необходимости вообще руками лучше не трогать.

Только после всех этих манипуляций Exchange соизволил установиться, открыть управляющую консоль, найти в ней новоустановленный сервер с ролями CA/HT и подцепиться к нему. Искренне надеюсь, что двумя MBX-серверами будет все же попроще.

Посматриваю заодно в сторону мааааааленького hMailServer, который мне безумно понравился еще во времена старой доброй 2003-й винды. Он просто работал :)

@музыка: Eleni Violaris - Rainstriker

@настроение: давненько не было записей с тегом MS Exchange...

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

10:17 

И смех, и слезы...

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

Bloody adorable! (c) Cpt. Haile

Хорошее начало рабочего воскресенья. Прийти на работу и обнаружить себя по другую сторону проблем с Exchange - в почтовом ящике толко рассылки за последние два дня %) Куда все подевалось?...
Важного ничего не было, но любопытно, что и где пошло не так.
Почему по другую сторону? Потому что раньше с такими вопросами обращались ко мне, а теперь... теперь самому приходится оставлять заявку %)

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

18:16 

MS Exchange 2003 Log files #2

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

Да-да, на дворе уже 2013 год за половину перевалил, но тут по-прежнему используется Exchange 2003. Впрочем, не об этом речь.
В общем и целом, начало этому посту было положено уже давно. История с лог-файлами, которая в моем личном хит-параде стоит на первом месте. Вот она: Клац!
А теперь ее продолжение, и хочется верить, что окончание.
Да, была авария на почтовом сервере. Да, есть бекап. Да, базу из него поднять можно и нужно.
Поскольку на том диске, где база и ее логи лежали изначально, место уже практически исчерпано (Zabbix об этом орет уже вторую неделю), решил восстановить базу на другой раздел, побольше. Памятуя о том, что у нас на разных разделах разный размер сектора (см. ту самую ссылку), размещаю файлы баз данных и логов Recovery Storage Group на новом разделе, а так называемый патч-файл (restore.env) и временные логи транзакций - на старом разделе. Для них места хватит, и на работу самого сервера еще останется. Все распланировано, запускается процесс восстановления. Файлы полного бекапа послушно кладутся на свои места, временные логи так же послушно кладутся на старый раздел. Поверх этого всего накатываются логи из Differential-бекапа, чтобы минимизировать потери почты. Дается команда Commit logs... И понимаем, что эта самая последняя команда не выполняется. Дает ошибку следующего вида:
Operation terminated with error -546 (JET_errLogSectorSizeMismatch, the log file sector size does not match the current volume's sector size)

Но как же так? ОК, сделаем то же самое, только руками, а не полагаясь на работу Backup Exec. Открываем командную строку, переходим в каталог с временными логами, даем слеующее:
eseutil /cc

Принудительное считывание и применение логов, обозначенных в файле restore.env, лежащем в текущем каталоге. Команда приводит к той же самой ошибке. Что за чертовщина? Следующая проверка:
eseutil /ml %LOG_FILE_NAME%
fsutil fsinfo ntfsinfo %DRIVE_NAME%


Размеры секторов совпадают. До байта. В чем проблема?
Начинаю вспоминать, как вообще нарвался на эту ошибку впервые. Ошибка появлялась при перенесении имеющихся логов группы хранения. В то же время, если их создать заново - все базы группы хранения спокойно примонтируются, а новые логи будут привязаны к разделу с новым размером сектора. Так, создание логов. Начинаем прикидывать, где у нас создаются логи при восстановлении баз. А создаются они в папке логов Recovery Storage Group. Чем черт не шутит, а почему бы не расположить их на том же разделе, что и временные логи из бекапа, где размер сектора тот, что надо?
Вы не поверите, это сработало. Даже при создании логов RSG учитывается размер сектора диска, где они будут лежать. Еще одно откровение, ничего не скажешь. Какое же счатье было читать в системном журнале сообщения следующего вида:
Information Store (992) Restore0008: The database engine has begun replaying logfile N:\Temp\SG1\E0085AEA.log.

@музыка: One More Time - Song of Fete

@темы: MS Exchange

13:18 

Outlook 2010 Profile Issues

В Dash'e под Chronostasis'ом.
Вот честно, когда вышел Office 2007 и его ленточный интерфейс, я ругался как черт. Хоть в Outlook там оставили привычный интерфейс. Когда же вышел Office 2010 - я начал плеваться и на Outlook тоже. Ибо более... ээммм... оригинально работающей программы я в славном племени офисных представителей не видел. Впрочем, речь пойдет не об интерфейсах, а о другом. Начать с уже ставшего головной болью сообщения "Загрузка профиля" (впрочем, тут я все же склонен винить больше серверную часть, нежели клиентскую) и закончить проблемой, которую пришлось решать совсем недавно.
Проблема эта проявилась в двух вещах. Первое - при работе в кэшированном режиме Outlook напрочь отказывается загружать автономную адресную книгу. Если вспомнить, что в кэш-моде идет работа исключительно с автономной книгой - все очень печально. Вторая проблема - автонастройка конфигурации Outlook. В какой-то момент в 100% случаев при ее использовании ответом стало: Unknown Error 0x80070057.
Обе любопытны. Дело в том, что обе они оказались завязаны на автоматическое создание профилей. Потому что:
1. Профиль, созданный руками, не испытывает никаких проблем с загрузкой OAB.
2. Профили, создаваемые руками с указанием адреса сервера и имени клиента, не испытывают никаких проблем с процессом, собственно, создания.
Пришлось отказаться от полностью автоматического создания почтовых конфигураций и заменить полуавтоматическим созданием - клиенту нужно будет три раза нажать кнопку Далее. Вопрос - как это сделать, и как было реализовано полностью автоматическое создание. Ответ рядом - setup.exe /admin, а уже в ней редактировать файл настроек Office 2010, который применяется в процессе установки всего комплекта. Лежит он в папке Updates. Открываем его, смотрим, видим, что помимо всего прочего именно там и задано поведение Outlook - "Определить изменения существующего профиля по умолчанию. Если профиль по умолчанию не существует, в Outlook создается новый профиль по указанным настройкам". Но по каким настройкам - неясно. Ок, сбрасываем этот параметр в дефолт, создаем новый файл настроек, восстанавливаем остальные параметры, сохраняем полученный MSP-файл в том же каталоге Updates, убив исходник. Проблему OAB на этом решили, новосозданные конфигурации принимают адресную книгу без всяких проблем. Осталось починить autodiscover, чтобы конфигурации могли создаваться как положено, а не через ввод параметров подключения. Поиск по гуглу вывел на статью в базе знаний MS, вот она: support.microsoft.com/kb/2028193/en-us?fr=1
Целиком и полностью наш случай. Решается установкой хотфикса. Прекрасно, но ставить руками хотфикс на каждую машину утомительно, а через WSUS данная обновка не распространяется. Что делать? Воспользоваться механизмом установки хотфиксов на стадии начальной установки самого пакета. Как? Очень просто - запрашиваем пакет с сайта, распаковываем его, и полученные msp и xml файлы кладем все в тот же каталог Updates в дистрибутиве Office 2010. С этого момента на всех новых установках офиса проблема будет решена. С уже установленными компьютерами - хуже, их придется обработать руками или через скрипт. Последнее предпочтительнее.

@музыка: Grave Digger - Highland Farewell

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

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

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

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

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

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

16:29 

Exchange Mailbox Permissions

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

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

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

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

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

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

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

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

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

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

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

главная