Skip to main content

Issue Restoring Domain Controller

Thread needs solution

I'm moving an Active Directory domain controller from one ESXi host to another ESXi host in a different vCenter instance.

I created a backup task with application aware backup enabled for Active Directory, and I manually chose the Microsoft VSS provider as instructed by the documentation - https://dl.managed-protection.com/u/backup/help/12.5/user/en-US/index.h… .

The backup ran successfully, and so did the move (restoration to the other ESXi host in the other vCenter instance).

However, after booting the domain controller VM, I noticed that the Windows Search service was throwing errors in the event log. Event IDs 3028, 3058, and 7010 coming from "Search". These errors were not in the event log on the original machine. Trying to start the Windows Search service resulted in error 1392. All information I found said to run chkdsk /r . I ran chkdsk (read only) and it did report that it found 3 errors. The original VM didn't have any such errors.

I'm running chkdsk /r on an offline replica of this VM to see what happens.

Any advice?

Thanks

0 Users found this helpful

Here's a screenshot of the chkdsk /r report from the replica (disconnected from the network):

Sorry this is a screenshot, but I didn't want to connect that replica to the network or attach devices to it to copy the log data off of it, so I just screenshotted the console.

The Windows Search service seems to be working on this VM now.

Is this is a known issue with the VSS and Windows Search?  The VM is running Server 2012.
Should I be concerned about anything else related to this domain controller?

Should I go ahead and run chkdsk /r on the live domain controller VM and reboot it to let it run?  Or could this cause any other potential issues?

I have two more domain controllers to move.  Should I do anything differently for them?
I can run a backup with the VM powered on or off, and I can run a backup with application aware backup (for Active Directory) enabled or disabled, and I can choose the Microsoft VSS provider or I can leave at the default.

Note that I am running the backup job via an Acronis virtual appliance on the source ESXi host. I believe the restore job runs from my local workstation using the Windows agent.

Thanks

frestogaslorastaswastavewroviwroclolacorashibushurutraciwrubrishabenichikucrijorejenufrilomuwrigaslowrikejawrachosleratiswurelaseriprouobrunoviswosuthitribrepakotritopislivadrauibretisetewrapenuwrapi
Posts: 0
Comments: 2016

Hello Brian,

thank you for posting on Acronis forums!

Should I go ahead and run chkdsk /r on the live domain controller VM and reboot it to let it run?  

Since the Windows Search errors and chkdsk showed file system errors on your restored machine, then it is recommended to check the original VM as well.

Or could this cause any other potential issues?

Yes, Acronis could create the backup in a sector-by-sector mode in case of severe file system errors.

I have two more domain controllers to move.  Should I do anything differently for them?

I recommend that you run chkdsk without any parameter (in order not to reboot those servers) and see whether there are any file system errors.

I can run a backup with application aware backup (for Active Directory) enabled or disabled, and I can choose the Microsoft VSS provider or I can leave at the default.

It is preferable to enable application-awre AD backup and use Microsoft VSS providers.

 

Thanks for the reply.

I checked the original VMs, and they had no errors.

All 3 of the VMs I moved (backup and restore in a new location) showed the exact same behavior with the Windows Search service failing to start and chkdsk reporting similar errors.

Running chkdsk /r and rebooting on the recovered (moved( VMs seems to have solved the issue, and I don't notice anything obviously broken when checking dcdiag or repadmin /replsum.

When running the backups, I did use application-aware settings with admin credentials for the domain, and I specifically used the Microsoft VSS provider.

 

frestogaslorastaswastavewroviwroclolacorashibushurutraciwrubrishabenichikucrijorejenufrilomuwrigaslowrikejawrachosleratiswurelaseriprouobrunoviswosuthitribrepakotritopislivadrauibretisetewrapenuwrapi
Posts: 0
Comments: 2016

Hello Brian,

thank you for sharing the outcome. 

Since we have not seen activity logs for backup/restore operations, we can't determine the root cause of the issue. However, file system errors on the restored system are definitely copied from the source system. 

We are glad that the chkdsk /r has cured the problem.