Now that would make sense, I think, up to the point where he said that making a change to the mailbox properties caused a dismount/move/remount. Changing the setting on the storage group would move the logs, which should be a quick process.
But where did the change to the mailbox properties come into play – or was it a case of he changed the store location and called it the mailbox?
Is it possible that you went into the properties of the storage GROUP the first time and changed a location there? Then when you went into the Mailbox Store and changed it, it moved for you? I can see a simple explanation for this, at the storage group level you only changed where the log files go, at the mailbox store level is where you actually set the database locations.
Just a thought,
Regional Health Inc.
I did finally get it to work, and made an interesting discovery which left me scratching my head a little.
I had gone into the properties of the STORE (not the Mailbox) and changed the location. As I stated, that went by too fast and claimed to have completed successfully but nothing actually was moved.
So I poked around and poked around, and then I noticed that the properties on the MAILBOX itself (not the store) were still displaying the old locations (!). So, I changed these manually. Sure enough, this did start the automatic mailbox migration I had been expecting, and it took about 40 minutes to move 7GB but all went well, and at the end of this process the EDB and STM files magically appeared in the new location and disappeared from the old location. Everything checked out OK and was running normally.
So what has me still scratchibng my head is: why is it necessary to move the Store *AND* the Mailbox individually? Indeed, what does it mean exactly, to have the Store in one location but the Mailbox in another? If the system allows for these two entities to be specified independently, this implies that it is meaningful to have the "Store" on, say, drive P and the "mailboxes" on some pther drive, say "Q". If so, what would there be on drive P? Not the transaction logs nor the SMTP logs, because those are specified independently too. So what is the point of specifying the location for the store locations independently of the mailbox locations?
If anyone has come across a situation where this level of separation is meaningful, I would love to hear it, just so I might learn something.
On 10/9/06, Rick Boza <rickb@xxxxxxxxxxxxxxx> wrote:
Actually it should do the move automatically – you have some other problem going on there.
I don't think ESM moves them for you. Every time I've moved a store I dismounted them, manually moved the files, and remounted using the new locations.
From: exchangelist-bounce@xxxxxxxxxxxxx [mailto:exchangelist-bounce@xxxxxxxxxxxxx] On Behalf Of Jabber Wock
Sent: Saturday, October 07, 2006 7:58 AM
Subject: [ExchangeList] relocating storage location
On a Exchange 2003 server, I am trying to move one Storage Area from one drive to another. So I went into the ESM, properties of the Storage Area, and changed the location from the old drive to the new drive (having created the necessary empty folder tree on the new drive where I wanted the storage storage database files to be moved to. The DB files are about 4G and 2G in size (EDB and STM).
As expected, I got a message that the database will be dismounted, is it OK? I said OK. The database got dismounted in a few seconds, then got remounted a few seconds later, with a "success" message. So far so good. In fact, too good, since I expected a 7GB move to take more that 2-3 seconds!
Sure enough, on checking, the DB files are still in the old location. The new drive is not showing any EDB or STM files but there is a tiny tmp.edb file there. However the ESM is showing all the mailboxes, and as far as I can tell, all users are also able to see all their mailboxes as before, no issues.
So when do the database files get physically moved? or did I jave to physically move them myself??!!
TIA and Best regards
***Note: The information contained in this message, including any attachments, may be privileged, 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 the Sender immediately by a "reply to sender only" message and destroy all electronic or paper copies of the communication, including any attachments.