Snapshots are not supported in Exchange — so don’t use them!

Snapshots is one of the many topics that comes up frequently on the Microsoft forums and other forums like Experts Exchange. Let’s cut to the chase: Microsoft does not support creating snapshots of Exchange or Active Directory. You may ask why? You may even say, “I have been doing this from the start or my backup software does this.” The reason it is not supported is because Microsoft Exchange and Active Directory write data in real-time. Records are constantly updated. Users’ mailboxes will constantly update as they are sending/receiving/deleting mail.

Snapshots issues

So, what are the problems with using snapshots to restore Exchange? First, you will be surprised at how busy an Exchange and Active Directory server is. Remember, snapshots are a fixed image of your server in a previous time. What are the common problems of restoring an Exchange server back in time using a snapshot after, say, a Windows update caused the server to Blue Screen of Death or it did not come back online or you did a cumulative update or rollup on Exchange and it caused an issue? The problems might include the following:

• Outlook profiles giving errors on opening.
• Data loss within Exchange and Outlook clients.
• Exchange not able to establish connections to Active Directory.
• Duplicate SIDs of machines.
• Backups failing.
• Exchange services not starting.

These are a few issues, but there may be others that you may encounter. As you can see, we have quite a serious list here and that means the SLA for company uptime is not going to be met.

Going back in time

If you use a snapshot, you are going to be doing a lot of running around (almost constantly) to fix Outlook profiles. They might work now but later on they won’t want to connect to the Exchange server. Data loss is a big problem within a company. When you restore a snapshot — let’s say you did a snapshot on Monday and the server crashed on Tuesday before the next snapshot — restoring the data back to Monday means you have lost about 24 hours’ worth of work for employees who use email as a filing system or, just in general, there may be mail loss.

The next issue you may face is having your Exchange server not connecting to Active Directory or failing to connect. This can lead to hours of unnecessary troubleshooting and changes to try to fix a problem that does not need fixing. This means that users will be offline and won’t be able to work, unless you have a disaster recovery plan like continuity for your Exchange server in the means of a third party like Mimecast or Symantec or an ISP that offers the solution that can detect when the server is down and then spool mail. In this scenario, at least users with Outlook plugins can still work as mail will flow. However, not every company has a DR plan or continuity plans in place, because of cost or because staff failing to understand the requirement for business continuity.

The next thing to look at is duplicate SIDS (machine ID) within active directory. If the backup software’s restore process does not restore to the original source and creates a new machine in AD, it is possible you can end up with duplicates.

Because you now have a restored machine, chances are the backups are still trying to go to the original server and not to the restored server. This means the backups will potentially be null and void and not valid anymore.

The last point I want to touch on here is the Exchange services that do not want to start. Trying to troubleshoot this scenario can take hours or days. This in turn just causes more issues trying to get Exchange back online.

The symptoms are similar to those of a failed CU or RU. You try to run an upgrade to fix the issue but the upgrade keeps failing as it cannot start the services either. This, in turn, leads to fiddling with registry entries and playing around in ADSIEdit, which can cause even more issues and data loss within the environment as keys might be deleted and “old” servers removed that shouldn’t be.

How to fix this

OK, so how do I fix this? The best approach, in my opinion, would be to recover the server. This recovery has to be done as follows:

• Reset Exchange machine in Active Directory (Not Delete).
• Create a new virtual machine with the same name and join it to Active Directory.
• Put the same IP information in and how your NICs were set up.
• Install Windows updates.
• Install the Exchange prerequisites for your version.
• Install Exchange Server by using the recovery switch option (Setup /mode:RecoverServer)
• Once the recovery is complete, reboot the server.
• Install any security updates for that cumulative version.
• Install any Windows updates for the Exchange server.
• Reboot your Exchange server.
• Add your storage to the server (mount points, existing drives).
• Map your drives
• Restore the databases from the last known good backup.
• Try to mount the databases within Exchange.

Those are a high-level set of steps that you need to do. If the last two steps don’t work then you will need to look at creating a recovery database and then restoring from a backup and using dial tone to get the stores online.

As you can see above, it can cause an IT admin a lot of headaches if you restore a snapshot of Exchange. It’s best to back up the Exchange databases, which will truncate the logs. Restores of this are supported. If you are running a database availability group (DAG), let the software backup the DAG as you never know when you switch databases.

Use proper backups

So, what’s the lesson here? Use proper backups. If you are unsure, jump onto the many forums and ask the question relating to your backups and many MVPs and Microsoft staff will provide you with an answer.

Featured image: Pixabay