Что делать? Если обратить внимание на приведённый выше скриншот, то можно увидеть, что среди пользователей SCCM есть встроенная учётная запись SYSTEM. В следующем узле Rights, можно убедиться, что учётная запись SYSTEM имеет полные административные права на управление SCCM. Соответственно осталось войти под учётной записью SYSTEM, запустить консоль управления System Center Configuration Manager Console и добавить себя в администраторы SCCM.

Но как войти под учётной записью SYSTEM? В данном случае может помочь известная утилита от Марка Русиновича – psexec, которая входит в набор PSTools. Распаковываем архив и запускаем:

psexec -s -i mmc.exe

Ключ -i делает интерактивный вывод приложения в данный сеанс, а ключ -s запускает приложение под учётной записью SYSTEM. Далее в открышемся окне Microsoft Management Console, нажимаем меню File, Open… и открываем оснастку управления SCCM, которая находится по следующему пути: C:\Program Files (x86)\Microsoft Configuration Manager\AdminUI\bin\adminconsole.msc.

Обращаем внимание, что теперь в контекстном меню узла Site Database…\Security Rights\Users доступно меню «Manage ConfigMgr Users». Соответственно, теперь уже по стандартной процедуре, добавляем новую учётную запись и предаставляем ей необходимые административные права на управление System Center Configuration Manager.

]]> http://www.lankey.ru/blog/2012/01/28/restore-admin-rights-to-sccm-console/feed/ 0 http://www.lankey.ru/blog/2011/03/20/how-to-delete-message-from-all-mailboxes-exchange-2010-sp1/ http://www.lankey.ru/blog/2011/03/20/how-to-delete-message-from-all-mailboxes-exchange-2010-sp1/#comments Sun, 20 Mar 2011 13:38:09 +0000 Сергей Ерин http://www.lankey.ru/blog/?p=741 Иногда возникает необходимость удалить определённое письмо из всех ящиков почтового сервера Exchange. Понятно, что можно,  дать себе права на все ящики, по одному заходить в каждый при помощи Outlook и удалять вручную. Но если ящиков не одна сотня, то процесс может затянуться на много часов. Но есть способы сделать это быстро при помощи PowerShell:

В 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 лучше всего брать в Ашане, там дешевле)

Диагностика

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

Исправление

Соответственно первое, что мы сделали, это прописали на оставшихся двух контроллерах домена в качестве DNS серверов 127.0.0.1 и второй контроллер. Затем при помощи утилиты ntdsutil и команды seize мы произвели захват fsmo ролей на один из контроллеров домена. После того, как все роли были перенесены, мы попытались назначить оставшиеся контроллеры домена серверами глобального каталога, но галка «Global Catalog» в свойствах NTDS Settings в оснастке Active Directory Sites and Services была неактивна. Проанализировав записи DNS-серверов, мы обнаружили, что в разделе Forward Lookup Zones\_msdcs.domain.ru\gc\_sites, отсутствовала запись Default-First-Site-Name, а именно в этом сайте находились корневые контроллеры домена. Мы вручную создали запись Default-First-Site-Name\_tcp, где создали 2 SRV-записи, ссылающиеся на 2 оставшихся контроллера домена:

_ldap Service Location (SRV) [0][100][3268] dc2.domain.ru
_ldap Service Location (SRV) [0][100][3268] dc3.domain.ru

После перезагрузки контроллеров домена, нам удалось поставить галку «Global Catalog» для каждого из контроллеров.

К сожалению сейчас не помню всех подробностей, но были ещё какие-то проблемы с записями в DNS, часть из которых была решена утилитой netdiag /fix. Кроме того, на определённом этапе восстановления структуры DNS, галка «Global Catalog» стала активной, но тем не менее, мы обнаружили, что на контроллерах домена служба lsass не слушает порт 3268. И проблема решилась только после того, как мы вручную прописали srv-записи описанным выше способом.

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

Восстановление репликации

Осталось решить проблему с репликацией 80 дочерних доменов. Топология репликации была таковой, что все дочерние филиалы реплицировались через Default-First-Site-Name. Проблема оказалось в том, что вышедший из строя в главном офисе контроллер домена был назначен единственным «preferred bridgehead» в данном сайте. Таким образом, ни один из 80 дочерних контроллеров домена даже не пытался начать репликацию ни с одним из оставшихся контроллеров домена основного офиса. Кроме того, ниодин из дочерних контроллеров домена более не мог узнать ни о каких изменениях в конфигурации главного сайта, ни о появлении новых bridgehead-ов, ни об удалении старого контроллера домена, в общем, ни о чем!

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

Мы составили некий алгоритм по восстановлению репликации с каждым дочерним филиалом:

