PowerShell remoting

PowerShell remoting is the primary method you use to run PowerShell sessions on Windows Server VMs that have network connectivity. PowerShell remoting allows you to have an interactive PowerShell session where you are signed on locally to a remote Windows Server VM. The account used to make a connection to this remote VM needs to have local Administrator privileges on the target VM. PowerShell remoting is enabled by default on Windows Server, but also by default, it requires a connection from a private network.

You can enter a remote session to a Windows Server VM that is a member of the same Active Directory forest by using the following commands, which will prompt you for the credentials that you’ll use to connect to the remote computer:

Click here to view code image

$cred = Get-Credential
Enter-PSSession -computername <computername> -Credential $cred

You can enable PowerShell remoting using the Enable-PSRemoting cmdlet if it has been disabled. PowerShell remoting relies on WSMan (Web Server Management). WSMan uses port 5985 and can be configured to support TLS over port 5986.

To enable PowerShell remoting to VMs that are not domain-joined, you must configure the trusted hosts list on the client computer from which you want to establish the remote session. You do this on the client computer using the set-item cmdlet. For example, to trust the computer at IP address 192.168.3.200, run this command:

Click here to view code image

Set-Item wsman:localhostClientTrustedHosts -Value 192.168.3.200 -Concatenate

After you’ve run the command to configure the client, you’ll be able to establish a PowerShell remote session by using the Enter-PSSession cmdlet. If you want more information about remoting, you can run the following command to bring up help text on the subject:

Click here to view code image

Help about_Remote_faq -ShowWindow

PowerShell Direct

PowerShell Direct allows you to create a remote PowerShell session directly from a Hyper-V host to a virtual machine hosted on that Hyper-V host without requiring the VM to be configured with a network connection. PowerShell Direct requires that both the Hyper-V host and the VM be running Windows Server 2016 or later server or Windows 10 or later client operating systems.

To use PowerShell Direct, you must be signed in locally to the Hyper-V host with Hyper-V Administrator privileges. You also must have access to valid credentials for the virtual machine. If you don’t, you won’t be able to establish a PowerShell Direct connection.

To establish a PowerShell Direct connection, use this command:

Click here to view code image

Enter-PSSession -vmname NameOfVM

You exit the PowerShell Direct session by using the Exit-PSSession cmdlet.

HVC for Linux

HVC.exe, which is included with Windows Server 2019 and later and Windows 10 and later, allows you to make a remote SSH connection from a Hyper-V host to a Linux virtual machine guest without requiring the Linux VM to have a functioning network connection. It provides similar functionality to PowerShell Direct. For HVC.exe to work, you must ensure that the Linux VM has an updated kernel and that the Linux integration services are installed. You also need the SSH server on the Linux VM to be installed and configured before you’ll be able to use HVC.exe to initiate an SSH connection.

Nested virtualization dynamic memory

You won’t be able to adjust the memory of a virtual machine that is enabled for nested virtualization while that VM is running. Although it is possible to enable dynamic memory, the amount of memory allocated to a VM configured for nested virtualization will not fluctuate while the VM is running.

Nested virtualization networking

To route network packets through the multiple virtual switches required during nested virtualization, you can either enable MAC address spoofing or configure network address translation (NAT).

To enable MAC address spoofing on the virtual machine that you have configured for nested virtualization, run the following PowerShell command:

Click here to view code image

Get-VMNetworkAdapter -VMName NameOfVM | Set-VMNEtworkAdapter -MacAddressSpoofing On

To enable NAT, create a virtual NAT switch in the VM that has been enabled for nested virtualization by using the following PowerShell commands:

Click here to view code image

New-VMSwitch -name VMNAT -SwitchTypeInternal
New-NetNAT -Name LocalNAT -InternalIPInterfaceAddressPrefix "192.168.15.0/24"
Get-NetAdapter "vEthernet (VmNat)" | New-NetIPAddress -IPAddress 192.168.15.1
-AddressFamily IPv4 -PrefixLength 24

After you’ve done this, you need to manually assign IP addresses to VMs running under the VM enabled for nested virtualization, using the default gateway of 192.168.15.1. You can use a separate internal addressing scheme other than 192.168.15.0/24 by altering the appropriate PowerShell commands in the previous code.

Smart paging

Smart paging is a special technology in Hyper-V that functions in certain conditions when a VM is restarting. Smart paging uses a file on the disk to simulate memory to meet Startup Memory requirements when the Startup Memory setting exceeds the Minimum Memory setting. Startup Memory is the amount of memory allocated to the VM when it starts, but not when it is in a running state. For example, you could set Startup Memory to 2,048 MB and the Minimum Memory to 512 MB for a specific virtual machine. In a scenario where 1,024 MB of free memory was available on the virtualization host, smart paging would allow the VM to access the required 2,048 MB of memory.

Because smart paging uses disk to simulate memory, it’s only active if the following three conditions occur at the same time:

• The VM is being restarted.

• There is not enough memory on the virtualization host to meet the Startup Memory setting.

• Memory cannot be reclaimed from other VMs running on the same host.

Smart paging doesn’t allow a VM to perform a “cold start” if the required amount of Startup Memory is not available but the Minimum Memory amount is. Smart paging is used only when a VM that was already running restarts and those three conditions have been met.

You can configure the location of the smart paging file on a per-VM basis. By default, smart paging files are written to the C:ProgramDataMicrosoftWindowsHyper-V folder. The smart paging file is created only when needed and is deleted within 10 minutes of the VM restarting.

Hyper-V Replica

Hyper-V Replica provides a replica of a VM running on one Hyper-V host that can be stored and updated on another Hyper-V host. For example, you could configure a VM hosted on a Hyper-V failover cluster in Melbourne to be replicated through Hyper-V Replica to a Hyper-V failover cluster in Sydney. Hyper-V Replica allows for replication across site boundaries and does not require access to shared storage in the way that failover clustering does.

Hyper-V Replica is asynchronous. While the replica copy is consistent, it is a lagged copy with changes sent only as frequently as once every 30 seconds. Hyper-V Replica supports multiple recovery points, with a recovery snapshot taken every hour. (This incurs a resource penalty, so the setting is off by default.) This means that when activating the replica, you can choose to activate the most up-to-date copy or a lagged copy. You would choose to activate a lagged copy in the event that some form of corruption or change made the up-to-date copy problematic.

When you perform a planned failover from the primary host to the replica, you need to switch off the primary host. This ensures that the replica is in an up-to-date and consistent state. This is a drawback compared to failover or live migration, where the VM will remain available during the process. A series of checks are completed before performing planned failover to ensure that the VM is off, that reverse replication is allowed back to the original primary Hyper-V host, and that the state of the VM on the current replica is consistent with the state of the VM on the current primary. Performing a planned failover will start the replicated VM on the original replica, which will now become the new primary server.

Hyper-V Replica also supports unplanned failover. You perform an unplanned failover in the event that the original Hyper-V host has failed or the site that hosts the primary replica has become unavailable. When performing an unplanned failover, you can choose either the most recent recovery point or a previous recovery point. Performing unplanned failover will start the VM on the original replica, which will now become the new primary server.

