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.
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:
- 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.
- Dismount the active copy of the mailbox database.
- Remove all DAG copies of the target database.
- Make sure that you keep the physical files (both Transaction Logs and Databases) of the database copies that you have removed.
- Allow for – or force a Domain Replication and then refresh both the database list and copies within the Exchange Management Console.
- 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.
- 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).
- 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.
- Once the database has been moved – allow for domain replication to take place (or force it if you cannot wait).
- Mount the database.
- 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:
- Removing the database copy
- Moving the Database path
- 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:
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.
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.