Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 745
  • Last Modified:

Need to point our M: (my virtual Exchange drive) to different physical Drive

For reasons I won't bother to expound on (other than the fact that I'm fixing a tech company's poor design decisions), we are running out of room on our Exchange (M:) drive. Our M: drive actually points to our physical C: drive. This is also my system drive, so things are not looking very bright at the moment. We have less than 300 megabytes left, so I need to do something soon. We have another drive that will house our Exchange store nicely. It has over 30 gigs of free space, and will probably stay fairly free for a while.

I know I am touching a dangerous thing when I start messing with Exchange's virtual drive, so my questions are as follows:

#1: What is the best way to point the virtual drive to a different drive (such as my E drive which has 30 gigs of free space)? If pointing it to a different drive isn't the answer to my space problem, then what is? I can't just tell people to delete their old e-mail. Much of that old e-mail is used for important business.

#2: Once I have made the change I am assuming people's folders (such as their "Deleted Items") will be empty since the drive will be pointing to a different physical drive. In order for them to access their old stuff do I need to physically copy and paste the contents of our Exchange store to the new drive?

I know I am playing with fire, but we NEED to do SOMETHING! I guess to summarize, we are running out of space for our Exchange mailbox store. I have other drives with plenty of space. How do I fix this problem with the least amount of impact on my users (not to mention my server!)?
0
mckeough
Asked:
mckeough
  • 5
  • 5
  • 4
  • +3
2 Solutions
 
xxgeniusCommented:
the M drive points the drive that Exchange is installed on.  you do not want to mess with the M drive nor where it points. if you want to move the databases which hold exchange mailboxes then follow the instructions on this link: http://www.msexchange.org/tutorials/MF001.html

This will move your database to the 30 gig drive. it will migrate everything including what's in the deleted items.  the databases will be "offline" and not available until the move finishes.  therefore your users will not have access until this completes.
0
 
bwinzenzCommented:
As already stated by xxgenius, the M drive will always point at the drive where Exchange is installed on.  It's just a Virtual drive, so it can be ignored.  In fact, what you might want to consider doing is hiding the M drive.  Instructions on how to do that can be found here.
http://support.microsoft.com/default.aspx?scid=kb%3Ben-us%3B305145

In addition to moving the databases, you should also look in the c:\program files\exchsrvr\mdbdata directory and see if you have a ton of e00x.log files.  These are the transaction log files for Exchange.  If you have not performed a full backup lately, this could be part of the reason that you are running out of space.  Moving the databases is a great suggestion, but you also need to ensure that you are either backing up your server on a regular basis (to purge the committed log files), or you turn on circular logging (not recommended).

Ben
0
 
Debsyl99Commented:
Hi

Just in case you need any further persuading, both xxgenius and bwinzenz are spot on correct in the resolution to your problem. But you do need to do something now, your exchange server will fall over very shortly if that's the only space you have left on the C: drive,

Deb :))

/******** Do not accept this as an answer*************/
0
NEW Veeam Backup for Microsoft Office 365 1.5

With Office 365, it’s your data and your responsibility to protect it. NEW Veeam Backup for Microsoft Office 365 eliminates the risk of losing access to your Office 365 data.

 
ikm7176Commented:
"Our M: drive actually points to our physical C: drive." - your assumption is wrong

http://blogs.msdn.com/exchange/archive/2004/02/09/70067.aspx

Dont touch your M: drive, its not the phyisical drive, it is the virtual drive.

You can change the Drive letter of M: though not recommended
http://www.msexchange.org/tutorials/Neat_Exchange_2000_Server_Tricks__Yes_you_really_can_have_it_your_way.html
0
 
jaguarpriestCommented:
Keep it simple. If the Exchange database is on the C: use the Exchange System Manager and move the database location paths to the other drive. Like some of the others said don't bother with trying to work with a drive that doesn't exist. The M: is a virtual representation only. Go to ESM, Navigate to your database stores. Right click properties and select database tab. Then click on Browse and find another location. When you click ok it will ask if you want to dismount the stores at this time. Click yes. They will dismount, copy, then mount again. It will then remove the old copy. This is to say that if something happens in the move, don't panic. I've worked on this and have moved 130GB Databases to Different SAN locations. It takes a while depending on the location so during production (working hours) would be a bad idea?

Secondly. What is the bulk of data taking up your space? is it transaction logs? i've got some ideas for you if they are.

Jaguar
0
 
mckeoughAuthor Commented:
Thanks guys. I really don't want to "move" or rename the M drive or anything. I just needed somewhere for its data to go. I will probably do the move this week. Does anyone know about how long it will take to move a 2 gig database?