Hyper-V extended replication allows you to create a second replica of the existing replica server. For example, you could configure Hyper-V replication between a Hyper-V virtualization host in Melbourne and Sydney, with Sydney hosting the replica. You could then configure an extended replica in Brisbane using the Sydney replica.

Hyper-V failover clusters

One of the most common uses for failover clustering is to host Hyper-V virtual machines. Hyper-V failover clusters allow VMs to move to another virtualization host in the event that the original experiences a disruption or when you need to rebalance the way that VMs across the cluster use Hyper-V host resources.

Hyper-V guest clusters

A guest cluster is a failover cluster that consists of two or more VMs as cluster nodes. You can run a guest cluster on a Hyper-V failover cluster, or you can run guest clusters with nodes on separate Hyper-V failover clusters. While deploying a guest cluster on Hyper-V failover clusters may seem as though it is taking redundancy to an extreme, there are good reasons to deploy guest clusters and Hyper-V failover clusters together:

• Failover clusters monitor the health of clustered roles to ensure that they are functioning. This means that a guest failover cluster can detect when the failure of a clustered role occurs and can take steps to recover the role. For example, say you deploy an SQL Server failover cluster as a guest cluster on a Hyper-V failover cluster. One of the SQL Server instances that participates in the guest cluster suffers a failure. In this scenario, failover occurs within the guest cluster, and another instance of SQL Server hosted on the other guest cluster node continues to service client requests.

• Deploying guest and Hyper-V failover clusters together allows you to move applications to other guest cluster nodes while you are performing servicing tasks. For example, you may need to apply software updates that require a restart to the operating system that hosts an SQL Server instance. If this SQL Server instance is participating in a Hyper-V guest cluster, you could move the clustered role to another node, apply software updates to the original node, perform the restart, and then move the clustered SQL Server role back to the original node.

• Deploying guest and Hyper-V failover clusters together allows you to live migrate guest cluster VMs from one host cluster to another host cluster while ensuring clients retain connectivity to clustered applications. For example, suppose a two-node guest cluster hosting SQL Server is hosted on one Hyper-V failover cluster in your organization’s datacenter. You want to move the guest cluster from its current host Hyper-V failover cluster to a new Hyper-V failover cluster. By migrating one guest cluster node at a time from the original Hyper-V failover cluster to the new Hyper-V failover cluster, you’ll be able to continue to service client requests without interruption, failing over SQL Server to the guest node on the new Hyper-V failover cluster after the first node completes its migration and before migrating the second node across.

Hyper-V live migration

Live migration is the process of moving an operational VM from one physical virtualization host to another with no interruption to VM clients or users. Live migration is supported between cluster nodes that share storage between separate Hyper-V virtualization hosts that are not participating in a failover cluster using an SMB 3.0 file share as storage; live migration is even supported between separate Hyper-V hosts that are not participating in a failover cluster using a process called “shared nothing live migration.”

Live migration has the following prerequisites:

• There must be two or more servers running Hyper-V that use processors from the same manufacturer (for example, all Hyper-V virtualization hosts configured with Intel processors or all Hyper-V virtualization hosts configured with AMD processors).

• Hyper-V virtualization hosts need to be members of the same domain, or they must be members of domains that have a trust relationship with each other.

• VMs must be configured to use virtual hard disks or virtual Fibre Channel disks; pass-through disks are not allowed.

It is possible to perform live migration with VMs configured with pass-through disks under the following conditions:

• VMs are hosted on a Windows Server Hyper-V failover cluster.

• Live migration will be within nodes that participate in the same Hyper-V failover cluster.

• VM configuration files are stored on a Cluster Shared Volume.

• The physical disk that is used as a pass-through disk is configured as a storage disk resource that is controlled by the failover cluster. This disk must be configured as a dependent resource for the highly available VM.

If performing a live migration using shared storage, the following conditions must be met:

• The SMB 3.0 share needs to be configured so that the source and the destination virtualization host’s computer accounts have read and write permissions.

• All VM files (virtual hard disks, configuration files, and snapshot files) must be located on the SMB 3.0 share. You can use storage migration to move VM files to an SMB 3.0 share while the VM is running before performing a live migration using this method.

You must configure the source and destination Hyper-V virtualization hosts to support live migrations by enabling live migrations in the Hyper-V settings. When you do this, you specify the maximum number of simultaneous live migrations and the networks that you will use for live migration. Microsoft recommends using an isolated network for live migration traffic, though this is not a requirement.

The next step in configuring live migration is choosing which authentication protocol and live migration performance options to use. You select these in the Advanced Features area of the Live Migrations settings. The default authentication protocol is CredSSP (Credential Security Support Provider). CredSSP requires local sign-in to both the source and the destination Hyper-V virtualization host to perform live migration. Kerberos allows you to trigger live migration remotely. To use Kerberos, you must configure the computer accounts for each Hyper-V virtualization host with constrained delegation for the CIFS (Common internet File System) and Microsoft Virtual System Migration Service services, granting permissions to the virtualization hosts that will participate in the live migration partnership. The performance options allow you to speed up live migration. Compression increases processor utilization. SMB will use SMB Direct if both the network adapters used for the live migration process support remote direct memory access (RDMA) and RDMA capabilities are enabled.

Fixed-sized disks

Virtual hard disks can be dynamic, differencing, or fixed. When you create a fixed-size disk, all space used by the disk is allocated on the hosting volume at the time of creation. Fixed disks increase performance if the physical storage medium does not support Windows Offloaded Data Transfer (ODX). Improvements in Windows Server reduce the performance benefit of fixed-size disks when the storage medium supports ODX. The space to be allocated to the disk must be present on the host volume when you create the disk. For example, you can’t create a 3 TB fixed disk on a volume that has only 2 TB of space.

Dynamically expanding disks

A dynamically expanding disk uses a small file initially and then grows as the VM allocates data to the virtual hard disk. This means you can create a 3 TB dynamic virtual hard disk on a 2 TB volume because the entire 3 TB will not be allocated at disk creation. However, in this scenario, you would need to ensure that you extend the size of the 2 TB volume before the dynamic virtual disk outgrows the available storage space.

Differencing disks

Differencing disks are a special type of virtual hard disk that has a child relationship with a parent hard disk. Parent disks can be fixed size or dynamic virtual hard disks, but the differencing disk must be the same type as the parent disk. For example, you can create a differencing disk in VHDX format for a parent disk that uses VHDX format, but you cannot create a differencing disk in VHD format for a parent disk in VHDX format.

Differencing disks record the changes that would otherwise be made to the parent hard disk by the VM. For example, differencing disks are used to record Hyper-V VM checkpoints. One parent virtual hard disk can have multiple differencing disks associated with it.

For example, you can create a specially prepared parent virtual hard disk by installing Windows Server on a VM by running the sysprep utility within the VM and then shutting the VM down. You can use the virtual hard disk created by this process as a parent virtual hard disk. In this scenario, when you create new Windows Server VMs, you would configure the VMs to use a new differencing disk that uses the sysprepped virtual hard disk as a parent. When you run the new VM, it will write any changes that it would normally make to the full virtual hard disk to the differencing disk. In this scenario, deploying new Windows Server VMs becomes a simple matter of creating new VMs that use a differencing disk that uses the sysprepped Windows Server virtual hard disk as a parent.

