Before moving mailboxes I checked the drive where the Exchange directory is located and saw it was around 104GB space left After moving several mailboxes to another storage group the amount of free space dropped to about 84GB. Of course there are a lot of transaction logs that would have accounted for that. After a night of a full backup, the figure increased only to 93GB. Did I lose space somewhere because of all the moves I did? Why has my free space suddenly gotten smaller after moving mailboxes?

On Thu, 30 Aug 2012 13:06:04 +0000, BartonUrp wrote: > > >Before moving mailboxes I checked the drive where the Exchange directory is located and saw it was around 104GB space left > >After moving several mailboxes to another storage group the amount of free space dropped to about 84GB. Of course there are a lot of transaction logs that would have accounted for that. After a night of a full backup, the figure increased only to 93GB. Did I lose space somewhere because of all the moves I did? Why has my free space suddenly gotten smaller after moving mailboxes? Well, what got bigger??? Did the database grow? It should have. Is it on the same disk as the log files? Were the log files truncated by the backup? --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

yes the logs are truncated by the backup The logs are also on the same disk/partition as the database itself

On Fri, 31 Aug 2012 14:56:18 +0000, BartonUrp wrote: >yes the logs are truncated by the backup > >The logs are also on the same disk/partition as the database itself So the question remains: what grew larger? --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

On Tue, 4 Sep 2012 19:09:28 +0000, BartonUrp wrote: >I would say it looks like the databases (MDBDATA files) grew larger. That's not surprising since you're adding records to the database. >Originally there was one large storage group. I created 4 more new ones to try and evenly distribute the users. My intention was to even them out and conduct offline defragmentation without affecting everyone. An off-line defrag will surely affect every user in the database being defragged! >However I noticed with each move, the overall size where the Exchange directory sits gets smaller and smaller. If all of your storage groups are on a single disk you have a poor design. Each storage group should be on a separate (set of) disks, and the log files should be on another set of disks. This design paradigm has changed a lot from 2003 to 2007 to 2010. >I noticed there are tons of transaction logs every time I move Of course! You're modifying the target database (and the source database) so the changes are going to be reflected in the transaction logs of both storage groups (but to a much greater extent in the target storage group). >but it also looks like the datastores are getting bigger and taking up more space. Sure. You're adding data to database; it has to grow to accompodate those additions. >Like I said I originally had over 100GB and now I'm down to 84GB after moving a bunch of accounts. > >Do you occupy MORE space when you move mailboxes into new datastores? You certainly increase the size of the target database when you add data to it and there's insufficient whitespace to accompdate the new data. >How can I find out the free space in a storage group? An approximation of the whitespace in a database can be found in the 1221 EventID in the Application eent log. >And how can I reclaim it or shrink the storage group? A storage group consists of the databases and log files. Log files that contain transaction the have been committed to the associated database will be truncated by a full ("normal") backup of every database in the storage group. Whitespace within a database can only be reclaimed by an off-line defrag (i.e. dismounting the database and running eseutil, followed immediately by a full backup of the storage group). If you've moved all of the mailboxes from a database to another database(s) you can remove the databases from the organization and then delete the database from the file system. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

That clarifies alot. What I meant was by splitting users into each of the 4 storage groups, I can offline defrag the database files from each storage group without affecting the users in the other storage groups. That's what I meant. I'm unable to check on how much space is left in the event log. Seems it was pushed away and overwritten already. Is there another way to check the amount of space left for a particular storage group's database? So are you saying a better design would be something like a 10 disk array with a storage group on their own separate disk? The transaction logs as well? Can you recommend which switches or ordering of switches for eseutil I should use when running an offline defrag?

On Tue, 4 Sep 2012 21:41:06 +0000, BartonUrp wrote: > > >That clarifies alot. > >What I meant was by splitting users into each of the 4 storage groups, I can offline defrag the database files from each storage group without affecting the users in the other storage groups. That's what I meant. > >I'm unable to check on how much space is left in the event log. Seems it was pushed away and overwritten already. Is there another way to check the amount of space left for a particular storage group's database? Sounds like you might be logging too much -- or your application log is too small. Those 1221 events should be happening once a day for each database. >So are you saying a better design would be something like a 10 disk array with a storage group on their own separate disk? The transaction logs as well? Your first consideration for storage design is making sure that whatever layout you choose is able to accommodate the I/O load generated by your users. At a minimum you'd be looking at RAID1 for each database (and maybe RAID10). Log files go on RAID1, and you may want to separate each set of log files on its own RAID1. I really wouldn't recommend using Exchange 2003 anymore, though. Besides being an end-of-life product the I/O demands are much higher than Exchange 2010, or even 2007) >Can you recommend which switches or ordering of switches for eseutil I should use when running an offline defrag? The only one you need is "-d". --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

