MICROSOFT CORPORATION AND/OR ITS RESPECTIVE SUPPLIERS MAKE NO REPRESENTATIONS ABOUT THE SUITABILITY, RELIABILITY, OR ACCURACY OF THE INFORMATION AND RELATED GRAPHICS CONTAINED HEREIN. ALL SUCH INFORMATION AND RELATED GRAPHICS ARE PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT AND/OR ITS RESPECTIVE SUPPLIERS HEREBY DISCLAIM ALL WARRANTIES AND CONDITIONS WITH REGARD TO THIS INFORMATION AND RELATED GRAPHICS, INCLUDING ALL IMPLIED WARRANTIES AND CONDITIONS OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, WORKMANLIKE EFFORT, TITLE AND NON-INFRINGEMENT. YOU SPECIFICALLY AGREE THAT IN NO EVENT SHALL MICROSOFT AND/OR ITS SUPPLIERS BE LIABLE FOR ANY DIRECT, INDIRECT, PUNITIVE, INCIDENTAL, SPECIAL, CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF USE, DATA OR PROFITS, ARISING OUT OF OR IN ANY WAY CONNECTED WITH THE USE OF OR INABILITY TO USE THE INFORMATION AND RELATED GRAPHICS CONTAINED HEREIN, WHETHER BASED ON CONTRACT, TORT, NEGLIGENCE, STRICT LIABILITY OR OTHERWISE, EVEN IF MICROSOFT OR ANY OF ITS SUPPLIERS HAS BEEN ADVISED OF THE POSSIBILITY OF DAMAGES.
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.
Determine free space available within a Microsoft Exchange database Tasks controlled by the IS Maintenance Schedule Tasks not controlled by the IS Maintenance Schedule If your required backup and maintenance windows are too large for the time you have available for maintenance tasks you can increase the throughput of your backup by following "System performance is negatively affected when Ntbackup.exe writes to a destination .bkf file"