AZ-800 Administering Windows Server Hybrid Core Infrastructure Questions and Answers

Disk1 (three-way mirror): 2 disks; Disk2 (parity): 1 disk

\In the Administering Windows Server Hybrid Core Infrastructure materials on Storage Spaces resiliency, Microsoft describes how each resiliency type determines simultaneous disk-failure tolerance. The guide explains that mirror spaces keep multiple copies of data: “Two-way mirror writes two copies and can sustain a single disk failure; three-way mirror writes three copies and can sustain the loss of any two disks without data loss.” It also differentiates parity spaces, which stripe data with parity information: “Parity provides capacity efficiency comparable to RAID-5 and tolerates a single disk failure (use dual parity to withstand two failures).”

Applying these to SSPace1:

Disk1 uses a three-way mirror across eight physical disks. By definition, a three-way mirror survives two concurrent disk failures and remains online, satisfying the “always available” requirement.

Disk2 is configured as parity across twelve physical disks. Standard parity (single parity) is equivalent to RAID-5 and survives one disk failure; only dual parity would allow two, but the configuration provided specifies parity (not dual parity).

Therefore, the maximum simultaneous physical disk failures while maintaining availability are 2 for Disk1 and 1 for Disk2.

In the Windows Server Hybrid Core Infrastructure objectives for Active Directory group design, group scope and type determine valid membership and usage. The study guidance for group scopes states that a Domain Local group is used to assign permissions in its own domain and “can contain accounts, computer objects, global groups from any domain, and universal groups; it can also contain other domain local groups from the same domain only.” Security-type restrictions also apply: “Security groups can contain only security principals; distribution groups cannot be nested into security groups for access control.”

Applying these rules to Group3 (contoso.com Domain Local Security): it can accept security groups of compatible scopes. From the lists, Group1 (contoso.com Universal Security) and Group2 (contoso.com Global Security) are valid. Distribution groups (Group4, Group5, Group6) are not valid members of a security group used for authorization. Therefore, Group3 ⇒ Group1 and Group2 only.

For Group5 (canada.contoso.com Global Distribution), the scope rule for Global groups is: “Global groups can include user accounts and other global groups from the same domain only; they cannot include universal or domain local groups.” Hence, the only eligible group from the same domain and scope is Group4 (canada.contoso.com Global Distribution). Group6 is domain local (invalid), and cross-domain globals (Group2) are not permitted. Therefore, Group5 ⇒ Group4 only.

No

Yes

Yes

In Administering Windows Server Hybrid Core Infrastructure, Microsoft states that the domain password policy for domain user accounts is determined by the GPO that wins at the domain root (commonly the Default Domain Policy). GPOs linked to OUs do not change the domain password policy for user accounts in those OUs; they only affect local accounts on computers within those OUs unless Fine-Grained Password Policies (PSOs) are used and scoped to users/groups. The case shows Default Domain Policy in contoso.com sets Minimum password length = 10. Therefore, both Admin1 (a domain user in Contoso\OU1) and User1 (in Contoso\OU3) fall under the 10-character minimum; the OU-linked GPO1 (14) does not override the domain password policy for their domain accounts → Admin1: No, User1: Yes.

For member servers and local accounts, the documentation explains that password policy settings in a GPO linked to the OU containing the computer apply to that computer’s local Security Accounts Manager (SAM). In the scenario, Server1 resides in Member Servers and GPO2 linked to Member Servers specifies Minimum password length = 8. Thus, when Admin1 creates a local account on Server1, the enforced minimum is 8 characters → Yes. This approach follows least privilege and standard precedence: domain-level for domain accounts, OU-linked GPOs for local accounts, unless PSOs are explicitly defined.

The AZ-800 content covering Active Directory Sites and Services clarifies that site, subnet, and site-link objects live in the Configuration partition. The guides emphasize that administration of the Configuration naming context is restricted to Enterprise Admins and to Domain Admins of the forest-root domain. In the context of changing replication topology parameters—such as editing the replication schedule on site links—the documentation notes: “Only Enterprise Admins or administrators in the forest-root Domain Admins group have default permissions to modify site and site-link objects,” because these objects affect replication forest-wide.

Applying this to the scenario:

Contoso\Admin1 (Enterprise Admins) has forest-wide rights to modify site links.

Contoso\Admin2 (Domain Admins in contoso.com, the forest-root domain) also has the required rights to change site-link schedules.

Canada\Admin3 (Domain Admins in canada.contoso.com) does not have default permissions in the Configuration partition for forest-wide site-link administration.

Thus, to meet the technical requirement to change all site links to a 30-minute schedule, the users who can perform the task are Admin1 and Admin2.

In the AZ-800 “Administering Windows Server Hybrid Core Infrastructure” objectives for Active Directory, server promotion is governed by forest/domain administrative roles. The materials state that promoting a member server to a domain controller in a given domain requires membership in either the Enterprise Admins group or the Domain Admins group of the target domain. The Configuration and Domain naming contexts that DCPromo touches (NTDS settings, SYSVOL/DFS-R readiness, DC computer account, and associated service SPNs) are protected so that “Enterprise Admins have full rights forest-wide, and Domain Admins have full rights within their respective domain.”

In this case, the requirement is to promote Server1 to a domain controller in canada.contoso.com. From the identities table:

Contoso\Admin1 is a member of Enterprise Admins (forest-wide authority).

Canada\Admin3 is a member of Canada\Domain Admins (authority within canada.contoso.com).

Contoso\Admin2 is Domain Admins (contoso.com) only, which does not grant administrative authority in the canada.contoso.com child domain.

Therefore, the users who can currently perform the required task for Server1 are Admin1 and Admin3.

Server1 - Set-Item

Server4 - Enable-PSRemoting

In the Windows Server exam materials for Administering Windows Server Hybrid Core Infrastructure (AZ-800), Microsoft documents that Data Deduplication is supported only on data volumes and specifically on NTFS-formatted volumes, and it cannot be enabled on the system or boot volume. The study text states: “Data Deduplication is applied at the volume level and supports NTFS data volumes. You cannot enable deduplication on the system or boot volume.” It further clarifies unsupported targets: “ReFS volumes and FAT/exFAT volumes are not supported for Data Deduplication in general-purpose server scenarios,” and emphasizes that deduplication is “not available for the operating system volume.”

Applying these rules to VM3:

C: NTFS but it is the OS/system volume → not eligible.

D: NTFS data volume → eligible.

E: ReFS → not supported for general-purpose dedup in this context.

F: exFAT → not supported.

Therefore, the only volume on which you can enable Data Deduplication to meet the requirement is volume D.

In Windows Server AD DS, group scope determines which groups/accounts can be members. The AZ-800 study materials summarize: “Domain Local groups can include accounts, Global groups, and Universal groups from any domain and Domain Local groups from the same domain only. Global groups can include accounts and other Global groups from the same domain only. Universal groups can include *accounts, Global groups, and Universal groups from any domain.” In addition, distribution vs. security does not change the scope membership rules; it only affects whether the group can be assigned permissions.

Applying the rules: Group3 is a Domain Local security group in contoso.com. Therefore it can contain Universal (Group1), Global from any domain (Group2 in contoso.com and Group4/Group5 in canada.contoso.com), but cannot contain a Domain Local from another domain (Group6 in canada.contoso.com). Hence: Group1, Group2, Group4, and Group5 only.

Group5 is a Global distribution group in canada.contoso.com. A Global group can only contain accounts or Global groups from the same domain. From the list, only Group4 (Global distribution, canada.contoso.com) fits. It cannot contain Group1 (Universal), Group2 (Global but different domain), or Group6 (Domain Local). Therefore: Group4 only.

The Administering Windows Server Hybrid Core Infrastructure materials explain that Azure AD Password Protection for on-premises AD uses two components: the DC agent and the proxy service. The DC agent is installed on every domain controller because it “intercepts password set/change operations locally on the DC and evaluates them against the forbidden-password policy.” The guidance further states that to ensure consistent enforcement “the DC agent should be deployed to all DCs in the forest, since password changes may occur on any DC.” The proxy service is installed on member servers (not necessarily DCs) and “relays policy downloads and telemetry to Azure AD on behalf of DCs,” which satisfies environments where “domain controllers must not directly contact Internet endpoints.” Finally, configuration of the global and custom banned password lists is performed in Azure AD, where administrators “define tenant-wide custom banned terms; DCs obtain the policy via the proxy and cache it for local enforcement.”

Given Fabrikam’s requirement to prevent DCs from accessing the Internet, the proxy must run on non-DC servers (VM1 and VM2). To guarantee enforcement wherever a password is changed, the DC agent must be on all domain controllers. The custom banned password list is configured in the Azure AD tenant and then distributed to on-premises DCs via the proxy.

The exam materials explain that to add a new domain controller to an existing AD DS forest in Azure, you deploy a Windows Server IaaS VM and then promote it: “To extend on-premises AD DS into Azure, provision a Windows Server VM in Azure and run AD DS to create an additional domain controller for the existing domain.” Conversely, Azure Active Directory Domain Services (Azure AD DS) provides a managed domain that is separate from and not writable by your on-premises administrators—you “do not get domain admin rights or access to DCs”—so it cannot be used to add a DC (dc3.corp.fabrikam.com) to the existing corp.fabrikam.com forest. Azure AD Application Proxy and Azure AD administrative units are unrelated to deploying DCs. Therefore, the correct implementation is to deploy an Azure virtual machine in Vnet1, install AD DS/DNS, and promote it to become DC3 in the existing domain.

In the Administering Windows Server Hybrid Core Infrastructure materials under Hyper-V management, Microsoft specifies that Enhanced Session Mode changes VMConnect from a raw console attach to a connection that uses Remote Desktop Protocol (RDP) to the guest. The guide states that Enhanced Session Mode “uses RDP to establish the VMConnect session so the user must supply credentials for a logon to the guest operating system,” and further that it “prevents a second administrator from inheriting an already signed-in console session” because the connection is treated as a new interactive sign-in. In contrast, the default basic console session “attaches directly to the active console without prompting for credentials,” which is exactly the current problem described for VM2.

The same objective area clarifies that other options do not meet the requirement: Guest Services integration only enables file copy and certain host-guest interactions; Credential Guard protects secrets inside Windows by isolating LSASS but does not affect Hyper-V console connection behavior; Shielded VMs provide fabric-level protections and encryption but are not required merely to force credential prompts for VMConnect.

Therefore, to force users to provide credentials when they connect to VM2 and to eliminate inherited console sessions, you should enable Enhanced Session Mode on the Hyper-V host (and ensure the guest supports RDP).

In the Administering Windows Server Hybrid Core Infrastructure objectives for managing Hyper-V, enabling nested virtualization is the required step when you must “run virtual machines inside a virtual machine.” The referenced guidance states that Hyper-V on a VM is supported only when the host exposes hardware virtualization features to the guest. The prescriptive step is: “Turn off the VM and run Set-VMProcessor -VMName <VMName> -ExposeVirtualizationExtensions $true to enable nested virtualization.” The module further notes that this action “passes through Intel VT-x/AMD-V to the guest so the guest OS can install the Hyper-V role and create VMs.” It also clarifies that “the setting is applied on the parent host for the target VM and requires the VM to be powered off before the change is committed.”

Because the technical requirement says “Ensure that you can run virtual machines on VM1”, VM1 must be able to host Hyper-V while itself running as a VM on Server2. The first and essential cmdlet is therefore Set-VMProcessor with the -ExposeVirtualizationExtensions switch set to $true against VM1. Other optional settings (for example, MAC spoofing on the vNIC or static memory) may be configured later if needed, but exposing virtualization extensions is the enabling prerequisite that satisfies the requirement.

The exam content for Group Policy processing stresses User Group Policy loopback processing for session hosts (RDS/AVD): “In environments like Remote Desktop Session Host (or Azure Virtual Desktop), enable loopback processing on the OU that contains the session host computers so that user settings from that GPO apply when users log on to those computers, regardless of the user’s own OU.” The requirement states: “Apply GPO4 to the Azure Virtual Desktop session hosts. Ensure that Azure Virtual Desktop user sessions lock after being idle for 10 minutes. Users must be able to control the lockout time manually from their client computer.” The idle-lock is a user configuration setting that must apply when users sign in to the session hosts, not to their personal devices. Therefore, enable loopback processing (Merge/Replace) in GPO4, which is linked to the VirtualDesktops OU containing the session hosts. Using security filtering or Enforced cannot make user settings in GPO4 override the user’s own OU without loopback. Loopback ensures the AVD hosts impose the 10-minute lock for sessions, while leaving users free to set their own client device policies independently—fulfilling least-impact design.

In the Administering Windows Server Hybrid Core Infrastructure guidance for extending AD DS into Azure, Microsoft states that when you place a domain controller in an Azure virtual network you must run DNS on that domain controller and point the VNet to that DNS server: “Domain controllers in Azure IaaS should host the AD-integrated DNS zone, and the virtual network’s DNS server setting must reference those DC/DNS IPs so Azure VMs use AD DNS rather than the Azure-provided resolver.” The materials also emphasize that Azure’s default DNS cannot host or manage AD DS zones, so custom DNS is required for domain-joined workloads. Therefore, to meet the requirement you (1) install the DNS Server role on DC3 so it can host the corp.fabrikam.com AD-integrated zone (F), and (2) configure the DNS Servers setting on Vnet1 to the IP of DC3 (and any additional DCs), ensuring all Azure VMs in Vnet1 resolve the domain via AD DNS (D). Creating a public Azure DNS zone or a Private DNS zone with the same AD name is not appropriate for AD-integrated name resolution. This design also supports the security requirement of preventing domain controllers from relying on Internet-facing resolvers.

