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

Sample Questions

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

Explanation:

There is a one-way forest trust in which the contoso.com forest trusts the adatum.com forest. Forest trusts are transitive. Members of the adatum.com and the west.adatum.com domain can be assigned permissions for resources in the contoso.com domain but members of the contoso.com domain can't be assigned permissions for the resources in the adatum.com and the west.adatum.com domain.

The adatum.com domain and the west.adatum.com have the default parent-child trust established. All domain trusts in an on-premises AD DS forest are two-way, transitive trusts. When a new child domain is created, a two-way, transitive trust is automatically created between the new child domain and the parent domain.

The members of Group2 (adatum.com) can be assigned permissons for the resources on Server2 (west.adatum.com), but not Group2 itself. Group2 is a domain local group and visible only in the adatum.com domain. A domain local group can be granted permissions only within the same domain where the group was created.

Group3 (west.adatum.com) is a global group. Group1 is a domain local group in the contoso.com domain. Since contoso.com trusts west.adatum.com, we can add Group3 as a member to Group1. A global group can be granted permissions on any domain in the same forest, or trusting domains or forests.

Group4 is a universal group in the contoso.com domain. Server1 is located in the adatum.com domain. Since adatum.com does not trust contoso.com, Group4 cannot be assigned permissions for the resources on Server1.

References:

How trust relationships work for forests in Active Directory

Active Directory security groups

Explanation:

An RODC makes it possible for organizations to easily deploy a domain controller in scenarios where physical security cannot be guaranteed, such as branch office locations, or in scenarios where local storage of all domain passwords is considered a primary threat, such as in an extranet or in an application-facing role.

Organizations that can guarantee the physical security of a branch domain controller might also deploy an RODC because of its reduced management requirements that are provided by such features as unidirectional replication.

Because RODC administration can be delegated to a domain user or security group, an RODC is well suited for a site that should not have a user who is a member of the Domain Admins group.

To promote a server to a Read-Only Domain Controller (RODC) when the RODC account is pre-created, the following accounts can perform the installation:

• A delegated user (the one assigned "Allowed to install RODC" on the pre-created computer account)
• Domain Admins in the target domain
• Enterprise Admins in the target forest

References:

Read-Only Domain Controllers Step-by-Step Guide

Steps for Deploying an RODC

Explanation:

A domain controller that runs your application or service cannot be cloned until the application or service is either:

• Added to the CustomDCCloneAllowList.xml file by using the Get-ADDCCloningExcludedApplicationList Windows PowerShell cmdlet

-Or-

• Removed from the domain controller

The first time the user runs the Get-ADDCCloningExcludedApplicationList cmdlet, it returns a list of services and applications that are running on the domain controller but are not in the default list of services and applications that are supported for cloning. By default, your service or application will not be listed. To add your service or application to the list of applications and services that can be safely cloned, the user runs Get-ADDCCloningExcludedApplicationList cmdlet again with the -GenerateXML option in order to add it to the CustomDCCloneAllowList.xml file. 

The DcCloneConfig.xml file is required for cloning Domain controllers. Its contents allow you to specify unique details like the new computer name and IP address.

Both, the CustomDCCloneAllowList.xml file and the DcCloneConfig.xml must be saved in the DSA Working Directory, which is %systemroot%\ntds by default. 

References:

Virtualized Domain Controller Cloning Test Guidance for Application Vendors

Virtualized Domain Controller Deployment and Configuration