Как уменьшить время на удаление (30 дней) после перемещения ящика Exchange в другую базу?

Question

[shupike]

Добрый день! Подскажите, плиз - переместил несколько ящиков Exchange в другую базу, white space не уменьшилось (нужно ждать 30 дней); как для конкретного ящика уменьшить это время? Ну то есть чтобы пространство после перемещенного ящика освободилось по требованию? Спасибо.

Answer 1

[MVV]

Вам точно нужно уменьшить именно whitespace (т.е. выпонить дефрагментацию БД), а не удалить из базы п/я, которые в ней остались в состоянии SoftDeleted (их можно увидеть командой Get-MailboxStatistics в EMS для БД, где они были)? Если нужно на самом деле удалить оставшиеся п/я (которые там по умолчанию болтаются упомянутые 30 дней), испольуйте команду Remove-StoreMailbox.

PS Дефрагментация же БД (онлайновая) идет сама по себе своим чередом и обычно кушать не просит. Ну а автономная (offline) дефрагментация, с помощью eseutil - это вообще средство на крайний случай.

Comments

[shupike]

Ну строго говоря, это ведь не удаление ящика - удаляю я обычно вместе с учеткой, там все понятно. А здесь именно перемещение ящика между базами и 30 дней старая версия ящика в старом расположении висит, съедая white space (ящики есть по 105 Гб). Вот чтобы ее убрать, не дожидаясь истечения 30 дней - нужна Remove-StoreMailbox?

[MVV]

Старая версия ящика в БД не отъедает whitespace (котрый есть потеря на фрагментацию), а является хранящимся в БД объектом. Выполните команду Get-MailboxStatistics -Database в EMS - и убедитесь в этом сами. После этого посмотрите GUID удаленного п/я и удалите его окончательно командой Remove-StoreMailbox. Если таких п/я много, можно окончательно удалить их из базы все, в документации на Remove-StoreMailbox есть пример, как это сделать (только он не для помеченных удаленными, а для отсоединеных п/я, но поменять там несложно).

[Роман Безруков]

shupike, whitespace в почтовой БД - это место в БД, которое используется при создании новых почтовых ящиков...
Причем правильное количество whitespace вам покажет только eseutil на размонтированной базе

P.S. ящики по 100+ гигов - вы там что храните и за какой период? Или у вас почта используется как файлообменник?

[shupike]

Роман Безруков, фактически да, пока что ожидается запуск CRM, а до тех пор все хранится в почте. Я почему так аккуратно все и делаю - не хотелось бы потерять данные. А началось все с неудачного обновления в июле - слетела индексация по всем ящикам за пару недель (пока заметили, что в поиск не попадают некоторые сообщения). Ну и лучшим рецептом оказалось переключение ящиков между базами, как это ни тупо. Больше ничего не помогло. Но если с небольшими ящиками не возникло сложностей, то с огромными приходится либо ждать 30 дней, либо вот пробовать удалить прежнюю копию в старом расположении.

Answer 2

[Роман Безруков]

Поменять в свойствах исходной почтовой базы время хранения удаленных ящиков (по умолчанию - это 30 дней).
Если после переноса ящика надо срочно освободить место - дефрагментация почтовой БД с помощью Eseutil

Comments

[shupike]

Правильно ли понимаю - это на уровне базы действует, но не на уровне ящика? То есть изменения повлияют на все ящики, смонтированные на эту базу?

[Роман Безруков]

shupike, да...
Вы не можете настроить время хранения отдельного удаленного/отключенного ящика