Well I'm trying to ramp up the Exchange now and move up to at least 2010 Enterprise Is there any easy way of migrating from 2003 to 2010 Exchange? What about the /k and /p switches for running a checksum and repair of priv1.edb? Are those necessary? I was thinking about dismounting and then copying the priv1.edb and priv1.stm files to another disk, then running the defrag operation on it, then copying it back. Just in case something happens I can at least revert to a good copy.

On Wed, 5 Sep 2012 04:29:21 +0000, BartonUrp wrote: > > >Well I'm trying to ramp up the Exchange now and move up to at least 2010 Enterprise > >Is there any easy way of migrating from 2003 to 2010 Exchange? I'm pretty sure you'll find that information in the 2010 deployment guide: http://technet.microsoft.com/en-us/exdeploy2010/default.aspx#Index >What about the /k and /p switches for running a checksum and repair of priv1.edb? Are those necessary? Do *NOT* user the /p switch unless you know _why_ you'd have to use it. Before using that switch consider restoring a good backup of the database. A repaired database is almost always a damaged database and the repair option may (and often does) repair the damage by removing database pages that may contain real data. You may get a mountable database, but it may be an empty one! If you're regularly making normal ("full") backups of the database and you're not seeing any -1018 errors in the logs (or any others during normal operation that point out checksum failures) then spending the time to run eseutil with the /k switch is usually not worth it. >I was thinking about dismounting and then copying the priv1.edb and priv1.stm files to another disk, then running the defrag operation on it, then copying it back. Just in case something happens I can at least revert to a good copy. That's what backups are for. :-) If you honestly feel you have to do that you can use the /p option together with the /d switch to leave the defragged file "in place". If you lack dik space you can add the /t option to use another disk. http://technet.microsoft.com/en-us/library/aa998863(v=exchg.80).aspx --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

Ricky, I am planning on conducting a dry run tonight to see how long it would take to make a copy of the EDB and STM files and defrag them. Would you happen to know or estimate how long it would take to copy 100GB over to another drive on the same server for testing? Would conventional copy be good enough or should I try using the eseutil /Y copy mode instead?

On Thu, 13 Sep 2012 14:32:44 +0000, BartonUrp wrote: >I am planning on conducting a dry run tonight to see how long it would take to make a copy of the EDB and STM files and defrag them. > >Would you happen to know or estimate how long it would take to copy 100GB over to another drive on the same server for testing? That depends on your hardware. >Would conventional copy be good enough or should I try using the eseutil /Y copy mode instead? The "copy" works more slowly because it copies a sector at a time. Eseutil will usually work faster because it copies using bigger chunks of the file. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

On Tue, 18 Sep 2012 13:54:15 +0000, BartonUrp wrote: >Someone mentioned the other option of just moving everything into a new mailbox store. I already have the maximum of 4 right now running on Enterprise edition. The Enterprise version of Exchange isn't limited to four databases. Four storage groups, but each of those can have up to five databases. >What's the proper way to go about this? Should I dump everything into one or two mailbox stores? That depends on your backup and restore goals. It takes a lot longer to restore a big monolithic database than it does to get smaller databases back onto disk (meaning not all of your users will be offline for the entire time it takes to restore). >- Which mailboxes should I move? Should I move everything I see in there? No, not everything. See the links below. >I see something called "SMTP (EXCHANGE-{86A....}" and "SystemMailbox{86A6....}" in the list of mailboxes. What are these? Should they be moved as well? I also see "System Attendant". You don't have to move any of those. The system attendant mailbox will be recreated after you nuke the database that holds the mailbox. http://support.microsoft.com/kb/821829 http://blogs.technet.com/b/evand/archive/2004/12/21/329172.aspx >- Assuming I moved everything into the new store, when is an appropriate time to delete the old store? Are the changes effective immediately? Do I wait a day? Or can I do it immediately? Will my overall drive space regain after deleting the store? Do it when your ready. The database will be empty of active mailboxes so it's serving no useful purpose. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

On Wed, 19 Sep 2012 06:21:17 +0000, BartonUrp wrote: >I see some instructions where you have to manually use ADSIEdit to change the HomeMDB for System Attendant? Is this required? Or is it supposed to be automatically created in the next mailbox store after restarting the System Attendant service? I am using Exchange 2003 Enterprise not 2007 The SA mailbox will be recreated when you remove its mailbox database. >There is currently some active Active Directory issues, mostly with promoting a DC so I'm a little worried about what if the System Attendant doesn't get recreated. If you're worried about the AD stability I wouldn't mess around with doing much else until that problem's fixed. >What if I were to move all user mailboxes away and leave just the system attendant, system mailbox and SMTP mailbox? Then defrag that? Essentially it's just an empty First Storage Group no? Yes. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP