wthrottle
asked on
Cannot move Exchange 2007 database to a new drive
Hello, The disk on our Exchange server 2007 has only 200MB free. I have moved everything possible from the drive to maximze space. When I move the Exchange database to a share on another server (Win 2008 R2) the database moves; however, it will not mount. I am in a crunch because if the drive reaches capacity the database will dismount. Any help is greatly appreciated. The error I receive is pasted below:
Mailbox Database
Completed
Warning:
The task completed successfully, but the database "DC1\First Storage Group\Mailbox Database" cannot be restored. The exception message is "MapiExceptionJetErrorData
".
Exchange Management Shell command completed:
move-DatabasePath -Identity 'DC1\First Storage Group\Mailbox Database' -EdbFilePath 'Z:\Mailbox\FirstStorageGr
Elapsed Time: 00:18:09
Mailbox Database
Completed
Warning:
The task completed successfully, but the database "DC1\First Storage Group\Mailbox Database" cannot be restored. The exception message is "MapiExceptionJetErrorData
".
Exchange Management Shell command completed:
move-DatabasePath -Identity 'DC1\First Storage Group\Mailbox Database' -EdbFilePath 'Z:\Mailbox\FirstStorageGr
Elapsed Time: 00:18:09
> When I move the Exchange database to a share on another server (Win 2008 R2) the database moves; however, it will not mount.
The database needs to be on disk/volume attached to the server. It cannot be on a network drive.
The database needs to be on disk/volume attached to the server. It cannot be on a network drive.
ASKER
Thanks for the quick reply. I do not have an extra drive bay in this server to add another drive. What external drive solution would be recommended (if any) as a temporary fix? Over the weekend my plan was to use shadow protect to migrate to a new drive; however, I am afraid this database will grow and fill the disk as soon as today.
The database needs to be attached to the server. They do not work on a shared drive. You can do this if you have a san however where the server will think it is physically attached when technically it is not.
Check the database is in clean shutdown by running eseutil /mh
IF it is in clean shutdown then move all the logs and mount the database.
However is is not recommended to keep the database in shared location.
IF it is in clean shutdown then move all the logs and mount the database.
However is is not recommended to keep the database in shared location.
I mounted a database on a USB attached disk once! ran like crap but it worked.
An alternative would be iSCSI to a NAS.
If you really have no other options try making more space by
- deletting hotfix uninstallers
- deleting iis Log files
- use TreeSize Free to locate any other large folders and clean out old data
- apply folder compression to some other folders
- enable ciruclar logging on the exchange databases/infostore
- hope you don't recieve too much email before you can shadowprotect to a new drive.
An alternative would be iSCSI to a NAS.
If you really have no other options try making more space by
- deletting hotfix uninstallers
- deleting iis Log files
- use TreeSize Free to locate any other large folders and clean out old data
- apply folder compression to some other folders
- enable ciruclar logging on the exchange databases/infostore
- hope you don't recieve too much email before you can shadowprotect to a new drive.
ASKER
R-R, The log files are located on the C: partitiion, and the database is on D: partition. What would be the best practice for moving the log files and database to accomplish this? From the other comments above I understand that this is not a good practice, but I just need something to get me through until the weekend when I can install a larger drive. Thanks!
for a temporary fix,
If you have another mailbox database, you can move few mailboxes to different database
If the log files are on the same drive where database available, you can enable circular logging for sometime
you can find big size mailboxes and archive them as pst, those regained space will be automatically used by exchange. once you attach the drive and move the database to new drive then you can move the archive pst file to mailbox
If you have another mailbox database, you can move few mailboxes to different database
If the log files are on the same drive where database available, you can enable circular logging for sometime
you can find big size mailboxes and archive them as pst, those regained space will be automatically used by exchange. once you attach the drive and move the database to new drive then you can move the archive pst file to mailbox
ASKER
aoakley, I actually considered the USB route to get me through the day! ;-) I ran treesize and removed/moved everything possible.
Would attaching a USB drive work? I know that sounds hokey, but the drive is so low on space that I am desparate.
The drive configuration in this Dell 1950 has two bays and both drive bays are occupied with in a RAID1 (mirror). I had also wondered if pulling the second drive and adding a new drive as a hot spare would work. This would disable the mirror; however, this would be temporary until the weekend when I could replace both drives with larger ones. Would this work?
Would attaching a USB drive work? I know that sounds hokey, but the drive is so low on space that I am desparate.
The drive configuration in this Dell 1950 has two bays and both drive bays are occupied with in a RAID1 (mirror). I had also wondered if pulling the second drive and adding a new drive as a hot spare would work. This would disable the mirror; however, this would be temporary until the weekend when I could replace both drives with larger ones. Would this work?
The best practice would be multiple drives.
One for logs and the other for database.
You said you already move the database to shared drive...thats the reason i recommended to check the database consistency and mount the database.
One for logs and the other for database.
You said you already move the database to shared drive...thats the reason i recommended to check the database consistency and mount the database.
Would attaching a USB drive work? - yes but will be slow as hell. depends on the number of users and if they are using cached mode in outlook or not.
>adding a new drive as a hot spare
You would not add the drive as a hot spare, but rather a a new single disk array with logical drive. never a good idea to reduce your redundancy thought, you could end up even worse off :)
What about just opening the case and plugging a HDD durectly into a SATA cable and power? remove the CDROM drive for example? This would be a better way of adding capacity.
edit: spelling
>adding a new drive as a hot spare
You would not add the drive as a hot spare, but rather a a new single disk array with logical drive. never a good idea to reduce your redundancy thought, you could end up even worse off :)
What about just opening the case and plugging a HDD durectly into a SATA cable and power? remove the CDROM drive for example? This would be a better way of adding capacity.
edit: spelling
You can't pull a disk from the RAID and attach a bigger one as it will only use the size of the smaller disk. Everyone else is correct about not being able to mount the Db on a "network drive". Any drive containing a Db must direct attached using iSCSI, or a SCSI HBA card, or USB even. If you can afford some down time, you can save the Db's to a different location. Replace the HD's, reinstall Exchange with /m:recoverserver to pull in all the configs from AD. Then mount the Db's again.
ASKER
Rajkumar-MCITP, Moving some mailboxes may be a good option. If I move some mailboxes to the C: partition (10GB free) this would give me some breathing room until I have the time over the weeeknd to do it all correctly. Question: If I move the mailboxes will the space actually be released on the D: drive (Exchchange database location)? Or do I have to run offline maintenance to free the space?
ASKER
aoakley, Plugging a drive in internally could be an option. The server is a 1U rack mount with hot plug drives so I need to open the cover on it and see if it has a cable and power to connect a spare drive to. Will check on this...
The only way to shrink the Db would be to perform an offline defrag.
ASKER
Thanks for the answer on that D_Hebs. I thought an offline defrag would be required to shrunk it. Unfortunately i do not have the required free space to defrag it.
ASKER
D_Hebs, related to your feedback "You can't pull a disk from the RAID and attach a bigger one as it will only use the size of the smaller disk".
My intention was not to replace the mirror with a larger drive, but to add the replacement drive as a single drive that is not part of the array. And then use this single drive to move the exchange database to. Do you think this approach would work?
Thanks for the feedback.
My intention was not to replace the mirror with a larger drive, but to add the replacement drive as a single drive that is not part of the array. And then use this single drive to move the exchange database to. Do you think this approach would work?
Thanks for the feedback.
I do not believe that would work. Your best bet would be to ghost/image the RAID1, destroy the RAID1 create 2 RAID0's and then put the image back on the first RAID0 and then move the Db to the second disk.
fyi - I personally would never do this in a live environment as whatever is lost when 1 of those disks fail is only recoverable via backups... (1950's are just not good canidates for Exchange servers.)
fyi - I personally would never do this in a live environment as whatever is lost when 1 of those disks fail is only recoverable via backups... (1950's are just not good canidates for Exchange servers.)
My intention was not to replace the mirror with a larger drive, but to add the replacement drive as a single drive that is not part of the array. And then use this single drive to move the exchange database to. Do you think this approach would work?
It would work. But Like many have said, risky. You are left without redundnacy.
You *could* also do this. But if a rebuild fails you are in the poo... but you have shadow protect so you could take a chance on it.
- pull out
- install newer bigger disk
- array would re-sync
- pull out first disk
- replace with bigger disk (now you have logical drive on array with free space)
- expand logical drive
It would work. But Like many have said, risky. You are left without redundnacy.
You *could* also do this. But if a rebuild fails you are in the poo... but you have shadow protect so you could take a chance on it.
- pull out
- install newer bigger disk
- array would re-sync
- pull out first disk
- replace with bigger disk (now you have logical drive on array with free space)
- expand logical drive
ASKER
I was exploring another approach. Resizing the partitions using gparting. Have any of you used this utiltiy to resize a Windows Server 2003 Rx (x64) partition?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Based on feedback from experts the other options presented were far to risky. Purchasing new drives eliminated any risk as I would have the option of inserting the old drives if the process failed with the new drives.
I don't think it will mount. attach a disk which will be local to the current server and move the mailbox database