Я объяснял подход перемещения почтовых ящиков, используемый в Exchange 2007. Это в основном работа с Move-Mailbox командой в Exchange Management Shell, хотя, конечно, можно использовать консоль управления Exchange Management Console для перемещения почтовых ящиков. В Exchange 2010 также можно перемещать почтовые ящики с помощью консоли управления Exchange Management Console и оболочки Exchange Management Shell, хотя в сам процесс был внесен ряд изменений. В этом цикле статьей из трех частей я расскажу о том, как перемещать почтовые ящики в Exchange 2010 и в большей степени буду акцентировать внимание на новой функции Move Request .

Запросы перемещения (Move Requests)

Итак, хочу начать статью, сказав, что Move-Mailbox команда больше не доступна в Exchange 2010. Весь подход к перемещению почтовых ящиков в Exchange 2010 сконцентрирован вокруг функции под названием запросы перемещения (move requests) . Поскольку команда Move-Mailbox больше не используется, следует вывод, что вы не можете воспользоваться Exchange 2007 Move-Mailbox командой для перемещения почтовых ящиков из Exchange 2007 в Exchange 2010; вам придется использовать функцию запросов перемещения продукта Exchange 2010.

Запрос перемещения создается администратором Exchange с помощью консоли управления Exchange Management Console или в Exchange Management Shell. В этой статье я сконцентрирую внимание на перемещении почтовых ящиков в одном лесу. Такой тип перемещения называют локальным запросом перемещения (local move request) . Когда вы перемещаете почтовые ящики между лесами, этот тип называется удаленный запрос перемещения (remote move requests) . Удаленные запросы перемещения будут рассматриваться в следующих статьях здесь на MSExchange.org.

Команды, являющиеся частью запроса перемещения, выполняются службой Microsoft Exchange Mailbox Replication Service , это новая служба в Exchange 2010, работающая на роли сервера Client Access Server. Эта служба показана на рисунке 1.

Рисунок 1: Служба Microsoft Exchange Mailbox Replication Service

Запрос перемещения помещает специальное системное сообщение в системный почтовый ящик базы данных почтовых ящиков. Служба Microsoft Exchange Mailbox Replication поверяет содержимое системного почтового ящика в каждой базе данных почтовых ящиков на предмет наличия там запроса перемещения, после чего обрабатывает такие запросы соответствующим образом. Есть много преимуществ перемещения почтовых ящиков с помощью этой службы. Вот три основных области, с которыми я обычно сталкиваюсь в процессе реализации проектов миграции, которые исправлены этими запросами перемещения:

  • Почтовые ящики теперь можно перемещать в режиме онлайн, даже когда пользователи вошли в них. Такая возможность доступна, только если почтовые ящики работают под управлением Exchange 2007 SP2 или более поздней версии, или Exchange 2010. Однако это очень полезное дополнение в процесс перемещения почтовых ящиков в целом, поскольку оно поможет избежать необходимости перемещения почтовых ящиков в нерабочее время.
  • Объекты в корзине теперь перемещаются в качестве части процесса. В предыдущих версиях Exchange перемещение почтовых ящиков не перемещало объекты корзины, поэтому пользователю необходимо было восстанавливать все удаленные объекты обратно в почтовый ящик, прежде чем переместить его. Можно было с легкостью забыть проинформировать пользователей об этом, и в некоторых случая пользователи, чьи почтовые ящики были перемещены, пытаясь восстановить объекты из корзины, обнаруживали, что корзина пуста.
  • Содержимое почтовых ящиков больше не обрабатывается компьютером, с которого выполняется процесс перемещения. Зачастую в Exchange 2007 было так, что команда Move-Mailbox, или связанный с ней сценарий, выполнялся на машине администратора, а не на целевом сервере Exchange 2007. Однако в таком сценарии содержимое почтового ящика перемещается с исходной базы данных на машину администратора, а затем в целевую базу данных. Такого сценария можно было избежать путем выполнения команды или командного сценария непосредственно на сервере целевой базы данных. В Exchange 2010 эта ситуация больше не будет встречаться, поскольку перемещение почтового ящика выполняется службой Microsoft Exchange Mailbox Replication, работающей на сервере Client Access Server.

Когда я впервые прочитал о том, что служба Microsoft Exchange Mailbox Replication на каждом сервере Client Access Server отвечает за обработку перемещений почтовых ящиков, мне стало интересно, как наличие нескольких серверов Client Access Servers повлияет на перемещение. Например, будут ли два сервера Client Access Servers пытаться переместить один и тот же почтовый ящик одновременно? К счастью, в Microsoft сообщили, что был применен общий механизм между всеми серверами Client Access Servers одного сайта Active Directory, чтобы избежать таких ситуаций.

Создание локального запроса перемещения

Теперь, когда мы немного разобрались с запросами перемещения, пришло врем посмотреть, как на практике можно переместить почтовый ящик с помощью этой новой функции. Давайте начнем с рассмотрения того, как создавать локальный запрос перемещения с помощью консоли Exchange Management Console.

  1. Когда консоль Exchange Management Console загружена, разверните Конфигурацию получателя (Recipient Configuration) в дереве консоли. В узле Recipient Configuration выберите объект Почтовый ящик (Mailbox) , который отобразит список всех почтовых ящиков в панели результатов.
  2. На этом этапе вам нужно выбрать почтовые ящики, которые нужно переместить. Вы можете выбрать несколько почтовых ящиков, которые будут перемещены одновременно.
  3. Когда вы выбрали почтовые ящики для перемещения, выберите опцию Новый локальный запрос перемещения (New Local Move Request)" в панели действий, или нажмите правой клавишей на объекте Mailbox и выберите эту же опцию из контекстного меню, как показано на рисунке 2.

Рисунок 2: Создание нового локального запроса перемещения

  1. У вас запустится мастер New Local Move Request Wizard и отобразит вводную страницу Introduction , как показано на рисунке 3. На этой странице будут отображены выбранные вами почтовые ящики, а также важная информация, включающая базу данных почтовых ящиков, в которой на данный момент расположены эти почтовые ящики.

Рисунок 3: Вводная страница мастера New Local Move Request

  1. На вводной странице нажмите кнопку Обзор (Browse)" , которая вызовет окно выбора базы данных почтового ящика (Select Mailbox Database) , как показано на рисунке 4. Это окно отобразит базы данных, которые доступны на всех серверах вашей организации. В своем примере я просто перемещу почтовый ящик из базы данных Mailbox Database 001 в Mailbox Database 002 на одном сервере с именем DAG1 . Таким образом, я просто выбираю эту базу данных и нажимаю OK .

Рисунок 4: Страница выбора базы данных почтовых ящиков

  1. Теперь на вводной странице поле базы данных должно быть заполнено именем целевой базы данных. Нажмите Далее (Next) .
  2. Далее откроется окно опций перемещения (Move Options) , как показано на рисунке 5. Это окно должно быть вам знакомо, если вы использовали предыдущие версии Exchange. Здесь вы можете указать, как обрабатывать поврежденные сообщения, если таковые будут найдены в исходной базе данных. Здесь у вас есть опция полностью пропустить почтовый ящик, или разрешить определенное количество поврежденных сообщений. Здесь нет правильных или неправильных настроек, все зависит от того, как в вашей организации относятся к потере данных. На рисунке ниже я выбрал опцию пропуска почтового ящика полностью; если какие-либо поврежденные элементы будут найдены, почтовый ящик не будет перемещен. Затем я просмотрю базу данных с помощью таких утилит, как ISINTEG на предмет возможности исправления повреждений.

