Replicate AD from Backup Source (AAP enabled)

[Zew]

Whenever I replicate my AD VMs from backup, and there's AAP enabled on it, the AD servers always come up in a broken state and I have to either do an FRS or DFSR restore to get them into a functional state. If I point the replicas to create right form production with doing AAP they seem to boot up just fine.

I noticed there's only an option to do AAP when I point my source to production but the options are removed from the wizard when I source from backup. What's the proper way to automate this? I've had enough doing manual restores.

If sourcing a backup without AAP enabled it seems to work, but I like the features of having AAP on my AD backups brings, and not fun to keep two sets up backups...

[HannesK]

Hello,
first: I believe that it is better for active directory to use native replication that is built-in the product over any kind of 3rd party backup / replication (except for single AD controller environments).

Did you ever try booting up from a backup? To me it sounds like, that the backup has an issue (which should be investigated by support then). Replica from backup just takes the data from the backup. The first boot should be in non-authoritative restore mode.

There is a KB article that might be interesting: https://www.veeam.com/kb2119

Best regards,
Hannes

[Zew]

This isn't the first time I had this issue: vmware-vsphere-f24/aap-on-dc-t33126.html

It's an extremely frustrating problem to have.

Did you ever try booting up from a backup? To me it sounds like, that the backup has an issue (which should be investigated by support then). Replica from backup just takes the data from the backup. The first boot should be in non-authoritative restore mode.

Yes, and the same thing happens, if I pick my source to be from a backup set were AAP was enabled the backups are all broken and fudged up. In the case of older DC's still using FRS, Yeah the link you shared is what I have to do every single time (https://www.veeam.com/kb2119) and it's an unreal PITA! However if I have to do newer DC's that use DFSR then that KB doesn't seem to work and I instead have to follow MS's official guide on doing an authoritative DFSR restore (https://docs.microsoft.com/en-us/troubl ... ronization) This also takes an unreal amount of time. So much a PITA that instead I simply delete and tear down the useless restores, find a backup set where there is no AAP enabled, or in case of replication point directly to production and ensure AAP is not checked. Run the jobs and the VMs are in a working state, so much faster and hassle free.

However as I already stated it's extremely annoying to have to 1) rely on production sourced replication jobs, and 2) having two sets of backups one with AAP enabled, one with no.

Why can't Veeam at least have an option for systems backed up via AAP to do a normal VM restore without mucking with the FRS/DFSR state?!?! If there was actually something wrong at the time of backup why wouldn't it state so at the time of backup?

Like everything "restores" in terms of the VM, it's just liek Veeam does something like you said puts it into a "non-auth restore state" but never does the needful to bring it up fine, and its really causing me a lot of grief in terms of restore, or testing, or a test environ, or even replicated VMs. Everything on the AAP enabled back up works, doing a AD explorer, opens, comparing to production, works, restoring individual items all work. This issue driving me crazy.

[HannesK]

Hello,
what we do is implementing the recommendation of Microsoft. If application consistent backups are broken, that's not normal. I can only recommend to investigate that with Veeam and / or Microsoft support.

Our software does what Microsoft requires for application consistent backup: trigger VSS. All we call is native Microsoft API. No "magic".

Restoring crash-consistent backups with old Windows DCs leads to USN rollback. For newer Windows versions, Microsoft built-in a protection for crash-consistent snapshots.

Yes, explorers work fine for most situations from crash-consistent backups (for example storage snapshots). That's expected behavior.

Best regards,
Hannes

[Zew]

Besides speculating and finger pointing, how can I validate your IF "If application consistent backups are broken, that's not normal" <- What can be done to verify this??

[HannesK]

SureBackup is what customers usually do. There is a checkbox for authoritative and non-authoritative restore.

https://helpcenter.veeam.com/docs/backu ... ml?ver=110

[Zew]

I don't have BR Enterprise, any other way?

[Mildur]

Start it up in a instant vm recovery session and test it manually.
You could script that by yourself if you need some sort of automation.

[Zew]

I guess I jumped the gun, I just restored the AD's doing full VM restore, the VMs came up without intervention required.

Why does the same not happen when I source these backups in a replication job?