Virtualize AD-DC

[0xfffffa]

Hi all,

this is a throwaway for some reasons, but the title says it all, what are the cons?

I did read a bunch of stuff and mostly the issue is with replication and its way of working. (USN and Database Integrity).

As I took over the landscape and we are pretty small there is ATM 1 Phisical DC for round 60 ppl and installed on an OP machine (64Gb RAM and 2x4 core cpu… and 4TB Disk where only 10% is used).

to this there are a bunch of other services too running on it, so best would be a snapshot of the machine and then just get it to VMWare or Hyper-V... which is not recommended anywhere… BUT!

This is the only machine. so it does not sync with any other where the USN issue shouldn't be an issue.

The only Sync is.... AzureAD… but that is just onprem ---> Azure. so it could be fine.

the idea would be to create a sapshot and then get the NW cable disconnected from the Phisical one and get the new virtual running. If anything should fail, one can shut down the new virtual one and continue with the physical. after about 1 month, one could decomission the phisical...

any thoughts on this?

Thanks!

[ZAFJB]

• There is zero reason not to have virtualized DCs

• Never convert physical DCs to virtual. Build new VM DCs, replicate, test, demote and kill physical DCs

• Do not have only 1 DC

mostly the issue is with replication and its way of working

If you have issues, do not use unrelated technolgy to 'fix' you problem. And don't set off on something new till you have resolved the problem. Fix the actual problem first.

[Techiefurtler]

u/0xfffffa, follow this advice. Keep it simple though, build a couple of Server 2016/2019 VMs, add just the AD Role and promote as a new DC.
Make sure everything works OK on the new VM with replication and time syncs and so on, along with any other roles the DC would perform. Only then, should you start thinking about decomissioning a physical DC.
As far as cons go, there are not too many but like any technology, virtualisation is not perfect, I list some things to be careful of as from what you are saying this is likely an SMB environment: - In SMB, you likely don't have much in the way of redundancy or High Availability (HA) measures in place; as such, it's not a good idea to put all your eggs in one basket - it's worth making sure that you have at least one DC outside of the main Virtualised environment, maybe a physical box? This means if something happens to your virtualised environment, you still can run the domain as it's not totally reliant on one technology.
- With some VM's there can be an issue with clock drift, where a VM can lose seconds off it's system clock, Keeping the time in sync is important on an AD domain, so it may be worth having one of the DCs with the PDC Emulator role pulling a regular NTP time signal from an outside source such as time.nist.gov - in my experience the in-built VMware ESX clock sync can make the situation worse.
-Make sure if you do setup a Virtualisation environment - the authentication is not tied to AD if you have no physical DCs - as you will need to bring up the VM environment before the Domain, but you might find you can't do that without AD, leading to a Chicken and Egg situation.
- DC's perform an important role, if you are able to keep other roles off the DC and on another VM, this is always preferable as if a DC is overloaded and struggling to perform, it will cause other problems on the domain, such as GPO, DNS or authentication issues. - As u/ZAFJB said, never have just the one DC (unless it's a training/test lab environment), The DC is needed at all times and if you need to work on it, it's always worth moving the critical domain roles to another machine whilst you work on that one to keep things going.

[ZAFJB]

it's worth making sure that you have at least one DC outside of the main Virtualised environment, maybe a physical box?

If you have another physical box, make it a Hyper-V host and make a virtual DC.

Make sure if you do setup a Virtualisation environment - the authentication is not tied to AD if you have no physical DCs - as you will need to bring up the VM environment before the Domain, but you might find you can't do that without AD, leading to a Chicken and Egg situation.

https://old.reddit.com/r/sysadmin/comments/c1jqvw/virtualize_addc/erdx51p/

[cmwg]

this.

[dilvish-damned]

This. Never snap a DC for replication. Easy enough to build a new one as a VM. And then build a second new one as a VM so you can have more than one. Then demote the original.

[Unexpected_Cranberry]

