Tony Redmond - Exchange 12 на Exchange

Обнаружил заметки, сделанные на выступлении Tony Redmond - Exchange 12 на Exchange Connections 2006.

Понравились следующие пункты:

Переход с Exchange 2003 на Exchange 12 , сравним с переходом с Exchange 5.5 на Exchange 2000. У меня Exchange 5.5 был в зачаточном состоянии, поэтому переход особых затруднений не вызвал, но сейчас .... Возможно придется повозится.

Это начало конца Public folders. В след. версии, в 2011 их не будет вообще. Никогда их не любил. Наконец-то.

Роутинг теперь будет сильно зависить от размещения AD сайтов. Вот это правильно. У AD свои правила репликации, у почты свои. А смысл?

RUS собираются заменить на какую-то новую службу. Ну и ладно.

Административных групп не будет в Exchange 12. Вот это интересно, как же теперь секьюрити на управление раздавать?

На клиентской стороне Outlook 2007 сам найдет и подключит сервер Exchange, надеюсь, что на одну головную боль будет меньше.

Использование Exchange на витруальных серверах. Это интересно, так у меня загрузка серверов 5-10%б, нужно попробовать запустить Exchange 12 на виртуальном сервере.

Хотя мне кажется, что Exchange 12 нужен или монстрам или только что созданным компаниям. Я пока не могу найти причину по которой мне нужен Exchange 12. А так хочется :-)

В оригинале поста еще много разных фактов. Полный адрес статьи

как запретить всем пользователям OMA

Сегодня прочитал статейку про то, как запретить всем пользователям OMA. По такому же принципу можно запретить OWA, IMAP, POP. Хотя лучше использовать утилиту ADModify
Преимущество скрипта заключается в том, что можно добавить немного логики и запрещать не всем и т.д.

Set xDSE = GetObject("LDAP://rootDSE")
Set xUsers = GetObject("LDAP://cn=Users," & xDSE.Get("defaultNamingContext"))
For Each xUser In xUsers
xUser.Put "msExchOmaAdminWirelessEnable", "7"
xUser.setinfo
Next

Полный адрес статьи

Microsoft Operation Manager по-русски

Нарыл сегодня мега ссылку на блог "Microsoft Operation Manager по-русски".

Похоже автор, Тарасов Вячеслав (vatarasov@gmail.com), очень некисло разбирается в МОМ.
Так что вэлкам. У меня начинается проект по внедрению МОМ в нашей компании. Курсы прослушаны,
теперь практика. Так что Вячеслав, держитесь! :-)


http://spaces.msn.com/vatarasov/

Приглашение почитать журнал Exchange&Outlook

Сегодня пришло приглашение почитать журнал Exchange&Outlook
administrator.

Этот журнал издается в печатном виде и подписка стоит около 100$ в год. Хороший журнал. Издание предлогает почитать несколько выпусков.

Я даже написал в него парочку маленьких статей, платят по 100$ за заметку. Проверено :-)

Не хорошая тенденция

Сегодня прислали интересную ссылку.
http://www.cnews.ru/reviews/articles/index.shtml?2006/03/23/198301

Представляете, что будет, если нужно будет хранить всю входящую почту? Это учитывая, что 80% всей почты - спам. Потом все это писать на внешние накопители.

http://www.elar.ru тогда развернется :-)

Как определить владельца smtp адреса в AD?

Казалось бы простой вопрос, но как это сделать проще всего.

Пример: есть адрес batman@mydomain.ru. Необходимо определить пользователя в AD, которому соответствует этот адрес.

Jim McBee предложил вот такое решение:

1. Открыть оснастку Windows 2003 Active Directory Users and Computers
2. Нажать правую кнопку мыши на домене и выбрать Find
3. В поле Find выбрать в списке "Custom Search" и в поле In: выбрать из списка "Entire Directory".
4. Выбрать Advanced property page и ввести вот такой вот LDAP запрос :

proxyaddresses=smtp:batman@mydomain.ru

Нажать Find.

Я немного поковырялся и пришел к мнению, что выбрав вместо "Custom Search" - "Users,Contacts and Groups",
затем Advanced и там Proxy addresses из меню User.

Выбираем "Starts with" и в поле Value пишем "smtp:batman@mydomain.ru"


Мне кажется так проще. Если Вы знаете другие способы или мой способ примитивен, напишите - обсудим.

История одного трабла с Exchange 2003 и DC на Windows 2000.

Так уж получилось, что у нашей компании есть доступ к службе поддержки Микрософт и нет-нет нам приходится прибегать к ее услугам.
Все началось как обычно, нежданно-негаданно. В удаленном офисе вдруг завалился сервер, пользователи побежали за пирожками или принялись рубиться в шашки, а локальный helpdesk стал обрывать мой телефон с одним вопросом: «Это надолго?”

