• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 278
  • Last Modified:

Exchange 2013 - drive letter mappings for Exchange DBs and changing them

Currently we've got 4 mailbox servers and 31 databases. We have one active and one passive copy of each database.

The servers themselves are set up using a variety of drive letters. i.e if DB1 needs to be active on Server1 then theres a G: drive on Server1 and a G: drive on Server2 (where its passive). There would be no G: drive mapped on the other servers (since we don't need a datbase on these).

Not the best idea since we used many drive letters. My understanding is if you build a new passive copy its got to be the same drive letter and path (i.e. G:) on the new server.

We're trying to tidy this up a bit, cutting down on drive letters, making all drive letters available on all mailbox servers. Basically, just using E, F, H.

Easy to do if we were starting from scratch BUT we have some DBs mapped to say, I: drive on two servers. I can't build a new passive copy on a new H: - it wont work I dont think.

I "could" physically copy the DB to the new drive - but don't like that idea at all. It seems like its going to be problematic.

Possibly export and import would do it too but thats never going to happen in this environment. DBs too big and no downtime allowed.
0
paulfoel
Asked:
paulfoel
  • 2
2 Solutions
 
ArneLoviusCommented:
Both the active and passive databases need to have the same path

If you're on JBOD, then you should use drive letters, but if you're on RAID, then you can use mount points instead of drive letters, mount points provide a way to get past the drive letter limitation.

https://technet.microsoft.com/en-us/library/ee832792(v=exchg.150).aspx

Rather than attempting to "move" databases to new paths, I would suggest creating new databases and moving mailboxes. Moving a mailbox in Exchange 2013 to a different database on the same server should be transparent to the end user, no downtime required.
0
 
paulfoelAuthor Commented:
Good point. Didnt think of that - creating new DBs and moving users might be easier.

Otherwise, I guess its doing a move-mailboxdatabasepath for which the DB needs to be offline. And not sure how long it takes either!

We've only just migrated from 2007 and that was bad enough. Although I guess its local storage this time. But still we;re looking at around 150Gb per database (and theres 31 of them).
0
 
ArneLoviusCommented:
I've not tried to move a database path on 2013 for a DAG database, but on 2010, the command would fail, you needed to unmount the database, use ADSIEdit to change the path, move the database, then either mount the database, and reseed the DAG, or make the same moves on the DAG copy and then mount the database

https://blogs.technet.microsoft.com/shekhar37k/2014/05/22/moving-database-and-log-file-path-in-exchange-2010-dag-option-1/

moving mailboxes takes longer (and generates transaction logs), but is a significantly lower risk operation with significantly lower downtime.

I would keep the idea of a volume per database, but move to mount points instead of drive letters, and if you have the CPU, memory and storage, I would use JBOD with 3 replicas rather than RAID with 1 replica, then you can lose any two servers and still have availability of all databases
0

Featured Post

Free Backup Tool for VMware and Hyper-V

Restore full virtual machine or individual guest files from 19 common file systems directly from the backup file. Schedule VM backups with PowerShell scripts. Set desired time, lean back and let the script to notify you via email upon completion.  

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now