Microsoft - AZ-800: Administering Windows Server Hybrid Core Infrastructure

Sample Questions

• Sign in to SRV1 as User1.
• Establish a PowerShell remoting session from SRV1 to SRV2.
• From the remoting session, invoke a command that targets SRV3 and runs the command in the security context of User1.

Explanation:

The "second hop problem" refers to a situation like the following:

1. You are logged in to ServerA.
2. From ServerA, you start a remote PowerShell session to connect to ServerB.
3. A command you run on ServerB via your PowerShell Remoting session attempts to access a resource on ServerC.
4. Access to the resource on ServerC is denied, because the credentials you used to create the PowerShell Remoting session aren't passed from ServerB to ServerC.

Using resource-based Kerberos constrained delegation (introduced in Windows Server 2012), you configure credential delegation on the server object where resources reside. Regarding the example above, for ServerC to allow delegation from a PowerShell remoting session on ServerB, we must set the PrincipalsAllowedToDelegateToAccount parameter on ServerC to the computer object of ServerB.

Reference: Making the second hop in PowerShell Remoting

• Size: 512 GiB
• Free space: 260 GiB
• Encryption: SSE with PMK
• Storage type: Standard SSD

• Size: 512 GiB
• Free space: 45 GiB
• Storage type: Standard HDD
• Encryption: Platform-managed key

Explanation:

You can expand data disks without deallocating your VM. The host cache setting of your disk doesn't change whether or not you can expand a data disk without deallocating your VM.

This feature has the following limitations. 

If a Standard HDD, Standard SSD, or Premium SSD disk is 4 TiB or less, deallocate your VM and detach the disk before you expand it beyond 4 TiB. If one of those disk types is already greater than 4 TiB, you can expand it without deallocating the VM and detaching the disk.

• Is supported only for data disks.
• Isn't supported for shared disks.
• Must be installed and use one of the following options:
• The latest Azure CLI.
• The latest Azure PowerShell module.
• The Azure portal.
• An Azure Resource Manager template with an API version that's 2021-04-01 or newer.
• Isn't available on some classic VMs. Use this script to get a list of classic VM products that support expanding without downtime.

Reference: Expand virtual hard disks attached to a Windows virtual machine

Explanation:

The Core scheduler in Hyper-V is designed to maximize isolation between virtual machines (guests) and the host.

The hypervisor core scheduler is an alternative to the classic scheduler logic. The core scheduler is available starting with Windows Server 2016 and Windows 10 version 1607. The core scheduler offers a strong security boundary for guest workload isolation. It also reduces performance variability for workloads inside VMs that run on an SMT-enabled virtualization host. The core scheduler supports running both SMT and non-SMT VMs at the same time on the same SMT-enabled virtualization host.

The core scheduler:

• Uses the virtualization host's SMT topology.
• Optionally exposes SMT pairs to guest VMs.
• Schedules groups of guest virtual processors from the same VM onto groups of SMT logical processors.

This work happens symmetrically. If logical processors are in groups of two, virtual processors are scheduled in groups of two, and a core is never shared between VMs. When you schedule a virtual processor for a VM without SMT enabled, that virtual processor consumes the entire core when it runs. When you use the core scheduler:

• It creates a strong security boundary for guest workload isolation. Guest virtual processors can only run on underlying physical core pairs, reducing vulnerability to side-channel snooping attacks.
• It reduces variability in throughput.
• It can potentially reduce performance. If only one virtual processor in a group can run, only one of the instruction streams in the core launches. The other is left idle.
• The operating system (OS) and applications running in the guest VM can use SMT behavior and programming interfaces (APIs) to control and distribute work across SMT threads, just like they do with a physical machine.

As of Windows Server 2019, Hyper-V uses the core scheduler by default. In earlier versions like Windows Server 2016, the core scheduler is optional, and the classic scheduler is the default one.

Reference: Manage Hyper-V hypervisor scheduler types

Explanation:

File screens control the types of files that the user can store on a file server. You can limit the extension that can be stored on your shared files. For example, you can create a file screen that doesn't allow files with an MP3 extension to be stored in personal shared folders on a file server.

FSRM supports volumes formatted with the NTFS file system only. The Resilient File System (ReFS) and exFAT (successor to FAT32) aren't supported.

References:

File Server Resource Manager (FSRM) overview

Create a File Screen

Explanation:

A multi-master enabled database, such as the Active Directory, provides the flexibility of allowing changes to occur at any DC in the enterprise. But it also introduces the possibility of conflicts that can potentially lead to problems once the data is replicated to the rest of the enterprise.

To prevent conflicting updates in Windows, the Active Directory performs updates to certain objects in a single-master fashion. In a single-master model, only one DC in the entire directory is allowed to process updates.

Active Directory extends the single-master model found in earlier versions of Windows to include multiple roles, and the ability to transfer roles to any DC in the enterprise. Because an Active Directory role isn't bound to a single DC, it's referred to as an FSMO role. Currently in Windows there are five FSMO roles:

Three operations master roles exist in each domain:

• PDC Emulator
• RID Master
• Infrastructure Master

Two operations master roles are present at the forest level:

• Schema Master
• Domain Naming Master

The domain naming master FSMO role holder is the DC responsible for making changes to the forest-wide domain name space of the directory, that is, the Partitions\Configuration naming context or LDAP://CN=Partitions, CN=Configuration, DC=<domain>. This DC is the only one that can add or remove a domain from the directory. It can also add or remove cross references to domains in external directories. There is one domain naming master in the entire forest. 

The RID master FSMO role holder is the single DC responsible for processing RID Pool requests from all DCs within a given domain. It's also responsible for removing an object from its domain and putting it in another domain during an object move.

When a DC creates a security principal object, such as a user or group, it attaches a unique Security ID (SID) to the object. This SID consists of:

• A domain SID that's the same for all SIDs created in a domain.
• A relative ID (RID) that's unique for each security principal SID created in a domain.

Each Windows DC in a domain is allocated a pool of RIDs that it's allowed to assign to the security principals it creates. When a DC's allocated RID pool falls below a threshold, that DC issues a request for additional RIDs to the domain's RID master. The domain RID master responds to the request by retrieving RIDs from the domain's unallocated RID pool, and assigns them to the pool of the requesting DC. There's one RID master per domain in a directory.

References:

Active Directory FSMO roles in Windows

Flexible Single Master Operations roles in Active Directory Domain Services