А случилось вот что. Как известно, Exchange хранит свою служебную информацию в AD. У нас AD разбросана по двум Windows сайтам в разных городах. Офисы соединены каналом 256к.

Мы выключили один из DC у себя, а сервер завалился в удаленном офисе. Оказывается, Exchange не хотел работать со своим локальным GC/DC в своем сайте и полез в наш сайт. Причем ему подходил только наш старый GC/DC, который мы выводили из эксплуатации. В логах Exchange было написано черным по белому: «Вижу локальный DC/GC, но работать с ним отказываюсь. Работаю с удаленным DC/GC» Пришлось на время включить старый DC/GC в нашем сайте и начать изучение Knowledge Base. Поиск ни к чему не привел. Пришлось открывать Trouble Ticket у Microsoft.

В связи с тем, что из 10-15 наших запросов к российской службе поддержки Микрософт нам реально помогли только один раз, мы попросили Микрософт направлять наши запросы сразу к буржуям. Ответы приходят от самых разных людей со странными именами и фамилиями. Сначала мы думали, что это китайцы. Потом пришли к мнению, что индусы. Им, конечно, большой респект, иногда диву даешься их знаниям.

На первой ступени мне прислали ссылку на hotfix. Мы его скачали, поставили. В Event log написано, что hotfix установлен successfully. НО! В списке установленных программ его нет, а в логах установки hotfix в c:\winnt\KBномерхотфикса.log сплошные ошибки. Реально hotfix не был установлен. Затем меня попросили проделать стандартную процедуру сбора информации – MS Report. Это софт, который запускает всевозможные утилиты, складывает результаты их работы в cab файл и этот 4-меговый ужатый файл нужно отослать службе поддержки.

Затем началась долгая переписка о том, что во всем виноват APC Powershut и сертификат Java машины, остатки которых обнаружены на сервере. Обновление, удаление этого софта и применение хотфикса заново ситуацию не изменили.

Вчера звонок в 9 вечера: «Хай, ит из Хумпур Бумпур фром Микрософт и т.д.» Оказывается, что нас перевели на новый уровень обслуживания и теперь будем общаться по телефону, т.к. по e-mail долго и непродуктивно. Договорились, что он перезвонит мне утром на работу. Можно сверять часы. Ровно в 10 началась наша 4х!!!-часовая беседа.

Сначала Хумпур Бумпур долго меня просил запускать dcdiag и netdiag, nslookup, ping и т.д. Я ему отослал результаты тестов и пошел на обед.
Вернувшись с обеда он перезвонил и сообщил мне, что проблема вышла за рамки ее компетенции и еще нужен спец по AD - Josh. Он задал пару вопросов и сказал, что без удаленного доступа продолжать работу нельзя. Для этого у Микрософта есть отличное решение – Microsoft Office Live Meeting. C помощью него можно расшарить доступ к своему рабочему столу, зайдя на страничку браузера и установив спец. компонент в Windows. В принципе это безопасно, т.к. ты видишь, что делают спецы Микрософта и можно им просто не давать управление, да они и сами не особо хотели.

В общем, находясь в одном российском городе, я зашел через RDP на сервер в другом городе и запустил туда спецов из ... Индии. Интернет воистину стирает границы. В конце концов в телефонной конференции сидело одновременно 5 человек из Микрософт и я. Все пялились на экран и один из них говорил мне, что делать, и я набирал команды и ставил галочки. Они это анализировали. Потом их осталось двое – спец по Exchange и спец по AD. Крутили, вертели - не работает и все тут. Начали устранять ошибки, полученные в результате работы DSDIAG. Последняя ошибка была такая: DC located is not Domain Controllers OU. Да, это правда. Каждый офис имеет свое OU и туда же перенесены все серверы. Переместив сервер в OU Domain Controllers, Exchange после рестарта сервиса System attendant увидел локальный DC, и воцарилось на земле счастье.

Итог всего этого. Хорошо, когда есть поддержка Микрософт. Методы работы этой службы и знания специалистов впечатляют. Затраты Микрософт – работа 5 человек, оплата за телефонную линию Индия-Россия в течении 4 часов. Впечатляет.

Очень понравился Microsoft Office Live Meeting. Они в нем как рыба в воде. Чувствуется богатый опыт по работе с клиентами, все вопросы ко мне сводились к Да/Нет. И все указания по запуску программ расчитаны на полных чайников.

Завтра меня ждет звонок в службу поддержки RedHat в России. Первое знакомство с ними закончилось фразами: «Ну? Ага!» с их стороны. Вот и сравним.

Опус про резервное копирование Exchange

