I'm trying to verfiy a Domain Controller via SureBackup Authorative Restore. The Server reboots 2 times for a VMware tools upgrade and it's done. In 50% of the cases Surebackup fails because the Domain Controller is still in DSRM Mode and not externally reachable. This happens regardless if using Surebackup from Full or Incremental Backup. The DC has all the FSMO roles
I can remove the safeboot flag manually, like described here: https://www.veeam.com/kb1277 but that is nothing for a unattended automated backup verification.
Following things have been done:
- Applied RegKey "UseGranularBcdRestore = 0"
- Firewall is disabeld on the DC
- Startup time from the SureBackup job has been increased ( https://helpcenter.veeam.com/docs/backu ... ml?ver=110)
- AV (SentinelOne) has been disabled during Backup
- All AV exclusions are set (https://www.veeam.com/kb1999)
- Applied "bcdedit /default {current}" on the DC
- Disabled safeboot Protection from SentinelOne
- Disabled CBT usage in the job settings
- Disabled "exclude swap file blocks" and "exclude deleted file blocks" in the job settings as well
- Restored the DC in a isolated einvironment (outside of Surebackup) -> No reboot after restoring tho
- Tried Application Restore which is successful
- Applied RegKey "UseLegacyStabilization = 1"
In normal settings, localhost is tertiary DNS, primary and secondary are other productive DCs in the environment.
So it seems, there is a timing issue with automatic fallback to localhost DNS as the current "solution" or workaround is to set 127.0.0.1 as primary DNS -> In this scenario SureBackup is currently succesful since about a week.
This cannot be the final solution as crossover DNS is best practive and MS recommends setting localhost never as primary, more only as secondary or teritary DNS
https://docs.microsoft.com/en-US/troubl ... mes-island
https://docs.microsoft.com/en-us/previo ... dfrom=MSDN
https://docs.microsoft.com/en-us/archiv ... on#dnsbest
Some quotes from those articles:
The inclusion of its own IP address in the list of DNS servers improves performance and increases availability of DNS servers. However, if the DNS server is also a domain controller and it points only to itself, or points to itself first for name resolution, this can cause a delay during startup. For this reason, use caution when configuring the loopback address on an adapter if the server is also a domain controller. The loopback address should be configured only as a secondary or tertiary DNS server on a domain controller.
It depends on who you ask.
We in MS have been arguing this amongst ourselves for 11 years now. Here are the general guidelines that the Microsoft AD and Networking Support teams give to customers, based on our not inconsiderable experience with customers and their CritSits:1. If a DC is hosting DNS, it should point to itself at least somewhere in the client list of DNS servers.
2. If at all possible on a DC, client DNS should point to another DNS server as primary and itself as secondary or tertiary. It should not point to self as primary due to various DNS islanding and performance issues that can occur. (This is where the arguments usually start)
Did somebody had similar issues in the past und managed to solve this? I was thinking off something like this:
(Get-CimInstance -ClassName Win32_ComputerSystem -Property BootupState).BootupState -ne 'Normal boot'
Checking if current bootstate is not "normal" and if so, modify primary DNS to localhost. But is there a possibility to modify the authorative restore script to execute Powershell on the Surebackup machine? As network is not available (nor sheduled tasks) during DSRM mode, the script cannot be copied remotely. So would it be possible thorugh VMware VIX API or something else?
Thanks in advance!
Refruit