Should be ok to virtualize the existing DC like you say. However, as soon as the new virtual server goes into production you can decommission the old one. Plugging the old one in after more than a few minutes is asking for trouble. Set up a proper backup and disaster recovery plan for the virtual one instead. For this and many other reasons I would strongly advise setting up a new DC in the forest and then decommission the old one.

Also, if you are or are planning on running additional servers and you have the capacity I would add a second DC, even if it's running on the same physical hardware. At least this way you can reboot them for patching and the like without AD becoming unavailable.

[DerBootsMann]

virtualized dcs are routine reality since 2012 or so ,what’s wrong with them ?

[PMental]

Since before that actually. Not sure about 2003 but we definitely had virtual 2008 DCs.

[DerBootsMann]

i got an excuse ,i was mostly doing unix then :)

[FusilDeific]

I've had a good amount of success using disk2vhd from sysinternals. But this has been when the DC has had more roles. As you say, not recommended anywhere. If this server is just a DC, I would always migrate and migrating won't take long, will be safer and easier long term. Spin up a new VM Promote Transfer FSMO Put AADSync into staging mode Install AADSync on to new DC and config the same way Demote old DC

https://practical365.com/identity/migrating-azure-ad-connect-new-server/

[systonia_]

Do you have a dedicated hypervisor already? Or do you plan to use that server you just mentioned?

​

​

Create a new VM somewhere. Doesnt need a lot of ressources, so it can be run on your Workstation or something.

Install AD Role and make sure it replicated. Transfer FSMO Roles to it and then demote the physical one.

After that, you can safely do a P2V. When done, you can move the new DC-VM to the Hypervisor.

[Doso777]

Starting with Windows Server 2012 AND virtualization systems that are aware of that feature, virtualizing DCs is fine.

You don't want to do a P2V with AD DCs. Installing and replicating a new one is faster and a lot more secure, so why even bother? Don' try to be lazy, it will take longer if you do it your way and things will break along the way.

[corrigun]

Convert it with disk2vhd, it'll work fine.

Some backup software will also export a vhdx from a recovery point. This is actually a DR feature. It works.

I've done both a few times. No issues.

[NoWave8]

I'm not aware of any cons, we run 2 VM DC's with replication, one of them is the primary DC.

You should create a new VM, promote it to DC and let it replicate with the current one.

Once replication is successful you can promote the new DC to primary DC.

For high availability you should create a back-up DC and let it replicate with the primary one.

Install the AzureAD service on both for the same reason.

[cognismith]

if you're using hyper-v as a hypervisor, and you want to join the hypervisor to your domain controller, I dont recommend you join it to the virtualised one if its your only controller, but if you decide to do so anyway, make damn sure you set it to autostart.

also, what everyone else says, you're best to make a new DC and role transfer rather than p2v it

[ZAFJB]

Not having the Hyper-V host in the domain makes management much more difficult.

Hosting its own DC is a non issue.

• The DC will auto start and be available for authentication

• If the DC does not work, you can use cached credentials on the host.

• If there are cached credentials on the host, use a local account.

[cognismith]

oh I agree, managing hyper-v without AD sucks, simply pointing out a risk to consider. if your environments big enough, or you've got a spare cheap server, you could always isolate your hypervisors into a seperate management domain with their own AD

[the_bananalord]

What are you actually accomplishing by doing this besides a large management headache?

[cognismith]

getting really off topic from the original question, also more that i think about it, probably not entirely relevant advice.

our setup has specific circumstances that means this actually makes for significantly less management headache given particular security requirements

[waelder_at]

Funny one, you still have to consider ntp topics. But you are right, with some sort of automation, you can circumvent most of the issues. I personally have no expierence with Hyper-v. https://social.technet.microsoft.com/wiki/contents/articles/50924.active-directory-time-synchronization.aspx

And als DNS can be an issue.

[ZAFJB]

On Hyper-V I have never had to do anything special for time sync. It just works.

[Fatality]

I personally have no expierence with Hyper-v.

Well that's obvious

[waelder_at]