Сегодня к нам в гости приезжал Computer Associates CA. У нас, за 5 лет эксплуатации Arcserve и Innoculate накопилось море вопросов, да и просто хотелось послушать про линейки продуктов СА. Одним из вопросов к СА был вопрос об оптимизации резервного копирования Exchange и мне захотелось закрепить свои мысли на "бумаге", т.е. в этом посте. Начинающие админы рано или поздно сталкиваются с проблемой резервного копирования. Какие вообще есть варианты? Копирование Exchange может быть осуществлено на трех уровнях: уровень баз данных, уровень почтовых ящиков, уровень писем. Это даже не уровни копирования, а уровни восстановления.

1. Уровень баз данных (Storage backup) - копирование баз данных почтовых сообщений.

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

Микрософт разработала специальный Backup API, чтобы делать резервное копирование без останова сервера. Именно этот способ поддерживает ntbackup.
http://www.msexchange.org/tutorials/Exchange-2003-Backup-Restore-NTBACKUP.html

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

Как правило к нам в 99% обращаются именно с такими просьбами. За 5 лет эксплуатации 7 серверов Exchange на базе оборудования HP только один раз я воспользовался режимом восстановления хранилищ. Они были разрушены в результате некорректной работы аппаратного RAIDа.

2. Уровень почтовых ящиков (Folder level backup) – это то, чего не хватало Exchange всю свою жизнь и нет сейчас. Микрософт конечно же предложило способ решения описанный выше и по этой ссылке:
http://www.msexchange.org/tutorials/Recovering-Mailboxes-Exchange2003-SP1.html

Стало удобнее, но не то что хотелось бы. Если есть ниша, то ее занимают третьи фирмы. Продукт CA BrightStore Arcserve поддерживает Brick level backup. Это агент, который по MAPI подсоединяется к Exchange. Представьте себе, как Outlook подсоединяется к серверу, копирует все папки в pst и отключается. Подобную процедуру проделывает и агент, сохраняя при этом информацию о папках в почтовых ящиках в собственной базе данных. После такого копирования Вы можете восстановить по запросу пользователя любую папку.
Недостатки этого способа – очень медленная работа. Вполне возможно, что Вам просто не хватит окна бэкапа. Зато появляется удобство при восстановлении.

3. Уровень писем (Message level backup)

Возможно, есть такие пользователи, которые точно знают, какое письмо им нужно восстановить. Как правило, сообщают только период времени и в крайнем случае от кого.
Неплохо бы было восстанавливать письма поштучно. У CA есть Backup Agent for Microsoft Exchange - Premium Add-on, который позволяет восстанавливать конкретные письма. По большому счету это тот же Brick level backup, только у него появилась мультипотоковость, т.е. данные будут вытягиваться одновременно из нескольких почтовых ящиков. Это конечно же увеличит скорость работы. Плюсом является хранение одной копии письма. Например, если рассылалось письмо размером 1 мегабайт, то в копии оно будет в одном экземпляре. Экономия ленточек J

Еще можно купить Ontrack PowerControls и выдирать из файла базы данных письма. Но я этот способ пока не пробовал.
http://www.ontrack.com/powercontrols/index.asp?pageTarget=Welcome&buttonName=PowerControls

Какой уровень резервного копирования нужен Вам, можете решить только Вы сами. Исторически сложилось так, что мы используем, и будем использовать CA Brightstore Arcserve в режимах Storage и Brick level backup. Возможно при обновлении лицензий мы заменим Brick level backup на Exchange - Premium Add-on.

На рынке существует масса продуктов резервного копирования. Смотрим ссылку:
http://www.msexchange.org/software/Backup-&-Recovery/

Рекомендую еще изучить следующие линки:
http://support.microsoft.com/ph/1773?sid=78

А вот тут есть еще и видео о том, как бэкапить Exchange.
http://www.microsoft.com/technet/prodtechnol/exchange/2003/operations.mspx

Микрософт объединит подразделение Exchange и Real-Time Collaborations (RTC)

Микрософт объединит подразделение Exchange и Real-Time Collaborations (RTC) в Unified Communications Group. Это значит, что в будущем Live Communications Server и IM станет ОПЯТЬ (Instant Messenger входил в состав Exchange 2000) частью сервисов Exchange.
Хорошо это или плохо покажет будущее.

Источник:http://news.com.com/

Рекомендую почитывать Technet Magazine

Рекомендую почитывать Technet Magazine, доступный по http://www.microsoft.com/technet/technetmag/

В январском выпуске опубликованы три любопытные статьи по Exchange. Хорошие, добротные статьи с картинками. :-) У них еще есть свой blog и выпуски можно выкачивать в виде HELP файлов.