To avoid USN rollbacks in the test environment, all domain controllers that are to be migrated from physical machines to virtual machines must be taken offline. After the domain controllers are offline, no new updates should be introduced to the environment. The computers must remain offline during the P2V migration; none of the computers should be brought back online until all the computers have been fully migrated. For virtual machines that are configured as domain controllers, it is recommended that you disable time synchronization between the host system and guest operating system acting as a domain controller.
This enables your guest domain controller to synchronize time from the domain hierarchy. To disable the Hyper-V time synchronization provider, shut down the VM and clear the Time synchronization check box under Integration Services. This guidance has been recently updated to reflect the current recommendation to synchronize time for the guest domain controller from only the domain hierarchy, rather than the previous recommendation to partially disable time synchronization between the host system and guest domain controller.
To optimize the performance of the domain controller virtual machine and ensure durability of Active Directory writes, use the following recommendations for storing operating system, Active Directory, and VHD files:. Guest storage. Store the Active Directory database file Ntds.
FUA ensures that the operating system writes and reads data directly from the media bypassing any and all caching mechanisms. Host storage of VHD files. Recommendations: Host storage recommendations address storage of VHD files. For maximum performance, do not store VHD files on a disk that is used frequently by other services or applications, such as the system disk on which the host Windows operating system is installed.
The ideal configuration is to store each VHD file on a separate physical drive. The host physical disk system must also satisfy at least one of the following criteria to meet the requirements of virtualized workload data integrity:.
Fixed VHD versus pass-through disks. There are many ways to configure storage for virtual machines. Pass-through disks, which virtual machines can use to access physical storage media, are even more optimized for performance. Pass-through disks are essentially physical disks or logical unit numbers LUNs that are attached to a virtual machine.
Pass-through disks do not support the snapshot feature. Therefore, pass-through disks are the preferred hard disk configuration, because the use of snapshots with domain controllers is not recommended. Domain controllers that are running on virtual machines have operational restrictions that do not apply to domain controllers that are running on physical machines.
When you use a virtualized domain controller, there are some virtualization software features and practices that you should not use:. All these recommendations are made to help avoid the possibility of an update sequence number USN rollback. Backing up domain controllers is a critical requirement for any environment. Backups protect against data loss in the event of domain controller failure or administrative error.
If such an event occurs, it is necessary to roll back the system state of the domain controller to a point in time before the failure or error. The supported method of restoring a domain controller to a healthy state is to use an Active Directory—compatible backup application, such as Windows Server Backup, to restore a system state backup that originated from the current installation of the domain controller.
With virtual machine technology, certain requirements of Active Directory restore operations take on added significance. For example, if you restore a domain controller by using a copy of the virtual hard disk VHD file, you bypass the critical step of updating the database version of a domain controller after it has been restored. Replication will proceed with inappropriate tracking numbers, resulting in an inconsistent database among domain controller replicas.
In most cases, this problem goes undetected by the replication system and no errors are reported, despite inconsistencies between domain controllers. With Windows Server and newer Hyper-V hosts and guests, you can take supported backups of domain controllers using snapshots, guest VM export and import and also Hyper-V Replication. All of these however are not a good fit for creating a proper backup history, with the slight exception of guest VM export.
The shielded VM project mentioned previously has a Hyper-V host driven backup as a non-goal for maximum data protection of the guest VM. As mentioned, domain controllers that are running in virtual machines have restrictions that do not apply to domain controllers that are running in physical machines. When you back up or restore a virtual domain controller, there are certain virtualization software features and practices that you should not use:.
To restore a domain controller when it fails, you must regularly backup system state. System state includes Active Directory data and log files, the registry, the system volume SYSVOL folder , and various elements of the operating system. This requirement is the same for physical and virtual domain controllers. System state restore procedures that Active Directory—compatible backup applications perform are designed to ensure the consistency of local and replicated Active Directory databases after a restore process, including the notification to replication partners of invocation ID resets.
However, using virtual hosting environments and disk or operating system imaging applications makes it possible for administrators to bypass the checks and validations that ordinarily occur when domain controller system state is restore. When a domain controller virtual machine fails and an update sequence number USN rollback has not occurred, there are two supported situations for restoring the virtual machine:.
Use the process in the following illustration to determine the best way to restore your virtualized domain controller. If a valid system state backup exists for the domain controller virtual machine, you can safely restore the backup by following the restore procedure prescribed by the backup tool that you used to back up the VHD file.
To properly restore the domain controller, you must start it in DSRM. You must not allow the domain controller to start in normal mode. If you miss the opportunity to enter DSRM during system startup, turn off the domain controller's virtual machine before it can fully start in normal mode.
It is important to start the domain controller in DSRM because starting a domain controller in normal mode increments its USNs, even if the domain controller is disconnected from the network.
Start the domain controller's virtual machine, and press F5 to access the Windows Boot Manager screen. If you are required to enter connection credentials, immediately click the Pause button on the virtual machine so that it does not continue starting. This happened to me a few years ago at another job, and there was a complicated procedure I had to do, but don't remember, other than at the time thinking if only they had a physical DC there would have not been an issue.
I would say it depends on situation. But if we have hosts, and they all power off for some reason, first thing you need to bring up after power shows up is DC. But I rarely see people use that option in DRS. Few people mentioned that DC is not so important to be powered on first, but if we have vCenter Server with external SQL database that uses integrated Windows Authentication and we do have that situation in large environments , we need to have DC up and running for vCenter Server to start up properly.
And if we have distributed switch that stores its configuration in external database - that means no network connectivity in whole virtual environment until DC is up and running, SQL database is started and vCenter server is started.
Cached credentials - yes, maybe, if you pull out network cables from every port than you can login to windows with cached credentials. If there is network connectivity and no DC available you are going to get "no logon server available" error. As I said, there is no single correct answer. Few years back it was Microsoft recommendation to have atleast one physical DC, now I don't thing they specify that.
The only real reason to keep at least one physical DC would be if your hosts are domain joined, if they are not it doesn't matter. The difference is now all hypervisors can boot the VMs automatically after power failure. There is no domain controller dependency. If AD isn't up, you can login to hypervisor with local or cached credentials as a backup.
I hope I actually address all questions. Microsoft domain-joined computers unless manually configured otherwise cache logins. So DC unavailable shouldn't be a problem.
In addition, all the hypervisor's I've used have the option which for servers should always be enabled to automatically boot selected VM's at hypervisor boot time. So the DC should be up shortly after the hypervisor is.
With VMware, there is a local "root" account and additional accounts can be created for local login so access CAN be gotten without DC accessibility. Windows Hyper-V is an underlying Windows OS, regardless of configuration, and therefore can have local admin backup accounts for Hyper-V administration, if needed. There are ways around your proposed issues, with proper advanced configuration and knowledge on how things work.
Good point. Even the 8GB RAM of the cheapest Dell rack server you can get allows you to cache the Active Directory database for an organization with over , users. Running Domain Controllers on physical hardware equals wasting computer resources. Wasting compute resources means wasting money.
Does that mean you can virtualize all your Domain Controllers? Does that mean you can be as coarse with virtual Domain Controllers as you can be with physical Domain Controllers? Does that mean virtual Domain Controllers are as secure as physical Domain Controllers? Join me for the answers on these questions in the next parts of this series. This site uses Akismet to reduce spam. Learn how your comment data is processed. Also, continue regular system state backups, and always restore from a system state backup.
Practice the art of disaster recovery regularly. Finally, always go back and re-evaluate your strategies; monitor results for improvements and make adjustments when necessary.
There are several excellent reasons for virtualizing Windows Active Directory. Virtualization offers the advantages of hardware consolidation, total cost of ownership reduction, physical machine lifecycle management, mobility and affordable disaster recovery and business continuity solutions.
It also provides a convenient environment for test and development, as well as isolation and security. Skip to content. Products Products Overview. Technology Solutions Technology Solutions Overview.
0コメント