Последние несколько недель занимался реструктуризацией почтовых баз. В итоге количество баз увеличилось примерно в 2 раза, средний размер составляет 20-25Гб. Несколько гигантских баз было расформировано и удалено (например 2 базы по 70Гб). К этому решению шёл долго. Началось всё с, казалось бы, незначительной проблемы с рассылкой почты по спискам распространения. Случайно выяснилось, что при рассылке почта доходит не всем адресатам. Доходя до некоторых адресатов почта застревает в очереди и либо через несколько попыток доходит, либо (что происходило чаще) через 3 дня с начала отправки формируется NDR и сообщение из очереди удаляется. Вот здесь пытался разобраться с этой проблемой. Как оказалось дело в том, что нарушена целостность почтовых баз. Решений оказалось всего три:
1. Нахождение проблемных пользователей, выгрузка их почты в PST, пересоздание почтового ящика и загрузка PST обратно.
2. Проверка почтовых баз и исправление ошибок с помощью isinteg.
3. Создание новых хранилищ и перенос пользовательских данных в них.
Первый пункт в моем случае оказался малопродуктивным (слишком много проблемных пользователей), со вторым возникла некоторая проблема. Как известно isinteg /fix работает примерно со скоростью 10Гб/с на базе без ошибок, а при исправлении ошибок скорость снижается на 3 порядка. В итоге 2 проблемные базы на 70Гб так до конца проверить и не получилось, так как оставлять часть офиса без почты более чем на 10 часов даже в выходные мне было запрещено. Остался только третий пункт. При переносе заметил следующую особенность – скорость переноса сильно зависит не от объёма ящика, как можно было бы подумать, а от количества сообщений в нём. Помимо этого скорость зависит ещё от количества одновременно переносимых ящиков. В итоге экспериментальным путём установил, что ящик, в котором около 30000 сообщений, переносится в районе часа.
Параллельно с процессом переноса решалась задача о соответствии структуры хранилищ организационной структуре компании. В итоге сваял простенький запрос на PoSh для вытаскивания на свет информации о пользователе, отделе в котором он работает, компании (у нас несколько юридических лиц и эта информация отображается в учётной записи пользователя) и базе, в которой находится его ящик:

Get-QADUser -IncludeAllProperties -SerializeValues -SizeLimit 0 | Where-Object {$_.homeMDB 
-notlike ''} | Select-Object Name, homeMDB, department, Company | Export-Csv f:tmp.csv

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

Известно, что в Windows 2008 server MS решила отказаться от использования утилиты ntbackup (скорее всего сказалось слияние Veritas и Symantec пару лет назад). Вместо неё предлагается утилита Windows Backup. Механизм её работы аналогичен механизмам работы продуктов для бэкапирования, что предлагает Acronis (бэкап на уровне томов и блоков, а не на уровне файлов). С месяц назад на руки мне попала бумажная вресия TechNet Magizine в котором имеется прекрасная статья о применении Windows Backup для бэкапа и восстановления AD.
Некоторые выжимки, интересные для меня выкладываю ниже.
1. Среда загрузки Windows 2008 server и Windows Vista отличаются от того, что было в предыдущих версиях. Ниже описываю процесс добавления пункта в загрузочное меню, которое позволяет загружаться в безопасном режиме.
Добавляем новый пункт меню, копируя в него информацию из дефолтного:

C:\>bcdedit /copy {default} /d "Directory Service Repair Mode"

Эта команда выдаст в итоге что-то типа следующего:

The entry was successfully copied to {c50d4710-a1f0-11dc-9580-0003ff402ae9}

Теперь этот пункт меню сделаем загрузкой в безопасном режиме:

C:\>bcdedit /set {c50d4710-a1f0-11dc-9580-0003ff402ae9} safeboot dsrepair

Теперь при загрузке мы можем выбирать в каком режиме нам грузится.
2. Работа с графической утилитой бэкапирования мне не интересна и честно говоря малоперспективна в связи с невозможностью на основе её создавать сложные пакетные задания.
Для бэкапа состояния системы используется следующая команда:

C:\>wbadmin start systemstatebackup –backuptarget:e:

Следует иметь ввиду, что в качестве backuptarget по умолчанию мы не можем указывать тот том, с которого снимается бэкап. Но это ограничение обходится следующим образом – в ветке реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\wbengine\SystemStateBackup создается следующий ключ:

Name: AllowSSBToAnyVolume
Data type: DWORD
Value data: 1

При переключении на 0, мы возвращаемся к поведению системы по умолчанию.
3. С созданием резервной копии состояния системы понятно. Теперь немного информации о том, что можно с этой копией сделать. Чтобы посмотреть имеющиеся в базе копии используется следующая команда:
[vash]C:\>wbadmin get versions[/bash]
Её результатом может быть что-то типа:

wbadmin 1.0 - Backup command-line tool
(C) Copyright 2004 Microsoft Corp.
Backup time: 11/30/2007 3:47 PM
Backup target: Fixed Disk labeled E:
Version identifier: 11/30/2007-22:47
Can Recover: Application(s), System State
Backup time: 12/1/2007 10:46 PM
Backup target: Fixed Disk labeled Backup(E:)
Version identifier: 12/02/2007-05:46
Can Recover: Volume(s), File(s), Application(s), Bare Metal Recovery, System State
Backup time: 12/2/2007 5:58 PM
Backup target: Fixed Disk labeled Backup(E:)
Version identifier: 12/03/2007-00:58
Can Recover: Volume(s), File(s), Application(s), Bare Metal Recovery, System State
Backup time: 12/3/2007 11:25 AM
Backup target: Fixed Disk labeled E:
Version identifier: 12/03/2007-18:25
Can Recover: Application(s), System State

А зная дату бэкапа и что бэкапировалось можно легко восстановить всё это, например следующим образом:

C:\>wbadmin start systemstaterecovery –version:12/03/2007-18:25

Таким образом мы получим неполномочное (non-authoritative) восстановление. Для восстановления объектов AD это не особо интересно, но знать об этом имеет смысл. Для принудительного восстановления каталога SYSVOL достаточно к этой команде добавить параметр -authsysvol. Более подробно о неполномочном восстановлении можно почитать здесь
4. Самое интересное – восстановление объектов AD. Как и в Windows 2003 server для этого используется ntdsutil, но предоставляемые возможности значительно шире. ntdsutil научился делать мгновенные снимки AD и в дальнейшем можно их подключать, использую стандартную оснастку AD Users & Computers. Создание снимка выглядит следующим образом:

ntdsutil: snapshot
snapshot: activate instance ntds
Active instance set to "ntds".
snapshot: create
Creating snapshot...
Snapshot set {42c44414-c099-4f1e-8bd8-4453ef2534a4} generated successfully.
snapshot: quit
ntdsutil: quit

Удаление ненужных снимков делается следующим образом:

C:\>ntdsutil
ntdsutil: snapshot
snapshot: list all
1: 2007/12/03:23:18 {42c44414-c099-4f1e-8bd8-4453ef2534a4}
2: C: {c0dd71ba-5bcd-4daf-9fbb-5cfbdd168022}
3: D: {2bbd739f-905a-431b-9449-11fba01f9931}
snapshot: delete 1
Snapshot {c0dd71ba-5bcd-4daf-9fbb-5cfbdd168022} mounted as C:$SNAP_200712032318_VOLUMEC$
Snapshot {2bbd739f-905a-431b-9449-11fba01f9931} mounted as C:$SNAP_200712032318_VOLUMED$
snapshot: quit
ntdsutil: quit
C:\>

Самое интересное – возможность монтирования ранее созданных снимков.

C:\>ntdsutil
ntdsutil: snapshot
snapshot: list all
1: 2007/12/03:23:18 {42c44414-c099-4f1e-8bd8-4453ef2534a4}
2: C: {c0dd71ba-5bcd-4daf-9fbb-5cfbdd168022}
3: D: {2bbd739f-905a-431b-9449-11fba01f9931}
snapshot: mount 1
Snapshot {c0dd71ba-5bcd-4daf-9fbb-5cfbdd168022} mounted as C:$SNAP_200712032318_VOLUMEC$
Snapshot {2bbd739f-905a-431b-9449-11fba01f9931} mounted as C:$SNAP_200712032318_VOLUMED$
snapshot: quit
ntdsutil: quit
C:\>

Их можно подключать командой dsamain, например так:

C:\>dsamain –dbpath c:\$snap_200712032318_volumed$ntdsdit ntds.dit -ldapport 10000

Теперь к снимку AD можно подключиться через AD Users & Computers используя localhost в качестве сервера и 10000 – в качестве порта к которому подключаемся.