Virtualized Active Directory without Physical Domain Controller

Virtualizing entire Active Directory without Physical Domain Controller

As an Active Directory Administrator I would think like, Can we setup or create a 100% virtual Active Directory without Physical Domain Controllers? It mitigates the risk of virtualization platform malfunction that will affect entire Active Directory platform, is this correct? Will discuss Pros and Cons of Virtualizing Windows Active Directory Domain Controllers

Also Read: Can we Replace on-premise Domain Controller with Cloud-based Active Directory

 

Pros:

Cookie cutter solution: Easy to deploy a new branch, they could build everything that was needed consistently and quickly

DR – even without AD resource available the operations team could start the build/recovery of the 3 machines

One powerful box in a rack was plenty grunty enough and reduced hardware support costs

Very easy and flexible to manage – like assign more RAM/disks/CPUs

Some things we could troubleshoot quicker – like one DC had a non-paged pool leak, so in the vSphere console the ops team could collect the RAM consumption across the DCs quicker than I could individually and also report historically – a feature I didn’t have

Also Read: Active Directory on Cloud (Azure Active Directory)

Cons:

Due to PCI etc. – the team that could access the VMware console/iLo were separate to us AD DAs, so I was dead in the water for troubleshooting and at most I could request they could bounce the box – I could not get on the console or even access DSRM

Troubleshooting was possible but I had to work together with the infrastructure team for me to do the AD bits and for them to do the physical bits – we were in different time-zones too

VMware was quite out of date, so daily we would experience problems that would start along the lines of reports that “the new build was not working”, which then became “GPO is not working”, which then was found the local DC was un-responsive, which was then traced to an issue with vSphere – everything from the VMware tools hanging to some perf issue on the box. I exhausted many cycles proving it was not an AD problem – if I just had access to the console I’d have known quickly that it was a host issue. Well anyway after vSphere was updated to 5.5 the issues went away è so the learning from this was that monitoring and health of vSphere was important + having a vSphere resource on hand or some vSphere training for the AD guys was necessary + access to vSphere is important for supporting AD

Also Read: Windows 10 compatibility with Windows Server 2003

Misconfiguration; such as the VMware tools were used to set the time on the DCs and would often result in an incorrect clock at best and there were times that a DC had hung, I was told by the ops team that this was due to the VMware tools hanging – so a low level application, without even DA or Server Operator rights, was able to impact the DCs

Operations would not always understand that the DC should be treated like a physical DC in that it should be gracefully shut down – many times it was often hard powered off

Also Read: Windows Server 2016 Features

Backup was run via “CommVault” – during a post-mortem although I could see the ESENT/VSS services correctly stopping the database for a snapshot, it turns out the backups being taken were worthless. So again because another team was managing the backups and the AD team didn’t have any control over them, there was no one responsible for verifying the viability of the backups

Also Read: Windows Server Administrator Interview Questions and Answers

Recommendation:

Better to have couple of physical Domain Controllers to avoid any design issues, I would recommend to keep the AD roles on physical box which helps easy recovery

Also See: Active Directory real time issues and solutions