Рисунок 5: Страница опций перемещения

  1. Как только вы выбрали подходящие параметры на странице опций перемещения, нажмите Далее . Это отобразит финальную страницу, где вы сможете просмотреть сводную информацию о конфигурации, прежде чем нажать кнопку Новый (New) для создания локального запроса перемещения.
  2. После этого локальный запрос перемещения будет создан и передан серверу Client Access Server; мастера можно закрыть.
Создание запроса перемещения с помощью PowerShell

Для создания локального запроса перемещения с помощью оболочки Exchange Management Shell можно воспользоваться командой New-MoveRequest и связанными с ней параметрами. Простая команда для создания локального запроса перемещения для перемещения одного почтового ящика из одной базы данных в другую может выглядеть следующим образом:

New-MoveRequest "Identity neil "TargetDatabase "Mailbox Database 004"

Здесь параметр Identity используется для указания почтового ящика, который будет перемещен, а параметр TargetDatabase указывает базу данных, в которую будет перемещен почтовый ящик. Выполнение этой команды создаст результаты, похожие на те, что показаны на рисунке 6.

Рисунок 6: Команда New-MoveRequest

На рисунке 6 вы заметите, что некоторая информация в столбцах несколько неясная при стандартном форматировании, используемом в Exchange Management Shell. Чтобы исправить эту ситуацию, можно прогнать результаты команды New-MoveRequest через команду format-table (сокращенную до ft в примере ниже), а также воспользоваться параметрами "AutoSize и "Wrap , как показано в этом примере:

New-MoveRequest "Identity neil "TargetDatabase "Mailbox Database 004" | ft "AutoSize -Wrap

Это предоставляет результаты, подобные тем, что показаны на рисунке 7, что значительно упрощает чтение данных.

Рисунок 7: Форматированная команда New-MoveRequest

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

Mailbox {name} has a completed move request associated with it. Before you create a new move request for the mailbox, run the Remove-MoveRequest cmdlet to clear the completed move request.

Это сообщение об ошибке показано на рисунке 8.

Рисунок 8: Ошибка New-MoveRequest

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

Примечание: запросы перемещения не удаляются автоматически даже при успешном перемещении почтового ящика. Это также имеет последствия для удаления баз данных почтовых ящиков, которые мы рассмотрим позже в этом цикле статей. Мы также рассмотрим далее.

Команда New-MoveRequest содержит множество доступных параметров, которые можно использовать для управления запросами перемещения. Как вы, возможно, ожидали, если знакомы с Exchange 2007, в оболочке Exchange Management Shell есть больше способов контроля запроса перемещения, чем в консоли Exchange Management Console. Полный список всех параметров можно найти , но в этой статье я опишу несколько самых важных параметров:

  • BadItemLimit - как было показано на рисунке 5, можно решать, сколько поврежденных элементов почтового ящика программа может допускать при перемещении ящика. В Exchange Management Shell параметр BadItemLimit управляет этой настройкой.
  • BatchName - это полезный параметр, позволяющий указывать имя пакета при перемещении нескольких почтовых ящиков. Затем можно использовать это имя пакета для поиска конкретных почтовых ящиков при использовании команды Get-MoveRequest , о чем я расскажу в третьей части этого цикла.
  • IgnoreRuleLimitErrors - если вы столкнетесь с ошибками ограничения правил во время перемещения почтового ящика, вы можете не перемещать правило пользователя в качестве части почтового ящика. Этот параметр позволяет вам это делать. Например, вы можете изменить параметры запроса перемещения после его предоставления, чтобы убедиться, что правила не обрабатываются. Об этом мы также поговорим в третьей части цикла.
  • MRSServer - обычно запрос перемещения обрабатывается одним сервером Client Access Servers сайта Active Directory. Чтобы указать конкретный сервер Client Access Server, используйте параметр MRSServer совместно с Fully Qualified Domain Name (FQDN) именем сервера Client Access Server.
  • SuspendWhenReadyToComplete - этот параметр используется для приостановки запроса перемещения, прежде чем почтовый ящик будет окончательно перемещен в целевую базу. Другими словами все действительные данные почтового ящика перемещаются, но окончательное перемещение не происходит, пока администратор не возобновит перемещение с помощью команды Resume-MoveRequest . Одной из ситуаций, в которых можно использовать такой подход, будет ситуация получения окончательного одобрения на перемещение почтового ящика. Этот параметр будет рассмотрен в третьей части этого цикла статей.
Управление целевыми базами данных

Интересным является то, что параметр TargetDatabase команды New-MoveRequest, на самом деле, является необязательным. В примерах, приведенных в начале этой статьи, видно, что данный параметр использовался, чтобы убедиться в том, что почтовый ящик был перемещен в базу под названием Mailbox Database 004 . Если вы исключите параметр TargetDatabase, процесс запроса перемещения автоматически выберет базу данных.

Если у вас одна и более баз данных почтовых ящиков, которые вы хотите исключить из этого процесса выбора, то вы можете изменить значение параметра IsExcludedFromProvisioning базы данных, которую хотите исключить. Этот параметр показан на рисунке 9, где он указан в значении по умолчанию false , означающем, что база данных доступна для заполнения почтовых ящиков. Если бы я хотел изменить значение этого параметра для базы данных Mailbox Database 004 на true, я бы выполнил следующую команду:

Set-MailboxDatabase "Mailbox Database 004" "IsExcludedFromProvisioning $True

Рисунок 9: Исключение баз почтовых ящиков из запроса перемещения

Управление запросами перемещения

Теперь, когда локальный запрос перемещения создан, вам нужно отследить его прогресс. В консоли Exchange Management Console нажмите на объект Move Request , расположенный в узле Recipient Configuration в древе консоли. Это вызовет окно подобное тому, что показано на рисунке 10. На этом рисунке я удалил панель действий для большей ясности.

Рисунок 10: Управление запросом перемещения