The exam materials state that Azure Automation runbooks can be authored in PowerShell and Python (along with Graphical and PowerShell Workflow where noted). The module on “Automate management in hybrid environments” specifies: “Runbooks support PowerShell for Windows-based automation and Python for cross-platform scenarios.” It further explains that these languages integrate with Automation Accounts, modules/packages, credentials, and managed identities to run tasks on Azure or hybrid resources through the Hybrid Runbook Worker. Languages such as Java, JavaScript, or Bicep are not runbook languages (Bicep is used for ARM template deployments, not runbook execution). Accordingly, Task1 can be implemented in PowerShell and Python.

The Administering Windows Server Hybrid Core Infrastructure content notes that Microsoft Entra Connect cloud sync uses lightweight agents and supports synchronizing specific OUs from multiple forests into a single tenant. The guide highlights that cloud sync “is designed for multi-forest or cross-organization scenarios and allows scoping to selected OUs and groups,” enabling granular onboarding of just the identities you need. The requirement says “the users in the Marketing OU (in Fabrikam’s forest) must have access to storage1.” Granting access to Azure Files using Entra-based authorization requires that those users exist in the same Entra tenant. Cloud sync enables importing only the Fabrikam Marketing OU into A. Datum’s tenant without establishing full trust for all users. Azure AD Connect in active or staging mode would target the A. Datum forest and isn’t intended for selectively bringing in a separate partner forest OU; AD FS is a federation solution and does not create tenant objects for ACLs on Azure resources like Azure Files. Therefore, implement Microsoft Entra Connect cloud sync and scope it to the Marketing OU to meet the requirement.

n the Administering Windows Server Hybrid Core Infrastructure guidance for managing AD DS, Microsoft emphasizes using OU-level delegation to satisfy administrative needs while adhering to the principle of least privilege. The documentation explains that the Delegate Control wizard on an OU lets you grant a user or group only the specific permissions required for common tasks, including “Modify the membership of a group”. This grants the write permission to the member attribute on group objects contained in that OU, without giving broader account-management rights across the domain.

By contrast, placing a user in Account Operators or Server Operators provides elevated, domain-wide capabilities far beyond what is required. Account Operators can create, delete, and modify many account types across the domain (except for protected admin accounts), which violates least-privilege for a task that only needs to change group membership in one OU. Server Operators is unrelated to group membership and is intended for server administration tasks. Creating a delegation at the domain root would similarly be excessive because it applies broadly to all containers and OUs.

Therefore, to meet the requirement “Ensure that User1 can manage the membership of all the groups in Contoso\OU3,” you should delegate control on OU3 and assign the built-in task “Modify the membership of a group” to User1, achieving the minimal permissions necessary.

In Azure AD Domain Services (Azure AD DS), administrative tasks for the managed domain—such as DNS and Group Policy—are performed by users who belong to the AAD DC Administrators group. The AZ-800 study guidance explains that Azure AD DS does not expose traditional Domain Admins or Enterprise Admins; instead, membership in AAD DC Administrators grants rights to create and edit GPOs, manage DNS, and perform domain-joined VM administration within the managed domain. The same guidance notes that Azure AD DS provides two writable OUs by default: AADDC Computers and AADDC Users. You manage computer settings (including local security options and password policies that affect the local SAM of domain-joined Windows VMs) by linking GPOs to the AADDC Computers OU.

The Group Policy path to configure local password policy is Computer Configuration \ Windows Settings \ Security Settings \ Account Policies \ Password Policy. Because these are computer-level policies, they must be applied to computer objects, which in Azure AD DS reside under AADDC Computers. Therefore, to configure a password policy for local accounts on Azure VMs joined to the managed domain, you (1) sign in with an account in AAD DC Administrators, and (2) create/link the GPO to the AADDC Computers OU so the policy applies to those VMs.

The Windows Server hybrid core curriculum describes IPAM as follows: “IP Address Management (IPAM) provides centralized administration and role-based access control (RBAC) for DHCP and DNS.” It further specifies: “IPAM enables delegation such as DHCP Scope Administrator, allowing an operator to manage specific scopes on selected DHCP servers without granting full server administration.” By contrast, the built-in groups provide coarse permissions: “Adding a user to DHCP Administrators (local or domain) grants broad administrative rights over the DHCP server and all scopes.” Windows Admin Center does not introduce per-scope RBAC for DHCP; it simply surfaces the existing server tools. In the scenario, the requirement is that User1 can manage only Scope1 and Scope3—that is scope-level delegation across two servers. The only option among the choices that provides granular, scope-scoped rights is IPAM, where you assign the DHCP Scope Administrator role to User1 for Scope1 on Server1 and Scope3 on Server2, leaving other scopes unmanaged by that user.

In Windows Server hybrid environments, domain password policy and fine-grained password policy (PSO) administration is performed with the Active Directory administration tools. The AZ-800 study domain states that to “manage AD DS, including users, groups, OUs, Group Policy, and fine-grained password policies from a member server, you must first install the Remote Server Administration Tools (RSAT) for Active Directory.” The RSAT AD DS package (RSAT-AD-Tools) installs Active Directory Users and Computers (ADUC), Active Directory Administrative Center (ADAC) (which includes the Password Settings container UI), and Windows PowerShell for Active Directory (the ActiveDirectory module). The guidance further clarifies: “ADAC exposes Password Settings Objects (PSOs) and lets administrators create, link, and manage fine-grained password and lockout policies without signing in to a domain controller.” Therefore, on Server1 the first required command is: Install-WindowsFeature RSAT-AD-Tools. Options for only PowerShell, DHCP, or WINS features do not provide ADAC/ADUC and cannot manage PSOs or domain password policies from a member server.

In the Administering Windows Server Hybrid Core Infrastructure materials (hybrid security and IaaS management), Just-In-Time (JIT) VM access from Microsoft Defender for Cloud is the prescribed way to require approval-based, time-bound Remote Desktop access to Azure VMs. The guide explains that JIT “locks down inbound traffic to management ports (for example, TCP/3389) and opens them only on request, for a limited time and only from approved source IPs.” Administrators request access; upon approval, Defender for Cloud creates a temporary NSG rule that expires automatically—you specify the maximum allowed window (e.g., 2 hours) and the ports. This matches the requirement: “Ensure that server administrators request approval before they can establish a Remote Desktop connection to an Azure virtual machine. If the request is approved, the connection must be established within two hours.” Alternatives don’t meet this: PIM governs Azure roles, not VM RDP port exposure; Azure Bastion provides secure RDP/SSH over TLS without public IPs but doesn’t provide approval/time-boxed gating; the Remote Desktop extension is for classic Cloud Services and not for policy-driven approval windows. JIT is the least-privilege, policy-enforced solution aligned with the exam’s hybrid security objectives.

In the Administering Windows Server Hybrid Core Infrastructure materials (AZ-800), Microsoft explains that Group Managed Service Accounts (gMSAs) are designed for services running on multiple servers and “provide automatic password management, simplified SPN management, and the ability to delegate the management to other administrators.” The guidance further states that before you can create any gMSA, “the domain must have a KDS root key so that the Key Distribution Service can generate and rotate strong, unique passwords for gMSAs on a schedule.” After the KDS root key is created, “use New-ADServiceAccount to create the gMSA and grant the computers (e.g., web servers) permission to retrieve the account password.” For IIS, the course notes specify that a gMSA can be used for app pools: “Configure the IIS application pool identity to a custom account and specify the gMSA name (ending with ‘$’) without a password; the password is managed automatically by AD and rotates by policy (for example, every 30 days).”

Mapping these requirements to the scenario: Webapp1 runs on WEB1 and WEB2 and must use the same service account with an automatic 30-day password change. Therefore, the correct sequence is: create the KDS root key, create the gMSA, and then set the IIS application pool to run under that account. This fulfills the security requirement while allowing both web servers to share the same, automatically-rotated credentials.

The exam materials for Administering Windows Server Hybrid Core Infrastructure explain that when replacing private WAN links with Azure, Azure Virtual WAN (vWAN) can be used to centralize connectivity. For private connectivity, ExpressRoute integrates directly with a vWAN hub by deploying an ExpressRoute gateway in the hub. The gateway is the Azure resource that terminates ExpressRoute and enables hub-and-spoke routing to connected VNets (such as Vnet1). The guides emphasize: “In a Virtual WAN hub, use the ExpressRoute gateway to connect ExpressRoute circuits and propagate routes across the hub to your virtual networks.”

On-premises, each site (New York and Seattle) requires an ExpressRoute circuit connection provisioned via a connectivity provider. The circuit is the dedicated private connection from the customer edge to Microsoft’s edge and is what the office sites actually use; it’s then linked to the vWAN hub’s ExpressRoute gateway. The same materials note that Site-to-Site VPN is an alternative transport but is not required when ExpressRoute is mandated. Likewise, Application Gateway is a Layer-7 load balancer for HTTP/S traffic, and on-premises data gateway relates to Power BI/Power Platform hybrid connectivity, neither of which establishes network transport between offices and Azure.

Therefore, to meet the requirement “connect both on-premises offices to Vnet1 by using ExpressRoute,” configure an ExpressRoute gateway on the vWAN hub and ExpressRoute circuit connections in the offices.

In Administering Windows Server Hybrid Core Infrastructure, Microsoft states that high availability for DHCP on Windows Server is achieved by using DHCP failover rather than the legacy split-scope (80/20) model. The guidance explains that DHCP failover “synchronizes lease data between two DHCP servers and can be configured in Load Balance or Hot Standby mode on a per-scope basis,” and that you enable it on each DHCP scope to create a partner relationship that automatically replicates scope configuration and active leases. This meets the requirement to keep address assignment available if one DHCP server is down.

The same materials further note that DHCP broadcasts do not traverse routers; therefore, when the partner server is reachable across a routed boundary (another site/subnet), you must configure the router as a DHCP relay (IP helper) to forward DHCPDISCOVER messages to the remote DHCP server(s). The text emphasizes: “When clients and DHCP servers are on different subnets, configure a relay agent on the router to forward requests to the DHCP server IP addresses.”

Applying this to Fabrikam: create DHCP failover between DHCP1 (Scope1) and DHCP2 (Scope2) (E) and configure the routers in New York and Seattle as DHCP relays that forward to both DHCP servers (B). You do not use Failover Clustering for DHCP here, and you do not create extra 25% scopes; those are split-scope practices superseded by DHCP failover.

Within the hybrid governance section of Administering Windows Server Hybrid Core Infrastructure, Microsoft specifies that Azure Arc–enabled servers are the mechanism to bring on-premises and multi-cloud servers under Azure control to apply Azure Policy (Guest Configuration) and Defender for Servers. The prerequisite is installing the Azure Connected Machine agent (Azure Arc agent) on each server: “To manage servers with Azure Policy and configuration management, install the Connected Machine agent to onboard them to Azure Arc; once connected, you can assign Azure Policy guest configuration and monitor compliance just like Azure VMs.” Hybrid Azure AD Join is unrelated to Azure Policy assignment; the Azure Monitor agent provides telemetry but does not onboard to Arc for policy governance; a hybrid runbook worker is for Automation runbooks, not for enforcing Azure Policy. Therefore, to “use Azure Policy to enforce configuration management policies on the servers in Azure and on-premises,” deploy the Azure Connected Machine agent to all servers to Arc-enable them and then assign the desired policies.

In Azure File Sync architecture (covered in Administering Windows Server Hybrid Core Infrastructure under “Implement and manage storage solutions”), the fundamental design points are:

Sync group – “A sync group defines a sync topology. Each sync group contains exactly one cloud endpoint (an Azure file share) and one or more server endpoints.” A server endpoint is a folder on a registered Windows Server. A server can participate in multiple sync groups so long as the server endpoints are different paths.

Storage Sync Service – “The Storage Sync Service is the top-level resource that maintains server registrations and houses your sync groups.” A Windows Server registers to one Storage Sync Service at a time, and that service can contain many sync groups and many servers.

Applying these rules to the requirement:

You have three Azure file shares: newyorkfiles, seattlefiles, and companyfiles. Because each sync group maps to one cloud endpoint, you need one sync group per share ⇒ 3 sync groups.

FS1 must sync with newyorkfiles and companyfiles; FS2 must sync with seattlefiles and companyfiles. Since one Storage Sync Service can host multiple sync groups and multiple servers, and a server must be registered to a single service, the most efficient design is a single Storage Sync Service containing all three sync groups and both servers.

The Administering Windows Server Hybrid Core Infrastructure module covering GUI management tools states that Active Directory Users and Computers (ADUC) exposes the domain-scoped FSMO roles through the Operations Masters dialog. By right-clicking the domain node (e.g., contoso.com) and selecting Operations Masters, administrators can view the RID, PDC, and Infrastructure masters and see (or change) the current role holder. The materials clarify that these three roles are domain-wide and are surfaced in ADUC, whereas the forest-wide roles (Schema Master and Domain Naming Master) are viewed in the Active Directory Schema and Active Directory Domains and Trusts consoles, respectively. Therefore, using ADUC exactly as described—right-clicking the domain and choosing Operations Master—does meet the goal of identifying which server holds the PDC Emulator role in that domain. This method is especially useful in GUI-enabled admin stations and supports safe, controlled transfers when appropriate permissions are present.

< Run from: Azure Cloud Shell

 Cmdlet: Enable-AzVMPSRemoting

In the Administering Windows Server Hybrid Core Infrastructure guidance for managing Windows Server IaaS VMs, Microsoft specifies that when a newly deployed Windows Server VM in Azure is using default settings, WinRM (PowerShell Remoting) isn’t opened by default in the NSG and the VM may not be configured for remoting. The prescribed method is to use Azure PowerShell to configure the VM from outside the VM. The module provides the purpose-built cmdlet Enable-AzVMPSRemoting, which “configures WinRM on the target Windows VM, opens the required inbound ports in the attached network security group, and enables required firewall rules by using the Azure VM agent.” Because you cannot yet remote to the VM to run Enable-PSRemoting, you must run the Azure cmdlet remotely—the study materials note that this can be executed from Azure Cloud Shell or any workstation with the Az PowerShell module. Running it from Azure Cloud Shell minimizes local setup and uses your signed-in Azure context.

