Exchange Services Won't Start After Restore

[rboynton]

Case 02925610. We are using one host only, and purchase a new host. Restored several VM's to the new host without problem. We shut down the Exchange 2013 server, and ran a backup, then restored it to the new host. We did a backup of the DC while it was running, then did a restore to the new host. When we brought up the DC and Exchange on the new host, the Exchange services would not start (cannot start exchange topology service). Worked for hours trying to figure out what happened. In the end, we blew away the DC and Exchange VM's on the new host and simply copied the powered-down VM files to the new host instead of using the backup job. Doing it that way worked fine.

Main issue is why the DC appears to not have worked when it was a fresh backup that was restored. This is very concerning; if the backup does not produce a usable VM after restoration, what is the point? Another "gotcha" we had was we had to attach the other host to the inventory so Veeam could see the new datastore to restore the files. This new host put us over on license processors, so we had to remove the old host. Before we could do that we had to remove the old backup jobs that referenced the old host. Not the end of the world, but frustrating as we cannot go back to the old DC backup job to see what the settings were in the hope of finding out why the restore did not produce a usable VM.

[foggy]

Hi Rick, the main question is whether application-aware processing was enabled in the job that backed up both DC and Exchange. In this case everything should be fine. As for the license, then unless you back up VMs on the new host (i.e. use it for restores only), there's no need to revoke license from the existing one.

[rboynton]

I am nearly 100% positive the job was set for application aware processing. I always set up DC, SQL, and exchange servers that way. I disabled the old jobs, but when I tried to create new jobs, I was not able to start them because the old host was still attached to the console, thus exceeded the licensing. Again, not the end of the world, but was frustrating that I needed to remove the old host... and the associated jobs tied to it... before new jobs would work. That forced me to remove the job that we are talking about if the app aware setting was enabled. My issue may be unusual, but there should be a way to have some grace period when a new host is brought into the mix... if nothing else but for this purpose.

[foggy]

...but when I tried to create new jobs, I was not able to start them because the old host was still attached to the console, thus exceeded the licensing.

This is expected, since all the hosts you're backing up from are counted.

As for the original issue, I recommend looking closer at it with the help of our support team, since the behavior doesn't look expected.

[rboynton]

This is expected, since all the hosts you're backing up from are counted.

Very unfortunate catch 22. Latest dialog with support is zeroing in on my doing a non-authoritative DC restore when an authoritative one should have been done. Never entered my mind that there would be a need to go through all of this for a "simple" restore after a fresh backup. Hope I never have to do this again.

[VladV]

This is expected because the automatic authoritative restore is not usually recommended. There are some manual steps involved but it is safer this way.

[foggy]

If it is just a single DC in the entire environment, authoritative restore is not required.

[Andreas Neufert]

Please check as well this: vmware-vsphere-f24/veeam-b-r-10-surebac ... 74045.html