Здесь видно, что отображен список запросов перемещения. На данный момент в прогрессе находится только один запрос перемещения, и поле состояния запроса Move Request Status показывает статус перемещения Moving . По умолчанию в консоли показываются только поля Имя дисплея (Display Name), Псевдоним (Alias), Состояние запроса перемещения (Move Request Status) и Тип запроса перемещения (Move Request Type). Есть два способа расширить информацию, которая будет вам доступна:

  1. В консоли Exchange Management Console выберите меню Вид (View) , затем опцию Добавить или удалить столбцы (Add/Remove Columns") , чтобы вызвать окно Add/Remove Columns , как показано на рисунке 11. Здесь видно, что поля Имя (Name), Имя удаленного хоста (Remote Host Name), Исходная база данных (Source Database) и Целевая база данных (Target Database) также доступны. Используя различные кнопки, имеющиеся на экране, вы можете указывать, какие дополнительные поля отображать, а также порядок, в котором они будут отображены.

Рисунок 11: Добавление дополнительных информационных столбцов

  1. Другим способом добавления информации в консоли Exchange Management Console является просмотр свойств запроса перемещения. Для этого просто нажмите правой клавишей на запросе перемещения и выберите Свойства (Properties) в контекстном меню. Это вызовет окно свойств запроса перемещения, похожее на то, что отображено на рисунке 12.

Рисунок 12: Свойства запроса перемещения

Одним из самых интересных полей, представленных на рисунках 10 и 12, является поле состояния Move Request Status . На рисунке 12 видно, что состояние указано как Completing , но конечно это поле может принимать и такие значения, как InProgress , Completed , Failed и т.д. Это позволяет вам видеть, на какой стадии находится запрос перемещения в общем процессе.

Управление запросами перемещения

Оболочку Exchange Management Shell можно использовать для просмотра того, как продвигается запрос перемещения с помощью команды Get-MoveRequest . В своем стандартном состоянии команда Get-MoveRequest вернет результаты всех доступных запросов перемещения. Для примера посмотрите на рисунок 13, где показан образец информации, возвращенной командой Get-MoveRequest. Здесь показан только один запрос перемещения, а также видно, что мой почтовый ящик был перемещен в целевую базу данных под названием TEST. Вы также видите, что запрос перемещения завершен.

Рисунок 13: Результаты Get-MoveRequest

Как и в случае с командой New-MoveRequest, для этой команды тоже доступно множество параметров Get-MoveRequest. Полный список параметров можно найти . Несколькими из самых важных параметров являются следующие:

MoveStatus : с помощью этого параметра вы можете использовать результаты команды Get-MoveRequest для получения запросов перемещения только с определенным состоянием. Например, если вам нужно просмотреть все запросы перемещения со статусом InProgress , нужно использовать следующую команду:

Get-MoveRequest "MoveStatus InProgress

Пример результатов такой команды показан на рисунке 14. Действительными параметрами статуса будут None , Queued , InProgress , AutoSuspended , CompletionInProgress , Completed , CompletedWithWarning , Suspended и Failed .

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

SuspendWhenReadyToComplete: этот параметр используется для приостановки запросов перемещения, прежде чем ящик будет окончательно перемещен в целевую базу данных. Об этом параметре мы поговорим чуть позже.

TargetDatabase: этот параметр похож на SourceDatabase за исключением того, что он показывает целевую базу.

Приостановка запроса перемещения

Как мы вкратце рассмотрели во второй части этого цикла и в предыдущем разделе, команды New-MoveRequest и Get-MoveRequest включают SuspendWhenReadyToComplete параметр, который используется для приостановки запроса перемещения, прежде чем окончательное место целевой базы данных будет обновлено. С таким подходом данные почтового ящика перемещаются, однако последнее переключение осуществляется только после того, как приостановленный запрос перемещения снова запущен. Также можно приостановить существующий запрос перемещения с помощью команды Suspend-MoveRequest .

Давайте рассмотрим использование параметра SuspendWhenReadyToComplete для команды New-MoveRequest. Примером команды для выполнения будет:

New-MoveRequest "Identity neil "SuspendWhenReadyToComplete

Если вы читали предыдущие части этого цикла, вы заметите, что вышеуказанная команда не включает параметр TargetDatabase для указания какой-либо определенной базы данных, в которую будет перемещен ящик. Без этого параметра база данных будет выбрана системой.

Как мы уже говорили, процесс перемещения почтового ящика будет отложен, пока не произойдет окончательное перемещение. Его можно настроить с помощью выполнения команды Get-MoveRequest . Взгляните на рисунок 15, где видно, что почтовый ящик был перемещен с использованием параметра SuspendWhenReadyToComplete. Немногим позже статус этого запроса перемещения примет значение InProgress , и содержимое почтового ящика перемещается. После очередного обновления команда Get-MoveRequest покажет, что статус запроса теперь изменился на AutoSuspended , а именно такой статус отображается при использовании параметра SuspendWhenReadyToComplete. Подобно этому консоль Exchange Management Console показывает этот статус, как видно на рисунке 16.

Рисунок 15: Приостановленный запрос перемещения " Exchange Management Shell

Рисунок 16: Приостановленный запрос перемещения " Exchange Management Console

Когда администратор решит, что можно завершить перемещение, запрос перемещения можно возобновить выполнением команды Resume-MoveRequest со следующим синтаксисом:

Resume-MoveRequest "Identity neil

Когда эта команда выполнена, повторный запуск команды Get-MoveRequest должен показать статус Completed .

Пакетные имена (Batch Names)

В предыдущей части этого цикла мы рассмотрели параметры команды New-MoveRequest и увидели, что один из этих параметров называется BatchName . С помощью этого параметра можно указывать имя пакета при перемещении нескольких почтовых ящиков, которое затем можно использовать с командой Get-MoveRequest для поиска определенных пакетов перемещения почтовых ящиков.

Имена пакетов вполне полезны при перемещении содержимого одной базы почтовых ящиков в другую. Чтобы все упростить, я просто создам два запроса для одинаковых почтовых ящиков и назначу каждому различные имена пакетов. Затем мы воспользуемся командой Get-MoveRequest, чтобы продемонстрировать, как искать эти имена пакетов. Сначала, давайте создадим два простых запроса перемещения с помощью оболочки Exchange Management Shell с указанием разных имен пакетов:

New-MoveRequest "Identity neil "TargetDatabase "Mailbox Database 003" "BatchName Batch001

New-MoveRequest "Identity rob "TargetDatabase "Mailbox Database 004" "BatchName Batch002

После создания этих запросов перемещения можно использовать команду Get-MoveRequest с BatchName параметром для обнаружения всех запросов перемещения почтовых ящиков, связанных с определенным именем пакета. Например, чтобы посмотреть все запросы перемещения почтовых ящиков, связанные с именем пакета Batch001 , нужно воспользоваться следующей командой:

Get-MoveRequest "BatchName Batch001

Результаты этой команды показаны на рисунке 17, где видно, что только один из двух почтовых ящиков вернулся, поскольку второй ящик был перемещен с использованием другого имена пакета.

Рисунок 17: Фильтрация по имени пакета

Перемещение нескольких почтовых ящиков

Во второй части этого цикла мы рассмотрели перемещение пользовательского почтового ящика с помощью команды New-MoveRequest . Перемещение одного почтового ящика является простой задачей, поскольку псевдоним этого ящика просто нужно указать в параметре Identity команды New-MoveRequest . А как на счет перемещения нескольких почтовых ящиков? Это можно сделать несколькими способами, некоторые из которых будут описаны ниже.

Во-первых, довольно просто переместить все почтовые ящики из одной базы данных в другую просто путем передачи команды Get-MailboxDatabase в команду New-MoveRequest . Примером может служить следующая команда:

Get-Mailbox "Database "Mailbox Database 001" | New-MoveRequest "TargetDatabase `

"Mailbox Database 002"

Если вам нужно переместить всего несколько почтовых ящиков, вы можете воспользоваться функцией массива в PowerShell. Предположим, что нам нужно переместить почтовые ящики, принадлежащие пользователям Neil, Rob и Mark. В этом примере имена пользователей также являются псевдонимами почтовых ящиков. Можно воспользоваться следующим сценарием для выполнения этой задачи:

$MailboxesToMove = "neil","rob","mark"

ForEach ($SingleMailbox in $MailboxesToMove) {New-MoveRequest "Identity $SingleMailbox `

"TargetDatabase "Mailbox Database 002" "BatchName Batch001}

В этом сценарии видно, что мы сначала определили $MailboxesToMove как массив, содержащий имена трех псевдонимов почтовых ящиков для перемещения. Затем каждый псевдоним почтовых ящиков передается в команду New-MoveRequest для обработки независимо от расположения исходной базы данных почтовых ящиков.