You can create differencing hard disks using the New Virtual Hard Disk Wizard or the New-VHD Windows PowerShell cmdlet. You must specify the parent disk during the creation process.

The key to using differencing disks is to ensure that you don’t make changes to the parent disk; doing so will invalidate the relationship with any child disks. Generally, differencing disks can provide storage efficiencies because the only changes are recorded on child disks. For example, rather than storing 10 different instances of Windows Server 2022 in its entirety, you could create one parent disk and have 10 much smaller differencing disks to accomplish the same objective. If you store VM virtual hard disks on a volume that has been deduplicated, these efficiencies are reduced.

Modifying virtual hard disks

You can perform the following tasks to modify existing virtual hard disks:

• Convert a virtual hard disk in VHD format to VHDX format.

• Convert a virtual hard disk in VHDX format to VHD format.

• Change the disk from fixed size to dynamically expanding or from dynamically expanding to fixed size.

• Shrink or enlarge the virtual hard disk.

You convert virtual hard disk type (VHD to VHDX, VHDX to VHD, dynamic to fixed, or fixed to dynamic) by using the Edit Virtual Hard Disk Wizard or by using the Convert-VHD PowerShell cmdlet. When converting from VHDX to VHD, remember that virtual hard disks in VHD format cannot exceed 2,040 GB in size. So, while it is possible to convert virtual hard disks in VHDX format that are smaller than 2,040 GB to VHD format, you will not be able to convert virtual hard disks that are larger than 2,040 GB.

You can only perform conversions from one format to another and from one type to another while the VM is powered off. You must shrink the virtual hard disk using the disk manager in the VM operating system before shrinking the virtual hard disk using the Edit Virtual Hard Disk Wizard or the Resize-VHD cmdlet. You can resize a virtual hard disk while the VM is running under the following conditions:

• The virtualization host is running Windows Server 2012 R2 or later.

• The virtual hard disk is in VHDX format.

• The virtual hard disk is attached to a virtual SCSI controller.

• The virtual hard disk must have been shrunk. You must shrink the virtual hard disk using the disk manager in the host operating system before shrinking the virtual hard disk using the Edit Virtual Hard Disk Wizard or the Resize-VHD cmdlet.

Pass-through disks

Pass-through disks, also known as directly attached disks, allow a VM to directly access the underlying storage rather than accessing a virtual hard disk that resides on that storage. For example, with Hyper-V you normally connect a VM to a virtual hard disk file hosted on a volume formatted with NTFS or ReFS. With pass-through disks, the VM instead accesses the disk directly, and there is no virtual hard disk file.

Pass-through disks allow VMs to access larger volumes than are possible when using virtual hard disks in VHD format. In earlier versions of Hyper-V—such as the version available with Windows Server 2008—pass-through disks provide performance advantages over virtual hard disks. The need for pass-through disks has diminished with the availability of virtual hard disks in VHDX format because that format allows you to create much larger volumes.

Pass-through disks can be directly attached to the virtualization host, or they can be attached to Fibre Channel or iSCSI disks. When adding a pass-through disk, you will need to ensure that the disk is offline. You can use the Disk Management console or the diskpart.exe utility on the virtualization host to set a disk to be offline.

To add a pass-through disk using PowerShell, use the Get-Disk cmdlet to get the properties of the disk that you want to add as a pass-through disk. Next, pipe the result to the Add-VMHardDiskDrive cmdlet. For example, to add physical disk 3 to the VM named Alpha-Test, execute the following command:

Click here to view code image

Get-Disk 3 | Add-VMHardDiskDrive -VMName Alpha-Test

A VM that uses pass-through disks will not support VM checkpoints. Pass-through disks also cannot be backed up with backup programs that use the Hyper-V VSS writer.

Virtual Fibre Channel adapters

Virtual Fibre Channel allows you to make direct connections from VMs running on Hyper-V to Fibre Channel storage. If the following requirements are met, Virtual Fibre Channel is supported on Windows Server 2016 and later:

• The computer functioning as the Hyper-V virtualization host must have a Fibre Channel host bus adapter (HBA) that has a driver that supports Virtual Fibre Channel.

• SAN must be NPIV (N_Port ID) enabled.

• The VM must be running a supported version of the guest operating system.

• Virtual Fibre Channel LUNs cannot be used to boot Hyper-V VMs.

VMs running on Hyper-V support up to four virtual Fibre Channel adapters, each of which can be associated with a separate storage area network (SAN). Before you can use a Virtual Fibre Channel adapter, you will need to create at least one virtual SAN on the Hyper-V virtualization host. A virtual SAN is a group of physical Fibre Channel ports that connect to the same SAN. VM live migration and VM failover clusters are supported; however, virtual Fibre Channel does not support VM checkpoints, host-based backup, or live migration of SAN data.

Storage QoS

Storage Quality of Service (QoS) allows you to limit the maximum number of IOPS (input/output operations per second) for virtual hard disks. IOPS are measured in 8 KB increments. If you specify a maximum IOPS value, the virtual hard disk will be unable to exceed this value. You use Storage QoS to ensure that no single workload on a Hyper-V virtualization host consumes a disproportionate amount of storage resources.

It’s also possible to specify a minimum IOPS value for each virtual hard disk. You would do this if you wanted to be notified that a specific virtual hard disk’s IOPS has fallen below a threshold value. When the number of IOPS falls below the specified minimum, an event is written to the event log. You configure Storage QoS on a per-virtual hard disk basis.

Hyper-V storage optimization

Several technologies built into Windows Server allow you to optimize the performance and data storage requirements for files associated with VMs.

Storage migration

With storage migration, you can move a VM’s virtual hard disk files, checkpoint files, smart paging files, and configuration files from one location to another. You can perform storage migration while the VM is either running or powered off. You can move data to any location that is accessible to the Hyper-V host. This allows you to move data from one volume to another, from one folder to another, or even to an SMB 3.0 file share on another computer. When performing storage migration, choose the Move the VM’s Storage option.

For example, you could use storage migration to move VM files from one Cluster Share Volume to another on a Hyper-V failover cluster without interrupting the VM’s operation. You have the option of moving all data to a single location, moving VM data to separate locations, or moving only the VM’s virtual hard disk. To move the VM’s data to different locations, select the items you want to move and the destination locations.

Exporting, importing, and copying VMs

A VM export creates a duplicate of a VM that you can import on the same or a different Hyper-V virtualization host. When performing an export, you can choose to export the VM, which includes all its VM checkpoints, or you can choose to export just a single VM checkpoint. Windows Server 2012 R2 and later support exporting a running VM. With Hyper-V in Windows Server 2012, Windows Server 2008 R2, and Windows Server 2008, it is necessary to shut down the VM before performing an export.

