Решение на данный момент: деинсталлировать апдейт 2449742. Ждем какого-нибудь исправления от Microsoft.

UPD: Проблема признана командой разработчиков Exchange, пока решение то же – не ставить данный апдейт.

UPD 2: Проблема решена, Microsoft выпустил исправление.

В Exchange Server 2007 и  Exchange Server 2010 RTM для удаления определённого письма из всех ящиков можно было воспользоваться командлетом Export-Mailbox:

Get-Mailbox -resultsize unlimited | Export-Mailbox -SubjectKeywords «Фотки со вчерашней вечеринки» -Deletecontent -confirm:$false

Но в Exchange 2010 sp1 командлет Export-Mailbox отсутствует, вместо него появился командлет New-MailboxExportRequest, который не позволяет удалить письмо из ящика. Тем не менее, сделать групповое удаление, всё же возможно, воспользовавшись командлетом  Search-Mailbox:

Get-Mailbox -resultsize unlimited | Search-Mailbox -SearchQuery ‘Subject:»Фотки со вчерашней вечеринки»‘ -DeleteContent -confirm:$false

После выполнения данной команды, произойдёт удаление всех писем с темой «Фотки со вчерашней вечеринки» из всех почтовых ящиков Exchange.

Какие сразу приходят в голову варианты решения: 1) Microsoft Transporter Suite и 2) Notes Migrator for Exchange от Quest Software (продаётся от 250 лицензий). Как вы думаете, какой из этих вариантов правильный? Мы то знали ответ, но решили поэксперементировать, и выбрали вариант №1, да и платить за лишние 50 лицензий Quest не хотелось. Об этом мы конечно потом несколько раз пожалели, но зато есть о чём написать).

Как известно Microsoft Transporter Suite поддерживает только Exchange 2007 и не поддерживает Exchange 2010. А поскольку наш лес уже подготовлен под Exchange 2010, значит Exchange 2007 мы тут уже не поставим. Поэтому мы решили поставить в отдельному лесу Exchange 2007,  а затем смигрировать из него ящики в Exchange 2010 путём Cross-Forest миграции.

Мигрируем Lotus на Exchange 2007.

Пошаговых инструкций писать не буду, в интернете их полно, но почему-то нигде не сказано про подводные камни, поэтому я сделаю акцент лишь на некоторых моментах. Ну соответственно ставим новый контроллер домена в отдельном лесу, ставим на него же Exchange 2007 sp3. Скачиваем и ставим  Transporter Suite (64-битный). Скачиваем и ставим IBM Lotus Notes 8.5 RUS (триал скачивается бесплатно после регистрации). Запускаем Lotus Notes и настраиваем его на подключение к Lotus Domino серверу под административной учетной записью.

1) Разрешаем имперсонализацию пользователей в каталоге EWS, чтобы Transporter Suite мог под административной учётной записью импортировать почту в ящики пользователей:

Общий вид команды:

Add-ADPermission -Identity (get-exchangeserver).DistinguishedName -User (Get-User -Identity Administrator | select-object).identity -extendedRight ms-Exch-EPI-Impersonation

ну или в частности:

Add-ADPermission -Identity ‘CN=EXCH2K7,OU=Domain Controllers,DC=domain,DC=local’ -User ‘domain\Administrator’ -ExtendedRights ms-Exch-EPI-Impersonation

2) Увеличиваем длину HTTP запроса. По умолчанию максимальный размер запроса равен 4 МБ, соответственно ни одно  письмо большего размера не смигрируется. Поэтому увеличиваем данное значение. Для этого правим файл web.config виртуальной директории в IIS   \EWS. Находим там строчку <httpRuntime maxRequestLength= «4096″>  и правим её на большее значение, скажем на «102400″, что равняется 100 МБ. Я рекомендую редактировать эти параметры не вручную, через блокнот, а через расширения консоли IIS Manager, так меньше вероятность допустить ошибки и испортить файл конфигурации. Расширение консоли IIS 7 можно скачать по ссылке. Соответственно после установки расширения, для правки запускаем IIS Manager, раскрываем Sites\Default Web Site\EWS, справа в консоли запускаем Configuration Editor, в разделе Section выбираем: system.web/httpRuntime, правим параметр maxRequestLength и нажимаем Apply.

3) Увеличиваем таймаут соединений. Для этого в IIS Manager выбираем Default Web Site, справа в консоли выбираем Limits и задаём большее значение, скажем 300 с.

После внесения изменений перезапускаем IIS:

iisreset /noforce

3) Синхронизируем каталог Lotus Domino с Active Directory. Запускаем Microsoft Transporter for Lotus Domino Console, нажимаем Enter Domino Credential, вводим пароль администратора домино. Раскрываем Migrate\Directory\Users. Выбираем всех пользователей и нажимаем Migrate Selected Users. Задаём OU для новых пользователей и пароль, можно сразу выбрать создать ящик в Exchange 2007.

4) Мигрируем ящики Lotus в Exchange 2007.  Запускаем Microsoft Transporter for Lotus Domino Console, переходим Migrate\Mailboxes, выбираем все ящики и нажимаем Migrate Selected Mailboxes. Теоретически процесс должен был бы занять несколько часов и завершиться полной миграцией всех ящиков, но не всё оказалось так просто. На миграции примерно 10-го из 200 ящиков вылетела ошибка System.OutOfMemoryException и миграция прекратилась. Мы попробовали повторно запустить процесс, временно пропустив данный ящик, но вскоре снова получили аналогичную ошибку. Иногда вылетала ошибка вида типа Pipe has been ended. Поискав решения данной проблемы мы выяснили, что это ошибка в коде самого Transporter Suite, и она неисправима! Ошибка возникает вследствие переполнения буфера памяти при миграции ящиков, содержащих письма большого объёма. При миграции Transporter Suite сначала определёнными порциями извлекает письма из Lotus Domino, и затем их через EWS инжектирует в ящик Exchange. Вся эта порция писем до процесса инжектирования хранится в памяти. Мы пробовали увеличивать объём памяти сервера до 12 ГБ, но и это не помогло, Transporter Suite занимал всю память сервера и завершался с ошибкой. Ждать исправления данной ошибки от Microsoft – бесполезно, ввиду того, что разработка продукта давно прекращена и он снят с поддержки.

