Hello All,I'm preparing to change my organization's physical server infrastructure used for Exchange.I'm going to install Exchange in a SCC configuration with a SAN using Exchange 2007 and move the database or mailboxes to the new cluster.Our current Exchange 2007 database is almost 300GB in size. Keeping in mind that Microsoft recommends a maximum of 100GB per mailbox database, we want to shrink the database size. We were thinking of performing an offline defrag or simply moving the mailboxes to the new server, the move should create a database that doesn't need to be defragmented anymore and thus we would save time and hard drive space.My questions are: 1. What is the best way to shrink such a large database (300GB) in our situation (infrastructure change) ?2. What is the best aproach for long term database maintenance without having to take the mail service offline? (How do we keep the database(s) from gaining serious proportions without downtime?)3. Do you recommend that we split the database in several smaller ones? (that would make sense to me)Event ID 1221 says :"The database "First Storage Group\Mailbox Database" has 2281 megabytes of free space after online defragmentation has terminated. " So it seems like there isn't much white space in the .edb file compared to the it's size (300GB)..Thanks,Cosmin

Hi Cosmin,1. To reduce the database in to small with out affecting the production, move the mailboxes to the new databases2. To keep the databases under control for log term maintanence, Have the Mailbox Records Management (MRM) with some retension policy3. It is always recommended to split the databases in to many so that the databases can be managed betterThe size you see in Explorer is not the exeact one. you need to check the 1221 and show how much data is there in the databases. rest is white spaces which can be reclaimed by running offline defrag

Hi,Thank you for you reply I forgot to mark the question as answered.I have migrated by moving the mailboxes and I split the database in several smaller ones which are easier to manage.I will look into configuring MRM with a retention policy.Cosmin