To ensure that the target virtual machine in the virtual lab does not affect the source environment, the target lab network must be isolated. Two levels of isolation can be applied:
You can configure the IP subnet that is different from the source machine subnet. Please ensure that gateway doesn't provide connectivity to production subnet.
There are several options to isolate network on the infrastructure level, some of them are:
Configure the standalone target host that has the standard virtual switch dedicated to the virtual lab and is not connected to the uplink physical adapter. This means that all target virtual machines can talk to each other, but cannot connect to the physical network or to virtual machines on other hosts. A virtual machine also cannot connect to virtual machines connected to a different virtual switch on the same host.
Configure isolated Virtual Local Area Network (VLAN) with standard/distributed virtual switch. In this configuration, the virtual machine is isolated through VLAN ID settings. Distributed virtual switch with VLAN ID settings is the recommended option to support the DRS cluster feature.
Recommendations and considerations related to the DNS server:
Add a DNS server to your virtual test environment. Ensure your virtual test environment has a properly configured DNS server. Add a source DNS server computer to your virtual lab project at Step 2: Add source computers to virtual lab project, so that the Active Directory Virtual Lab creates a virtual machine for the DNS server in your test environment.
Initially, use one DNS server per domain that hosts its DNS zone. We recommend that in Step 3: Modify virtual machine creation settings you specify the same DNS server for all target virtual machines in that domain. This does not mean that you should not add multiple DNS servers to your virtual test environment. You can add them, but initially configure the target virtual machines to use only one of the added DNS servers. After you start your virtual test environment and Active Directory® replication completes then you can reconfigure the target virtual machines to use other DNS servers you have added.
AD and DNS may be interdependent at startup. In case with Active Directory-integrated DNS, you should consider the fact that Active Directory and DNS are interdependent at startup. That is, when you start virtual machines in the virtual test environment, Active Directory® waits for DNS to become available. In turn, DNS cannot start without Active Directory®. However, there’s a timeout programmed in Active Directory®, and after some time of waiting Active Directory® starts without DNS, and this will make DNS work too.
Invalid resource records in DNS. If DNS in the virtual test environment is the exact copy of the source DNS and you excluded some source computers from the virtual test environment, there may be left some invalid resource records in DNS referring to those excluded computers. To eliminate the invalid resource records from DNS, recreate the primary forward lookup zones in your virtual test environment. As for invalid resource records in the reverse lookup zones, you can recreate or delete these zones because they are not vital for Active Directory®.
To create virtual machines, the virtualization software supported by the Active Directory Virtual Lab needs to install its virtualization agent on the source computers.
Note |
If you work with Microsoft SCVMM 2012 R2, use the Disk2vhd utility instead of virtualization agent. For more details, see Working with SCVMM 2012 R2. |
If you use Microsoft SCVMM, it automatically removes its virtualization agent from the source computers after the virtualization completes. However, in case with VMware vCenter or ESX, the virtualization agent remains on the source computers after the virtualization. You can uninstall the agent manually by using a shortcut menu command on the source computers in the Active Directory Virtual Lab console.
To create virtual test environment using Microsoft SCVMM 2012 R2 or higher, you need to install the Disk2vhd utility on the source computers instead of virtualization agent using Active Directory Virtual Lab console. This tool creates Virtual Hard Disk (VHD) versions of physical disks.
Download Disk2vhd v2.02 here.
Unpack Disk2vhd.zip and save disk2vhd.exe to the folder of your choice on the computer where the Active Directory Virtual Lab console is installed.
Run the utility and accept the License Agreement.
In the Active Directory Virtual Lab console, select Tools | Configure and specify the path to the Disk2vhd utility.
Note |
Do not remove the Disk2vhd utility. Otherwise, the ADVL console cannot deploy the utility on the source machine. |
Forest Recovery Agent must be installed on the source computers. This is the same Forest Recovery Agent that is used by Recovery Manager for Active Directory to recover domain controllers. Forest Recovery Agent also plays a vital part in the virtual test environment creation. For example, it is used to clean up metadata, seize FSMO roles, and validate that guest OS tools are installed on the virtual machines created in the lab.
For this reason, before creating a virtual test environment, you need to ensure that each source computer has the current Forest Recovery Agent version installed. To do so, you can use the Active Directory Virtual Lab console.
When you click the Verify Settings button in Step 4: Verify virtual machine creation settings in Step-by-step instructions, the Active Directory Virtual Lab checks and displays the Forest Recovery Agent version installed on the source computers in your project. If the current version of the agent is not installed, the Active Directory Virtual Lab displays a warning. If you ignore this warning, the current agent version will be automatically installed on the source computers during the virtual test environment creation.
Alternatively, you can use the Active Directory Virtual Lab console to manually install or update the Forest Recovery Agent: just select the appropriate shortcut menu command on the source computers in the virtual lab project.
© 2024 Quest Software Inc. ALL RIGHTS RESERVED. Terms of Use Privacy Cookie Preference Center