В итоге мы сначала выполнили миграцию всех ящиков, которые мигрировались без ошибок, выписывая имена ящиков, миграция которых вызывала ошибку. Причем после каждой ошибки процесс миграции приходилось запускать заново, заново вводить Domino Credentials, т.к. иногда вылетал сам процесс Transporter Suite , иногда с ошибкой вылетал процесс Notes-клиента. В итоге, через дня 3 мы смигрировали 170 ящиков из 200. Соответственно получили 30 ящиков, миграция которых завершалась с ошибкой. Чтобы выполнить их миграцию, мы решили: во-первых мигрировать ящики по одному, а во вторых, в пределах одного ящика мигрировать письма порциями, а именно разбивая по датам. Для этого мы воспользовались следующей командой:

Move-DominoMailbox ‘user@lotus-domain.com’ -TargetMailboxDatabase ‘EXCH2007\First Storage Group\Mailbox Database’ -EmailStart 01.01.2001 -EmailEnd 31.12.2005

затем

Move-DominoMailbox ‘user@lotus-domain.com’ -TargetMailboxDatabase ‘EXCH2007\First Storage Group\Mailbox Database’ -EmailStart 01.01.2006 -EmailEnd 31.12.2008

и т.д.

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

Мигрируем Exchange 2007 на Exchange 2010.

Для начала нам нужно было развернуть в организации Exchange 2010. При установке которого мы столкнулись с рядом проблем, а именно сервер уже когда-то был развёрнут, а затем неправильно удалён. При установке выдавалась ошибка Database is Mandatory. Одна из проблем заключалась в том, что у всех пользователей остались атрибуты Exchange, ссылающиеся на старый сервер. Чтобы их удалить разом у всех пользователей, мы воспользовались бесплатными PowerShell командлетами от Quest Software – ActiveRoles Management Shell for Active Directory, которые можно скачать по ссылке. Для этого выполнили команды:

$userlist = Get-QADUser -IncludeAllProperties
$userlist | ForEach { Set-QADUser $_ -ObjectAttributes @{msexchmailboxguid=»; msexchhomeservername=»; legacyexchangedn=»; mail=»; mailnickname=»; msexchmailboxsecuritydescriptor=»; msexchpoliciesincluded=»; msexchrecipientdisplaytype=»; msexchrecipienttypedetails=»; msexchumdtmfmap=»; msexchuseraccountcontrol=»; msexchversion=» } }

После установки Exchange 2010 sp1, можно было приступать к процессу миграции. Существует несколько путей кросс-доменной миграции Exchange 2007 на Exchange 2010 sp1. И многое зависит от начальных условий, так, например в нашем случае можно было сначала установить во временном лесу (где развёрнут Exchange 2007) CAS сервер под управлением Exchange 2010, а затем выполнить миграцию между лесами. Можно было мигрировать и напрямую с Exchange 2007, но с соответствующей подготовкой атрибутов всех пользователей в конечном лесу. Причем процесс связан с использованием Microsoft Identity Lifecycle Manager и различных скриптов. Также в нашем случае особенность заключалась в том, что в конечном лесу уже были созданы все пользователи и ящики. В общем мы решили не заморачиваться, на синхронизации атрибутов, а пойти наиболее простым с нашей точки зрения путём, и выполнить миграцию через старые добрые .pst – файлы.

Для этого сначала выполнили экспорт всех ящиков в .pst – файлы на Exchange 2007. Напоминаю, что командлет Export-Mailbox можно использовать только в 32-х разрядной версии Exchange 2007, требуется развернуть 32-х битный сервер, например Windows Server 2008 x86, скачать и развернуть Exchange Server 2007 sp3 x86, скачать и развенуть Outlook 2007/2010 x86. После чего с данного сервера можно будет выполнять:

get-mailbox | Export-Mailbox -PSTFolderPath z:\

После завершения процесса экспорта, на диске z:\ (=\\fs\exported_mailboxes) мы получим 200 .pst файлов вида aliace.pst. Затем выполняем импорт данных файлов в ящики Exchange 2010. Соответственно предварительно в Exchange 2010 мы создали ящики для всех необходимых пользователей. Для запуска самого процесса импорта нужно выполнить следующую команду:

Dir \\fs\Exported_Mailboxes\*.pst | %{ New-MailboxImportRequest -Name ImportPST -BatchName ImportPST_Bulk -Mailbox $_.BaseName -FilePath $_.FullName}

отследить состояние процесса миграции можно при помощи командлета Get-MailboxImportRequest, а после завершения процесса, лучше все очереди очистить командлетом Remove-MailboxImportRequest.

В общем-то после завершения процесса все ящики будут смигрированы, и предварительно можно было бы сказать, что задача выполнена. Есть правда в этом процессе небольшая особенность. А именно, именование папок внутри ящика. Эти имена создаются при первом подключении пользователя к ящику, либо при помощи Outlook, либо при помощи OWA. Соответственно,  если пользователь при первом подключении использовал русскую версию Outlook 2010, то и папки у него будут называться Входящие, Отправленные, Удалённые и т.п., а если английскую, то Inbox, Send Items, Deleted и т.д. Аналогично и при подключении через OWA, там зависит от языка, выбранного в браузере и выбора самого пользователя. И к сожалению, никакими средствами централизовано для всех это не задашь. Но мы попытались использовать некий work around.

Задание русских имён папок Outlook для всех почтовых ящиков Exchange.

1) Даём системному администратору права на все ящики Exchange:

Get-Mailbox | Add-MailboxPermission -user Administrator -AccessRights FullAccess

2) На OWA Virtual Directory ставим встроенную аутентификацию так, чтобы запуская Internet Explorer под администратором и открывая OWA, у нас не спрашивало логин и пароль, а автоматически попадало в ящик администратора.

3)  Задаём язык по умолчанию для клиентов OWA.

Set-OwaVirtualDirectory -identity «Owa (Default Web Site)» -LogonAndErrorLanguage 1049 -DefaultClientLanguage 1049

get-mailbox | set-mailbox -Languages «ru-RU»

4) Заходим в каждый ящик, через OWA под администратором при помощи браузера, где языком по умолчанию выбран русский.

get-mailbox | foreach-object -process {start iexplore.exe «https://exch2010/owa/$_@domain.com»; start-sleep 5; taskkill /im iexplore.exe}

Данная команда последовательно выводит весь список ящиков, запуская для каждого ящика Internet Explorer с параметром https://exch2010/owa/aliace@domain.com, после 5 секунд ожидания, процесс Internet Explorer убивается, и затем открывается новый ящик. По сути каждый раз происходит вход в ящик пользователя под администратором.

Перевод входящей почты на Exchange 2010.

Когда были завершены все описанные выше действия, мы предоставили пользователям доступ к почтовой системе через OWA, а также всем установили и настроили Outlook 2010 и попросили пользователей, ознакомиться с новой почтовой системой и проверить, корректно ли были смигрированы все их данные (за исключением последнего месяца). Всё время, пока у нас шёл процесс миграции вся входящая почта продолжала приходить в Lotus Domino. Когда пользователи ознакомились с новой системой электронной почты и убедились, что всё смигрировано верно, было решено переключить входящую почту на Exchange. Все пользователи были проинформированы, что c понедельника они начинают использовать Outlook и Lotus будет более недоступен. В пятницу вечером мы изменили публикацию 25-го порта на TMG 2010 и вся внешняя почта стала приходить на Exchange Server. Теперь нам оставалось только домигрировать ту почту, которая пришла в ящики пользователей с начала нашего процесса миграции. Для этого, выполняем туже самую последовательность действий, но везде задаём интервал только за последний месяц. Сначала мигрируем из Lotus Domino в Exchange 2007:

Get-DominoMailbox | Move-DominoMailbox -TargetMailboxDatabase ‘EXCH2007\First Storage Group\Mailbox Database’ -EmailStart 01.01.2011 -EmailEnd 31.01.2011

затем выгружаем из Exchange 2007 в .pst файлы:

get-mailbox | Export-Mailbox -PSTFolderPath z:\ -StartDate 01.01.2011 -EndDate 31.01.2011 -confirm:$false

затем импортируем в Exchange 2010:

Dir \\fs\Exported_Mailboxes\*.pst | %{ New-MailboxImportRequest -Name ImportPST -BatchName ImportPST_Bulk -Mailbox $_.BaseName -FilePath $_.FullName}

По завершению этой операции, казалось бы, что все дела сделаны и наши мучения закончились, но оказалось, что это не так. Оказывается вся новая почта, которая пришла за последний месяц, смигрировалась в ящики пользователей под английскими именами папок. Т.е. у каждого пользователя в ящике оказалось по 2 экземпляра каждой папки – на русском и на английском: «Входящие» и «Inbox», «Отправленные»  и «Sent Items» и т.д. – Причем выглядела эта ситуация очень удручающе! 200 ящиков! Удалять ящики и выполнять миграцию заново мы уже не могли, 1 – это долго, 2 – у пользователей уже поприходили в ящики новые письма, которых нет в Lotus. Кроме того в русских и в английских папках были дубликаты, т.к. процесс миграции был долгий и одни ящики мигрировались неделю назад, а другие месяц назад, а последняя миграция делалась за 1 месяц для всех. Если бы миграция была произведена в нужные папки, то был бы произведён процесс слияния и дубликатов бы не возникло.

В общем времени особо долго думать у нас не было и мы решили удалить все английские папки и мигрировать данные за последний месяц заново. Соответственно возник вопрос, как наиболее быстро удалить необходимые папки из 200 почтовых ящиков. Если покопаться на MSDN и иметь навыки программиста, то можно было быстро написать программку для Exchange Web Services, но мы (видимо не имея навыков программиста) пошли немного другим путём, а именно решили использовать бесплатную библиотеку RDO, которую можно скачать по ссылке. Собственно скачиваем архив и распаковываем его в Windows\System32, после чего выполняем regsvr32 Redemption64.dll.

Затем создаём следующий PowerShell скрипт Delete_Folders.ps1:

$rdo = new-object -com Redemption.RDOSession
$aliace = echo($_.BaseName+»@domain.com»)
$rdo.LogonExchangeMailbox(«$aliace»,»exch2010″)#$rdo.CurrentUser.name
$test = $rdo.Stores.DefaultStore.IPMRootFolder.folders | where { ($_.name -eq «Drafts» ) -or ($_.name -eq «Inbox») -or ($_.name -eq «Junk E-Mail») -or ($_.name -eq «Notes») -or ($_.name -eq «Outbox») -or ($_.name -eq «Sent Items»)}
foreach ($test in $test) {$test.delete()}
$rdo.logoff()

Затем выполняем:

$users = Dir \\fs\Exported_Mailboxes\new\*.pst
$users | foreach {.\Delete_Folders.ps1}

Вкратце поясню. Данный скрипт удалит папки Inbox, Outbox, Notes, Junk E-Mail, Drafts и Sent Items из всех ящиков, .pst файлы которых лежат в папке \\fs\Exported_Mailboxes\new\.

Собственно после этого, производим повторный процесс миграции писем, пришедших в Lotus за последний месяц, но теперь делаем это немного по другому, а именно указываем из какой папки и в какую мигрировать письма:

Мигрируем из папки «Inbox» в папку «Входящие». В Exchange все папки имеют системные имена, которые не зависят от языка. Так, например, папка «Входящие» имеет системное имя #Inbox#:

Dir \\fs\Exported_Mailboxes\new\*.pst | %{ New-MailboxImportRequest -Name ImportPST -BatchName ImportPST_Bulk -Mailbox $_.BaseName -FilePath $_.FullName -ConflictResolutionOption KeepLatestItem -SourceRootFolder «Inbox» -TargetRootFolder «#Inbox#»}

Мигрируем из папки «Sent Items» в папку «Отправленные». Папка «Отправленные» имеет системное имя #SentItems#:

Dir \\exch2007\Exported_Mailboxes\new\*.pst | %{ New-MailboxImportRequest -Name ImportPST -BatchName ImportPST_Bulk -Mailbox $_.BaseName -FilePath $_.FullName -ConflictResolutionOption KeepLatestItem -SourceRootFolder «Sent Items» -TargetRootFolder «#SentItems#»}

После данной процедуры, все письма попали в нужные папки. И в общем-то процесс миграции был завершён, но некоторые пользователи нам создали дополнительные трудности, а именно, забыв выполнить процедуру синхронизации своих адресных книг, ввиду чего они остались без личных контактов. Проблема заключается в том, что  Lotus Notes по умолчанию хранит все личные контакты пользователей в .nsf-файлах на локальных компьютерах пользователей. Для синхронизации контактов на сервер каждый пользователь должен в Lotus Notes запустить Synchronize Address Book из меню Actions, о чем сотрудники были проинформированы. Но естественно, как это всегда бывает, часть пользователей эту задачу проигнорировали и опомнились только после завершения всех процедур миграции. Соответственно для некоторых пользователей отдельно пришлось домигрировать личные контакты.

Миграция контактов.

Мигрируем всё, кроме элементов почты из Lotus на Exchange 2007:

Get-DominoMailbox | Move-DominoMailbox -TargetMailboxDatabase ‘EXCH2007\First Storage Group\Mailbox Database’ -ExcludeEmail -ExcludeSchedule -ExcludeTask

Мигрируем контакты из Exchange 2007 в .pst, чтобы сэкономить время, мигрируем лишь пользователей из списка users_wo_contacts.txt, Соответсвенно мигрируем только папку «Contacts»:

more users_wo_contacts.txt | Export-Mailbox -PSTFolderPath z:\contacts -IncludeFolders «\Contacts»

Импортируем контакты в Exchange 2010:

Dir \\fs\Exported_Mailboxes\Contacts\*.pst | %{ New-MailboxImportRequest -Name ImportPST -BatchName ImportPST_Bulk -Mailbox $_.BaseName -FilePath $_.FullName -ConflictResolutionOption KeepLatestItem -SourceRootFolder «Contacts» -TargetRootFolder «#Contacts#»}

На этом наш проект в общем-то был завершён.

Кто-то, прочитав данную заметку, возможно спросит, а не пробовали ли мы мигрировать с использованием Exchange Server 2003, который имел встроенный Connector for Lotus Notes, и я отвечу, что да пробовали – и это ещё хуже! Во-первых Exchange Server 2003 плохо понимает письма в формате HTML и при миграции переделывает их в формат RTF, при этом перегаживая всё форматирование, во-вторых он плохо разбирает кодировку и почти все письма отображаются иероглифами (хотя это можно обойти используя прямую миграцию в .pst, а затем импорт .pst файлов в Exchange 2007, используя библиотеки Outlook 2007) и в третьих Exchange 2003 не может создавать .pst файлы больше 2-х ГБ. Но если всё же кто-то, вдруг, решится мигрировать, используя Exchange 2003 и прямой экспорт в .pst, есть небольшой совет: По умолчанию Exchange 2003 при миграции из Lotus все .pst файлы защищает паролем, причем у каждого .pst-файла пароль свой. Соответствие .pst-файлов и паролей хранится в текстовом файле в тойже директории, где и сами pst-шники. Но это очень неудобно для дальнейшего использования, в частности для операций пакетного импорта файлов. Чтобы .pst файлы экспортировались без паролей, нужно установить специальный патч на Exchange 2003, патч можно скачать по ссылке. Патч ставится только на Exchange 2003 sp1. После установки патча, нужно в разделе реестра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange\MSExchangeMailMig, создать ключ CreateWithoutPassword типа REG_DWORD со значением «1″.

Подытожив, хочу дать несколько советов:

1 – используйте платные средства миграции, например Notes Migrator for Exchange от Quest Software;

2 – тщательно всё планируйте и тестируйте до миграции в рабочей среде;

3 – почаще делайте бэкапы. Если у вас используется система виртуализации, то можно использовать снапшоты;

4 –  Adrenaline Rush лучше всего брать в Ашане, там дешевле)

Для Windows Server 2008 R2:

• Windows6.1-KB977020-v2-x64.msu – 0,6 Мб.
• Windows6.1-KB979099-x64.msu – 2,2 Мб.
• Windows6.1-KB979744-x64.msu – 6,5 Мб.
• Windows6.1-KB982867-v2-x64.msu – 4,4 Мб.
• Windows6.1-KB983440-x64.msu – 3,5 Мб.
• FilterPack64bit.exe – 3,9 Мб.

Для Windows Server 2008:

• Windows6.0-KB973136-x64.msu – 0,7 Мб.
• Windows6.0-KB977592-x64.msu – 0,3 Мб.
• Windows6.0-KB977624-v2-x64.msu – 3,2 Мб.
• Windows6.0-KB979744-x64.msu – 6,5 Мб.
• Windows6.0-KB979917-x64.msu – 3,5 Мб.
• Windows6.1-KB983440-x64.msu – 3,5 Мб.
• FilterPack64bit.exe – 3,9 Мб.

Update: совсем забыл указать требуемые для установки роли Unified Messaging компоненты:

• UcmaRuntimeSetup.exe – 16 Мб.
• SpeechPlatformRuntime.msi – 2,8 Мб.

Exchange Server 2010 позволяет отправлять и принимать SMS через Outlook или OWA, используя обычный коммуникатор, подключенный по протоколу ActiveSync. Отправка SMS поддерживается с использованием коммуникаторов на базе Windows Mobile 6.1 и старше. При подключении к Exchange Server 2010 коммуникатора на базе Windows Mobile 6.5 по протоколу Active Sync, можно выбрать параметр синхронизации «Текстовые сообщения.» Но, когда вы используете коммуникатор на базе Windows Mobile 6.1 (коих сейчас больше всего), данный пункт меню поумолчанию отсутствует. Но при первом подключении к коммуникатора к Exchange Server 2010, в коммуникатор должно прийти специальное письмо-уведомление, в котором будет ссылка на загрузку обновления с сайта Microsoft для Outlook Mobile. Подробнее об этом можно прочитать тут, а инструкцию по настройке можно найти в следующем документе.

Но почему-то на практике не всё оказалось так гладко. Мой коммуникатор Samsung i900 (Omnia, WiTu), работающий под управлением Windows Mobile 6.1, подключился к Exchange 2010, применил политики, синхронизировал почту, календарь и контакты, но никаких уведомлений об обновлениях я так и не получил. И соответсвенно никаких функций по синхронизации SMS у меня так и не появилось. Поиски в Интернете никаких результатов тоже не дали.

Однако вернувшись к инструкции, я увидел скриншот со ссылкой на соответствующее обновление http://go.microsoft.com/fwlink/?LinkId=150061

Пройдя по этой ссылке, мы попадаем на загрузку файла обновления Outlook Mobile: https://outlook.vo.msecnd.net/OutlookMobileSetup.cab На самом деле это не файл обновления, а лишь инсталлятор и весит он всего 180 КБ. Далее этот инсталлятор загружает соответсвующее обновление через Интернет, в соответствие с текущей версией операционной системы коммуникатора и локализации.

Далее я вручную загрузил этот CAB-файл на мобильное устройство и запустил его. Но при установке получил сообщение об ошибке 0×80040700 «Не достаточно свободного места». На телефоне было свободно около 5 МБ системной памяти, но нигде не говорится о том сколько же требуется для установки. Эту информацию мне удалось найтив лог-файле Outlook Mobile, который расположен тут: Windows\OutlookLive\ClientLog0.txt. Там была строчка disk space Needed: 10709112. Как только я высвободил необходимое пространство на внутренней памяти, обновление успешно установилось, и в настройках синхронизации появился соответсвующий пункт меню: »Текстовые сообщения«.

После завершения процесса синхронизации, перезапустив  Microsft Office Outlook или OWA, вы увидите, что в папке входящие помимо писем, появятся и ваши SMS сообщения.

Теперь SMS-сообщения можно и отправлять прямо из Outlook или OWA. Можно просто ответить на входящее сообщение, а можно и создать новое. В меню «Создать», появился новый пункт «Текстовое сообщение».

Причём, можно и не набирать телефон вручную, достаточно выбрать людей из адресной книги, написать SMS и нажать отправить. По протоколу ActiveSync сообщение попадёт в ваш коммуникатор, который сразу же отправит его получателю. И через несколько секунд ваша SMS-ка придёт на мобильный телефон соответствующего человека. Если он вам ответит, то через несколько секунд его ответ вы увидите у себя в Outlook. При этом на самом телефоне SMS-переписка также сохраняется.

Единственное, что я заметил, так это, что при отправке SMS-сообщений через Outlook, не запрашиваются подтверждения о доставке.

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

]]> http://www.lankey.ru/blog/2010/04/19/send-sms-exchange-server-2010/feed/ 0 http://www.lankey.ru/blog/2010/03/30/ne-dostavlyayutsya-golosovye-soobsheniya-v-exchange-2010/ http://www.lankey.ru/blog/2010/03/30/ne-dostavlyayutsya-golosovye-soobsheniya-v-exchange-2010/#comments Tue, 30 Mar 2010 08:31:37 +0000 Ярослав Никифоров http://blogs.lankey.ru/?p=509 Столкнулись с проблемой: перестали доставляться сообщения голосовой почты, отправленные пользователям Exchange через Unified Messaging. В журнале событий при этом повторяются следующие ошибки:

Source: MSExchange Unified Messaging
Event ID: 1185
Task Category: UMCore
The Unified Messaging server failed to submit a message to Hub Transport server 'EXCHANGE' due to the following error: Unexpected server response. Expected: 220, actual: 500, whole response: 500 5.3.3 Unrecognized command

Source: MSExchange Unified Messaging
Event ID: 1423
Task Category: UMCore
A pipeline stage encountered the following error. Details : 'Microsoft.Exchange.UM.UMCore.SmtpSubmissionException: Submission to the Hub Transport server failed. The operation will be retried. ---> Microsoft.Exchange.Net.ExSmtpClient.UnexpectedSmtpServerResponseException: Unexpected SMTP server response. Expected: 220, actual: 500, whole response: 500 5.3.3 Unrecognized command

   at Microsoft.Exchange.Net.ExSmtpClient.SmtpTalk.CheckResponse(ServerResponseInfo response, Int32 expectedCode)
   at Microsoft.Exchange.Net.ExSmtpClient.SmtpTalk.Command(SmtpChunk[] chunks, SmtpCommandType command, Int32 expectedCode)
   at Microsoft.Exchange.Net.ExSmtpClient.SmtpTalk.StartTls()
   at Microsoft.Exchange.Net.ExSmtpClient.SmtpClient.Submit()
   at Microsoft.Exchange.UM.UMCore.SmtpSubmitStage.SubmitMessage()
   at Microsoft.Exchange.UM.UMCore.SmtpSubmitStage.InternalDoSynchronousWork()
   --- End of inner exception stack trace ---

Server stack trace:
   at Microsoft.Exchange.UM.UMCore.SmtpSubmitStage.HandleTransientSmtpFailure(Exception e, InternalExchangeServer smtpServerToUse)
   at Microsoft.Exchange.UM.UMCore.SmtpSubmitStage.InternalDoSynchronousWork()
   at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs)
   at System.Runtime.Remoting.Messaging.StackBuilderSink.AsyncProcessMessage(IMessage msg, IMessageSink replySink)

