Restore AD Forest-Domain

[mamosorre84]

Hi all,

I'm working on a shift and lift project for a customer who need to migrate his primary virtual infrastructure site from a shared cloud to a private cloud.

I have configured Veeam replica jobs for all VMs, and the "macro" plan is: shutdown production, perform last replica, power on in the new environment.

My doubt is the AD: there are 2 forest DCs + 2 domain DCs involved in the migration, and other 4 DCs in 4 different sites not involved.

The question is: which is the best way to perform the AD migration?

My idea is:

1)migrate domain DC with no FSMO roles (shutdown, replica, power on)
2)move domain FSMO roles to this DC
3)migrate second domain DC
4)do the same with forest DCs

Any advice or suggestion?

Second (dummy) question: does Veeam non-authoritative restore work if the source VM is powered off during the last replica (and no application-aware command processed) ?

Thanks

Marco S.

[HannesK]

Hello,
as far as I know (I'm not an AD specialist. A Microsoft forum might be a better source), the "best" way is to just add new DCs and de-promote old DCs. No backup / replication and no restore. AD has everything "built-in".

I'm not sure what the idea of step 2 is. If the IP addresses do not change, then it's just a "power off" and "power on" of all machines.

does Veeam non-authoritative restore work if the source VM is powered off during the last replica (and no application-aware command processed) ?

If you do it manually, then yes. But I'm not sure why a non-authoritative restore would be required. Veeam does not do anything application related for a powered off machine. It's just "power off" and "power on"

AAIP is required for a Veeam restore www.veeam.com/kb2119 (which you do not need as far as I see)

Best regards,
Hannes

[mamosorre84]

Hi Hannes,

create new DCs is better but it has more effort in terms of time, analysis and reconfiguration of all applications that point directly to the old ones (I believe it's not recommendend change DC's ip).

The idea of seizing FSMO roles during the migration is to avoid issues powering on a replicated FSMO role's owner.

If I choose the way to replicate DCs instead of create new ones I thin I need to "use" non-authoritative restore..is not a replica "failover" similar to a restore from backup? am I out of the way?

Regards

Marco S.

[HannesK]

Hello Marco,

avoid issues powering on a replicated FSMO role's owner.

I see no reason for issues. I don't see that the "restore" scenario. It's "just" a power off / power on.

It's not a classic "failover" (where you go back in time) and it's not a "restore" (where you also go back in time). I see your scenario more like a storage & host VMotion

Best regards,
Hannes

[mamosorre84]

Sorry but, in my opinion, it's not just a power off/power on, or more like storage/host vmotion..we are using VBR for replicate the environment, so the replicated VMs are "under Veeam's laws" !

I've tested several times DR environment replicated with Veeam, DCs always reboot automatically due to Veeam application-aware influence..

It's like a classic failover, it's a "permenent failover"..do you agree?

Marco S.

[HannesK]

due to Veeam application-aware influence

with a powered-off machine I don't see how application aware processing can happen. I only see a 1:1 copy.

I'm talking about the planned failover: https://helpcenter.veeam.com/docs/backu ... ml?ver=100

[mamosorre84]

Perfect, planned failover could be the right definition..but it's always a Veeam replica, not a simple vMotion

I understand that for a powered-off VM application-aware can't happen, I just want to know the difference for a domain controller, in this case..

If, for example, I power on a replicated Microsoft SQL server, there is no difference:

- source VM is powered-on during the replica job (with app-aware): VSS makes the DB consistent
- source VM is powered-off during the replica job: the DB is obviously consistent

And, above all, no automatic process happens during power on.

We can summarize my post with these questions:

What happens to a DC during a failover, a process like DC restore or not?
Is there any difference if the DC is powered-off during the latest replica job before the failover?

Regards

Marco S.

[DaveWatkins]

I've done this many times, planned failovers work fine. As log as you power off, do final sync, power on the new VM and destroy the old VM so it can never be bought online you have nothing to worry about. All you're doing is effectively shutting down the DC's, then powering them back on. That's all they think has happened, they can't see they are on new hardware or potentially somewhere else in the world. HOnestly you'll spend longer fixing their IP addresses and getting them all replicating nicely than you will with the failover process

[mamosorre84]

Thanks Dave!

[adrien.herve]

That's all they think has happened, they can't see they are on new hardware or potentially somewhere else in the world.

Yes of course they can. A replicated DC could be aware that it has been replicated somewhere else due to VM-GenerationID (AD safeguard) since 2012 R2. And in this case it's more like a non-authoriative restore than only powering them back on. The ID is provided by the hypervisor and a specific driver is included in Windows to catch it (vmgencounter.sys).

https://docs.microsoft.com/en-us/window ... chitecture

Marco can you please give me your feedback on this? How you deal with VM-GenerationID?

[mamosorre84]

Hi Adrien, honestly i didn't care about the VM-GenID, , following this kb everything worked fine.

https://www.veeam.com/kb2119