чем открыть базу exchange
Работа с базой данных Exchange
Данная статья представляет из себя шпаргалку по работе с почтовой базой Exchange на примере версий 2010, 2013 и 2016.
Работа с почтовой базой несет в себе потенциальную опасность потери всей информации. Прежде, чем начать работу, стоит убедиться в наличии актуальной резервной копии.
Просмотр содержимого базы
1. Список элементов базы можно увидеть командой в Powershell:
* где Base1 — имя базы данных, содержимое которой необходимо посмотреть.
Важно отметить, что это могут быть уже перенесенные элементы.
2. Список действующих ящиков, находящихся в базе:
3. Размер почтовых ящиков в базе:
4. Список всех элементов в базе и занимаемый ими размер:
5. Посмотреть системные почтовые ящики:
6. Установленные квоты
На все базы данных:
Get-MailboxDatabase | fl Name, *Quota
На конкретную базу:
Get-MailboxDatabase Base1 | fl Name, *Quota
Дефрагментация
Необходима для освобождения пространства, занимаемого файлом базы. Это связано с тем, что при удалении элементов, сама база не уменьшается.
Посмотреть, какое количество пространства удастся высвободить можно командой:
* где DatabaseSize — текущий размер базы; AvailableNewMailboxSpace — пространство, которое можно освободить при дефрагментации.
Саму оптимизацию можно выполнить двумя способами:
В текущем подразделе мы рассмотрим первый способ.
Офлайн дефрагментация приведет к отключению почтовой базы и, как следствие, приостановку работы почтовых ящиков, которые в нем содержатся.
Если используется база на основе группы DAG, сначала необходимо удалить неактивную копию.
Операция дефрагментации выполняется из Exchange Management Shell с применением утилиты eseutil.
Сначала переходим в каталог хранения базы данных, например:
cd C:\Program Files\Microsoft\Exchange Server\V14\Mailbox\Base1
Выполняем команду для отмонтирования базы:
* напомним, что это приведет к отключению базы и приостановки обслуживания.
eseutil /d Base1.edb /t \\share\base1_tmp.edb
* где опция d — имя файла базы; t — путь до временного файла на момент дефрагментации, если его не указать, временный файл будет создан в каталоге с основным файлом и, в таком случае, нужно убедиться, что на диске достаточно свободного места (110% от размер дефрагментируемого файла).
После завершения операции, снова подключаем базу:
Перемещение файла базы в другую папку
Если используется база на основе группы DAG, сначала необходимо удалить неактивную копию.
Вытаскиваем GUID для нужной базы:
Get-MailboxDatabase Base1 | fl Name, Guid
Используя GUID, перемещаем базу:
* где 55e0595f-9b48-4285-b12a-faeb8efa7278 — идентификатор перемещаемой базы; D:\Database\NewPath — каталог, куда будет перемещена база (если не создан, система создаст автоматически).
На вопросы консоли отвечаем утвердительно — Y.
Перемещение почтовых ящиков между базами
Переместить все ящики
Для переноса почтовых ящиков из Base1 в Base2 выполняем следующую команду в Powershell:
После не забываем перенести системные почтовые ящики, если они есть в базе:
Посмотреть статус перемещения можно командой:
Переместить один ящик
Для перемещения одного единственного ящика в новую базу, вводим команду:
* в данном примере мы перенесем почтовые данные пользователя user в базу Base7.
Посмотреть статус перемещения можно командой:
Освобождение пространства базы после перемещения ящиков
Мы заметим, что после перемещения ящиков, размер базы не изменился. Дело в том, что его полное удаление из базы произойдет после того, как пройдет количество дней, выставленное в параметре MailboxRetention. Посмотреть значение для каждой базы можно командой:
Get-MailboxDatabase | Select Name, MailboxRetention
Если мы не хотим ждать, меняем данное значение:
После нужно сделать дефрагментацию базы. Несмотря на указание 0, нужно немного подождать применения настроек.
Удаление копии базы в DAG-группе
Данное действие не приведет к удалению самих файлов, имеющих отношение к базе. Если необходимо полностью очистить сервер от данных, после удаления копии базы, вручную удаляем ее файлы.
Сначала проверяем, что для базы отключено ведение циклического журнала. После можно переходить к удалению.
Графический интерфейс
и подтверждаем желаемое действие.
Powershell
* где Base1 — имя базы; Server1 — имя сервера, на котором находится удаляемая копия.
Включение активной копии базы в DAG
В группе DAG только одна копия базы может быть активной. Таким образом, может возникнуть необходимость переключиться на другой сервер. Это делается в графическом интерфейсе или командной консоли Powershell.
Графический интерфейс
Ниже кликаем правой кнопкой по базе, которая находится на нужном нам сервере и выбираем Включить копию базы данных. :
В появившемся всплывающем окне выбираем параметр для автоматического переопределения активного сервера или оставляем в положении «Нет».
Powershell
Для смены активного сервера базы из группы DAG вводим:
* где ActivateOnServer указываем на целевой сервер, на котором должна быть активирована копия базы; MountDialOverride — параметр для автоматического подключения базы (возможны варианты: None, Lossless, GoodAvailability, BestAvailability, BestEffort); Confirm — требование от администратора вводить подтверждение перемещения активной копии (необходимо отключать для скриптов). В данном примере мы перемещаем активную копию базы DB5 на сервер SERVER15 без переопределения автоматического переноса сервера; консоль не потребует подтвердить наши намерения.
Отключение или включение ведения циклического журнала
Графический интерфейс
На вкладке Обслуживание снимаем галочку Включить циклическое ведение журнала (или ставим, если нужно его включить):
Powershell
Ручное удаление файлов журанала
Данное действием может понадобиться для освобождения дискового пространства, которое занимается журналами.
Запускаем Exchange Management Shell. Переходим в каталог хранения базы данных, например:
cd C:\Program Files\Microsoft\Exchange Server\V14\Mailbox\Base1
* в данном примере подразумевается, что база находится в каталоге C:\Program Files\Microsoft\Exchange Server\V14\Mailbox\Base1.
Находим файл, в котором находится информация из контрольной точки фиксации журналов:
Результат будет, примерно, следующим:
* в данном примере, нужный нам файл называется E05.chk.
Теперь узнаем последний файл журнала, действия из которого были занесены в базу Exchange:
Мы получим информацию о фиксации журналов — нас интересует Checkpoint
* в данном примере для нас важно значение 561299.
. теперь, когда мы получили значение Checkpoint, мы знаем имя файла, который был последним зафиксирован (его информация уже в базе данных). Находим в проводнике файл, в названии которого есть наше значение Checkpoint:
Теперь можно удалять все файлы журналов (их название начинается с E и это txt-файлы), которые старше найденного нами файла.
Переиндексация базы (восстановление поиска или репликации)
Данную процедуру необходимо выполнять, если наблюдаются проблемы с поиском в почте или репликации DAG-копии. Выполняется в Exchange Management Shell.
Одна копия базы
Переходим в каталог Exchange:
cd «\program files\microsoft\exchange server\v14\scripts»
При использовании DAG
Смотрим, у какой копии базы произошел сбой индекса:
Name : DAG01\Server1
ContentIndexState : Failed
Name : DAG01\Server2
ContentIndexState : Healthy
Активируем копию базы на сервере с исправным индексом:
Запускаем копирование каталога с исправного сервера:
Делаем активной копию базы на старом сервере:
Перенос отключенных почтовых ящиков между базами
В данном примере мы рассмотрим ситуацию, когда у нас есть база от старого или другого сервера exchange, и мы должны перенести из нее все почтовые ящики в новую базу. Предположим, что база DAG01 — старая база, а DAG02 — новая.
Получаем список отключенных почтовых ящиков:
Необходимо подключить почтовый ящик к существующему пользователю Active Directory без почтового ящика. Имя пользователя должно совпадать с именем почтового ящика, иначе почтовый ящик будет переименован:
* где identity — Identity или DisplayName почтового ящика; user — аккаунт или DisplayName пользователя домена.
Для подключения почтового ящика к пользователю имеющему почтовый ящик, необходимо сначала отключить его текущий почтовый ящик:
Теперь можно перенести почтовый ящик в другую базу:
Для перемещения нескольких пользователей сразу необходимо создать задание на перемещение с указанием CVS файла содержащего имена пользователей:
Работа с Microsoft Exchange через ESEUTIL
Прерывание электричества, ваш сервер Microsoft Exchange выключается и почтовая база данных почему-то уже не поднимается автоматически.
В диагностике и решении проблемы нам поможет утилита ESEUTIL.
Как проверить состояние базы данных с помощью eseutil?
Проверить статус всех баз можно с помощью выполнения скрипта в Exchange Management Shell:
Для проверки целостности всех лог-файлов нужно использовать команду:
Восстановление базы данных из Dirty Shutdown в Clean Shutdown
Для начала, разберёмся, как работает почтовая база данных Microsoft Exchange и как вообще попадают в базу письма.
В папке с базой данных у нас есть несколько типов файлов:
Прежде чем, письмо придёт к пользователю в клиент, оно проходит несколько уровней:
В процессе работы сервера может возникнуть ситуация, когда новая информация находится только в transaction логе и не была записана в базу данных. Если в этот момент произойдёт некорректное выключение сервера, часть данных останется в файле E00.log, а база данных перейдёт в состояние Dirty Shutdown.
В большинстве случаев, при некорректном выключении и переводе базы в Dirty Shutdown, конечно, Exchange сервер самостоятельно проведёт необходимые проверки, решит проблему и смонтирует базу.
Но если этого не случилось и база остаётся в Dirty Shutdown, чтобы снова её смонтировать, нам необходимо провести действия по переводу в Clean Shutdown самостоятельно.
Для начала, проверим состояние базы.
Переходим в каталог с базой:
Теперь для проверки целостности базы данных вызываем команду:
Смотрим на поле State.
И проверяем лог-файлы, используя команду:
Вместо E00 — ваш префикс лога. Если баз несколько, он может быть E01, E02 и т.д.
Итак, если база данных в состоянии Dirty Shutdown, а все логи в состоянии ОК, можно воспользоваться мягким восстановлением (Soft Recovery). Фундаментальным предположением, используемым при процессе «мягкого» восстановления, является то, что ни один файл базы данных или журналов не был перемещен, удален или уничтожен при сбое или администратором после произошедшего сбоя.
Если у меня логи лежат на диске L в папке MYDB и база лежит на диске D в папке MYDB, команда будет выглядеть так:
Если восстановление прошло успешно и состояние базы сменилось на Clean Shutdown, можно начинать монтировать базу. Если этого не произошло, то стоит попробовать другие методы. Будьте осторожны, не забывайте про бэкапы.
Полезные ссылки по теме восстановления базы через eseutil
Другие команды eseutil
При использовании ESEUTIL, вы должны убедиться, что забекапились, понимаете что делаете и готовы к последствиям.
(2 оценок, среднее: 5,00 из 5)
Загрузка.
Добавьте копию базы данных почтовых ящиков в Exchange Server
При добавлении копии базы данных почтовых ящиков автоматически включается непрерывная репликация между базой данных и ее копией. Копиям баз данных автоматически назначено удостоверение в формате \ Например, копия базы данных DB1, которая размещается на сервере MBX3, будет называться DB1\MBX3.
Сведения о других задачах управления, относящихся к копиям базы данных почтовых ящиков, см. Проверьте Управление копиями баз данных почтовых ящиков.
Что нужно знать перед началом работы?
Предполагаемое время выполнения задачи: 2 минуты, а также время на заполнение копии базы данных, которое зависит от ряда факторов, например размера базы данных, скорости, доступной полосы пропускания и задержки сети, а также скорости работы хранилища.
Для выполнения этих процедур необходимы соответствующие разрешения. Сведения о необходимых разрешениях см. в статье Запись «Копии базы данных почтовых ящиков» в разделе Разрешения высокого уровня доступности и устойчивости сайта.
Необходимо подключить активную копию базы данных.
Указанный сервер почтовых ящиков не должен содержать уже существующую копию базы данных.
Путь к копии базы данных и ее файлам журналов должен быть доступен на указанном сервере почтовых ящиков.
Сервер, на котором размещается активная копия и сервер, на котором будет размещена пассивная копия, должны находиться в одной группе обеспечения доступности базы данных (DAG). Группа доступности базы данных также должна иметь кворум и быть работоспособной.
Если добавляется вторая копия базы данных (например, создается первая пассивная копия базы данных), для указанной базы данных почтовых ящиков не должно быть включено циклическое ведение журнала. Если циклическое ведение журнала включено, его необходимо отключить. После добавления копии базы данных почтовых ящиков циклическое ведение журнала можно включить. После включения циклического ведения журнала для реплицируемой базы данных почтовых ящиков вместо циклического ведения журнала JET используется циклическое ведение журнала с непрерывной репликацией (CRCL). Если добавляется третья или последующая копия базы данных, CRCL можно оставить включенным.
Сочетания клавиш для процедур, описанных в этой статье, приведены в статье Сочетания клавиш в Центре администрирования Exchange.
Возникли проблемы? Попросите помощи на форумах Exchange. Перейти на форумы можно по следующим ссылкам: Exchange Server, Exchange Online или Exchange Online Protection.
Использование EAC для добавления копии базы данных почтовых ящиков
В Центре администрирования Exchange последовательно выберите пункты Серверы > Базы данных.
Выберите базу данных, которую нужно скопировать, выберите Дополнительно (три точки справа от значка «Обновить»), а затем нажмите Добавить копию базы данных.
На странице Добавление копии базы данных почтовых ящиков щелкните Обзор, выберите сервер почтовых ящиков, на котором будет размещена копия базы данных, а затем щелкните ОК.
При необходимости настройте Приоритет активации для копии базы данных.
Щелкните дополнительные параметры. Чтобы назначить копию базы данных в качестве отстающих копий базы данных, настроив время задержки воспроизведения или оторвав автоматическое посевное копирование копии базы данных.
Щелкните Сохранить для сохранения изменений конфигурации и добавления копии базы данных почтовых ящиков.
Нажмите кнопку ОК, чтобы подтвердить все появляющиеся сообщения.
Используйте оболочку Exchange управления, чтобы добавить копию базы данных почтовых ящиков
В этом примере копия базы данных почтовых ящиков DB1 добавляется на сервер почтовых ящиков MBX3. Время задержки воспроизведения и время запаздывания усечения остаются без изменений (0), а для приоритета активации устанавливается значение 2.
Как проверить, что все получилось?
Чтобы убедиться, успешно ли создана копия базы данных почтовых ящиков, выполните одно из следующих действий:
В центре администрирования Exchange откройте раздел Серверы > Базы данных. Выберите базу данных, которая была скопирована. В области «Сведения» отображается состояние копии базы данных и индекса ее содержимого, а также текущая длина очереди копирования.
В командной Exchange управления запустите следующую команду, чтобы проверить, что копия базы данных почтовых ящиков создана и здорова.
Состояние самой копии и индекса содержимого должно быть указано как работоспособное.
/AlexxHost/
Вы попали на блог, целиком и полностью посвященный продуктам компании Microsoft. В основном речь будет идти про системы корпоративных коммуникаций на базе Exchange Server.
понедельник, 26 сентября 2011 г.
Восстановление сервера Exchange
Представим, что у нас есть Exchange сервер в организации и внезапно железо, на котором он крутится, умирает. Причем умирает так, что восстановить ни чего уже нельзя, а актуальных бэкапов самого сервера (с System State) нет. Есть только бэкап баз данных.
Ситуация не приятная, но не критичная и из неё есть по крайней мере два выхода:
Потеряв сам сервер, но имея актуальный бэкап баз данных, мы достаточно быстро можем вернуть систему в рабочее состояние. Фактически, мы можем поднять совершенно новый сервер Exchange с теми же ролями, назвать сервер другим именем, но подключить старые базы данных, после чего переключить на новый сервер старых пользователей. Далее по пунктам:
Поднимаем новый сервер и подключаем базы данных:
В установке сервера ни чего сложного нет, напомню только, что мы его поднимаем на новом железе, на свежеустановленной и обновленной операционке с новым именем. Далее надо подключить к нему базы данных, предварительно восстановив их из бэкапа.
Дело в том, что восстановленные из бэкапа базы данных находятся в состоянии Dirty Shutdown, прежде чем их смонтировать, нужно перевести базы в состояние Clean Shutdown. Для этого придется вооружиться утилитой ESEUTIL, о том, как ей пользоваться я писал ранее в статьях «Восстановление баз данных при помощи ESEUTIL» и «Исправление базы данных почтовых ящиков в Exchange» (желательно использовать первый вариант).
После того, как базы данных готовы, можно монтировать их на новый сервер под новыми именами. Для того, чтобы смонтировать базу с другого сервера поступим следующим образом:
Теперь можно сказать, что почтовые ящики пользователей возвращены в организацию, но сами пользователи об этом пока ни чего не знают.
Переключение пользователей на работу с новым сервером и новой базой данных:
Пользователи узнают о том к какой базе и к какому серверу почтовых ящиков они подключены, читая атрибуты своей учетной записи в Active Directory. Т.е. для того, чтобы перенацелить пользователей на новый сервер и новую базу, нужно изменить всего 3 атрибута:
Рис.1: Атрибуты, указывающие на сервер и базу данных.
Сделать это можно руками, через программу ADModify всем сразу, либо через PowerShell (EMS). Команда в EMC будет выглядеть следующим образом:
Get-Mailbox –Database
- | Set-Mailbox –Database
Рис.2: Перенацеливаем пользователей на другую базу данных.
Теперь, открывая Outlook пользователь и не заметит, что его почтовый ящик переехал на новый сервер.
Примечание: В Exchange 2007 это команда работать не будет, нужно использовать командлет Move-Mailbox с параметром –ConfigurationOnly.
Восстановление параметров сервера:
Восстановив доступ пользователей к своим почтовым ящикам, мы решили только половину задачи. Т.к. мы поднимали новый сервер, а не восстанавливали его в режиме Восстановления, то теперь осталось самое трудное – перенести все настройки со старого сервера на новый. В большинстве своем сделать это придется руками.
Облегчить задачу может ситуация, если мы ещё не удалили сервер из Active Directory. В этом случае в консолях управления сервером мы можем прочитать большинство параметров со старого сервера и установить аналогичные на новом.
Конкретные рекомендации тут дать трудно, подскажу только, что надо не забыть сменить сервер, отвечающий за генерацию ОАВ (см. рис.3)
Рис.3: Изменение параметров ОАВ.
После того, как все параметры будут перенесены, и вы убедитесь, что новый сервер работает не хуже старого, можно почистить все упоминания о старом сервере, т.е. удалить его совсем из организации. Для этого необходимо удалить учетную запись в Active Directory и удалить объект сервера в разделе Конфигурация базы данных AD, через оснастку ADSIEdit.
Для этого откроем ADSIEdit, подключимся к разделу
Рис.4: Объект сервера Exchange в базе данных Active Directory.
Заключение
Берегите свои сервера, делайте регулярные бэкапы и не ставьте Exchange на контроллер домена! К сожалению, команда metadata cleanup не всегда отрабатывает так, как должна, а сбросить учетку контроллера, не сделав его рядовым сервером, мы не можем.
Во время подготовки данной статьи, в роли технического эксперта выступал Александр Станкевич (Stanky), за что ему огромное спасибо! Без него данный материал не появился бы на страницах этого блога, да и задача, на основе которой написана статья, была бы решена другим, менее рациональным способом.