Exception rethrown at [0]:
   at System.Runtime.Remoting.Proxies.RealProxy.EndInvokeHelper(Message reqMsg, Boolean bProxyCase)
   at System.Runtime.Remoting.Proxies.RemotingProxy.Invoke(Object NotUsed, MessageData& msgData)
   at Microsoft.Exchange.UM.UMCore.SynchronousPipelineStageBase.SynchronousWorkDelegate.EndInvoke(IAsyncResult result)
   at Microsoft.Exchange.UM.UMCore.SynchronousPipelineStageBase.EndSynchronousWork(IAsyncResult r)'

Роли Hub Transport и Unified Messaging находятся на одном и том же сервере, но тем не менее, голосовое сообщение, оставленное пользователем, в ящик получателя не попадает.

Из приведенных ошибок видно, что при попытке установления SMTP-соединения служба Hub Transport выдает ответ, что команда не распознана. По подробной информации видно, что ошибка возникает в процессе работы процедуры StartTls, то есть имеет место быть неудачная попытка установки шифрованного соединения.

Ошибка возникла из-за следующей тонкости:

Сам сервер внутри сети называется EXCHANGE.имя-домена. А опубликован в Интернет он под именем MAIL.имя-домена. Соответственно, в процессе настройки в Receive Connector захотелось внести изменения, чтобы при подключении сервер отвечал не своим внутренним именем, а внешним, отличающимся от внутреннего. Но – при несовпадении FQDN, предоставляемого в ответ на HELO или EHLO, и системного имени сервера, отказывается работать включенная по умолчанию аутентификация Exchange Server authentification. Соответственно, эта галочка и была выключена.

