The criticism regarding this is fair. I actually did spend some time working on such a document (and yes, I'm a Veeam "greenie"), and have continued to work on it during available time, so there will be a document forthcoming. Publishing a document isn't just a matter of creating it, you must actually test all of those procedures across a range of potential platforms (2003, 2008, 2012), each having their uniqueness, and verify that the procedures work. It's a time consuming process, and even then, environmental uniqueness can still cause issues.
However, in the interim, I thought I'd share some information that might be useful. For one thing, the Surebackup process is indeed quite different than a normal restore, and there's a very good reason for that. The Veeam "automatic" DC restore process performs a non-authoritative restore of the DC because, in most cases DCs are restored when there are still other functional DCs in the environment. In this case the non-authoritative restore process should truly be 100% "automatic". In other words, if I have 3 DCs, and after Windows updates last night one BSODs, restoring that single DC VM should be a 100% automatic process. The automatic recovery should also work for environments with only a single DC.
Most customers, however, have multiple DCs but when running Surebackup, it's quite common that, while the environment may have multiple DCs in production, only a single DC is started in the Surebackup environment. This means the server must effectively stand on it's own. It's in an isolated environment so it's not going to find it replication partners, etc. and we don't won't it to waste a lot of time attempting to do so. To prevent this, during the "Configuring DC" phase of the Surebackup process, Veeam makes some changes to the registry of the DC prior to powering it on the the Suerbackup lab. These change force an authoritative restore of the DC, and specifically of SYSVOL. You can see the exact changes being made by looking in the Surebackup job log in the Veeam log directory. Open up the logs and search for "PrepareDC" and you'll quickly find the section where this "magic" is performed during Surebackup, including all of the gory details of the registry entries, but in summary it's the following:
1. Set Burflags = D4 to force authoritative SYSVOL restore for systems using FRS for SYSVOL replication (i.e. Windows 2003 and older and potentially upgraded AD environments where users have yet to migrate SYSVOL to DFS-R)
2. Set NTDS\Repl Perform Initial Synchronizations = 0 to keep the DC from wasting 15 minutes (or more) attempting to contact replication peers which simply aren't going to be there
3. Set DFSR\Restore\"SYSVOL" = authoritative to force authoritative restore of SYSVOL for systems using DFS-R (hopefully all Windows 2008R2 DCs and newer)
So now we get to the 100% full DC recovery scenario, i.e. "I've lost all my DCs". When you restore a DC using either full or instant recovery (as stated earlier, there should be no difference other than performance which might increase the time it takes to come online), the automatic recovery process performs a non-authoritative restore reboots and then starts looking for his other DCs to sync up. Because all DCs are gone, there are no other partners available, the replication may take 15 minutes (or longer) to even start (in the absence of the Repl Perform Initial Synchronizations key used by Surebackup). This is why restoring all DCs together will generally work better, as this timeout to start SYSVOL replication is avoided. However, since you have restored all DCs non-authoritatively, they'll likely all be waiting around hoping that one of them claims to be the authoritative SYSVOL so that they can start replicating. You'll need to designate one of these DCs as authoritative for SYSVOL and the procedure to do this varies slightly based on if you are using FRS
for SYSVOL replication.
So if I were doing a complete disaster restore, I'd restore two of the original DCs, power them on, wait for their reboot, and force one to become authoritative for SYSVOL, then restore the other DCs and they should recover automatically.