Oh, this means if I wanted to put this on a shared network drive (a drive that isn't resident on the Exchange server) I could, right? This last question was asked purely out of curiosity.

Jaguar, if you share your ideas about log files I'll give you 150 points because I'll use the information on this server and another server we had run low a few months ago.

ikm7176, What is the point of your post? I know the M drive is virtual. Did you read the title of my post?

xxgenius and bwinzenz - Thanks for your posts they will help a lot!
0
 
xxgeniusCommented:
Oh, this means if I wanted to put this on a shared network drive (a drive that isn't resident on the Exchange server) I could, right?
------nooooooooo. it must be a local drive either Harddisk, scsi, or SAN.

to reduce transaction logs do full backups.  a full backup will commit trans logs and delete them automatically.  use an exchange aware backup software.  you should backup your exchange nightly.
0
 
mckeoughAuthor Commented:
OK. Good to know. I'm not certified in Exchange, but I have taken over Exchange administration. I know enough to know when to go ask you experts.  

On the subject of backups - I have Backup Exec scheduled to do full backups of Exchange every night. We do a full server backup every Friday night. Monday through Thursday are differential backups except for Exchange which is a full backup included on our differential.
0
 
xxgeniusCommented:
on the backups, that's good you should be ok with your log file growth once you move the databases and logs to the new 30 gig.

advice:
1. put limits on everones mailboxes to keep database growth from getting out of control
2. create a folder for the DBs and another for the logs

you seem to have a small shop there so this will be fine.  of course, if you had more users and bigger stores you would need to redesign your server for better performance. but at least you look ok until you can learn more.  exchange is complicated but very rewarding $$$$$
0
 
Debsyl99Commented:
Hi

Not trying to cut across you guys, but when you backup exchange - do you make sure that you back up the information store specifically? (not the M drive or anything) Forgive me if it's a stupid question but I have learned that it never hurts to ask stupid questions (as sometimes you just miss the obvious)

Deb :))

0
 
xxgeniusCommented:
>>Not trying to cut across you guys, but when you backup exchange - do you make sure that you back up the information store specifically?

an exchange aware product will backup the DBs/logs on a DB level.  
you should never backup the M drive or the DBs/logs on a file level. most exchange aware apps will not allow this but if they do this could cause corruption.
0
 
mckeoughAuthor Commented:
Don't worry about cutting across us... No. We don't backup the M drive, only the database and logs. The M drive isn't touched by anything but Exchange. All of this is why I asked. I know the M drive is EXTREMELY touchy, and I wanted to make sure I did this thing right. In fact, about two weeks ago we had a virus that crippled Symantec on our Exchange server, and it corruped security settings for Exchange. I caught the virus without it doing any real damage to the system, but the virus had corrupted Symantec in such a way that it was trying to do the job of Symantec Mail Security, which is separate from Antivirus. Every now and then this stopped the flow of e-mail because it was trying to scan Symantec's special folder for Exchange.

Anyway, thanks for being concerned about our backups. I appreciate that. Thanks again for the guidance on what to do. As you can see, I've learned enough about Exchange that I know messing with it is NOT fun, and if you don't do it right you can cause yourself more trouble than you were ever in before.
0
 
Debsyl99Commented:
That's cool - but you never know - just spotted the reference to Backup Exec now so apologies for missing that. However the NT backup on exchange is also exchange aware - doen't mean it will back up the mailbox store if you don't tell it to, which is why I felt I should ask,

Deb :))
0
 
mckeoughAuthor Commented:
No, seriously, it's my post and I don't care if people ask questions related to what I post. No apologies needed.
0
 
Debsyl99Commented:
Thanks - but I like to be thorough - I'm an exchange admin myself so I know what the beast can be like - that said, these guys absolutely know what they're talking about so I'll leave you in their safe hands. I've just learnt from EE never to take anything for granted. I'll leave you with one tip though (again just in case you don't know) - if you can test everything separate from your exchange environment, particularly planning for disaster recovery, then do so, because if your exchange users are anything like mine and the rest of the world they can just about manage for a while without many things, but email isn't one of them!

If you don't have a test environment then get yourself something like VMWare Workstation and a beefy PC - not ideal and has limitations but at least you can experiment in splendid safety,

Best wishes to all of you,

Deb :))
0
 
ikm7176Commented:
Good article about exchange Backup

http://www.msexchange.org/tutorials/The_Exchange_Server_2000_Database_Structure_Its_always_a_rainy_day_when_youre_doing_restorations.html

Types of backup:

Normal/Full Backup - All Information Store, Directory, log and patch files are backed up. All transaction logs are purged. A full restore will bring Microsoft Exchange to the state as of the end of the backup.
Copy - Same as full backup without purging the transaction logs.
Incremental - Backs up log files containing all transactions since the last backup of any type. All transaction logs are purged.
Differential - Backs up log files containing all transactions since the last full backup. Transaction logs are not purged.

0
 
mckeoughAuthor Commented:
Thanks for all the comments everyone! I really appreciate all the input you guys had!
0

Featured Post

Simplify Active Directory Administration

Administration of Active Directory does not have to be hard.  Too often what should be a simple task is made more difficult than it needs to be.The solution?  Hyena from SystemTools Software.  With ease-of-use as well as powerful importing and bulk updating capabilities.

  • 5
  • 5
  • 4
  • +3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now