А если выключена Exchange Server authentication – то в ответ на команду EHLO сервер в списке допустимых команд НЕ ВЫВОДИТ команду X-ANONYMOUSTLS, и не отвечает на нее. А службы Unified Messaging пытаются установить соединение с Hub Transport именно этим способом.

Решение: в нашем случае помогло включение обратно пункта Exchange Server authentication, смена выдаваемого FQDN в окне Receive Connector обратно на внутреннее имя сервера, и перезапуск служб MSExchange Hub Transport и MSExchange Unified Messaging.

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

На семинаре будут рассмотрены решения на базе Windows Server 2008 R2, Exchange Server 2010, и платформа для объединённых коммуникаций на базе Office Communications Server 2007 R2. В рамках семинара будет рассказано о продуктах для обеспечения информационной безопасности компании GFI.

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

Количество мест ограничено!

Для участия в семинаре требуется регистрация: http://www.lankey.ru/?id=1072#reg

Информация о семинаре на сайте Microsoft: http://www.microsoft.com/rus/events/detail.mspx?eventid=1032445810

Информация о семинаре на сайте GFI: http://www.gfi.ru/getnews.php?newsid=50

Информация о семинаре на сайте LanKey: http://www.lankey.ru/?id=1072

У одного из наших клиентов мы уже внедряем Exchange 2010, поэтому дистрибутив был тут же забран для обновления.