Exporting a VM with all of its checkpoints will create multiple differencing disks. When you import a VM that was exported with checkpoints, these checkpoints will also be imported. If you import a VM that was running at the time of export, the VM is placed in a saved state. You can resume from this saved state, rather than having to restart the VM.

When importing a VM, you can choose from the following options:

• Register The Virtual Machine In Place (Use The Existing ID) Use this option when you want to import the VM while keeping the VM files in their current locations. Because this method uses the existing VM ID, you can only use it if the original VM on which the export was created is not present on the host to which you wish to import the VM.

• Restore The Virtual Machine (Use The Existing Unique ID) Use this option when you want to import the VM while moving the files to a new location; for example, you would choose this option if you are importing a VM that was exported to a network share. Because this method also uses the existing VM ID, you can only use it if the original VM on which the export was created is not present on the host to which you wish to import the VM.

• Copy The Virtual Machine (Create A New Unique ID) Use this method if you want to create a separate clone of the exported VM. The exported files will be copied to a new location, leaving the original exported files unaltered. A new VM ID is created, meaning that the cloned VM can run concurrently on the same virtualization host as the original progenitor VM. When importing a cloned VM onto the same virtualization host as the original progenitor VM, ensure that you rename the newly imported VM; otherwise you may confuse the VMs.

Virtual machine MAC addresses

By default, VMs running on Hyper-V hosts use dynamic MAC addresses. Each time a VM is powered on, it will be assigned a MAC address from a MAC address pool. You can configure the properties of the MAC address pool through the MAC Address Range settings available through Virtual Switch Manager.

When you deploy operating systems on physical hardware, you can use two methods to ensure that the computer is always assigned the same IP address configuration. The first method is to assign a static IP address from within the virtualized operating system. The second is to configure a DHCP reservation that always assigns the same IP address configuration to the MAC address associated with the physical computer’s network adapter.

This won’t work with Hyper-V VMs in their default configuration because the MAC address may change if you power the VM off and then on. Rather than configure a static IP address using the VM’s operating system, you can instead configure a static MAC address on a per-virtual network adapter basis. This will ensure that a VM’s virtual network adapter retains the same MAC address whether the VM is restarted or even if the VM is migrated to another virtualization host.

To configure a static MAC address on a per-network adapter basis, edit the network adapter’s advanced features. When entering a static MAC address, you will need to select a MAC address manually. You shouldn’t use one from the existing MAC address pool because there is no way for the current virtualization hosts or other virtualization hosts on the same subnet to check whether a MAC address that is to be assigned dynamically has already been assigned statically.

Network isolation

Hyper-V supports VLAN (virtual local area network) tagging at both the network adapter and the virtual switch levels. VLAN tags allow the isolation of traffic for hosts connected to the same network by creating separate broadcast domains. Enterprise hardware switches also support VLANs as a way of partitioning network traffic. To use VLANs with Hyper-V, the virtualization hosts’ network adapter must support VLANs. A VLAN ID has 12 bits, which means you can configure 4,095 VLAN IDs.

You configure VLAN tags at the virtual network adapter level by selecting Enable Virtual LAN Identification in the Virtual Network Adapter Properties dialog box. VLAN tags applied at the virtual switch level override VLAN tags applied at the virtual network adapter level. To configure VLAN tags at the virtual switch level, select the Enable Virtual LAN Identification For Management Operating System option and specify the VLAN identifier.

Optimizing network performance

You can optimize network performance for VMs hosted on Hyper-V in a number of ways. For example, you can configure the virtualization host with separate network adapters connected to separate subnets. You do this to separate network traffic related to the management of the Hyper-V virtualization host from network traffic associated with hosted VMs. You can also use NIC teaming on the Hyper-V virtualization host to provide increased and fault-tolerant network connectivity. You’ll learn more about NIC teaming later in this chapter in the section “Configure NIC teaming.”

External switches

An external switch connects to a physical or wireless network adapter. Only one virtual switch can be mapped to a specific physical or wireless network adapter or NIC team. For example, if a virtualization host had four physical network adapters configured as two separate NIC teams, you could configure two external virtual switches. If a virtualization host had three physical network adapters that did not participate in any NIC teams, you could configure three external virtual switches. VMs connected to the same external switch can communicate with each other as well as external hosts connected to the network to which the network adapter mapped to the external switch is connected. For example, if an external switch is connected to a network adapter that is connected to a network that can route traffic to the internet, a VM connected to that external virtual switch will also be able to connect to hosts on the internet. When you create an external switch, a virtual network adapter that maps to this switch is created on the virtualization host unless you clear the option that allows the management operating system to share the network adapter. If you clear this option, the virtualization host will not be able to communicate through the network adapter associated with the external switch.

Internal switches

An internal switch allows communication between the VM and the virtualization host. All VMs connected to the same internal switch are able to communicate with each other and the virtualization host. For example, you could successfully initiate an RDP connection from the virtualization host to an appropriately configured VM or use the Test-NetConnection PowerShell cmdlet from a PowerShell prompt on the virtualization host to get a response from a VM connected to an internal network connection. VMs connected to an internal switch are unable to use that virtual switch to communicate with hosts on a separate virtualization host that are connected to an internal switch with the same name.

Private switches

VMs connected to the same private switch on a VM host can communicate with one another, but they cannot communicate directly with the virtualization host. Private switches only allow communication between VMs on the same virtualization host. For example, say VM alpha and beta are connected to private switch p_switch_a on virtualization host h_v_one. VM gamma is connected to private switch p_switch_a on virtualization host h_v_ two. VMs alpha and beta will be able to communicate with each other, but they won’t be able to communicate with h_v_one or VM gamma.

Process isolation

Process isolation mode provides a container with process and namespace isolation. Containers running in this isolation mode share a kernel with all other containers running on the container host. This is similar to the manner in which containers run on Linux container hosts. Process isolation is the default mode used when running a container. If you want to ensure that the container is being used, start the container using the --isolation=process option.

Hyper-V isolation

A container running in Hyper-V isolation mode runs in a highly optimized virtual machine that also provides an isolated application execution environment. Hyper-V isolation mode containers don’t share the kernel with the container host, nor do they share the kernel with other containers on the same container host. You can only use Hyper-V isolation mode containers if you have enabled the Hyper-V role on the container host. If the container host is a Hyper-V virtual machine, you must enable nested virtualization. By default, a container uses the process isolation mode. You can start a container in Hyper-V isolation mode by using the --isolation=hyperv option.

For example, to create a Hyper-V container from the microsoft/windowsservercore image, issue this command:

Click here to view code image

Docker run -it --isolation=hyperv mcr.microsoft.com/windows/servercore cmd

Installing and configuring Docker

Containers on Windows Server are managed using the Docker engine. The advantage here is that the command syntax of Docker on Windows is almost identical to the command-line tools in Docker on Linux. Although there is a community-maintained PowerShell module for managing containers on Windows Server available on GitHub, PowerShell is not the primary tool for Windows Server container management, and very few people use PowerShell to manage containers.

For Windows Server administrators unfamiliar with Docker syntax, the commands include extensive help support. Typing Docker at the command prompt will provide an overview of the high-level Docker functionality. You can learn more about specific commands by using the --help command parameter. For example, the following command will provide information about the Docker Image command:

docker image --help

Install-Module -Name DockerMsftProvider -Repository PSGallery -Force

Install-Package -Name docker -ProviderName DockerMsftProvider

Install-Package -Name docker -ProviderName DockerMsftProvider

Stop-Service docker

{
    "hosts": ["tcp://0.0.0.0:2701"]
}

{
    "authorization-plugins": [],
    "dns": [],
    "dns-opts": [],
    "dns-search": [],
    "exec-opts": [],
    "storage-driver": "",
    "storage-opts": [],
    "labels": [],
    "log-driver": "",
    "mtu": 0,
    "pidfile": "",

    "cluster-store": "",
    "cluster-advertise": "",
    "debug": true,
    "hosts": [],
    "log-level": "",
    "tlsverify": true,
    "tlscacert": "",
    "tlscert": "",
    "tlskey": "",
    "group": "",
    "default-ulimits": {},
    "bridge": "",
    "fixed-cidr": "",
    "raw-logs": false,
    "registry-mirrors": [],
    "insecure-registries": [],
    "disable-legacy-registry": false
}

Start-Service docker

Service accounts for Windows containers

Although containers based on the Server Core and Nano Server operating systems have most of the same characteristics as a virtual machine or a bare-metal deployment of the Server Core or Nano Server versions of Windows Server, one thing that you can’t do with containers is to join them to a domain. This is because containers are supposed to be temporary, rather than permanent, and domain-joining them would clog up Active Directory with unnecessary computer accounts.

While containers can’t be domain-joined, it is possible to use a group-managed service account (gMSA) to provide one or more containers with a domain identity similar to that used by a device that is realm-joined. Performing this task requires downloading the Windows Server Container Tools and ensuring that the container host is a member of the domain that hosts the gMSA. When you perform this procedure, the container’s LocalSystem and Network Service accounts use the gMSA. This gives the container the identity represented by the gMSA.

To configure gMSA association with a container, perform the following steps:

1. Ensure that the Windows Server container host is domain-joined.

2. Add the container host to a specially created domain security group. This domain security group can have any name.

3. Create a gMSA and grant gMSA permission to the specially created domain security group of which the container host is a member.

4. Install the gMSA on the container host.

5. Use the New-CredentialSpec cmdlet on the container host to generate the gMSA credentials in a file in JSON format. This cmdlet is located in the CredentialSpec PowerShell module, which is available as a part of the Windows Server Container Tools. For example, if you created a gMSA named MelbourneAlpha, you would run the following command:

   Click here to view code image

   New-CredentialSpace -Name MelbourneAlpha -AccountName MelbourneAlpha

6. You can verify that the credentials have been saved in JSON format by running the Get-CredentialSpec cmdlet. By default, credentials are stored in the c:ProgramDataDockerCredentialSpecs folder.

7. Start the container using the option --security-opt "credentialspec=" and specify the JSON file containing the credentials associated with the gMSA. For example, run the following command if the credentials are stored in the file twt_webapp01.json:

   Click here to view code image

   docker run --security-opt "credentialspec=file://twt_webapp01.json" --hostname
   webapp01 -it
   
   mcr.microsoft.com/windows/servercore:ltsc2019 powershell

Once you’ve configured the container to indirectly use the gMSA for its Local System and Network Service accounts, you can give the container permission to access domain resources by providing access to the gMSA. For example, if you want to provide the container with access to the contents of a file share hosted on a domain member, you can configure permissions so that the gMSA has access to the file share.

Updating images

One of the concepts that many IT operations personnel find challenging is that you don’t update a container that is deployed in production. Instead, you create a fresh container from the original container image, update that container, and then save that updated container as a new container image. You then remove the container in production and deploy a new container to production that is based on the newly updated image.

For example, suppose you have a container that hosts a web app deployed from a container image named WebApp1 that is deployed in production. The developers in your organization release an update to WebApp1 that involves changing some existing settings. Rather than modifying the container in production, you start another container from the WebApp1 image, modify the settings, and then create a new container image named WebApp2. You then deploy a new container into production from the WebApp2 container image and remove the original container (that hasn’t been updated).

Although you can manually update your container base OS images by applying software updates, Microsoft releases updated versions of the container base images each time a new software update is released. After a new container OS base image is released, you or your organization’s developers should update existing images that are dependent on the container OS base image. Regularly updated container base OS images provide an excellent reason for eventually moving toward using Dockerfiles to automate the process of building containers. If you have a Dockerfile configured for each container image used in your organization, updating your container base OS images when a new container base OS image is released is a quick, painless, and automated process.

Managing container images

To save a Docker image for transfer to another computer, use the docker save command. When you save a Docker image, you save it in TAR format. For example, to export the container image tailwind_app to the c:archive folder, issue this command:

Click here to view code image

docker save tailwind_app -o c:archive	ailwind_app.tar

You can load a Docker image from a saved image using the docker load command. For example, to load the container image from the c:archive ailwind_app.tar file created earlier, use this command:

Click here to view code image

docker load < c:archive	ailwind_app.tar

When you have multiple container images that have the same name, you can remove an image by using the image ID. You can determine the image ID by running the command docker images. You can also use Windows Admin Center to view this information. You can’t remove a container image until the last container instance created from that image either directly or indirectly has been deleted.

You then remove the image by using the command docker rmi with the image ID. For example, to remove the container image with the ID a896e5590871, use this command:

Click here to view code image

docker rmi a896e5590871

You can also remove a container image by selecting the image in the list of containers in Windows Admin Center and selecting Delete.

While you can transfer container images between hosts by exporting and importing them as TAR files, the usual way to distribute container images is to use a container registry. A container registry is a service that allows you to store and distribute container images. Public registries are available for anyone to interact with, and private registries allow you to limit access to authorized individuals.

Before uploading (also termed pushing) an image to a registry, it’s necessary to tag the container image with the fully qualified name of the registry login server. For example, to tag the image tailwind-app when you are using the Azure Container Registry instance twt-registry.azurecr.io, run the command

Click here to view code image

docker tag tailwind-app twt-registry.azurecr.io/tailwind-app

You upload a container image to a container registry using the docker push command. For example, to upload a container image named tailwind-app to registry twt-registry.azurecr.io, use the command

Click here to view code image

docker push twt-registry.azurecr.io /tailwind-app

Starting a container

You create a new container instance by using the docker run command and specifying the container image that will form the basis of the container. You can start a container instance by selecting a container image that is present locally or by specifying a container image that is stored in a registry. For example, to start a container from the Microsoft/windowsserver core image stored in the Microsoft container image registry, run this command:

Click here to view code image

docker run mcr.microsoft.com/windows/servercore:ltsc2022

You can start a container and run an interactive session either by specifying cmd.exe or PowerShell.exe by using the -it option with docker run. Interactive sessions allow you to directly interact with the container through the command line from the moment the container starts. Detached mode starts a container, but it doesn’t start an interactive session with that container.

For example, to start a container from the Microsoft/windowsservercore image and to enter an interactive PowerShell session within that container once it’s started, use this command:

Click here to view code image

docker run -it mcr.microsoft.com/windows/servercore:ltsc2022 powershell.exe

If you want to start an interactive session on a container that you started in detached mode, use the command docker exec -i <containername> powershell.exe.

By default, containers use network address translation. This means that if you are running an application or service on the container that you want to expose to the network, you’ll need to configure port mapping between the container host’s network interface and the container. For example, if you wanted to start a container in detached mode, mapping port 8080 on the container host to port 80 on the container, you would run the following command:

Click here to view code image

docker run -d -p 8080:80 mcr.microsoft.com/windows/servercore:ltsc2022

You can verify which containers are running by using the docker ps command or by using Windows Admin Center. The problem with the simple docker ps command option is that this will only show you the running containers and won’t show you any that are in a stopped state. You can see which containers are on a container host, including containers that aren’t currently running, by using the docker ps -a command. If you have loaded the Containers extension into Windows Admin Center, you can also view the containers that are on a Windows Server container host using Windows Admin Center. In some cases, it will be necessary to start a stopped container. You can start a stopped container using the docker start <containername> command.

One thing that you’ll notice about containers is that they appear to be assigned random names, such as sarcastic_hedgehog, fraggle_advocate, dyspeptic_hamster, and sententious_muppet. Docker assigns random names rather than asking you for one because containers are a more ephemeral type of application host than a VM; because they are likely to only have a short life span, it isn’t worth assigning any name to them that you’d need to remember. The reason for the structure of the random names is that they are easy to remember in the short term, which makes containers that you must interact with on a short-term basis easier to address than when using hexadecimal container IDs.

Modifying a running container

After you have a container running, you can enter the container and make the modifications that you want to make to ensure that the application the container hosts will run correctly. This might involve creating directories, using the dism.exe command to add roles, or using the wget PowerShell alias to download and install binaries such as Java. For example, the following code, when run from inside a container, downloads and installs an older version of Java into a container based on the Server Core base OS container:

Click here to view code image

wget -Uri "http://javadl.sun.com/webapps/download/AutoDL?BundleId=107944" -outfile javaInstall.exe -UseBasicParsing
REG ADD HKLMSoftwarePoliciesMicrosoftWindowsInstaller /v DisableRollback /t REG_DWORD /d 1 | Out-Null ./javaInstall.exe /s INSTALLDIR=C:Java REBOOT=Disable | Out-Null

Once you are finished modifying the container, you can type Exit to exit the container. A container must be in a shutdown state before you can capture it as a container image. You use the docker stop <containername> cmdlet to shut down a container.

NAT

Network address translation (NAT) allows each container to be assigned an address in a private address space, whereas connecting to the container host’s network uses the container host’s IP address. The default NAT address range for containers is 172.16.0.0 /16. In the event that the container host’s IP address is in the 172.16.0.0 /12 range, you will need to alter the NAT IP prefix.

You can also allow connections to custom NAT networks when a container is run by allowing use of the --network parameter and specifying the custom NAT network name. To do so, you need to have the bridge: none option specified in the daemon.json file. The command to run a container and join it to the CustomNat network created earlier is:

Click here to view code image

docker run -it --network=CustomNat <ContainerImage> <cmd>

Port mappings allow ports on the container host to be mapped to ports on the container. For example, to map port 8080 on the container host to port 80 on a new container created from the windowsservercore image and to run powershell.exe interactively on the container, create the container using the following command:

Click here to view code image

docker run -it -p 8080:80 microsoft/windowsservercore powershell.exe

Port mappings must be specified when the container is created or when it is in a stopped state. You can specify them using the -p parameter or the EXPOSE command in a Dockerfile when using the -P parameter. If you do not specify a port on the container host but you do specify one on the container itself, a random port will be assigned. For example, run this command:

Click here to view code image

docker run -itd -p 80 mcr.microsoft.com/windows/servercore/windowsservercore: ltsc2022
powershell.exe

A random port on the container host can be mapped to port 80 on the container. You can determine which port is randomly assigned by using the docker ps command. When you configure port mapping, firewall rules on the container host will be created automatically that will allow traffic through.

Transparent

Transparent networks allow each container endpoint to connect to the same network as the container host. You can use the transparent networking mode by creating a container network that has the driver name transparent. The driver name is specified with the -d option, as shown in this command:

Click here to view code image

docker network create -d transparent TransparentNetworkName

If the container host is a virtual machine running on a Hyper-V host and you want to use DHCP for IP address assignment, it’s necessary to enable MACAddressSpoofing on the VM network adapter. The transparent networking mode supports IPv6. If you are using transparent network mode, you can use a DHCPv6 server to assign IPv6 addresses to containers.

If you want to manually assign IP addresses to containers, when you create the transparent network you must specify the subnet and gateway parameters. These network properties must match the network settings of the network to which the container host is connected.

For example, if your container host is connected to a network that uses the 192.168.30.0/24 network and uses 192.168.30.1 as the default gateway, you would create a transparent network that will allow static address assignment for containers on the network called TransNet by running this command:

Click here to view code image

docker network create -d transparent --subnet=192.168.30.0/24 --gateway=192.168.30.1
TransNet

Once the transparent network is created with the appropriate settings, you can specify an IP address for a container by using the --ip option. For example, to start a new container from the microsoft/windowsservercore image, enter the command prompt within the container. To assign it the IP address 192.168.30.101 on the TransNet network, run this command:

Click here to view code image

docker run -it --network:TransNet --ip 192.168.30.101 microsoft/windowsservercore cmd.
exe

As when you use transparent network, containers are connected directly to the container host’s network; you don’t need to configure port mapping into the container.

Layer 2 Bridge

Layer 2 Bridge (L2 Bridge) networks are similar to transparent networks in that they allow containers to have IP addresses on the same subnets as the container host. They differ in that IP addresses must be assigned statically. This is because all containers on the container host that use an L2 Bridge network have the same MAC address.

When creating an L2 Bridge network, you must specify the network type as l2bridge. You must also specify subnet and default gateway settings that match the subnet and default gateway settings of the container host. For example, to create an L2 Bridge network named L2BridgeNet for the IP address range 192.168.88.0/24 and with the default gateway address 192.168.88.1, use the following command:

Click here to view code image

docker network create -d l2bridge -subnet=192.168.88.0/24 --gateway=192.168.88.1
L2BridgeNet

Creating a new image from a container

Once the container is in the desired state and shut down, you can capture the container to a new container image. You do this using the docker commit <container_name> <new_image_name> command. For example, to commit the container image elegant_wombat to the image name tailwind_app, run this command:

Click here to view code image

docker commit elegant_wombat tailwind_app

After you have committed a container to a container image, you can remove the container using the docker rm command. For example, to remove the elegant_wombat container, issue this command:

Click here to view code image

docker rm elegant_wombat

Using Dockerfiles

Dockerfiles are text files that allow you to automate the process of creating new container images. You use a Dockerfile with the docker build command to automate container creation, which is very useful when you need to create new container images from regularly updated base OS container images.

Dockerfiles have the elements shown in Table 3-1.

