The basic operating system setup will now already be based on a Zero-Touch installation, but we want to achieve more than this and will include some additional options.

Add the amd64_Microsoft-Windows-TerminalServices-LocalSessionManager component to Pass4 and configure it to enable Remote Desktop Access to the server:

<?xml version="1.0" encoding="UTF-8"?>
<component xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" language="neutral" versionScope="nonSxS" publicKeyToken="31bf3856ad364e35" processorArchitecture="amd64" name="Microsoft-Windows-TerminalServices-LocalSessionManager">
  <fDenyTSConnections>false</fDenyTSConnections>
</component>

To reach the Server via RDP via its designated IP address, we will also set the basic network settings. Keep in mind that based on your converged network setup for Hyper-V, these might be overwritten at a later step (Chapter 5, Network Best Practices).

Add the amd64_Microsoft-Windows-TCPIP component to Pass4 and configure a static IP Address—in this case, based on the name of the interface. This is also possible using the MAC address. Configure the network as shown in the following code:

<?xml version="1.0" encoding="UTF-8"?>
<component xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" language="neutral" versionScope="nonSxS" publicKeyToken="31bf3856ad364e35" processorArchitecture="amd64" name="Microsoft-Windows-TCPIP">
  <Interfaces>
    <Interface wcm:action="add">
      <Ipv4Settings>
        <DhcpEnabled>false</DhcpEnabled>
        <Metric>10</Metric>
        <RouterDiscoveryEnabled>true</RouterDiscoveryEnabled>
      </Ipv4Settings>
      <UnicastIpAddresses>
        <IpAddress wcm:action="add" wcm:keyValue="1">192.168.1.41/24</IpAddress>
      </UnicastIpAddresses>
      <Identifier>Local Area Connection</Identifier>
    </Interface>
  </Interfaces>
</component>

Whether Hyper-V hosts should be added to an Active Directory domain is a topic that is often discussed. Having seen a lot of Hyper-V environments, either domain-joined or workgroup-joined, my answer to this is a strong yes. Windows Server 2012 R2 Servers can boot up even clusters when domain-joined without an Active Directory domain controller available, so this chicken-or-egg problem from earlier Hyper-V versions is not a problem any more. Hyper-V will run without an Active Directory domain; however, very basic capabilities such as live migration won't be available on workgroup environments. Huge Hyper-V installations or high-security companies even leverage their own management domain to place their Hyper-V hosts into an Active Directory domain.

There is little security consideration standing against a huge management benefit, through credential management, group policies, and so on, so you should domain-join all Hyper-V hosts to your existing Active Directory domain. If your Hyper-V hosts will be placed in high-security environments, join them to a dedicated management domain (within a separated Active Directory forest) and not to your production domain.

Add the amd64_Microsoft-Windows-UnattendedJoin component to Pass4 and configure it to join an existing Active Directory domain:

<?xml version="1.0" encoding="UTF-8"?>
<component xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" language="neutral" versionScope="nonSxS" publicKeyToken="31bf3856ad364e35" processorArchitecture="amd64" name="Microsoft-Windows-UnattendedJoin">
  <Identification>
    <Credentials>
      <Domain>Elanity.local</Domain>
      <Password>Hannover96</Password>
      <Username>joindomain</Username>
    </Credentials>
    <JoinDomain>Elanity.de</JoinDomain>
    <MachineObjectOU>OU=Hyper-V,DC=Elanity,DC=local</MachineObjectOU>
  </Identification>
</component>

A typical configuration that is seen in this step is the disabling of the Windows Firewall. In my opinion, this is a bad practice. The Windows Firewall is a great layer of security and should be configured to your needs, but not disabled. For a central Firewall configuration, we'll use Group Policy settings, so we don't need to include any configuration in our unattended.xml.