С Release Candidate до RTM версии апгрейд проводится просто запуском установки – обновление прходит без проблем. С Beta-версии до RTM апгрейд не предусмотрен – надо деинсталлировать Beta и устанавливать RTM.

Недавно к нам обратилась одна компания с просьбой восстановить Exchange Server. В компании работает около 500 человек. Занимается компания бизнесом в Интернете. Можно себе представить насколько критичным для данной компании является сервис электронной почты, куда приходят все заказы от клиентов, и происходит общение между сотрудниками.

В тот момент, когда компания обратилась за помощью к нам, почта уже не работала 2 дня, руководство было в панике. Самое плохое, что всё это время системные администраторы пытались восстановить работоспособность почтового сервиса самостоятельно, и как всегда это бывает, лучше бы они ничего не делали! И почему за помощью к специалистам обращаются не начальном этапе, а когда уже всё находится в полной {nslookup 83.102.180.3}?)

В компании был только один Exchange Server 2007 Standard Edition, на котором располагались все ящики пользователей. Ящики большего числа пользователей были распределены по 2-м базам данных, каждая по 250 ГБ. Было также ещё 2 MailBox Store для руководства и 1 Public Folder Store. Резервное копирование выполнялось при помощи Acronis True Image Echo Enterprise Server, который выполнял снимок всего диска.

Пролог

Итак, что же случилось? Хронология событий такая: В одну прекрасную ночь в офисе компании выключили свет, UPS продержал сервера 1 час, затем PowerChute начал завершать работу операционных систем, но Exchange Server завершить работу не успел, и UPS выключился. На утро системные администраторы включили сервера, и обнаружили, что Exchange Server не подмонтировал 2 самые большие базы данных, в которых находились ящики 250 пользователей. Попытки смонтировать БД вручную не увенчались успехом, ввиду их физического повреждения, несмотря на то, что БД размещались на массиве RAID 10 (плохо, что вместе с логами транзакций). Далее системные администраторы решили вытащить базы данных из резервных копий Acronis-а. Который сказал, что процесс восстановления будет завершён через 10 часов. Руководство сказало, что это слишком долго и нужно сделать так, чтобы пользователи смогли получать хотя бы новые письма, пока идёт процесс восстановления. Этот метод называется Dial-tone Recovery.

Но то ли системные администраторы не очень внимательно читали документацию, толи не так её поняли, но сделали они всё примерно так: Они решили создать новую БД, чтобы переместить в неё всех пользователей. Запустили Exchange Management Console перешли в раздел Server Configuration\Mailbox, создали новую БД и попытались её смонтировать, на что получили ошибку. Они долго разбирались в природе этой ошибки и затем поняли, что ошибка была вызвана тем, что они пытались смонтировать 6-ю БД в Exchange Server Standard, который поддерживает только 5! Следующим их действием стала попытка удалить повреждённую БД, которая тоже не увенчалась успехом, потому что в этой базе были ящики пользователей и её нельзя удалять (точнее Exchange не даёт этого сделать)! Эта ситуация вогнала системный администраторов в небольшой ступор (и лучше бы они в нём и оставались), так нет же, среди них нашёлся один знаток Active Directory, который вызвался помочь. Он взял и удалил базы данных сервера Exchange через ADSIedit.msc. Радостные и благодарные ему системные администраторы Exchange, создали 2 новые БД, и смонтировали их. Этот процесс естественно прошёл успешно.

Но их радость очень быстро закончилась! Когда администраторы попытались переместить пользователей в новые пустые БД, то столкнулись с новой «проблемкой». При открытии консоли Exchange Management Console > Recipient Configuration > Mailbox, при открытии любого ящика стала выдаваться ошибка The properties on User have invalid data. А командлеты Get-MailBox и Move-Mailbox выдавали ошибку Object Domain/OU/User has been corrupted and it is in an inconsistent state. Database is mandatory on user MailBox.

В этот момент системные администраторы поняли, что дела совсем плохи, надежд больше нет и лучше приложить все усилия к написанию нового резюме! В конце концов, руководство решило обратиться за помощью к сертифицированному партнёру Microsoft, в компанию «ЛанКей».

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

Восстановление.

Часов через 10 восстановились базы данных недельной давности, из Acronis-овского бэкапа. Но ни одна из них не стала монтироваться. Ещё раз убеждаемся в том, что Acronis не умеет резервировать Exchange Server и все БД были в состоянии Dirty Shutdown. Хотя базы данных были зарезервированы вместе с логами, но чтобы выполнить софт-рековери, логов в архиве не хватало. Пришлось восстанавливать базы данных при помощи eseutil /p. На каждую базу данных потребовалось ещё 5 часов восстановления. После этого базы смонтировались. На всякий случай, мы также запустили проверку логической структуры при помощи isinteg.

Теперь мы должны были разобраться с тем, что ящики пользователей нельзя было ни переместить, ни восстановить. Проанализировав ситуацию, мы выяснили, что у всех пользователей был удалён атрибут homeMDB, точнее был удалён не сам атрибут, а его значение. В тестовых целях, мы восстановили данный атрибут у одного из пользователей вручную через ADSIedit.msc. И теперь мы могли перемещать и восстанавливать ящик данного пользователя. Но восстанавливать значения этого атрибута у 500 пользователей было бы довольно трудоёмкой задачей. Поэтому мы решили как-то автоматизировать данный процесс. Первым в голову конечно же пришло использовать Power Shell. Но командлеты для управления Active Diretory появились только в Windows Server 2008 R2, здесь же вся инфраструктура была построена на Windows Server 2003. Но выход был найден, мы решили использовать PowerShell Commands for Active Directory от Quest Software http://www.quest.com/powershell/activeroles-server.aspx (спасибо Ярославу за подсказку).

Для задания атрибута homeMDB, использовался командлет:
Set-QADUser user_name -ObjectAttributes @{HomeMDB=’FQDN_базы’}

Теперь оставалось задать соответствующий атрибут каждому пользователю. Но не всё оказалось так просто. Ведь у нас было 2 базы данных и 250 пользователей, и нет никакой информации о том, какой пользователь в какой БД размещался. И соответственно непонятно какой атрибут, какому пользователю присваивать. Мы задались вопросом: как выяснить, какой пользователь, в какой базе находился? Ведь в Active Directory эта информация была стёрта. Единственное место, где эта информация осталась – это сами базы данных. И вытащить её оттуда можно было при помощи командлета Get-MailboxStatistics.

Поскольку Get-MailboxStatistics – является командлетом Exchange, а Set-QADUser – является командлетом Quest. Нужно было подгрузить обе оснастки в один сеанс PowerShell, для чего использовали командлет Add-PSSnapin. Итак, для задания атрибута homeMDB для пользователей из db1 использовали следующий скрипт:

Add-PSSnapin Microsoft.Exchange.Management.PowerShell.Admin
Add-PSSnapin Quest.ActiveRoles.ADManagement
Get-MailboxStatistics -Database exchsrv\First Storage Group\db1 | ForEach-Object -process {Get-QADuser $_.Displayname} | Set-QADUser -ObjectAttributes @{HomeMDB=’CN=db1,CN=First Storage Group,CN=InformationStore,CN=exchsrv,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=DOMAIN,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=ru’}

Аналогичный скрипт для задания атрибута homeMDB для пользователей из второй БД:
Add-PSSnapin Microsoft.Exchange.Management.PowerShell.Admin
Add-PSSnapin Quest.ActiveRoles.ADManagement
Get-MailboxStatistics -Database exchsrv\Second Storage Group\db2 | ForEach-Object -process {Get-QADuser $_.Displayname} | Set-QADUser -ObjectAttributes @{HomeMDB=’CN=db2,CN=Second Storage Group,CN=InformationStore,CN=exchsrv,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=DOMAIN,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=ru’}

После перезапуска службы Information Store пользователи успешно подключились к своим ящикам, но ни получение ни отправка почты не работала. Мы обратили внимание на то, что служба HUB Transport не работает. После запуска её вручную, она сразу же останавливалась. Как мы выяснили, была повреждена база данных почтовой очереди, которая располагается здесь: C:\Program Files\Microsoft\Exchange Server\TransportRoles\data\Queue\mail.que.
Чтобы не потерять почту, которая успела попасть в очередь, мы решили восстановить эту БД при помощи eseutil:

eseutil /p c:\Program Files\Microsoft\Exchange Server\TransportRoles\data\Queue\mail.que

После восстановления этой БД, служба HUB Transport запустилась и заработала. Пользователи начали получать новую почту.

PS1:

На самом деле процесс восстановления был немного сложнее, чем описано выше. Просто лень много писать, да и про метод Dial-tone Recovery подробно написано на technet. В кратце:

На время восстановления мы переместили всех пользователей во временные пустые БД, потом восстановили БД из резервных копий, заменили ими новые БД. Затем новые БД смонтировали в Recovery Storage Group и слили всю почту, полученную во время восстановления, с восстановленными из архива ящиками.

PS2:

Немножко размышлений:

• Как нам потом доложили, сбой почтовой системы вылился компании в 2 млн. рублей убытков. Интересно учитывал ли кто-нибудь эти деньги при проектировании почтовой системы и разработке политики резервного копирования? Было ли это прописано в SLA?
• Ведь спасти от такого сбоя могла простая SCR репликация, которая обошлась бы примерно в дополнительные 150 000 р. И восстановление заняло бы максимум пол часа. Хотя можно было бы подумать и о внедрении CCR кластера, который всё равно бы обошёлся раза в 2 дешевле, понесённых убытков.
• Резервировать Exchange Server 2007 нужно поддерживаемыми средствами резервного копирования, такими как Symantec BackUp Exec, Microsoft Data Protection Manager, ну или на худой конец ntbackup. Даже Windows  Backup из состава Windows Server 2008 уже поддерживает резервное копирование Exchange Server 2007 (sp2). Эти средства резервного копирования правильно подготавливают базу данных Exchange к процедуре резервирования, закрывают базу на запись, и после завершения резервного копирования, удаляют логи. Используемое в данном случае средство резервного копирования, неправильно резервировало БД Exchange, что привело к дополнительным 10 часам простоя.
• Также в данном случае большой ошибкой стало то, что логи транзакций размещались на одном и том же диске с базами данных, и поэтому было потеряно всё разом.
• Кроме того,  помимо еженедельного полного резервного копирования, было бы неплохо выполнять ежедневное добавочное. В данном случае произошла бы потеря почты только за один день, а не за неделю.

PS3:

История полностью вымышленная, любые сходства с реальным миром, простые совпадения!

Чтобы случайно не потерять нужные письма, оптимальнее всего настроить помещение писем, определённых как спам, в Карантин. Для этого нужно создать какой-нибудь ящик, например spm@domain.ru, и указать его в параметрах Content Filtering.

Внимание!  - mail-enabled Public Folder указывать нельзя! Т.е. ящик spm@domain.ru должен быть mail-enabled user-ом.

Казалось бы, что всё хорошо и все должны быть рады, но кто уже пытался вытащить письмо из карантина, знает, что не всё так просто! Если открыть ящик spm@domain.ru в Outlook, то там будет куча писем, отправленных от Postmaster. Открыв письма, конечно можно  увидеть по заголовкам от кого оно пришло и кому назначалось, но извлечь исходное писмо будет невозможно.

Чтобы можно было извлекать исходные сообщения из карантина нужно определённым образом настроить Outlook 2007:

Сначала нужно создать новый шаблон форм. Создаём файл:
QTNE.cfg

Затем копируем этот файл в папку: C:\Program Files\Microsoft Office\Office12\FORMS\1033

Запускаем Outlook нажимаем Сервис\Параметры, переходим на вкладку Дополнительно, нажимаем там Дополнительно…, нажимаем внизу Дополнительные формы, затем Диспетчер форм, нажимаем кнопку установить и выбираем файл C:\Program Files\Microsoft Office\Office12\FORMS\1033\QTne.cfg, далее на нужно нажать, ОК, Закрыть, ОК, ОК….

Далее нажимаем Сервис\Настройка учётных записей…, выбираем учетную запись Exchange, нажимаем Изменить\Другие настройки…, переходим на вкладку Дополнительно и нажимаем Добавить…, пишем наш ящик spm@domain.ru, на всех окошках жмём ОК.

В Главном окне Outlook раскрываем Почтовый ящик spm@domain.ru, и переходим в папку Входящие.

В правой части окна нажимаем правой кнопкой мыши по названию полей и выбираем Выбрать поля.

Далее нужно в окне выбора поля, раскрыть список часто используемых полей, промотать вниз и выбрать Формы…

Далее нужно будет выбрать Quarantine Extension Form, нажать добавить, затем Закрыть.

После этого вы снова попадёте к выбору поля, где уже будет создано новое поле Orginal Sender Address, там нужно будет схватить его левой кнопкой мыши и перетащить на мсто поля От, само поле От, кстати можно будет убрать, чтобы оно не отвлекало. Убирается поле путем перетаскивания из окна Outlook в панель выбора поля.

Теперь Outlook будет отображать в папке SPAM, отправителя письма, что позволит легко найти нужное письмо. Чтобы письмо доставить получателю, нужно его открыть, дважды щёлкнув мышью и нажать вверху кнопку «Отправить заново». После этого откроется оригинальное письмо, адресатом которого уже будет указан первоначальный получатель. Нужно будет просто ещё раз нажать кнопку отправить и письмо будет отправлено изначальному получателю.

К сожалению оно будет отправлено от имени того, кто письмо восстанавливает из карантина! Если уж очень хочется, чтобы в адресе отправителя стоял исходный отправитель, то можно добавить в Outlook 2007 POP3/SMTP – учётную запись, указав в SMTP адресе адрес исходного отправителя письма (по сути сделать подмену). И при восстановлении письма из спама, выбрать отрпавить через эту учётную запись. Да!, вот так вот, немножко неудобно!