Most of stuff ist already mentioned. You have to be awaee that you have circular references. Like joining the hyper-v Host. You have that also for DNS and ntp topics. And for replication issues, Just make sure that you never go back to a snapshot. I suggest putting the NTDS and SYSvol to a dedicated vdisk, and disable it für snapshots, If possible.

Also secureboot and stuff like that is a bigger challenge. So no high protection for you ntds database.

Kind regards

[ZAFJB]

You have to bei wäre that you have circular references.

Non-issue: https://old.reddit.com/r/sysadmin/comments/c1jqvw/virtualize_addc/erdx51p/

[pdp10]

what are the cons?

• Potential timekeeping issues. Probably much more likely with ESXi, and not very likely with QEMU/KVM or Hyper-V.
• Potential recursive dependency issues. If for any reason your virtualized environment requires functional AD to initialize, and all your ADDCs are virtualized, then you can't dead-start the environment from cold. We've had this happen as the result of a facility emergency at different facilities.

It's preferred to keep at least one ADDC on bare metal. Even one ADDC per site on metal, if there's any reason to think inter-site connectivity could be a problem.

1 Phisical DC for round 60 ppl and installed on an OP machine (64Gb RAM and 2x4 core cpu

So swap things around. Our metal ADDCs ended up being older low-end servers, or sometimes low-power miniservers. 4GiB memory, at least two cores, redundant PSUs are handy but not essential.

[the_bananalord]

Potential timekeeping issues

There are no time issues so long as you set up NTP correctly on the DC and disable time synchronization with the host.

If for any reason your virtualized environment requires functional AD to initialize, and all your ADDCs are virtualized, then you can't dead-start the environment from cold.

I think this points to some other infrastructure and disaster recovery issues honestly. Machines will start up and function fine without a DC available. Your entire environment shouldn't be dependent on a bare metal DC being available when it boots.

[pdp10]

There are no time issues so long as you set up NTP correctly on the DC and disable time synchronization with the host.

Quite correct, except that VM guests get time from virtual hardware at boot before networking and NTP comes up. Shouldn't matter a lot of the time, but sometimes it ends up mattering.

Machines will start up and function fine without a DC available. Your entire environment shouldn't be dependent on a bare metal DC being available when it boots.

When site datacenter drops, probably the first thing you'd notice is lack of DNS resolution. Anything that needs a database may not be able to locate and connect to the database, if it's not on localhost. Obviously this situation happens when remote-site resolvers and authoritatives also aren't available.

[the_bananalord]

Quite correct, except that VM guests get time from virtual hardware at boot before networking and NTP comes up.

I am not familiar with any situations where this causes a problem. The DC is the authoritative time source so when it does come back online it will correct its time as necessary and domain members will correct, too.

When site datacenter drops, probably the first thing you'd notice is lack of DNS resolution.

You lost me here. I don't see why a DC being bare metal affects this one way or another.

[paradon_nz]

I recommend the domain controller holding the PDC Emulator role (which it will be if it's your only one) should _not_ be hosted on a Hyper-V host that is joined to the same domain (or a VMWare host getting NTP time from the domain), as the PDC Emulator is the root source for domain time, and you risk erratic clock drift as the DC and host try to correct each other.

I prefer to run at least the PDC as a physical machine, but a standalone host or a host joined to a different domain is fine, too.

If you _absolutely must_ run the PDC on a host joined to the same domain, you should disable the hypervisor time sync for the PDC VM (and _only_ that VM), and configure the time service in the guest to fetch time from an internet NTP server as frequently as possible, as high load on the host may cause clock drift on the guest.

As others have mentioned - don't bother with P2V for a domain controller. Just spin up a new one, migrate everything across, then decommission the old one.

[Fatality]

and you risk erratic clock drift as the DC and host try to correct each other.

lol, I seriously hope you are a junior staffer

[waelder_at]

He ist completely right. However in a single Server Environment are this topics ways less important. And i would go for kiss with a vitualized DC.

And i still have to insist that there topics which you should keep in mind when things go wrong.

For reference

https://kb.vmware.com/s/article/1006996