Exchange 2010 – Moving the Database Path on DAG Servers…

This is a pretty well documented process on the web and indeed on TechNet, but recently I have had to change the database path within my production DAG environment, so I thought that I would share with you some of “frustrations” that I had which will give you the chance to “plan ahead” should you need to do the same.

It is important to note that nothing in this article pertains any major issues within Exchange Server 2010 – the focus is more on how prevailing conditions within your own environment (or indeed in the case of this post – conditions in mine) can affect the process of changing a DAG database path.

The process

Firstly it probably makes sense to give a high level overview of the whole process of changing the paths of DAG enabled databases – this is provided at a very high level below:

  1. Backup your databases! – This might seem obvious, but it is important to ensure that you have a working backup of any database that you intend to modify.
  2. Dismount the active copy of the mailbox database.
  3. Remove all DAG copies of the target database.
  4. Make sure that you keep the physical files (both Transaction Logs and Databases) of the database copies that you have removed.
  5. Allow for – or force a Domain Replication and then refresh both the database list and copies within the Exchange Management Console.
  6. From within the Exchange Management Console right click on the dismounted copy of the database and from the context menu select the “Move Database Path” option.
  7. Choose a new location on your Server for the Exchange EDB path (you can also select a new location for the transaction logs if you wish to).
  8. On each DAG node that will house copies of the databases move the physical files that you kept in step 4 to the relevant locations.
  9. Once the database has been moved – allow for domain replication to take place (or force it if you cannot wait).
  10. Mount the database.
  11. Re-add your Mailbox Database copies.

For steps 2,3,6,7,10,and 11 (above) you can also use the following Exchange Management Shell commands:

Dismount-Database –id <DB ID> –Confirm:$False

Remove-MailboxDatabaseCopy –Identity <Server>\<DB> -Confirm:$False

Move-DatabasePath –Identity <DB ID> –EdbFilePath <C:\NewFolder\MyDatabase.edb>

Mount-Database –id <DB ID>

Add-MailboxDatabaseCopy –id <DB ID> –MailboxServer <Target MBX> –ActivationPreference <Act Pref>

Seems simple enough, so what can go wrong?

Well – it’s not so much what can go wrong – but what might not work as you might expect depending on how your environment is setup. The following are some considerations that I found during the migration of about 1TB’s worth of Exchange Databases to new LUNS.

Allow for domain controller replication!

When you remove the database copies or change the database path – please ensure that you have allowed for domain controller replication to have taken place. If you don’t – issues can occur during the mount process on the new path.

Furthermore – be mindful of the replication schedule – especially if your Exchange DAG nodes are in different Active Directory sites. If you are in a hurry and force a domain replication you should wait wait for it to complete. A replication should happen (from my experience) when each of the following steps have been performed:

  1. Removing the database copy
  2. Moving the Database path
  3. Adding the mailbox copy

Also if you have a single network to a remote site that is facilitating domain controller replication, normal network traffic and DAG replication – be mindful of what time of day you are forcing increased bandwidth as you could bring communications to a grinding halt.

Log replay after the DAG copy has been re-added

Depending on how long your databases are dismounted and how busy your environment is, replaying logs can take quite a while to complete. This will also be dependant on the speed of the network connection which your replication network has access to between DAG nodes. If you have a configuration which is similar to that of my company – where the replication network is in essence a remote link to another data centre that carries other traffic then you need to factor this into you time calculations.

Perform the changes outside hours

This is perhaps one of the more obvious recommendations – but honestly please stick to it!. Unless you have configured dedicated NIC for replication, on a dedicated VLAN, on a dedicated network pipe to a remote datacentre which has your remote Exchange Servers – attempting to compete for bandwidth on the link with day-to-day traffic is a “no no” and will prolong the process.

Restart the MSExchangeSearch Service when the move has completed

Whereas not always necessary, I have seen a few instances where the Content Index Catalogue from the previous database maintains a lock with the MSExchangeSearch service. Restarting the Service will release the lock and allow for the files to be deleted.

Activating Copies after the process

When the database path has been moved – the MSExchangeSearch will resume crawling the database. During this process – there is a chance that the copy will not activate until the crawl has completed on the relevant Exchange Server. I recommend that you keep an eye on the indexing status to ensure that it reads as “Healthy”. You can do this using the following command on the server(s) which have a database copy:

Get-MailboxDatabaseCopyStatus | select Name,*ContentindexS* | ft –AutoSize

When everything is ok, you should receive output similar to that below:

15-07-201217-39-05

Do not work on two or more databases at the same time!

This might sound a little mad, but I would recommend that you only work on one database at a time if you are moving multiple databases to a new path. The various Services in Exchange will be doing lots of different things – therefore do not overload them.

In fact there are some operations that cannot happen on multiple databases at the same time.

Other Options

You you could opt to not move the physical database path, and choose to create a new database, establish a copy and then move all the mailboxes, however – whilst this does get around replay and indexing issues – it does not necessarily protect you from excessive transaction log generation, which could create more problems that it solves – unless you are prepared to place the databases in Circular Logging mode, or are not worried about the amount of logs which might be generated.

However if you are looking at a DB with a small amount of Mailboxes – this may be a good choice.

Sharing is caring!:

7 thoughts to “Exchange 2010 – Moving the Database Path on DAG Servers…”

  1. Nice post… helped me out a lot when I had to do this. If I may, I have one extra tip for moving large mailbox databases. It takes a long time and uses a lot more disk space than it needs to, even if you are moving paths within the same volume it copies the database file and then deletes the original.

    So, here’s what I did:

    Dismount the database.
    Remove the DAG copies.
    Rename the edb file to something like .edb.tmp then move it manually to it’s new location.
    Create a new text file in the old location and rename it to .edb
    Complete up to step 6, moving the database path. That will move your zero size file to the new path.
    Then delete the zero sized .edb and rename .edb.tmp back to .edb
    Pick up from step 8 and continue to the end.

    This was fine for the edb file. It still takes a few minutes to move the logs if you have a lot of them, but the time saved is well worth it. For my situation the database and logs were configured by a previous engineer in the same folder, and I was moving them to separate ones in subfolders (required by a new version of our exchange backup software).

  2. hi there, great article, helped me allot!

    i didn’t have to copy the databases over to my new storage location? when i did the move db path it copied them for me? Is this a new feature of sp2?

    anyway, cheers 🙂

  3. Hello,

    I have question concerning steps above. Why is step 2 performed? IN our test environment (Exchange 2010 SP3) it works perfectly fine without detaching DB, so just remove copies, move paths, move files of copies, add copies.

  4. Thank you for the tips.
    How long does it takes for the ContentIndexStatus to be healthy? is it a quick process like 5-10 mins? or depends on the size of database?

Leave a Reply

Your email address will not be published. Required fields are marked *