Not really a tool for that...NetIQ and Quest's migration tools are going to cost a lot, and aren't really meant for this type of move (and might not even work).
You're probably stuck with lots of manual effort. --James On Tue, Jul 29, 2008 at 2:25 PM, Karsten, Matthew <[EMAIL PROTECTED]> wrote: > I could alternate incrementals in there if I needed to, they prefer > fulls but... > > Is there a Tool that would make this move easier on me in terms of time, > free would be nice, but not required. > > The math - yeah, that makes sense. I should've thought about that. > > Matt > > > -----Original Message----- > From: James Wells [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 29, 2008 3:12 PM > To: MS-Exchange Admin Issues > Subject: Re: Moving Mailboxes > > That's certainly a problem. Unless your SLA lets you alternate > incremental and full backups (ie. do moves one night, then incremental > backup -- full backup with no moview the next night, etc). > > For moving large mailboxes - halting full backups during the move > operation is pretty much a requirement... > > > For the math on how much 1012 logs will be...if you move mailboxes at > a low-usage hour...then nearly all of the translog activity will be > from your moves, and 1012 logs x 5MB ~ 5GB of move data. > > > --James > > On Tue, Jul 29, 2008 at 2:07 PM, Karsten, Matthew > <[EMAIL PROTECTED]> wrote: >> I never knew how much data the 1012 uncommited transactions logs could >> hold. If its around 5GB, that's not going to be fun for me, around 40 >> of my users have over 1GB mailboxes. Then another 120 or so have over >> 500MB mailboxes. >> >> I could make sure backups run right after a move, the problem is, a > full >> backup isn't exactly quick. So when I get to these really large >> mailboxes, I am going to have to do them in very small groups? I was >> hoping to avoid extending this out as long as that would take, if I >> can't, I will deal with that though. >> >> Matt >> >> >> -----Original Message----- >> From: James Wells [mailto:[EMAIL PROTECTED] >> Sent: Tuesday, July 29, 2008 2:57 PM >> To: MS-Exchange Admin Issues >> Subject: Re: Moving Mailboxes >> >> Then it's not space that's a problem...you really need to watch how >> many mailboxes you move during an ESE backup operation. You can only >> create 1012-ish "uncommitted" transaction logs before the storage >> group is taken offline as a precaution. That works out to ~5GB of >> mailbox data. >> >> Can you halt backups when you do the moves, then immediately take a > full >> backup? >> >> --James >> >> >> On Tue, Jul 29, 2008 at 1:54 PM, Karsten, Matthew >> <[EMAIL PROTECTED]> wrote: >>> That would be the one. >>> >>> Matt >>> >>> >>> -----Original Message----- >>> From: James Wells [mailto:[EMAIL PROTECTED] >>> Sent: Tuesday, July 29, 2008 2:48 PM >>> To: MS-Exchange Admin Issues >>> Subject: Re: Moving Mailboxes >>> >>> Is this the problem you're having? >>> >>> http://support.microsoft.com/kb/905801 >>> >>> >>> >>> --James >>> >>> On Tue, Jul 29, 2008 at 1:43 PM, Karsten, Matthew >>> <[EMAIL PROTECTED]> wrote: >>>> I think I got plenty of space for the logs on the server (currently >>> 80GB >>>> free out of 120GB total on that particular drive). I just verified >>> that the >>>> log files are being written to the drive I thought they were. >>>> >>>> >>>> >>>> The processor is barely being used on the box so compression > wouldn't >>> be >>>> bad. >>>> >>>> >>>> >>>> Matt >>>> >>>> >>>> >>>> From: Campbell, Rob [mailto:[EMAIL PROTECTED] >>>> Sent: Tuesday, July 29, 2008 2:06 PM >>>> >>>> To: MS-Exchange Admin Issues >>>> Subject: RE: Moving Mailboxes >>>> >>>> >>>> >>>> IMHO - the answer to that depends on your backup and SLA for >>>> recoverability. >>>> >>>> >>>> >>>> Moving large mailboxes creates a lot of transaction logs. >>>> >>>> >>>> >>>> You might want to consider increasing the amount of space you have >>> allocated >>>> for the transaction logs temporarily while you're doing the mailbox >>> moves, >>>> then cut it back when you're finished. >>>> >>>> >>>> >>>> Transaction logs also compress pretty well, so you might consider >>> enabling >>>> compression on the transaction log directories if you can afford the >>>> processor load without it hurting your performance too much. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> ________________________________ >>>> >>>> From: Karsten, Matthew [mailto:[EMAIL PROTECTED] >>>> Sent: Tuesday, July 29, 2008 12:59 PM >>>> To: MS-Exchange Admin Issues >>>> Subject: Moving Mailboxes >>>> >>>> >>>> >>>> Exchange Server 2003 SP2. >>>> >>>> >>>> >>>> We have always had all of our users (around 1200) in one large > store. >>> This >>>> single store had grown to be around 400GB. >>>> >>>> >>>> >>>> A while ago we decided to start moving all of our users out of this >>> store >>>> and into several different stores organized based on desired >>> configuration. >>>> We then began moving mailboxes out of the large store in groups > into >>> the >>>> other stores. This has been going fine for our smaller users. We >> now >>> have >>>> hit a point where we are at our users that have larger mailboxes >>> (200mb - >>>> 2gb). As I am moving them in groups, the stores keep dismounting. >>> Looking >>>> at the event logs it appears that they are dismounting because the >>> logs are >>>> filling up. >>>> >>>> >>>> >>>> I did more looking and it appears that the easiest way to fix this > is >>> to >>>> enable circular logging. Reading more on circular logging, there >> seem >>> to be >>>> mixed opinions on whether it should be enabled or not. >>>> >>>> >>>> >>>> So I guess I have 2 questions. >>>> >>>> 1. Is circular logging the way to go to deal with this? >>>> >>>> 2. If so, is there anything I need to watch out for? >>>> >>>> >>>> >>>> I had been planning just to enable it to finish the mailbox moves > and >>> then >>>> just turn it off. >>>> >>>> >>>> >>>> Matt Karsten >>>> >>>> >>>> >>>> >>>> >>>> >>> >> > ************************************************************************ >>> ************************** >>>> >>>> Note: >>>> >>>> The information contained in this message may be privileged and >>> confidential >>>> and >>>> >>>> protected from disclosure. If the reader of this message is not the >>>> intended >>>> >>>> recipient, or an employee or agent responsible for delivering this >>> message >>>> to >>>> >>>> the intended recipient, you are hereby notified that any >>> dissemination, >>>> >>>> distribution or copying of this communication is strictly > prohibited. >>> If >>>> you >>>> >>>> have received this communication in error, please notify us >>> immediately by >>>> >>>> replying to the message and deleting it from your computer. >>>> >>>> >>> >> > ************************************************************************ >>> ************************** >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> ~ Ninja Email Security with Cloudmark Spam Engine Gets Image Spam ~ >>> ~ http://www.sunbeltsoftware.com/Ninja ~ >>> >>> >>> >>> >>> ~ Ninja Email Security with Cloudmark Spam Engine Gets Image Spam ~ >>> ~ http://www.sunbeltsoftware.com/Ninja ~ >>> >> >> ~ Ninja Email Security with Cloudmark Spam Engine Gets Image Spam ~ >> ~ http://www.sunbeltsoftware.com/Ninja ~ >> >> >> >> >> ~ Ninja Email Security with Cloudmark Spam Engine Gets Image Spam ~ >> ~ http://www.sunbeltsoftware.com/Ninja ~ >> > > ~ Ninja Email Security with Cloudmark Spam Engine Gets Image Spam ~ > ~ http://www.sunbeltsoftware.com/Ninja ~ > > > > > ~ Ninja Email Security with Cloudmark Spam Engine Gets Image Spam ~ > ~ http://www.sunbeltsoftware.com/Ninja ~ > ~ Ninja Email Security with Cloudmark Spam Engine Gets Image Spam ~ ~ http://www.sunbeltsoftware.com/Ninja ~
