DC’s and VM’s – Avoiding the Do-Over

re: DC’s and VM’s – Avoiding the Do-Over

Jonathan Stephens, MSFT — Mon, 12 Apr 2010 13:27:24 GMT

Why does there need to be a workaround?

1. You don't have to reinstall the entire AD. You have to demote/cleanup/promote the failing DC. If you only have one DC, you can't get into this situation anyway. Let's not overstate the problem.

2. USN rollback is an error condition caused by not restoring a domain controller properly in the first place. And the article is quite clear on explaining how that error state occurs.

3. We strongly encourage admins in your situation to restore a DC is to use a System State Backup. You did take such a backup before installing new software on your DC, did you not?

re: DC’s and VM’s – Avoiding the Do-Over

goranv — Sun, 11 Apr 2010 01:47:51 GMT

this is interesting. i installed Forefront just to learn that it cannot be used on a secondary DC. Then used clonezilla to restore to a previous point. Got this problem exactly as described.

There must be some kind of a work-around. reinstalling the entire AD seems a very cumbersome way to restore a DC. Did MS not realize that before?

re: DC’s and VM’s – Avoiding the Do-Over

Pronichkin — Fri, 12 Mar 2010 12:41:01 GMT

Sorry for being pushy on this but I really want to figure out how it works and still cannot get it.

As noted at “VSS Backup and Restore of the Active Directory” (http://msdn.microsoft.com/library/aa384675.aspx):

“Following a crash requiring disaster recovery, the Active Directory can be restored as part of the restoration of the operating system state.

This restore operation is essentially a writerless restore”.

For me it sounds like nobody special gets involved into bare-metal recovery of AD Controller. No writer or whatever. So how does it happen that restored Controller detects it was restored from backup and correctly notifies its replication partners?

The only idea I have is that is done using reading “LastRestoreId” registry key at DS startup. That would work in case of System State restore but would not help in case of full volume recovery (because LastRestoreId key is not set in this case). So I'm completely lost here.

re: DC’s and VM’s – Avoiding the Do-Over

Pronichkin — Mon, 08 Mar 2010 15:19:56 GMT

And who's actually in charge for changing Invocation IDs and other post-restore tasks? Is it NTDS Writer who needs to be made aware of restore or some special backup app plug-in?

re: DC’s and VM’s – Avoiding the Do-Over

NedPyle [MSFT] — Mon, 08 Mar 2010 14:00:51 GMT

I'm not a backup/restore guru, so here's where the Wiki hopefully kicks in with community experience. :-D

One specific aspect of making AD backups through VSS starting in WIn2008 is that your backup/restore software is supposed to understand the NTDS writer.

Lots more info on MSDN and TechNet about this. A starting point:

http://msdn.microsoft.com/en-us/library/bb968827(VS.85).aspx

re: DC’s and VM’s – Avoiding the Do-Over

Pronichkin — Sun, 07 Mar 2010 14:18:08 GMT

Thanks for your remark. I've added it to the article nearly “as is”. And I have one more ongoing question.

“Backup and Restore Considerations for Virtualized Domain Controllers” guidance (http://technet.microsoft.com/library/dd363545.aspx) says:

“There are two supported ways to perform backup and restore of a virtualized domain controller:

<...>

2.Run Windows Server Backup on the host. This action calls the Volume Shadow Copy Service (VSS) writer of the guest to make sure that the backup is performed properly”.

Is it correct to substitute “Windows Server Backup” in this statement with something like:

“Any certified backup and restore application that is running in the “parent” (or “management”) partition of any certified virtualization platform assuming that this backup and restore application is aware of VSS in the Guest OS and calls it during backup and restore operations”?

I.e. is there any magic in how Windows Server Backup specifically holds AD DS or it is just okay to call in-guest VSS and it would take care of the rest?

re: DC’s and VM’s – Avoiding the Do-Over

NedPyle [MSFT] — Sat, 06 Mar 2010 16:17:56 GMT

Looks great to me :). The only thing I might clarify in there is that "flush" and "commit" are somewhat interchangeable (or at least often related) terms that will be used through a lot of documentation. Your doc uses both also, just at different points.

For example: http://msdn.microsoft.com/en-us/library/ms683106(EXCHG.10).aspx

Nice work, glad to see that the Wiki is already got traction.

re: DC’s and VM’s – Avoiding the Do-Over

Pronichkin — Sat, 06 Mar 2010 13:06:55 GMT

Hi Ned and many, many thanks fot the clarifications on this.

Could you please take a minute and review what I've written on general backup theory in TN Wiki? What I tried to do there is (among other similar goals) to explain the “USN Rollback” feature in “Simple English” languate avoiding any technical details and still giving explicitly all necessary warnings and support “do and don't”s.

The article is located at http://social.technet.microsoft.com/wiki/contents/articles/backup-and-restore-special-considerations.aspx

Now I gonna write another article there in the same style that talks specifically on VM backup and restore (I'm VM MVP after all). But before that I want to make sure that I'm OK with all application-specific points.

re: DC’s and VM’s – Avoiding the Do-Over

NedPyle [MSFT] — Fri, 05 Mar 2010 19:46:48 GMT

Nah, but plenty of other stuff is... :-/

So, back to your question. I was able to dig up the right folks and get some calrification. I plan on having this article edited for clarity, but:

1. As long as you never boot the hyper-v snapshot until after you’ve set the ‘dsa restoring from backup’ key, then you’re good and supported (this was tested in Win2008 R2). However, if you ever accidentally boot the hyper-v snapshot before you’ve set the key, then you’re in a USN rollback scenario.

2. Step 12 is baloney. If the value is not present or correct, you cannot start over with this VHD. You must have another snapshot to restore or have made a copy of this image before you started all these steps.

3. And finally - the reason the article starts with "Do not use the Snapshot feature as a backup to restore a virtual machine that was configured as a domain controller" but then goes on to give steps is for the absolute last resort, last gasp, "OMG we're all gonna die man" scenarios where your system state backups are not working. The SS backups are still the mechanism you should be using, and the snapshots should never, ever be done in lieu of system state backups. That's why this article is hard to find, but USN rollback articles are easy to find - we want people using system state backups.

re: DC’s and VM’s – Avoiding the Do-Over

rsoe — Fri, 05 Mar 2010 14:45:32 GMT

I hope this didn't cause you any delay in the "Friday Mail Sack" ;)