For example, the following Dockerfile will create a new container from the mcr.microsoft.com/windows/servercore:ltsc2022 image, create a directory named ExampleDirectory, and then install the iis-webserver feature:

Click here to view code image

FROM mcr.microsoftcom/windows/servercore:ltsc2022
RUN mkdir ExampleDirectory
RUN dism.exe /online /enable-feature /all /featurename:iis-webserver /NoRestart

To create a container image named example_image, change into the directory that hosts the Dockerfile (no extension) file, and run the following command:

Click here to view code image

docker build -t example_image .

Shared disks

Shared disks are a managed disk functionality that you can use to attach a single Azure managed disk to multiple IaaS VMs simultaneously. Shared disks allow you to create guest clusters from Azure IaaS VMs where the shared disk functions as shared storage. The functionality of Azure shared managed disks is conceptually similar to the functionality of shared virtual hard disks used with guest clusters on Hyper-V. Only ultra disks, premium SSDs, and standard SSDs can be configured as shared disks for IaaS VMs.

Disk images and snapshots

Managed disks support images and snapshots. An image of an IaaS VM can be created from a generalized IaaS VM (on Windows Server you would use sysprep.exe to perform the generalization operation) only when that IaaS VM has been deallocated. IaaS VM images include all disks attached to the IaaS VM and can be used to create new IaaS VMs.

Snapshots are point-in-time copies of an IaaS VM virtual hard disk. Snapshots can be used as a point-in-time backup or as a copy of the virtual machine for troubleshooting scenarios. Snapshots can be created of OS and data disks. You should only take snapshots of shutdown IaaS VMs to ensure that data is consistent across the disk since managed disk snapshots do not use Volume Shadow Copy services to ensure point-in-time consistency. Unlike disk images, the IaaS VM does not need to be deallocated for you to take a snapshot. Snapshots exist only at a per-disk level, which means that you shouldn’t use them in any situation where data is striped across multiple disks. You can create snapshots of an operating system disk and create a new IaaS VM from that snapshot.

IaaS VM encryption

Beyond storage service encryption, you can configure BitLocker disk encryption for Windows Server IaaS VMs. To support IaaS VM disk encryption, the Windows Server IaaS VM must be able to do the following. (By default, IaaS VMs do meet these conditions unless you remove the default network security group rules.)

• The server must be able to connect to the key vault endpoint so that the Windows Server IaaS VM can store and retrieve encryption keys.

• The server must be able to connect to an Azure Active Directory endpoint at login.microsoftonline.com so that it can retrieve a token that allows it to connect to the key vault that holds the encryption keys.

• The server must be able to connect to an Azure storage endpoint that hosts the Azure extension repository and the Azure storage account that stores the VM’s virtual hard disks.

• If the Windows Server IaaS VM is domain-joined, do not configure BitLocker-related Group Policies other than the Configure User Storage Of BitLocker Recovery Information: Allow 256-Bit Recovery Key policy. This policy is usually configured automatically during the encryption process, and the encryption process will fail if a Group Policy conflict in any TPM- or BitLocker-related policies exists.

Connecting with an Azure AD Account

When you deploy an IaaS VM, you usually configure a username and password for a local Administrator account. If the computer is standalone and not AD DS or Azure AD DS joined, you have to decide whether you want to limit access to the accounts that are present that you have configured on the IaaS VM itself or if you also want to allow local sign-on using Azure AD accounts.

Sign-on using Azure AD is supported for IaaS VMs running Windows Server 2019 and Windows Server 2022. The IaaS VMs need to be configured on a virtual network that allows access to the following endpoints over TCP port 443:

• https://enterpriseregistration.windows.net—For device registration

• http://169.254.169.254—Azure Instance Metadata Service endpoint

• https://login.microsoftonline.com—For authentication flows

• https://pas.windows.net—For Azure RBAC flows

You can enable Azure AD logon for a Windows Server IaaS VM when creating the IaaS VM using the Azure portal or when creating an IaaS VM using Azure Cloud Shell. When you do this, the AADLoginForWindows extension is enabled on the IaaS VM. If you have an existing VM Windows Server IaaS VM, you can use the following Azure CLI command to install and configure the AADLoginForWindows extension (where ResourceGroupName and VMName are unique to your deployment):

Click here to view code image

Az vm extension set --publisher Microsoft.Azure.ActiveDirectory --name
AADLoginForWindows --resource-group ResourceGroupName --vm-name VMName

Once the IaaS VM has the AADLoginForWindows extension configured and enabled, you can determine what permissions the Azure AD user account has on the IaaS VM by adding them to the following Azure roles:

• Virtual Machine Administrator Login Accounts assigned this role are able to sign on to the IaaS VM with local administrator privileges.

• Virtual Machine User Login Accounts assigned this role are able to sign on to the VM with regular user privileges.

Remote PowerShell

You can initiate a remote PowerShell session from hosts on the internet. Another option is to run a Cloud Shell session in a browser and perform PowerShell remote administration in this manner. Cloud Shell is a browser-based CLI and a lot simpler to use than adding the Azure CLI to your local computer. There is a Cloud Shell icon on the top panel of the Azure console.

You can enable Remote PowerShell on an Azure IaaS Windows VM by performing the following steps from Cloud Shell:

1. Ensure that Cloud Shell has PowerShell enabled by running the pwsh command.

2. At the PowerShell prompt in Cloud Shell, type the following command to enter local Administrator credentials for the Azure IaaS Windows VM:

   $cred=get-credential

3. At the PowerShell prompt in Cloud Shell, type the following command to enable PowerShell remoting on the Windows Server IaaS VM, where the VM name is 2022-IO-A and the resource group that hosts the VM is 2022-IO-RG:

   Click here to view code image

   Enable-AzVMPSRemoting -Name 2022-IO-A -ResourceGroupName 2022-IO-RG -Protocol
   https -OSType Windows

4. Once this command has completed executing, you can use the Enter-AzVM cmdlet to establish a remote PowerShell session. For example, run this command to connect to the IaaS VM named 2022-IO-A in resource group 2022-IO-RG:

   Click here to view code image

   Enter-AzVM -name 2022-IO-A -ResourceGroupName 2019-22-RG -Credential $cred

Azure Bastion

Azure Bastion allows you to establish an RDP session to a Windows Server IaaS VM through a standards-compliant browser such as Microsoft Edge or Google Chrome rather than having to use a remote desktop client. You can think of Azure Bastion as “jumpbox as a service” because it allows access to IaaS VMs that do not have a public IP address. Before the release of Azure Bastion, the only way to gain access to an IaaS VM that didn’t have a public IP address was either through a VPN to the virtual network that hosted the VM or by deploying a jumpbox VM with a public IP address from which you then created a secondary connection to the target VM. If you have configured an SSH server on the IaaS VM, Bastion also supports creating SSH connections to Linux IaaS VMs or Windows Server configured with the SSH server service.

Prior to deploying Azure Bastion, you need to create a special subnet named AzureBastion-Subnet on the virtual network that hosts your IaaS VMs. Once you deploy Azure Bastion, the service will manage the network security group configuration to allow you to successfully make connections.