Также можно воспользоваться командой Get-Content , имеющейся в PowerShell. Прежде всего, нужно создать простой текстовый файл, содержащий список псевдонимов почтовых ящиков, которые вы собираетесь переместить. На рисунке 18 показан пример такого файла, это файл под названием mailboxes.txt .

Рисунок 18: Примерный Mailboxes.txt файл

Затем примерный сценарий для перемещения почтовых ящиков, перечисленных в файле mailboxes.txt, может выглядеть следующим образом:

$Mailboxes = Get-Content ./mailboxes.txt

For ($Start = 0; $Start -lt $Mailboxes.length; $Start++) {New-MoveRequest "Identity `

$Mailboxes[$Start] -TargetDatabase "Mailbox Database 002"}

В этом сценарии команда Get-Content используется для получения содержимого mailboxes.txt файла и назначения содержимого для $Mailboxes . Затем выполняется петля через содержимое $Mailboxes и для каждой петли используется команда New-MoveRequest .

Хотя существуют различные способы перемещения почтовых ящиков Exchange 2010 посредством использования нескольких команд Exchange Management Shell, следует знать о том, что компания Microsoft предоставляет MoveMailbox PowerShell сценарий, который можно найти в папке \Program Files\Microsoft\Exchange Server\V14\Scripts после установки Exchange 2010. Этот сценарий будет выполнять локальный запрос перемещения в одной организации Exchange, и обладает дополнительным преимуществом, заключающимся в том, что он удаляет запрос перемещения сразу после его выполнения. Прежде чем рассмотреть пару примерных сценариев, давайте взглянем на параметры, используемые с ним. Этот сценарий использует несколько параметров, которые мы уже обсуждали в этом цикле статей, хотя несколько параметров имеют другие названия.

Во-первых, есть AutoSuspend параметр, функция которого такая же, как и у параметра SuspendWhenReadyToComplete , используемого с командами New-MoveRequest и Get-MoveRequest . Также, BadItemLimit параметр можно использовать со сценарием MoveMailbox. Есть также параметры MailboxDatabase и TargetDatabase , управляющие исходной и целевой базой данных соответственно. Одним из основных параметров, которые вы будете использовать с этим сценарием, является DatabaseMap параметр. Это действительно полезный параметр, позволяющий вам указывать, куда нужно переместить почтовые ящики. Мы чуть позже подробно рассмотрим этот параметр.

А пока, давайте рассмотрим простой процесс перемещения одного почтового ящика с использование сценария MoveMailbox. Чтобы переместить свой почтовый ящик в базу под названием Mailbox Database 002 , я просто выполняю сценарий со следующими параметрами:

./MoveMailbox.ps1 "Identity neil "TargetDatabase "Mailbox Database 002"

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

Рисунок 19: Перемещение одного почтового ящика с помощью командной сценария MoveMailbox.ps1

Карты базы MoveMailbox.ps1 Database Maps

Параметр DatabaseMap командного сценария MoveMailbox очень полезен при обработке нескольких почтовых ящиков в нем и перемещении этих ящиков в несколько целевых баз данных. Можно указывать несколько пар источник/цель в командной строке, что значительно повышает ее эффективность. Синтаксис использования этого параметра будет следующим:

DatabaseMap @{"Source Database"="Target Database";"Source Database"="Target Database"}

В этом синтаксисе видны два сопоставления источник/цель, и они разделяются точкой с запятой. Таким образом, что использовать это для примера, в котором вы хотите переместить почтовые ящики базы Mailbox Database 001 в базу Mailbox Database 003 , а почтовые ящики базы Mailbox Database 002 в базу Mailbox Database 004 , нужно выполнить команду со следующим синтаксисом параметра DatabaseMap:

DatabaseMap @{"Mailbox Database 001"="Mailbox Database 003";"Mailbox Database 002"="Mailbox Database 004"}

Предположим, вы хотите переместить все почтовые ящики, принадлежащие пользователям, которые являются сотрудниками отдела Консультантов (Consultants) , в новую базу почтовых ящиков таким же способом, как мы только что обсудили. Для этого можно воспользоваться следующей командой PowerShell, если предположить, что атрибут "department" в Active Directory правильно заполнен:

Get-User | Where {$_.Department "eq "Consultants"} | Get-Mailbox | ./MoveMailbox.ps1 "DatabaseMap @{"Mailbox Database 001"="Mailbox Database 003";"Mailbox Database 002"="Mailbox Database 004"}

Этот код сначала получается подробности об учетных записях тех пользователей, чей Active Directory "department" атрибут имеет значение Consultants . Результаты этой команды подаются на обработку в команду Get-Mailbox с целью получения подробностей о почтовых ящиках этих пользователей. Затем эти подробности о почтовых ящиках обрабатываются в сценарии MoveMailbox и почтовые ящики перемещаются соответствующим образом. Как показано на рисунке 20, команда вызывает сценарий MoveMailbox, и теперь сценарий ожидает окончания процесса перемещения. По завершении этого процесса, информация состояния отображается на экране, как показано на рисунке 21. В результате выполнения этой команды в моей простой тестовой среде один почтовый ящик перемещен из базы Mailbox Database 001 в базу Mailbox Database 003 , а ящик из базы Mailbox Database 002 перемещен в базу Mailbox Database 004 .

Рисунок 20: Перемещение нескольких почтовых ящиков в процессе

Рисунок 21: Процесс перемещения нескольких почтовых ящиков завершен

Здоровье службы репликации почтовых ящиков

В этой статье мы уже говорили, что служба Microsoft Exchange Mailbox Replication является очень важной для общего процесса запросов перемещения, отсюда следует, что необходимо выполнять соответствующий мониторинг этой службы. В предыдущем цикле статей на msexchange.org, я рассказывал о различных Exchange 2007 "тестовых" Exchange Management Shell командах, которые можно использовать для тестирования определенных функций Exchange 2007. Exchange 2010 включает Test-MRSHealth команду, где MRS – это сокращение для службы репликации почтовых ящиков (Mailbox Replication Service). Для проверки здоровья определенного сервера Client Access Server нужно просто воспользоваться параметром "Identity , содержащим соответствующее имя сервера Client Access Server, например:

Test-MRSHealth "Identity DAG1

В вышеуказанном примере сервер Client Access Server называется DAG1. Результат выполнения этой команды будет схож с тем, что показан на рисунке 22.

Рисунок 22: Результаты выполнения команды Test-MRSHealth

На рисунке 22 видно, что команда Test-MRSHealth проверяет, работает ли служба репликации Mailbox Replication Service, затем выполняет RPC ping этой службы и, наконец, проверяет, как много времени прошло с момента сканирования очереди базы почтовых ящиков.

Удаление базы данных почтовых ящиков

В качестве части обычных обязанностей администратора вам иногда приходится списывать существующий Exchange 2010 сервер или просто удалить старую базу данных почтовых ящиков. Из предыдущих частей вы, возможно, помните, что запросы перемещения не очищаются автоматически, даже если перемещение было завершено. Исключением являются ситуации, когда используется сценарий MoveMailbox.ps1, но если запросы перемещения создавались вручную с использованием Exchange Management Shell или Exchange Management Console, их нужно будет удалить до того, как будет удалена база почтовых ящиков. Это применимо даже в тех ситуациях, когда данная база почтовых ящиков не содержит ни одного почтового ящика, но все еще имеется запрос перемещения.

Попытки удалить базу данных почтовых ящиков с существующим запросом перемещения приведут к выводу отчета об ошибке, начинающегося текстом "Эта база почтовых ящиков связана с одним или несколькими запросами перемещения (This mailbox database is associated with one or more move requests)"". Такая ошибка показана на рисунке 23. По этой причине нужно использовать Get-MoveRequest и Remove-MoveRequest команды для поиска и удаления существующих запросов перемещения.

Рисунок 23: Имеющийся запрос перемещения во время удаления базы данных

Заключение

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

Нейл является основным консультантом в Silverslands (www.silversands.co.uk), Золотом партнере Microsoft в Великобритании и отвечает за разработку, применение и поддержку приложений для многих крупных клиентов по всей Европе. В IT отрасли он трудится с 1987 года и специализируется на отправке сообщений с 1995. Он начинал работать еще с Exchange 4.0. Он также обладает званием Exchange MVP и уделяет некоторую часть своего личного времени на помощь различным пользователям Exchange, ведет блоги, посвященные Exchange. Эти блоги вы можете найти по адресу www.msexchangeblog.com . С Нейлом можно связаться по адресу

Вводная.

Имеются два леса AD. Каждый лес состоит из одного домена: forest1.local и forest2.local . В одном лесу (forest1) расположены учетные записи пользователей. В другом лесу (forest2) развернута организация Exchange 2010 SP3, в которой находятся почтовые ящики пользователей из forest1. Зеркального отражения учетных записей пользователей нет.

Задача.

Развернуть в forest1 организацию Exchange 2010 и перенести контент пользовательских почтовых ящиков из forest2 в forest1.

Описание инфраструктуры.

Forest1

forest1.local


  • forest1-dc1.forest1.local - контроллер домена

  • forest1-cas1.forest1.local

  • forest1-mbx1.forest1.local

  • forest1-tmg1.forest1.local

Принцип именования пользователей - [первая буква имени][фамилия]. Например, Иван Иванов - iivanov

Forest2

Лес AD состоящий из одного домена - forest2.local

В лесу развернуты следующие сервера:


  • forest2-dc1.forest2.local - контроллер домена

  • forest2-cas1.forest2.local - сервер Exchange 2010 SP3 (CAS и Hub)

  • forest2-mbx1.forest2.local - сервер Exchange 2010 SP3 (Mailbox)

  • forest2-tmg1.forest2.local - межсетевой экран, прокси, обратный (реверсный, реверсивный и т.п.) прокси

Принцип именования пользователей - [имя].[фамилия]. Например, Иван Иванов - ivan.ivanov

Организация Exchange обслуживает SMTP домен - forest.com . Пользователи получают доступ к почтовым ящикам по Outlook Anywhere, OWA, ActiveSync.

Перенос почтовых ящиков.

Подготовка сетевой инфраструктуры.

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


  • Обеспечить маршрутизацию трафика между двумя лесами (VPN Site-To-Site и т.п.).

  • Настроить взаимное разыменование внутренних имен (передача зоны, зоны-заглушки, условная пересылка и т.п.)

  • Убедиться, что сервера Exchange в обоих организациях доверяют сертификатам друг друга.

Подготовка серверов клиентского доступа.

Инициировать передачу контента почтового ящика можно, как из исходного леса (в моем примере -forest2), так и из конечного леса (в моем примере - forest1). Если команда на перемещение инициируется из конечного леса, то параметр должен быть разрешен в исходном лесу. Если команда на перемещение инициируется из исходного леса, то параметр Mailbox Replication Service Proxy (MRS Proxy) должен быть разрешен в конечном лесу.

Я буду инициировать перенос контента почтовых ящиков из конечного леса, поэтому включить MRS Proxy я должен на сервере forest2-cas1.forest2.local .



Set-WebServicesVirtualDirectory -Identity "Forest2-Cas1\EWS (Default Web Site)" -MRSProxyEnabled $true



Get-WebServicesVirtualDirectory | Set-WebServicesVirtualDirectory -MRSProxyEnabled $true

Подготовка пользовательских учетных записей в конечном лесу.

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


  • Отображаемое имя в обоих лесах - Семен Петров

  • Имя пользователя в Forest1 - spetrov

  • Имя пользователя в Forest2 - semen.petrov

  • Почтовый адрес - [email protected]

Перед началом переноса контента необходимо подготовить пользовательские учетные записи в конечном лесу (forest1). Это выполняется в два этапа.

Первый этап подготовки пользовательских учетных записей в конечном лесу.

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


Второй этап подготовки пользовательских учетных записей в конечном лесу.

На втором шаге необходимо, с помощью скрипта Prepare-MoveRequest.ps1 , скопировать некоторые атрибуты пользователя из исходном лесу.



Prepare-MoveRequest.ps1 -Identity ‘[email protected]’ -RemoteForestDomainController forest2-dc1.forest2.local -RemoteForestCredential (Get-Credential forest2\adm) -UseLocalObject

Я передаю в скрипт параметр -UseLocalObject . Это необходимо сделать, т.к. у меня в конечном лесу уже существует пользователь с включенной поддержкой почты.

Перенос контента почтового ящика из исходного леса в конечный лес.

Перенос контента осуществляется с помощью командлета New-MoveRequest .



New-MoveRequest -Identity "semen.petrov" -Remote -RemoteHostName forest2-cas1.forest2.local -RemoteCredential (Get-Credential forest2\adm) -TargetDeliveryDomain "forest1.local"

Что в это время происходит у пользователя?

После переноса контента почтового ящика у пользователя появится следующие сообщение:

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

Перемещение почтовых ящиков Exchange 2013 из одной БД в другую можно достаточно легко выполнить через EAC (Exchange Admin Center), но в этой статье я рассмотрю вариант переноса с помощью powershell, т.к. веб-интерфейс даже версии SP1 достаточно сырой и периодически возникают ошибки в заданиях при банальном перетаскивании ящика из одной базы в другую.

Найти больше информации по настройке и администрированию Exchange 2013 на моем блоге вы сможете в основной статье тематики — .

Перемещение почтовых ящиков Exchange 2013

Для создания запросов перемещения ящиков между базами данных используется командлет New-MoveRequest . Пример полной команды будет выглядеть следующим образом:

C:\Windows\system32>New-MoveRequest -Identity «[email protected]» -TargetDatabase «Name of you target database» -BatchName «Enter your request name» -BadItemLimit «200»

Запрос на перемещение сделали, отлично. Но что, если ящик имеет либо большой размер, либо огромное количество элементов и вы просто хотите отследить прогресс операции, который в самом начале показался в столбце PercentComplete ? Тут наступает самое интересное, потому что для отслеживания прогресса выполнения задания нам будет нужен уже другой командлет, вот он: Get-MoveRequestStatistics .

Пример использования на основе данных из команды в начале статьи:

C:\Windows\system32>Get-MoveRequestStatistics -Identity [email protected]

А вот и вывод команды:

Справа можно увидеть столбец с процентом выполнения задачи.

Следует отдельно рассказать о параметре BadItemLimit командлета New-MoveRequest : он отвечает за количество поврежденных элементов, которое будет пропущено. По умолчанию, если его не указывать, он равен 0 и Microsoft строго рекомендуют его не трогать. Однако если в ящике присутствуют поврежденные элементы, запрос будет завершаться с ошибкой и ящик останется в той же самой базе данных. На моей практике при переносе двух сотен ящиков из одних баз в другие (при миграции с Exchange 2010 на 2013) было не больше 2-4 ящиков с хотя бы одним поврежденным элементом, при том что 2010 сервер работал несколько лет. Поэтому можно сделать вывод, что при грамотном администрировании Exchange случаев с присутствием поврежденных элементов у вас будет достаточно мало.

Также хочу отметить, что если значение BadItemLimit у вас больше 50, то нужно принудительно указать ключ AcceptLargeDataLoss , по крайней мере так написано на Technet, но реально я всегда ставил количество элементов 200 и меня ни разу никто не спросил о том, согласен ли я на «большие потери данных» и не запретил при этом выполнение команды (см. первый скриншот, параметр AcceptLargeDataLoss там не указан).

Надо отметить, что концепция Exchange 2013 состоит в том, что центры администрирования включают в себя только базовый функционал, минимальный набор. Для получения же доступа к тонким параметрам, а зачастую даже к некоторым функциям (например, к операциям над Offline Address Book, но об этом в другой раз), нужно использовать исключительно Powershell.

Встроенные средства администрирования ОС не всегда удобны или зачастую не обладают достаточным функционалом, поэтому арсенал сисадмина со временем пополняется полезными утилитами, надстройками и скриптами, которые существенно упрощают повседневные задачи. Вдвойне отрадно, когда найденное решение не только помогает справиться с определенной проблемой, но и распространяется на безвозмездной основе.

Advanced IP Scanner

Сисадмин должен знать все о системах, работающих в сети, и быстро получать к ним доступ. С данной задачей помогает справиться Advanced IP Scanner , предназначенный для быстрого многопоточного сканирования локальной сети. Предоставляется AIPS совершенно бесплатно, без каких-либо оговорок. Программа очень проста и понятна в работе. После запуска AIPS проверяет IP-адреса сетевых интерфейсов хоста, на котором она установлена, и автоматически прописывает диапазон IP в параметры сканирования; если IP менять не нужно, то остается запустить операцию сканирования. В результате получим список всех активных сетевых устройств. Для каждого будет собрана вся возможная информация: MAC-адрес, производитель сетевой карты, сетевое имя, зарегистрированный в системе пользователь, доступные общие ресурсы и сервисы (общие папки, HTTP, HTTPS и FTP). Практически все опции сканирования можно настроить, например изменить скорость или исключить проверку определенного типа сетевых ресурсов (общие папки, HTTP, HTTPS и FTP). К любому ресурсу можно подключиться одним кликом, достаточно лишь отметить его в списке. AIPS интегрирована с программой Radmin и в процессе сканирования находит все машины с работающим Radmin Server. Результат сканирования можно экспортировать в файл (XML, HTML или CSV) или сохранить в «Избранном» (поддерживается drag-and-drop). В дальнейшем, при необходимости обращения к нужному клиентскому компу, сканировать сеть повторно не требуется. Если удаленное устройство поддерживает функцию Wake-on-LAN, его можно включить и выключить, выбрав соответствующий пункт меню.

Компания NetWrix, специализирующаяся на разработке решений для аудита изменений IT-инфраструктуры, предлагает десять бесплатных и очень полезных утилит , призванных заметно упростить администрирование ОС Windows. Например, NetWrix Inactive Users Tracker позволяет решить одну из насущных проблем безопасности - наличие неактивных учетных записей, которыми некоторое время никто не пользуется (уволенные сотрудники, командировка, перемещение по должности, временная учетка и тому подобное). Кадровики редко предупреждают IT-отдел об изменениях, и таким аккаунтом может запросто воспользоваться злоумышленник. Утилита периодически проверяет все учетные записи в доменах и сообщает о тех, доступ к которым не осуществлялся определенное время. В версии Free в качестве действий возможно указать лишь предупреждение по e-mail (достаточно задать параметры SMTP), все остальные операции админ производит вручную, хотя и предупреждения в нашем случае достаточно. В платной версии доступны: автоматическая установка случайного пароля, деактивация учетной записи и перемещение в другой OU, фильтр OU для поиска учетных записей. Отдельно предлагается PowerShell-командлет get-NCInactiveUsers, позволяющий получать список неактивных пользователей (проверяется атрибут «lastLogon») и упростить написание соответствующих скриптов.

WinAudit Freeware

WinAudit - бесплатная утилита от компании Parmavex Services , позволяющая произвести полный аудит системы. Не требует установки, может выполняться в режиме командной строки. Программа обладает простым и локализованным интерфейсом, поддерживается запуск на всех версиях Windows, в том числе 64-битных. Сбор данных занимает примерно минуту (продолжительность процесса может варьироваться в зависимости от операционной системы и конфигурации компьютера), результирующий отчет состоит из 30 категорий (поддается настройке). В результате админ может получить данные о системе, установленном ПО и обновлениях с указанием версии и вендора, подключенных устройствах; список открытых сетевых портов (номер, сервис, программа и прочее) и открытых папок; активные сессии; установки безопасности; права доступа к периферии; информацию об учетных записях и группах; список задач/сервисов; программы в автозапуске; записи журналов и системную статистику (uptime, использование памяти, дисков). Также можно задать поиск определенных файлов по имени. Например, чтобы найти музыку и видео на жестких дисках пользователя, достаточно задать соответствующие расширения (avi, mp3 и тому подобные). Результат можно открыть как веб-страницу, экспортировать в файл многих популярных форматов (txt, XML, CSV, PDF) или в базу данных (при помощи мастера, поддерживаются все популярные: MS SQL, MS Access, MySQL, Oracle и другие), отправить по e-mail и распечатать.


Учет компьютеров с помощью CheckCfg

Проблема учета оргтехники и используемого ПО остро стоит в любой организации. Решить ее можно разными способами, один из вариантов предлагает разработчик Андрей ТатуковCheckCfg . Это решение периодически собирает данные о железе, ОС и программах, включая тип CPU, объем ОЗУ, место на дисках, состояние S.M.A.R.T. и прочее. При этом CheckCfg легко справляется с несколькими сотнями компьютеров. Результат выводится в удобной древовидной форме, к локальным каталогам легко получить доступ. Каждому ПК может присваиваться инвентаризационный номер, при необходимости легко сгенерировать отчет в RTF-формате.

CheckCfg представляет собой целый комплекс программ. За непосредственный сбор данных о компьютере отвечает CheckCfg, которая запускается при старте ОС и записывает результат в файл. Управление и архивация информации производится при помощи программы учета Sklad, которая обрабатывает файлы, созданные CheckCfg, и сохраняет в свою базу данных, после чего можно формировать отчеты. При помощи программы Sklad_w можно в удобной форме просматривать текущие конфигурации компьютеров и основные данные по оргтехнике (по IP-адресам, CPU, Memory, ПО). Для анализа изменений в конфигурации ПК и оповещения об этом администратора используется еще одна утилита - Doberman. Возможно, настройка покажется не совсем тривиальной, так как предстоит вручную создать нужные конфигурационные файлы, но детальное описание на сайте и имеющиеся шаблоны позволяют без проблем со всем разобраться.

MailArchiva Open Source Edition

Некоторые почтовые серверы, вроде MS Exchange, имеют функции архивирования почты, позволяющие при необходимости найти старые сообщения, в том числе и чтобы выявить утечку конфиденциальной информации при расследовании инцидентов. В остальных случаях приходится обеспечивать данные функции самостоятельно. Вариантом решения является разработка компании MailArchiva , совместимая с большинством современных почтовых серверов (Lotus Domino, MS Exchange, MDaemon, Postfix, Zimbra, Sendmail, Scalix, Google Apps). Поддерживается архивирование по протоколам SMTP, IMAP/POP3, WebDAV и через Мilter (программа имеет встроенный SMTP- и Milter-сервер, IMAP/POP-клиент). Чтобы не собирать всю почту, можно создавать любые правила архивации. Реализовано три уровня доступа к сохраненным данным - пользователь (только своя почта), администратор (настройки и своя почта) и аудитор (вся почта, можно ограничить правилами). В Open Source версии MailArchiva также реализованы функции интуитивного поиска, в том числе во вложениях (Word, PowerPoint, Excel, OpenOffice, PDF, RTF, ZIP, tar, gz). Работает MailArchiva на Windows, Linux, FreeBSD и Mac OS X.

Performance Analysis of Logs

В случае проблем с производительностью системы обнаружить узкое место при помощи штатного Windows Performance Monitor, не имея опыта, довольно сложно. Для того чтобы разобраться, какие метрики нужно снимать и как правильно интерпретировать результат, потребуется тщательно прошерстить документацию. Утилита PAL (Performance Analysis of Logs, pal.codeplex.com) заметно упрощает поиск «бутылочного горлышка». После запуска она просматривает журналы и анализирует их при помощи встроенных шаблонов. В настоящее время имеются настройки для большинства популярных продуктов MS - IIS, MOSS, SQL Server, BizTalk, Exchange, Active Directory и других. После запуска администратор в мастере PAL Wizard активирует нужные счетчики, просто выбрав шаблон из списка предложенных, указывает текущие настройки сервера (количество CPU и прочие), интервал анализа и каталог для сохранения результата. Через некоторое время будет выдан подробный отчет в HTML и XML, содержащий описание, имя счетчика и показатели (Min, Avg, Max и Hourly Trend). Отчет затем можно легко скопировать в любой документ. Но разбираться далее в собранных параметрах придется все равно самостоятельно. Хотя если PAL показывает, что характеристика находится в зеленом секторе, волноваться не стоит. Сам запрос сохраняется в скрипте PowerShell PAL.ps1, который можно сохранить для дальнейшего использования. Шаблоны представляют собой XML-файлы; взяв за пример любой из них, можно создать свой вариант. Для редактирования параметров в шаблоне предлагается встроенный редактор PAL Editor.


Официально поддерживается Win7, но работает на всех ОС от MS, начиная с WinXP (32/64). Для установки понадобится PowerShell v2.0+, MS .NET Framework 3.5SP1 и MS Chart Controls for Microsoft .NET Framework 3.5.

Создаем точку доступа с Virtual Router

Ситуация, когда компьютер с Wi-Fi-картой необходимо превратить в точку доступа, сегодня отнюдь не редка. Например, нужно быстро развернуть WLAN или расширить зону покрытия Wi-Fi. Изначально работа беспроводной карты предусматривалась только в одном из двух режимов: точка - точка, когда клиенты подсоединяются друг к другу, или как точка доступа. В Win7/2k8 (кроме Win7 Starter Edition) появилась возможность виртуализировать сетевые соединения (технология Virtual Wi-Fi), позволяющая создавать несколько Wi-Fi-модулей со своими настройками при использовании одного физического Wi-Fi-адаптера. Таким образом компьютер может быть подключен к Wi-Fi и в то же время выступать в качестве точки доступа (SAPoint, Software Access Point). Соединение с таким виртуальным хот-спотом защищено при помощи WPA2. Превратить ПК под управлением Win7/2k8R2 в точку доступа можно при помощи консольной утилиты Netsh, через Центр управления сетями и общим доступом, либо воспользовавшись приложением Virtual Router , обладающим интуитивно понятным GUI и очень простыми настройками. После запуска Virtual Router нужно лишь указать SSD и пароль для подключения, а затем активировать точку доступа. При необходимости остановить работу хот-спота можно также нажатием одной кнопки. Дополнительно в окне отображаются текущие подключения к точке, для каждого можно задать свой значок и изменить некоторые параметры.


Управление RDC-подключениями - RDCMan

Для удаленного управления серверами и ПК, работающими под управлением Windows, предназначена оснастка Remote Desktop Connection. Если необходимо устанавливать много RDP-соединений с различными настройками, то работать с ней становится неудобно. Вместо методичного сохранения индивидуальных настроек для каждого удаленного компьютера можно использовать бесплатный инструмент Remote Desktop Connection Manager RDCMan , автоматизирующий этот процесс. После запуска следует указать настройки RDP-подключения, которые будут использоваться по умолчанию и наследоваться всеми соединениями. Здесь задаем общие учетные данные, шлюз, установки экрана, параметры безопасности и многое другое. Далее создаем нужное количество групп систем (например, по назначению, расположению, версии ОС), для каждой из них можно указать специфические настройки соединения. И последний шаг - заполнение групп системами. Для добавления сервера следует ввести лишь доменное имя, если любой параметр будет отличаться от настроек групп, его можно тут же переопределить. При необходимости системы легко перемещаются между группами простым перетаскиванием. Если систем много, проще создать текстовый файл, указав по одному имени в строке, после чего скормить заготовку утилите. Теперь, чтобы подключиться, достаточно выбрать нужный сервер и в контекстном меню щелкнуть пункт «Connect». Можно одновременно активировать несколько соединений и переключаться между ними.

Free Active Directory Tools

Управлять параметрами Active Directory при помощи штатных инструментов не всегда просто и удобно. В некоторых ситуациях поможет комплект утилит Free Active Directory Tools , разрабатываемый компанией ManageEngine. Комплект состоит из четырнадцати утилит, запускаемых из одной оболочки. Для удобства они разбиты на шесть групп: AD USer Report, SharePoint Report, User Management, Domain and DC Info, Diagnostic Tools и Session Management. Например, запуск Empty Password User Report позволит получить список учетных записей с пустыми паролями, GetDuplicates - получить аккаунты с одинаковыми атрибутами, CSVGenerator - сохранить в CSV-файл данные аккаунтов Active Directory. Другие возможности: отчет о времени последнего входа в систему, получение данных из AD на основе запроса, отчеты по установкам SharePoint, управление локальными учетными записями, просмотр и редактирование политик паролей домена, получение списка контроллеров домена и их ролей, управление их репликацией, мониторинг их работы (загрузка CPU, ОЗУ, жестких дисков, производительность и прочее), управление терминальными сессиями и многое другое.

Comodo Time Machine

Возможность восстановления системы при помощи компонента System Restore заложена в Windows, начиная с ХР, но его функциональность, мягко говоря, ограничена, поэтому для бэкапа часто используют сторонние приложения. Бесплатная утилита Comodo Time Machine (comodo.com) позволяет сделать откат ОС до любого предыдущего состояния. Причем она будет работать даже в том случае, когда ОС совсем перестала загружаться. В процессе CTM создает точки восстановления (вручную или по расписанию), в них заносятся все измененные системные файлы, реестр, а также файлы пользователя. Это большое преимущество по сравнению с System Restore, который сохраняет и восстанавливает только системные файлы и реестр. Максимальный размер имеет первая копия, остальные копии хранят лишь измененные файлы. С целью экономии свободного дискового пространства следует периодически создавать новую контрольную точку, удаляя старые архивы. Для возможности восстановления ОС информация о CTM прописывается в загрузочный сектор; чтобы вызвать соответствующее меню, достаточно нажать клавишу Home. Восстанавливать состояние ОС можно также по расписанию, например настроить поведение утилиты так, чтобы при каждой перезагрузке производился автоматический откат к «чистой» версии системы. Это будет полезно, например, в интернет-кафе, где пользователи после себя оставляют в системе много мусора. Кроме полного восстановления ОС, утилита предоставляет возможность получить из архива более раннюю версию любого файла. Реализован поиск, поэтому найти нужные данные можно без проблем.

Amanda

Задачу централизованного резервного копирования данных с рабочих станций и серверов, работающих под управлением Windows и *nix, можно решить при помощи AMANDA Advanced Maryland Automatic Network Disk Archiver). Изначально программа была создана для работы с ленточными накопителями, но со временем разработчики предложили механизм под названием «виртуальные ленты» (vtapes), позволяющий сохранять собранные данные на жесткие диски и CD/DVD. AMANDA является удобной надстройкой к стандартным Unix-программам dump/restore, GNU tar и некоторым другим, поэтому ее основные характеристики следует рассматривать именно исходя из возможностей этих базовых утилит. Работает по клиент-серверной схеме. Для доступа к компьютерам используются все доступные методы аутентификации: Kerberos 4/5, OpenSSH, rsh, bsdtcp, bsdudp или пароль Samba. Для сбора данных с Windows-систем задействуется специальный агент или, как вариант, Samba. Сжатие и шифрование (GPG или amcrypt) информации можно выполнять как непосредственно на клиенте, так и на сервере. Все настройки параметров резервирования производятся исключительно на сервере, в поставке имеются готовые шаблоны, поэтому разобраться довольно просто.

