Exchange : Exchange 2003/2007/2010 mailbox database white space

To check the amount of white space, admins can use one of these two options:

1. The Get-MailboxDatabase cmdlet will return the available space for new mailboxes

Get-MailboxDatabase <DB Name> -Status | fl Name,Avail*


Output from the Get-MailboxDatabase <DB Name> -Status | fl Name,Avail* command

2. To get a completely accurate representation of white space in the mailbox database, admins should use the ESEUTIL /MS command:

Output from the ESEUTIL/MS command

Exchange : KB555323 : Event ID 1221 reports less free space than should be the case

Event ID 1221 is a Microsoft Exchange event that reports the free or “white” space within a database after online defragmentation has taken place to be significantly less than you think it should be.


Symptoms include the increase in size of the Microsoft Exchange Information Store databases even after the lowering of the Deleted Item Retention Time figure (days) or after the deletion of a large mailbox or after a Mailbox Manager Recipient Policy reports a large amount of mail has been purged.

Furthermore, whilst totalling the number of mailboxes and subtracting that number from the total size of the EDB and STM files is an extremely crude measure, if you find the two numbers to be radically at odds (in hundreds of MB or even into GB) then you may be experiencing the problem described in the cause section.

This situation can be caused by the Exchange backup commencing during the online maintenance window. If the backup starts during this window the defragmentation pass will suspend, logging event id 704, and the Event ID 1221 will report the amount of contiguous free space that it has created up to that point in time. The online defragmentation will resume after the backup has stopped, so long as the backup has completed within the time frame of the maintenance window.

This can be checked for by looking for event 702 which resumes the defragmentation pass at the point it was suspended and then 703 which reports the completion of a previously suspended pass. You will see the 220 and 221 events reporting which stores have been backed up and when they were completed. If you never see a 702 event then you know that your 1221 event is inaccurate.

Another cause can be that a background cleanup process has yet to run to commit the deletions to the database. See the links at the More Information section.
This information applies to the Private (Mailbox) stores only. So long as the maintenance window is still open the Public Folder online defragmentation will restart within the next 15 minutes following completion of the backup.


Ensure that the backup is set to run before the maintenance window. The backup can run into the window allocated to the maintenance schedule because the maintenance schedule will “listen” for the backup to finish and then start after the backup has completed. Wherever possible try to run your maintenance window completely outside of the backup. You can benchmark the backup start and finish times to help you decide at what time to configure the maintenance window for.

VMWare : KB2000015 : Collecting vCenter Server logs when an alarm is triggered Purpose

To trigger the collection of vCenter Server logs when a particular error occurs:

  1. Create an alarm on the host in vCenter Server with the desired settings.
  2. Click the Actions tab in the Alarm Settings dialog.
  3. Click Add and select Run a command in the Action dropdown.
  4. Click the Configuration field and enter the command to run when the alarm is triggered. To collect the vCenter Server logs, enter:

    C:\Windows\System32\cscript.exe "C:\Program Files\VMware\Infrastructure\VirtualCenter Server\scripts\vc-support.wsf" /z

    Note: Ensure that you select the correct status for the Action. The status must match the status defined in the Triggers tab.

When this action is triggered, the vCenter Server log files will be located in C:\Windows\System32\config\systemprofile\Desktop.