Exchange 2013 Troubleshooting: Reseed failed database copy

  • Article

Introduction

In Exchange 2013, we will encounter a database copy in a failed state and need to reseed it. This can be a complete reseed or a catalog reseed. There are many reasons why they can fail. These can include:

  • Sudden reboot of a server
  • Loss to the storage location where the database copy is stored
  • Hardware failure
  • Many other reasons

Let’s expand a bit on the above. A sudden reboot of a server can be a Power Failure in the environment and where we do not have backup power in place like a UPS or generator and I would strongly advise you to look into something like this to ensure you have no data loss or in actual fact, no hardware loss.

The second option is having a loss to the storage location. Generally, Exchange databases are written to Mount points which are located on our SAN vs being located on the physical server or Direct attached storage. If our Exchange mailbox databases do not want to mount, first see if you can access the mount points. It could be the server lost access to it and therefore Exchange cannot find the database to mount & you faced failed to mount error.

The last big reason why it can fail is due to the fact that your hardware has failed. This can be just a drive (hopefully you have RAID configured) or the actual server has failed completed in which case it would need to be replaced. This would result in you having to reseed your database vs just updating the catalog.

Other reasons of why you would need to reseed an Exchange mailbox database could be due to you having 1 copy of the DAG in a remote site and it fails (not best practice but it does occur) or your WAN link has been down for an extensive period of time.

Once you have identified the problem in your environment, you would need to reseed the database. This can be rather time consuming as it all depends on how fast your Lan is or if it is a WAN reseed and how big the databases themselves are.

As mentioned above, you will need to reseed the database but if you are on a single site, it makes the re-seeding more easier however if it is a multi-site and you need to re-seed this can take longer as the re-seeding will put more strain on the network as it would need to copy the database across plus all the transaction log files and the content index for that database.

Exchange allows you to select a source server for the database reseed which will allow you to select a serve that has better connectivity to reseed from, such as a DAG member server in the same site.

We can now look the ways to reseed a database:

Reseeding a database copy using the Exchange Admin Center (EAC)

Reseeding a  database copy using the Exchange Management Shell (EMS)

Let’s look at each one:

Reseeding a database copy using the Exchange Admin Center

Open the Exchange Admin Center and navigate to Servers -> Databases. Select the database that has the failed copy.

On the database copy that is shown as failed click the Update link.

We  can click Browse and specify a source server if we need to, otherwise click Save to reseed from the server that hosts the active database copy.

Wait for the reseed operation to complete. This can take a while depending on the size of the database.

When the reseed operation has finished the database copy should now be healthy.

Reseeding a  database copy using the Exchange Management Shell (EMS)

The second option is too reseed the Exchange mailbox database using PowerShell and you can do this by running the Update-MailboxDatabaseCopy command.

To start off with, you need to know the name of the database that you want to reseed. Once you have that you can then run the following command below:

Update-MailboxDatabaseCopy "Mailbox Database 1"

If you want to specify a Source server then you would use the -SourceServer parameter as well in your command:

Update-MailboxDatabaseCopy "Mailbox Database 1" -SourceServer Server2

If you receive an error message that log files already exist in the transaction log path for the database you can use the -DeleteExistingFiles switch to inform the Exchange server to remove those files before beginning the reseed. To do this you can use the following command:

Update-MailboxDatabaseCopy "Mailbox Database 1" -DeleteExistingFiles

You can also look at updating the content index state in which case we will just update the catalogue only vs reseed the entire database. To do this you can run the following command:

Update-MailboxDatabaseCopy "Mailbox Database 1" –CatlogOnly

This will take a little while to update as well but once it has completed you will then have the index in a healthy state.

Lastly, for long reseeds where you either have a task that ends PowerShell (could be a precaution due to malware) or you do not want to leave your Exchange Management Shell open then you can look at using the –BeginSeed option within your script, here is an example below:

Update-MailboxDatabaseCopy "Mailbox Database 1" -DeleteExistingFiles -BeginSeed -SourceServer Server2

Monitoring

All of these commands are great to have handy but as an Exchange Admin, you need to ensure that you are always keeping an your databases, it is better to catch something early before you end up with a complete failure where neither of the databases want to mount. There are many monitoring solutions out there like System Center Operations Manager (SCOM) or Solar Winds or any other software that monitors the environment end-to-end.

Some MVP’s have written scripts to check DAG health or you could simply check the database copy status on a server to see the health of your DAG.