Therefore, to ensure you can connect to VM1 using PowerShell remoting, run Enable-AzVMPSRemoting from Azure Cloud Shell. Options like Enable-PSRemoting -Force or Enable-PSSessionConfiguration require executing on the VM itself, which isn’t possible until remoting is already enabled.

In a cloud-sync deployment, Microsoft’s hybrid identity guidance for Administering Windows Server Hybrid Core Infrastructure specifies that you do not install the full Microsoft Entra (Azure AD) Connect server. Instead, cloud sync “uses a lightweight agent—called the Microsoft Entra Connect provisioning agent—installed on one or more Windows Server computers that can reach your AD DS domain controllers.” The agent handles directory read operations and securely communicates with the cloud provisioning service. The study material further states that all configuration—including creating sync configurations, scoping filters, and enabling features such as Password Hash Synchronization (PHS)—is performed in the Microsoft Entra admin experience: “Cloud sync is configured in the Azure portal; you create a cloud sync configuration, select the on-premises AD forest, and enable password hash synchronization so password hashes are synchronized to Microsoft Entra ID.”

Because you are using Microsoft Entra Connect cloud sync, the correct software to install on-premises is the Microsoft Entra Connect provisioning agent (not the full Microsoft Entra Connect server or ADFS tools). And to enable PHS for cloud sync, you use the Azure portal (Microsoft Entra admin center) to turn on Password hash synchronization within the cloud sync configuration. This meets both requirements: installing the proper agent for cloud sync and enabling PHS centrally in the portal.

 File1: Server1 and the Azure file share

 File3: The Azure file share only

Azure File Sync cloud tiering logic is governed by two distinct policies that work in tandem to manage local disk space: the Volume Free Space Policy and the Date Policy. According to Microsoft official documentation, the Volume Free Space policy always takes precedence over the Date policy.

Volume Analysis: Volume E has a capacity of 500 GB. The policy requires 30 percent free space, which equates to 150 GB ($500 \times 0.30 = 150$). This leaves a maximum of 350 GB ($500 - 150 = 350$) available for locally cached file content.

Date Policy Evaluation: The date policy is set to 70 days.

File4 (100 days ago) exceeds the 70-day limit and is automatically tiered to The Azure file share only.

File1 (2 days), File2 (10 days), and File3 (60 days) are all within the 70-day window and would ideally stay local.

Volume Free Space Evaluation: The total size of the remaining "hot" files (File1, File2, and File3) is 500 GB ($200 + 100 + 200 = 500$). This exceeds the 350 GB local cache limit.

Tiering Order: To reach the 150 GB free space target, Azure File Sync tiers the "coldest" files first based on the last access time.

File1 (most recent) and File2 (second most recent) combined take up 300 GB, which fits within the 350 GB limit. They remain as Server1 and the Azure file share.

File3 (last accessed 60 days ago) is the oldest among the files that fit the date policy but must be tiered to satisfy the 30% free space requirement. It is moved to The Azure file share only.

The Administering Windows Server Hybrid Core Infrastructure materials for Azure File Sync explain that a cloud endpoint in a sync group must be an Azure file share and that “the storage account that contains the Azure file share must be in the same Azure region as the Storage Sync Service.” The guide also clarifies supported account types: “Azure File Sync supports Azure Files in general-purpose v2 (StorageV2) accounts for Standard performance and FileStorage accounts for Premium performance; BlockBlobStorage accounts are not supported for Azure Files.” Additionally, only storage accounts that contain Azure file shares can be selected for cloud endpoints; blob containers (used by Block Blob) are not applicable to Azure File Sync.

Applying these requirements to the table:

storage1 (East US, StorageV2) → valid region and account kind, and it has share1 (an Azure file share) → eligible.

storage3 (East US, FileStorage) → valid region and supported Premium account kind, with share3 → eligible.

storage2 (East US, BlockBlobStorage) → Block Blob only, no Azure Files share → ineligible.

storage4 (Central US, StorageV2) → has a file share but is not in the same region as the Storage Sync Service (Synd in East US) → ineligible.

Therefore, when creating the sync group in Synd (East US), you can use storage1 and storage3, and the only valid cloud endpoints you can specify are share1 and share3.

In the AZ-800/“Administering Windows Server Hybrid Core Infrastructure” content, Azure AD Connect cloud sync uses a lightweight provisioning agent that reads from on-premises AD DS. The agent runs under a Group Managed Service Account (gMSA) so it can securely obtain and rotate credentials automatically. The implementation guidance states that during agent installation you provide domain admin credentials once so the installer can create and delegate a gMSA for the agent; alternatively, you can pre-create the gMSA and assign it. The documentation emphasizes that cloud sync does not rely on user or computer accounts with static passwords; instead it “deploys a gMSA for the agent service to ensure secure, automatic password management and least-privilege directory access.” System-assigned managed identities apply to Azure resources only (not on-prem AD DS), and InetOrgPerson is an object class for users, not a service identity. A regular user account would introduce password management and rotation issues and is not the recommended nor required identity type for the cloud sync agent. Therefore, to satisfy Azure AD Connect cloud sync prerequisites, you create and use a gMSA.

The Administering Windows Server Hybrid Core Infrastructure guidance for Hyper-V Discrete Device Assignment (DDA) explains that a PCIe/NVMe device passed through to a VM becomes detached from the host PnP stack and “owned” by the guest. To reclaim the device for the host you must first turn off the VM because “changes to DDA device assignments require the virtual machine to be in an Off state.” After the VM is stopped, you remove the association using Remove-VMAssignableDevice (the inverse of assigning with Add-VMAssignableDevice). The device is then returned from the VM’s configuration. Next, you return the device to the host by calling Mount-VMHostAssignableDevice, which “re-attaches the PCI device to the host and makes it available to the host operating system.” Finally, because the host previously dismounted the device to make it assignable, Windows on the host requires a PnP re-enable: use Device Manager (or a rescan) to enable the hardware so the host can use it again.

Therefore, the correct sequence to make the NVMe device available to Server1 is: stop VM1, run Remove-VMAssignableDevice, run Mount-VMHostAssignableDevice, and then enable the device in Device Manager on the host.

In the Administering Windows Server Hybrid Core Infrastructure materials, Azure Network Adapter (ANA) is presented as a Windows Admin Center (WAC) capability used to connect on-premises Windows Server computers to Azure. The guidance states that Windows Admin Center provides an Azure Network Adapter workflow that creates a point-to-site (P2S) VPN from the selected on-premises server to an Azure virtual network. The server-side configuration (VPN profile, certificates, and routes) is pushed directly from WAC; therefore, you use Windows Admin Center—not Server Manager, Azure CLI, or RRAS—to configure the on-premises servers.

On the Azure side, the same module explains that the P2S connection terminates on an Azure VPN Gateway deployed in the target virtual network. ANA either uses an existing gateway or helps you provision one by ensuring a GatewaySubnet exists and configuring Point-to-Site settings. The study content emphasizes that “Azure Network Adapter establishes a point-to-site VPN to an Azure VNet by using an Azure VPN gateway; other Azure services such as Bastion, Firewall, Private Endpoints, or Load Balancers are not used for this tunnel.” Consequently, the required Azure component is an Azure virtual network gateway.

Putting it together: to set up ANA you configure the on-premises servers with Windows Admin Center, and to connect to Azure you use an Azure virtual network gateway as the VPN termination point.

ProcessA: All the containers and Server1

ProcessB: Container3 and Server1 only

Comprehensive and Detailed Explanation with all Administering Windows Server Hybrid Core Infrastructure documents: =

Understanding the visibility of processes within Windows Server containers depends entirely on the isolation mode used: Windows Server isolation (Process isolation) or Hyper-V isolation. According to official documents for Administering Windows Server Hybrid Core Infrastructure, these two modes determine how the container's kernel and processes interact with the host system.

Windows Server Isolation (Process Isolation): In this mode, containers share the same kernel as the host. Processes running inside the container are essentially standard processes on the host, albeit isolated through namespaces and resource controls. Consequently, a process running in a process-isolated container (like Container1 and Container2 in the exhibit) is visible from the host's Task Manager or Get-Process command, as well as from other containers sharing the same host kernel. Therefore, ProcessA can be verified as running from All the containers and Server1.

Hyper-V Isolation: This mode provides a more secure and isolated environment by running each container inside its own highly optimized virtual machine (utility VM). Because each container has its own private kernel, the host cannot "see" the internal processes of the container, and containers cannot see into each other. Container3 uses Hyper-V isolation. Therefore, ProcessC is only visible to the internal operating system of Container3 and, at a management level, to Server1 (the host). It is invisible to other containers (Container1, 2, and 4) because they are separated by kernel-level boundaries. Thus, you can verify ProcessC on Container3 and Server1 only.

 Hotpatch: VM1 and VM2 only

 SMB over QUIC: VM1 and VM2 only

The Administering Windows Server Hybrid Core Infrastructure guidance for Azure Automanage and Windows Server 2022 features states that Hotpatch is available only for Azure VMs that run Windows Server 2022 Datacenter: Azure Edition. The materials describe Hotpatch as an Azure capability that “applies security updates to Windows Server 2022 Azure Edition without requiring a reboot in most cases,” and clarify that it is supported on both Desktop Experience and Server Core images of Azure Edition used in Azure IaaS. Therefore, only VM1 (Windows Server 2022 Datacenter: Azure Edition) and VM2 (Windows Server 2022 Datacenter: Azure Edition Core) meet the Hotpatch prerequisite. Regular Windows Server 2022 Datacenter (VM3) and Windows Server 2019 Datacenter (VM4) are not eligible for Hotpatch.

For file services, the same exam content explains that SMB over QUIC is a Windows Server 2022 feature limited to Azure Edition when acting as the SMB server endpoint: it “provides SMB encryption and TLS 1.3 over UDP (QUIC) to enable secure, VPN-less access to SMB shares” and is available on Windows Server 2022 Datacenter: Azure Edition. Consequently, only VM1 and VM2 can host SMB over QUIC. Standard Windows Server 2022 Datacenter (VM3) and Windows Server 2019 Datacenter (VM4) do not provide the SMB over QUIC server capability.

Thus, the correct selections are VM1 and VM2 only for both Hotpatch and SMB over QUIC.

[Answer choice] can have production checkpoints. = VM1, VM2, and VM3

 [Answer choice] can be hibernated. = Only VM1 and VM2

TASK 2

???? Objective: Configure DC3 to replicate with DC1 and DC2 only between 8:00 PM and 6:00 AM.

Step-by-Step Guide: Replication Scheduling for DC3

✅ Step 1: Promote DC3 to a Domain Controller (if not already done)

Use Server Manager or PowerShell to install the Active Directory Domain Services role and promote the server as a domain controller.

Example PowerShell command to install the AD DS role:

powershell

Copy

Install-WindowsFeature AD-Domain-Services

To promote:

powershell

Copy

Install-ADDSDomainController -DomainName "contoso.com"

✅ Step 2: Open Active Directory Sites and Services

Log in to DC3 or another DC with administrative tools.

Open Active Directory Sites and Services (dssite.msc).

✅ Step 3: Locate the Site

In the left pane, expand the Sites container and find the site that contains DC3.

Expand the site to find Servers.

Under Servers, select DC3.

✅ Step 4: Configure Replication Connection Objects

Expand DC3 and click on NTDS Settings.

In the right pane, you’ll see connection objects to other domain controllers (these represent replication partners).

✅ Step 5: Adjust the Replication Schedule for Each Connection

For each connection object to DC1 and DC2:

Right-click the connection object and select Properties.

Click the Change Schedule button.

✅ Step 6: Set the Replication Schedule

In the schedule window, you’ll see a grid of hours.

Clear all hours except the time window of 8 PM to 6 AM (in 1-hour blocks).

Select 8 PM to 6 AM (10 hours total) for all days.

Click OK to save.

✅ Step 7: Verify and Document

Ensure that both connection objects (to DC1 and DC2) have the updated schedule.

Document your configuration as part of your environment’s change control.

Infrastructure documents: =

In the Windows Server container objectives of Administering Windows Server Hybrid Core Infrastructure, image creation is performed from a Dockerfile by using the build workflow. The guide explains that a Dockerfile is a “text manifest of instructions that define how to assemble an image.” To produce the actual image, you run docker build against a build context, optionally specifying the Dockerfile name and the image tag. The study text notes: “Use docker build to compile a container image from a Dockerfile; the command processes each instruction (FROM, COPY, RUN, EXPOSE, etc.) and writes the resulting layers to a new image.” Other commands serve different purposes: docker exec runs a command inside an existing container; docker create prepares a container from an already-built image without starting it; docker images merely lists images. Therefore, to generate an image from df1, you would run a command such as docker build -f df1 -t contoso/app:1.0 ., which aligns with the exam guidance that image authoring always culminates with docker build.

One possible solution to ensure that a DHCP scope named scope1 on SRV1 can service client requests is to activate the scope on the DHCP server. A scope must be activated before it can assign IP addresses to DHCP clients. To activate a DHCP scope on SRV1, perform the following steps:

On SRV1, open DNS Manager from the Administrative Tools menu or by typing dnsmgmt.msc in the Run box.

In the left pane, expand your DHCP server and click on IPv4.

In the right pane, right-click on the scope that you want to activate, such as scope1, and select Activate.

Wait for the scope to be activated. You can verify the activation status by checking the icon next to the scope name. A green arrow indicates that the scope is active, while a red arrow indicates that the scope is inactive.

Now, the DHCP scope named scope1 on SRV1 can service client requests and lease IP addresses to DHCP clients. You can test the DHCP service by using the ipconfig /renew command on a DHCP client computer that is connected to the same subnet as the scope.

To collect the recommended Windows Performance Counters from SRV1 in a Log Analytics workspace, you can follow these steps:

Step 1: Access the Log Analytics Workspace Log in to the Azure portal and navigate to your Log Analytics workspace.

Step 2: Configure Performance Counters In the Log Analytics workspace, select Advanced settings and then choose Data > Windows Performance Counters1. You can add the recommended performance counters by selecting the + button. If you’re using legacy agent management, you can add counters from the Legacy agents management menu2.

Step 3: Add Performance Counters Select the counters you want to collect. You can add common counters quickly by checking the boxes next to them. For specific counters, enter the name of the counter in the format object(instance)\counter. For example, to collect the Processor Time counter for all instances of the Processor object, specify Processor(_Total)\% Processor Time.

Step 4: Set Sample Interval When adding a counter, you can set the sample interval, which is the frequency at which data is collected. The default is 10 seconds, but you can change this to a higher value if needed.

Step 5: Apply Configuration After adding the desired performance counters, select Apply at the top of the screen to save the configuration.

Step 6: Install and Configure the Agent Ensure that the Microsoft Monitoring Agent (MMA) is installed on SRV1. Configure the agent to report to your Log Analytics workspace by specifying the workspace ID and key during setup.

Step 7: Verify Data Collection After the agent is configured, it will start collecting the specified performance counters. You can verify the data collection in the Log Analytics workspace by running queries against the collected data.

Note: The legacy Log Analytics agent will be deprecated by August 2024. Migrate to the Azure Monitor agent before this date to continue ingesting data3.

By following these steps, you should be able to collect the recommended Windows Performance Counters from SRV1 in your Log Analytics workspace. Ensure that you have the necessary permissions and that SRV1 has network connectivity to Azure services.

To use Azure File Sync to replicate the contents of C:\app on SRV1 to an Azure file share named sharel1, with the source files located in \\dc1.contoso.com\install, follow these steps:

Step 1: Prepare Windows Server for Azure File Sync Ensure that SRV1 meets the prerequisites for Azure File Sync, such as having a supported version of Windows Server and PowerShell 5.1 or later1.

Step 2: Deploy the Storage Sync Service In the Azure portal, deploy the Storage Sync Service in the same region as your Azure file share1.

Step 3: Create an Azure File Share Create an Azure file share named sharel1 in your storage account1.

Step 4: Install the Azure File Sync Agent Download and install the Azure File Sync agent on SRV11.

Step 5: Register SRV1 with the Storage Sync Service After installing the agent, register SRV1 with the Storage Sync Service using the Azure portal1.

Step 6: Create a Sync Group and Server Endpoint In the Azure portal, go to your Storage Sync Service and create a new sync group. Add a server endpoint with the path C:\app on SRV12.

Step 7: Configure Cloud Endpoint Add the Azure file share sharel1 as the cloud endpoint to the sync group2.

Step 8: Initiate the Sync Process The initial sync will start automatically after the cloud endpoint and server endpoint are added to the sync group. Ensure that the Azure File Sync agent is running on SRV11.

Step 9: Monitor the Sync Status Monitor the sync status in the Azure portal to ensure that the files are being replicated correctly from C:\app on SRV1 to the Azure file share sharel11.

Note: Make sure that the network connectivity between SRV1 and the Azure file share is established and that the necessary ports are open. Also, verify that the SMB security settings allow for the required SMB protocol version and authentication methods1.

By following these steps, you should be able to replicate the contents of C:\app on SRV1 to the Azure file share sharel1 using Azure File Sync. Ensure that you have the necessary permissions to perform these actions and that SRV1 is properly configured to communicate with Azure services.

In Hyper-V, access to local devices such as a USB hard drive connected to the management computer (Server1) from within a VM session (VM1) is provided only when using Enhanced Session Mode through the Virtual Machine Connection (vmconnect) client. The AZ-800/“Administering Windows Server Hybrid Core Infrastructure” materials emphasize that Enhanced Session Mode “enables redirection of local resources (audio, clipboard, printers, drives, and supported Plug and Play devices) to a guest when connecting with Virtual Machine Connection.” To use it, you must first enable it on the host and then select the device in vmconnect before establishing the session.

Accordingly, you should:

Enable Enhanced Session on the host: In Hyper-V Manager → Host1 → Hyper-V Settings → Enhanced Session Mode Policy, select Allow enhanced session mode (and optionally Use enhanced session mode under User settings). This satisfies option A.

Choose the USB drive in the vmconnect UI: When launching the connection to VM1, click Show Options → Local Resources → More…, and select Drives or the specific USB device so it is redirected into the guest. This matches option D.

Options B and E relate to host Disk Management operations and do not provide guest redirection of a USB attached to Server1. Option C (“switch to a basic session”) explicitly disables the RDP-based redirection channel that Enhanced Session Mode relies upon, preventing USB/drive passthrough. Therefore, the correct pair is A and D.

TASK 5

???? Objective:

Configure a Group Policy Preference to create a shortcut to \\srvi.contoso.com\data on the desktop of users in the Server Admins OU.

Step-by-Step Guide: Using Group Policy Preferences to Create a Desktop Shortcut

✅ Step 1: Open Group Policy Management Console (GPMC)

Log in to a DC or a management computer with RSAT installed.

Open Group Policy Management (gpmc.msc).

✅ Step 2: Create a New GPO

In the GPMC console, expand the forest and the domain (e.g., contoso.com).

Right-click the OU named Server Admins and select Create a GPO in this domain, and Link it here.

Name the GPO, e.g., Desktop Shortcut for Server Admins.

✅ Step 3: Edit the GPO

Right-click the newly created GPO and select Edit.

This opens the Group Policy Management Editor.

✅ Step 4: Navigate to User Preferences

In the editor, expand:

User Configuration > Preferences > Windows Settings > Shortcuts.

✅ Step 5: Create the Shortcut

Right-click Shortcuts and select New > Shortcut.

In the New Shortcut Properties window:

Action: Create

Name: Data Folder

Target Type: File System Object

Location: Desktop

Target Path: \\srvi.contoso.com\data

Optionally, set an icon or description if you want.

✅ Step 6: Configure Item-Level Targeting (Optional)

If you want to limit this shortcut strictly to specific users/groups, click the Common tab.

Check Item-level targeting and configure conditions (optional).

For this scenario, linking the GPO to the Server Admins OU is usually sufficient.

✅ Step 7: Close and Update

Close the editor.

In GPMC, ensure the GPO is linked to the Server Admins OU.

Force a Group Policy Update on client computers:

On a client computer:

gpupdate /force

Or wait for the next Group Policy refresh cycle.

✅ Step 8: Verify

Log in as a user in the Server Admins OU.

The shortcut to \\srvi.contoso.com\data should appear on the desktop.

One possible solution to ensure that all DHCP clients that get an IP address from SRV1 will be configured to use DC1 as a DNS server is to use the DHCP scope options. DHCP scope options are settings that apply to all DHCP clients that obtain an IP address from a specific scope. You can use the DHCP scope options to specify the DNS server IP address, as well as other parameters such as the default gateway, the domain name, and the DNS suffix. Here are the steps to configure the DHCP scope options on SRV1:

On SRV1, open DNS Manager from the Administrative Tools menu or by typing dnsmgmt.msc in the Run box.

In the left pane, expand your DHCP server and click on IPv4.

In the right pane, right-click on the scope that you want to configure and select Properties.

In the Scope Properties dialog box, click on the DNS tab.

Check the box Enable DNS dynamic updates according to the settings below. This option allows the DHCP server to register and update the DNS records for the DHCP clients.

Select the option Always dynamically update DNS records. This option ensures that the DHCP server updates both the A and PTR records for the DHCP clients, regardless of whether they request or support dynamic updates.

Check the box Discard A and PTR records when lease is deleted. This option allows the DHCP server to delete the DNS records for the DHCP clients when their leases expire or are released.

Check the box Dynamically update DNS records for DHCP clients that do not request updates. This option allows the DHCP server to update the DNS records for the DHCP clients that do not support dynamic updates, such as legacy or non-Windows clients.

In the DNS servers section, click on the Add button to add a new DNS server IP address.

In the Add Server dialog box, enter the IP address of DC1, which is the DNS server that you want to use for the DHCP clients, and click Add.

Click OK to close the Add Server dialog box and return to the Scope Properties dialog box.

Click OK to apply the changes and close the Scope Properties dialog box.

Now, all DHCP clients that get an IP address from SRV1 will be configured to use DC1 as a DNS server. You can verify the DNS configuration by using the ipconfig /all command on a DHCP client computer and checking the DNS Servers entry. You can also check the DNS records for the DHCP clients by using the DNS Manager console on DC1.

TASK 3

???? Objective:

Create a user named Admin1 in contoso.com.

Admin1 must be able to back up and restore files on SRV1.

Follow the principle of least privilege.

Step-by-Step Guide

✅ Step 1: Create the User Account

Log in to a Domain Controller (e.g., DC1) with appropriate admin rights.

Open Active Directory Users and Computers (dsa.msc).

In the contoso.com domain:

Right-click the Users container or another OU where you want to create the account.

Select New > User.

Enter the following:

First name: Admin1

User logon name: Admin1

Click Next and set a password (ensure it meets the domain’s password policy).

Configure password options (e.g., User must change password at next logon, if required).

Click Finish.

✅ Step 2: Grant Backup and Restore Rights on SRV1

By default, Backup Operators have the ability to back up and restore files (without giving full admin rights).

Log in to SRV1 (the target server).

Open Computer Management (compmgmt.msc).

In the left pane, expand:

System Tools > Local Users and Groups > Groups.

Find and double-click the Backup Operators group.

Click Add.

In the Select Users, Computers, Service Accounts, or Groups window:

Type Admin1.

Click Check Names to resolve the user.

Click OK to add Admin1 to the group.

Click OK again to close the Backup Operators group properties.

✅ Step 3: Verify Access

Log in as Admin1 on SRV1 and test performing backup and restore operations using tools like Windows Server Backup.

Since Backup Operators can back up and restore data but do not have full administrative privileges, this follows the least privilege principle.

✅ Additional Notes

If you prefer using PowerShell, you can add the user to the group like this on SRV1:

Add-LocalGroupMember -Group "Backup Operators" -Member "contoso\Admin1"

To run a container on SRV1 using the mcr.microsoft.com/windows/servercore/iis image, publish port 60 on the container to port 5001 on SRV1, and ensure it runs in the background, you can follow these steps:

Step 1: Pull the IIS Image First, pull the IIS image from the Microsoft Container Registry:

docker pull mcr.microsoft.com/windows/servercore/iis

Step 2: Run the Container Next, run the container with the required port mapping and ensure it runs in the background using the -d flag:

docker run -d -p 5001:60 --name iis_container mcr.microsoft.com/windows/servercore/iis

This command will start a container named iis_container using the IIS image, map port 60 inside the container to port 5001 on SRV1, and run the container in detached mode.

Step 3: Verify the Container is Running To verify that the container is running and the port is published, use the following command:

docker ps

This will list all running containers and show the port mappings.

Step 4: Access the IIS Server You can now access the IIS server running in the container by navigating to http:// :5001 in a web browser, where is the IP address of SRV1.

Note: Ensure that Docker is installed on SRV1 and that the port 5001 is open on the firewall to allow incoming connections1.

By following these steps, you should be able to run the IIS container on SRV1 with the specified port mapping and have it running in the background.

Objective:

Grant permissions to the BranchAdmins group to manage the fabikam.com DNS zone on DC1.

Step-by-Step Guide

✅ Step 1: Log in to the DNS Server

Log in to DC1 (which hosts the DNS zone fabikam.com) using an account with Domain Admin or Enterprise Admin rights.

✅ Step 2: Open the DNS Manager

Open DNS Manager:

Press Windows + R, type dnsmgmt.msc, and hit Enter.

✅ Step 3: Locate the Zone

In the DNS Manager, expand the Forward Lookup Zones.

Locate and right-click on the zone fabikam.com.

✅ Step 4: Open Zone Properties

Right-click on fabikam.com and select Properties.

In the Properties window, go to the Security tab.

✅ Step 5: Grant Permissions

In the Security tab, click Add.

Enter the name of the group:

nginx

Copy

BranchAdmins

Click Check Names to resolve the group.

Click OK.

✅ Step 6: Assign the Appropriate Permissions

In the Permissions window, select the BranchAdmins group.

Assign the following permissions:

Read

Write

Create All Child Objects

Delete All Child Objects

Optionally, click Advanced for more granular control if needed.

✅ Step 7: Apply and Close

Click Apply and OK to save the changes.

To create a group-managed service account (gMSA) named gMSA1 and make it available on SRV1, you can follow these steps:

Step 1: Create the Key Distribution Services Root Key First, you need to create the KDS Root Key, which is required for the gMSA to function. You can do this with the following PowerShell command:

Add-KdsRootKey –EffectiveTime ((get-date).addhours(-10))

Note: The -EffectiveTime parameter is set to 10 hours in the past to ensure immediate effect.

Step 2: Create the gMSA Next, use the New-ADServiceAccount cmdlet to create the gMSA:

New-ADServiceAccount -Name gMSA1 -DNSHostName gmsa1.domain.com -PrincipalsAllowedToRetrieveManagedPassword SRV1$

Replace domain.com with your actual domain name.

Step 3: Install the gMSA on SRV1 Now, you need to install the gMSA on the server SRV1. Run the following command on SRV1:

Install-ADServiceAccount -Identity gMSA1

Step 4: Test the gMSA To ensure that the gMSA is installed correctly and ready for use, perform a test using:

Test-ADServiceAccount -Identity gMSA1

If the test returns True, the gMSA is correctly installed and ready for use on SRV1.

Step 5: Configure the Service to Use the gMSA Finally, configure the service that requires the gMSA to use gMSA1 by setting the service’s logon account to domain\gMSA1$ and leave the password field blank.

This will create and make the gMSA gMSA1 available on SRV1. Ensure that you have the necessary permissions and that SRV1 is properly joined to the domain before proceeding with these steps123.