1) Нужно зайти на контроллер домена каждого дочернего филиала, запустить оснастку Active Directory Sites and Services, раскрыть \сайт соответствующего филиала\Servers\контроллер домена\NTDS Settings, и удалить связи, ссылающиеся на удалённый контроллер домена.

2) Затем нажать правой кнопкой на NTDS Settings, нажать New Active Directory Connection, и выбрать из списка любой из двух оставшихся в сайте Default-First-Site-Name контроллеров домена.

3) Затем проделать тоже самое на контроллере домена центрального филиала, желательно на том же, который мы выбрали в предыдущем шаге.

4) Далее сначала в дочернем филиале нажать по вновь созданной связи и выбрать Replicate now. Подождав несколько минут, убедиться что репликация прошла успешно, из Default-First-Site-Name должен исчезнуть удалённый контроллер домена центрального филиала.

5) Далее лучше удалить вручную созданные связи с обоих контроллеров домена и перезапустить службу Kerberos Key Distribution Center, спустя какое-то время (около 15 мин) служба KCC автоматически сгенерирует связь между филиалом и сайтом центрального офиса.

Соответственно данную процедуру  пришлось проделать вручную с каждым из 80 дочерних филиалов!

Восстановление репликации с устаревшими контроллерами

При восстановлении репликации описанным выше способом на некоторых контроллерах домена мы столкнулись с ошибкой:

The naming context is in the process of being removed or is not replicated from the specified server.

 Скорее-всего данная ошибка была вызвана тем, что репликация данных контроллеров не производилась уже достаточно давно больше периода времени захоронения tombstone lifetime (128 дней). Для того, чтобы возобновить репликацию не переустанавливая контроллер домена, мы решили отключить проверку целостности и разрешить репликацию с неправильным партнёром. Для этого в реестр каждого контроллера домена были добавлены следующие ключи:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters]

«Strict Replication Consistency»=dword:00000000

«Allow Replication With Divergent and Corrupt Partner»=dword:00000001

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

Очистка метаданных.

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

Кстати, если кому-то интересно, то для удобства анализа большого числа данных монитора репликации, очень удобно использовать Excel. Для этого данные можно выгрузить в формат .csv:

repadmin /showrepl * /csv > showrepl.csv

Для удаления контекста именования отсутствующего домена мы решили воспользоваться утилитой ntdsutil и командой metadata cleanup, более подробно об этом написано здесь: http://support.microsoft.com/kb/216498/en-us Но к сожалению данная попытка удаления не увенчалась успехом, мы получили ошибку 0×2162<The requested domain could not be deleted because there exist domain controllers that still host this domain.>. Данная ошибка говорит о том, что невозможно удалить домен, т.к. существуют контроллеры домена, которые содержат данный домен.

Пытаясь найти решение данной ошибки, мы попали на статью: http://support.microsoft.com/default.aspx?scid=kb;en-us;Q235416, которая к сожалению тоже никак не помогла, т.к. ни в одной оснастке уже не отображался ни сайт, относящийся к этому домену, ни сам домен. Но при помощи оснастки ADSI Edit, в разделе Configuration\Partitions\ всё ещё находился раздел этого домена. Попытка его удалить через ADSI Edit приводила к аналогичной ошибке:

Мы решили найти данный контекст именования в удалённых объектах, для этого воспользовались утилитой Active Directory Explorer (ADexplorer) от sysinternals, хотя в принципе с таким же успехом можно было использовать и ldp.exe. В итоге в разделе Configuration\Sites мы обнаружили удалённый сайт, содержащий в себе удалённый объект Servers, внутри которого был удалённый объект контроллера домена, но вот внутри объекта контроллера домена ничего не было, хотя там должен был быть объект NTDS Settings, что нас и навело на определённые мысли.

В итоге мы догадались заглянуть в контейнер LostAndFoundConfig и обнаружили там объект NTDS Settings от данного сайта, который не был удалённым, но принадлежал удалённому серверу и сайту.

После удаления объекта NTDS Settings, мы снова вернулись к ntdsutil > metadata cleanup и успешно удалили остатки старого домена.

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/04/01/activesync-hacked/ http://www.lankey.ru/blog/2010/04/01/activesync-hacked/#comments Wed, 31 Mar 2010 23:18:25 +0000 Сергей Ерин http://blogs.lankey.ru/?p=531 Прошло не так много времени, после того, как компания Pastware выпустила утилиту для взлома BitLocker, и вот новая сенсация: Буквально вчера компания Pastware объявила о выпуске утилиты для взлома протокола ActiveSync.

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

Утилита позволяет перехватывать сигнал, расшифровывать трафик и смотреть всю почтовую переписку пользователя.

Как это работает:

Все вы слышали, когда телефон лежит рядом с компьютером и, например, приходит SMS, то в колонках происходит характерное потрескивание/гудение, которому никто не придаёт особого значения. Тоже самое происходит и при получении письма посредством ActiveSync через GPRS/EDGE/3G. Утилита компании Pastware перехватывает возмущения, возникающие в аналоговых цепях звуковых карт, снимает дамп этих шумов и, используя преобразования фурье и выделение гармоник, получает двоичный код сетевых пакетов TCP/IP. Затем специальными парсерами из общего потока выделяется содержимое HTTPS-пакетов протокола ActiveSync. Затем SSL пакеты расшифровываются другим модулем из пакета Pastware Kit и на выходе получаем всю почтовую переписку за определёный момент времени.

100% достоверность, пока не гарантируется, качество перехвата напрямую зависит от частоты дискретизации звуковой карты и разрядности АЦП. Рекомендуется использовать звуковые карты разрядностью 24 бит и более и частотой дискретизации 96 КГц и выше, без систем активного шумоподавления.

Для переноса OEM лицензий с одного компьютера на другой Microsoft выпустила специальный OEM Transporter Kit.

В комплект поставки входит дремель и несколько насадок. Смысл набора очень прост: В том месте старого системного блока, где у вас наклеена лицензионная наклейка, вы с помощью дремеля выпиливаете стенку корпуса и приклеиваете её к новому корпусу.  Далее вы переустанавливаете и переактивруете Windows на новом оборудовании и всё!

По предварительным данным стоимость КИТ-а будет составлять примерно 50$. В прайсах продукт можно будет найти под именем: WinPro 7 RUS OEM NL Transportering DrillGenuine

Совершенно недавно ученые психологи обнаружили новое психическое заболевание у системных администраторов, которое получило название Гейтофобия – или боязнь недоступности основного шлюза.

Гейтофобия – чаще всего проявляется у сетевых администраторов, имеющих сертификаты CCNA и CCNP, т.к. именно они в основном в компаниях отвечают за сетевую инфраструктуру, за работу интернет-а и соответственно за доступность основного шлюза. На них лежит большая ответственность и именно в них летят все «палки», в случае неработоспособности сети.

Основными симптомами заболевания являются параноидальный мониторинг доступности шлюза  при помощи ICMP пакетов, который в особо острой фазе и приводит к самой недоступности шлюза, ввиду невозможности последнего обработать такой большой поток Ping-ов. Далее, когда системный администратор видит надпись Default Gateway is Unavailable, происходит нервный срыв, который может сопровождаться нецензурной бранью, повышением температуры, а также почечной недостаточностью, вызванной высоким потреблением пива.

Пока способов лечения Гейтофобии не найдено, но врачи рекомендуют использовать резервные шлюзы с разными метриками, применять технологии балансировки сетевой нагрузки такие, как NLB или CARP.

Задачу автоматического выключения компьютеров наши инженеры решили довольно быстро, слава богу на всех компьютерах был установлен Windows 7 с продвинутым шедулером на основе триггеров. На всех компьютерах в Планировщике была создана задача, которая запускала скрипт с командой shutdown – s -t 0, а срабатывала задача при появлении события Windows Update Client, код события 21, ключевое слово Перезагрузка.

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

Но вот задача автоматического включения компьютеров оказалась немного сложнее. Первое, что конечно пришло в голову – это использование Wake on-Lan, но к сожалению данная функция работает далеко не на всех компьютерах, поэтому требовалось иное решение.  Данная задача была передана инженерам ОНВ (Отдел Нетрадиционного Внедрения). И решение было найдено! У данного заказчика весь офис запитан от одного большого централизованного ИБП APC Smart-UPS VT 30 kVA. Инженеры отдела ОНВ предложили на каждом компьютере в BIOS выставить режим Питания Always On. В данном режиме компьютер автоматически включается, если произошло выключение и затем повторное включение питания. Ну а дальше дело оставалось за малым, точнее за большим UPS-ом. Через консоль управления APC Power Chute было задано запланированное выключение и затем повторное включение питания всего офиса в 2 часа ночи каждую среду.

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

Данное решение работает уже около полугода в продакшене и не имеет почти никаких побочных эффектов, кроме того, что секретарша не может понять, какие сверхестетсвенные силы каждую среду сбрасывают время на кофемашине

Для тех, кто по каким-то причинам не смог посетить семинар, мы решили выложить видеозаписи докладов:

Доклад по  Windows Server 2008 R2:

Доклад по Exchange Server 2010:

Доклад по Office Communications Server 2007 R2:

Доклад по GFI:

Также, вы можете отдельно скачать сами презентации:

Презентация Windows Server 2008 R2

Презентация Exchange Server 2010

Презентация Office Communications Server 2007 R2

Презентация  GFI: Часть 1, Часть 2.

Внимание! Все материалы презентаций являются собственностью компаний LanKey, Microsoft и GFI. Без письменного разрешения владельцев запрещается частичное или полное копирование и публикация любых материалов данных презентаций.