Core Configurator 2.0 for Server Core

Первоначальная настройка сервера, работающего под управлением Win2k8/R2 в режиме Server Core, производится в консоли при помощи команд. Чтобы упростить задачу, разработчики ОС добавили в R2 интерактивный скрипт SCONFIG.cmd, позволяющий настроить основные параметры системы. На Сodeplex доступна альтернатива - замечательный конфигуратор Core Configurator . Для его работы понадобится наличие компонентов NetFx2-ServerCore, NetFx2-ServerCore и PowerShell. После запуска Start_CoreConfig.wsf получаем меню, в нем находим несколько пунктов, обеспечивающих доступ к основным настройкам, которыми пришлось бы управлять из командной строки: активация продукта, настройка разрешения экрана, часов и временной зоны, сетевого интерфейса, установка разрешений для удаленных RDP-подключений, управление локальными учетными записями, настройки Windows Firewall, включение/отключение WinRM, изменение имени компьютера, рабочей группы или домена, настройка роли, компонентов, Hyper-V и запуск DCPROMO. Если установить флажок «Load at Windows startup», то программа будет загружаться вместе с системой.

Exchange 2010 RBAC Manager

В Exchange 2010 появилась новая ролевая модель доступа, позволяющая тонко контролировать уровень привилегий для пользователей и администраторов в зависимости от выполняемых задач. Единственный минус - встроенные средства управления при помощи командлетов PowerShell не всем могут показаться удобными и понятными. Более развитыми возможностями обладает бесплатный инструмент Exchange 2010 RBAC Manager (RBAC Editor GUI, rbac.codeplex.com), предлагающий понятный графический интерфейс для настройки свойств всех ролей. Разобраться с его особенностями не составит труда даже новичку. Программа написана на C# и использует PowerShell. Для работы понадобится установленный Exchange 2010 Management Tools.

PowerGUI

Едва появившись, командная оболочка PowerShell завоевала симпатии виндовых админов, которые давно нуждались в инструменте, позволяющем автоматизировать многие задачи. С первыми версиями PowerShell разработчики из Microsoft не смогли предложить более-менее функциональный редактор, поэтому нишу заполнили несколько сторонних проектов. Самым лучшим из них на сегодня является PowerGUI , предоставляющий удобный графический интерфейс для эффективного создания и отладки PowerShell-скриптов. При этом авторы предлагают готовые комплекты сценариев для решения многих задач - их можно использовать в своих разработках.

Multi-Tabbed PuTTY

Свободно распространяемый клиент PuTTY хорошо известен админам, которым необходимо подключаться к удаленным хостам по протоколам SSH, Telnet или rlogin. Это очень удобная программа, позволяющая сохранить настройки сессий для быстрого подключения к выбранной системе. Единственное неудобство - при большом количестве подключений рабочий стол получается загружен множеством открытых окон. Эту проблему решает надстройка Multi-Tabbed PuTTY , реализующая систему вкладок.

INFO

Изначально PuTTY разрабатывался для Windows, однако позднее был портирован на Unix.

Заключение

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

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

Powershell скрипт получения списка недавно созданных пользователей в Active Directory

Для получения списка пользователей созданных в Active Directory за последние 24 часа, проще всего воспользоваться командлетом PowerShell Get-ADUser . Вывод командлета будем фильтровать по атрибуту пользователя whencreated , в котором хранится дата и время создания учетной записи. У меня получится такой простенький PowerShell скрипт:

$lastday = ((Get-Date).AddDays(-1))

$exportcsv=”c:\ps\new_ad_users_” + $filename + “.csv”
Get-ADUser -filter {(whencreated -ge $lastday)} | Export-csv -path $exportcsv

В этом примере список учетных записей AD сохраняется в файл с текущей датой в качестве имени. С помощью планировщика можно настроить ежедневный запуска данного скрипта, в результате чего в указанном каталоге будут накапливаться файлы содержащих информацию о дате создания той или иной учетной записи. В отчет можно добавить любые другие атрибуты пользователя из Active Directory (см. статью об использовании ).

Как узнать, кто создал учетную запись в Active Directory

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

При заведении нового пользователя в журнале безопасности контроллера домена (только того DC, на котором создавалась учетная запись ) появляется событие с кодом EvenId 4720 (на DC должна быть включена в политике Default Domain Controller Policy).

В описании этого события содержится строка A user account was created , а затем указан аккаунт, из-под которого была создана новая учетка пользователя AD (выделен на скриншоте ниже).

Скрипт для выгрузки всех событий создания аккаунтов из журнала контроллера домена за последние 24 часа может выглядеть следующим образом:

$time = (get-date) - (new-timespan -hour 24)
$filename = Get-Date -Format yyyy.MM.dd
$exportcsv=”c:\ps\ad_users_creators” + $filename + “.csv”
Get-WinEvent -FilterHashtable @{LogName="Security";ID=4720;StartTime=$Time}| Foreach {
$event = $_.ToXml()
if($event)
{
$Time = Get-Date $_.TimeCreated -UFormat "%Y-%m-%d %H:%M:%S"
$CreatorUser = $event.Event.EventData.Data."#text"
$NewUser = $event.Event.EventData.Data."#text"
$dc = $event.Event.System.computer
$dc + “|” + $Time + “|” + $NewUser + “|” + $CreatorUser| out-file $exportcsv -append
}
}

По аналогии со статьей « » можно настроить сохранение информации о найденных событиях не в текстовый файл на каждом DC, а через единую базу MySQL.