Just-in-Time VM access

Rather than have management ports, such as the port used for Remote Desktop Protocol, TCP port 3389, open to hosts on the internet all the time, Just-in-Time (JIT) VM access allows you to open a specific management port for a limited duration of time and only open that port to a small range of IP addresses. You only need to use JIT if you require management port access to an Azure IaaS VM from a host on the internet. If the IaaS VM only has a private IP address or you can get by using a browser-based RDP session, then Azure Bastion is likely a better option. JIT also allows an organization to log on that has requested access, so you can figure out exactly which member of your team was the one who signed in and messed things up, which led to you writing up a report about the service outage. JIT VM access requires that you use the Azure Security Center, although doing so incurs an extra monthly cost per IaaS VM. Keep that in mind if you are thinking about configuring JIT.

Windows Admin Center in Azure Portal

Windows Admin Center, available in the Azure portal, allows you to manage Windows Server IaaS VMs. When you deploy Windows Admin Center in the Azure portal, WAC will be deployed on each Azure IaaS VM that you wish to manage. Once this is done, you can navigate directly to an Azure portal blade containing the WAC interface instead of loading Windows Admin Center up directly on your administrative workstation or jumpbox server.

Azure Serial Console

Azure Serial Console allows you to access a text-based console to interact with IaaS VMs through the Azure Portal. The serial connections connect to the COM1 serial port of the Windows Server IaaS VM and allow access independent of the network or operating system state. This functionality replicates the Emergency Management Services (EMS) access that you can configure for Windows Server, which you are most likely to use in the event that an error has occurred that doesn’t allow you to access the contents of the server using traditional administrative methods.

You can use the Serial Console for an IaaS VM as long as the following prerequisites have been met:

• Boot diagnostics are enabled for the IaaS VM.

• The Azure account accessing the Serial Console is assigned the Virtual Machine Contributor role for the IaaS VM and the boot diagnostics storage account.

• A local user account is present on the IaaS VM that supports password authentication.

IaaS virtual networks

Azure IaaS VMs can only use virtual networks that are in the same location as the IaaS virtual machine. For example, if you are deploying an IaaS VM to Australia South East, you’ll only be able to connect the IaaS VM directly to a virtual network in Australia South East.

Once you have deployed the virtual network, you can configure the following properties for the virtual network using the Azure console:

• Address Space This property allows you to add additional address spaces to the Azure virtual network. You partition these address spaces using subnets.

• Connected Devices This property lists the current devices that are connected to the Azure virtual network. The property includes a list of VM network adapters and the internal IP address to which those adapters are assigned.

• Subnets This property shows subnets that you create within the address space and allows you to put different Azure virtual machines on separate subnets within the same virtual network.

• DNS Servers This property allows you to configure the IP address of the DNS servers assigned by the DHCP server used by the Azure virtual network. Use this to configure DNS settings when you deploy a domain controller on an Azure IaaS VM or when you deploy Azure AD DS for an Azure virtual network.

• Properties This property allows you to change which subscription the Azure virtual network is associated with.

• Locks This setting allows you to apply configuration locks, which block changes being made to the settings of the resource unless the lock is first removed.

• Automation Script This setting allows you to access the JSON template file that you can use to reproduce and redeploy virtual networks with similar settings.

By default, hosts that are located on one subnet in a virtual network will automatically be able to communicate with other subnets on a virtual network. You can modify this behavior by configuring user-defined routes, network security groups, Azure Firewall, or network virtual appliances, which allow you to configure the subnets within a virtual network in a manner similar to the way you might segment traffic on an on-premises network.

IP addressing

A virtual machine on an Azure network will have an internally assigned IP address in the range specified by the virtual network it is associated with. You can configure this assignment to be static or dynamic. It is important to remember that you assign an IP address as dynamic or static on the network adapter object within Azure—you don’t manage IP address configuration from within the IaaS virtual machine operating system.

You may also assign a public IP address to the IaaS VM, but you should only do this in the event that the VM needs to be directly accessible to hosts on the internet. An IaaS VM with an internally assigned IP address can perform outbound communication to hosts on the internet without a public IP address, so a public address is necessary only if hosts on the internet need to directly communicate with the IaaS VM.

Even VMs that do need to be accessible to hosts on the internet can avoid having a public IP address if they are sitting behind a load balancer, web application, or network virtual appliance. A network virtual appliance (NVA) is similar to a traditional perimeter firewall or application gateway device and mediates traffic flow to a web application or VM running in the cloud.

You can determine which IP addresses are assigned to an Azure virtual machine on the Network Interfaces blade of the IaaS VM’s properties. You can also use this blade to apply a region-specific DNS name to the network interface so that you can connect to the IaaS VM using a fully qualified domain name (FQDN) rather than an IP address. If you have a DNS server or you have configured an Azure DNS zone, you can then create a CNAME record that points to the region-specific DNS name for future connections. This saves you from always connecting to a cloudapp.azure.com address, and by using a CNAME, the FQDN will also remain pointing to the IaaS VM if the IaaS VM changes IP address.

Network security groups

A network security group (NSG) is a packet filter for mediating traffic at the virtual network subnet level and also at the level of an IaaS VM’s network adapter. When you create a virtual machine, an NSG is automatically applied to the IaaS VM’s network adapter interface, and you can choose whether you want to allow traffic on management ports, such as TCP port 3389 and to the IaaS VM.

An NSG rule has the following elements:

• Priority NSG rules are processed in order, with lower numbers processed before higher ones. The moment traffic meets the conditions of a rule, that rule is enforced, and no further rules are processed.

• Source Specifies the source address or subnet of traffic. Can also include a service tag, which allows you to specify a particular Azure service or an application security group (a way of identifying the network identity of a series of workloads that make up an application).

• Destination Specifies the destination address or subnet of traffic. Can also include a service tag, which allows you to specify a particular Azure service or an application security group.

• Protocol Can be configured to TCP, UDP, ICMP, or Any.

• Port Range Allows you to specify either an individual port or a range of ports.

• Direction Specifies whether the rule applies to inbound or outbound traffic.

• Action Allows you to specify whether you want to allow or deny the traffic.

Network security groups are fairly basic in that they only work on the basis of IP address information and cannot be configured on the basis of an FQDN. Azure offers more advanced ways of mediating traffic flow, including Azure Firewall and network virtual appliances, which can be used in conjunction with NSGs; however, these topics are beyond the scope of the AZ-800 exam.

VPNs and IaaS virtual networks

You can configure IaaS virtual networks to support VPN connections by configuring a VPN gateway. IaaS virtual network VPN gateways support site-to-site connections. A site-to-site connection allows you to connect an IaaS virtual network to an existing network, just as you might connect a branch office network to a head office network in your on-premises environment. IaaS virtual network VPN gateways also support point-to-site VPN connections. This allows you to connect individual host computers to IaaS virtual networks. Windows Server 2022 includes simplified setup of a point-to-site VPN connection through deployment of Azure Network Adapter, covered in more detail in Chapter 4, “Implement and manage an on-premises and hybrid networking infrastructure.”