Microsoft Entra Connect password hash synchronization is strictly a one-way flow that pushes password hashes from the on-premises AD DS domain up to Microsoft Entra ID; it never creates or populates an on- premises AD DS account for a user who currently exists only as a cloud-only object in the Microsoft Entra tenant. Because App1 authenticates against AD DS on Server1 rather than against Microsoft Entra ID, User1 needs a genuine on-premises AD DS account for that Active Directory authentication path to succeed at all, so the correct fix is to create a matching AD DS account for User1 directly in the domain. Microsoft Entra Connect ' s default soft-match logic then links that newly created on-premises account to User1 ' s existing cloud object on the very next synchronization cycle, based on matching attributes such as the primary SMTP address, rather than creating a duplicate, unlinked identity in the tenant. Enabling password writeback only pushes cloud-initiated password resets back down to an on-premises account that is already linked through synchronization, which does not help when no on-premises account exists yet, and disabling soft match or enabling BlockCloudObjectTakeoverThroughHardMatch would each make it harder, not easier, to link a newly created on-premises account back to User1 ' s existing cloud identity.

Registering an already-deployed Azure Migrate appliance requires two portal-side actions performed within the Azure Migrate service itself: creating an Azure Migrate project, which is the container that discovery, assessment, and migration tools attach to, and generating a project key from that project. The generated key is then entered into the appliance configuration manager running on VM1, which is what actually completes registration and links the appliance to that specific project. Adding a migration tool or an assessment tool are configuration choices made within an already-registered project to enable specific downstream capabilities, not the registration action itself, and downloading the Azure Migrate installer script ZIP file is a step used earlier, when deploying the appliance on a physical server rather than when registering an appliance that has already been imported and is running as VM1. Therefore, creating a project and generating a project key are the two actions that together register VM1 with Azure Migrate.

Explanation:
1. Add-KdsRootKey 2. New-ADServiceAccount 3. Install-ADServiceAccount
Before any group managed service account can be created in a forest, the Key Distribution Service root key must exist, since it supplies the key material the KDS uses to compute and periodically roll the gMSA ' s password; this is created once with Add-KdsRootKey. Next, New-ADServiceAccount creates the actual gMSA object, and its -PrincipalsAllowedToRetrieveManagedPassword parameter can be pointed directly at the existing NLBHosts group, which authorizes all five NLB nodes to retrieve the managed password in a single step, without needing to grant permission to each computer individually. Finally, Install- ADServiceAccount must be run locally on each of the five NLB nodes to actually install and cache the gMSA account on that computer, which is what allows the NLB service running there to authenticate as the gMSA.
Set-KdsConfiguration adjusts advanced KDS server-side settings and is not a required step in standard gMSA provisioning. Add-ADGroupMember would only be needed if authorization were being granted by adding individual computer accounts to a security group after the fact, which is unnecessary here since the group already exists and is referenced directly. Add-ADComputerServiceAccount associates a computer with a standalone (non-group) managed service account and does not apply to gMSA scenarios like this one.

Explanation:
1. az extension add. 2. az vm repair create. 3. az vm repair run. 4. az vm repair restore.
The Azure VM repair commands are delivered as the vm-repair Azure CLI extension rather than as a built-in part of the core CLI, so az extension add, which installs that extension, is always the required first step before any az vm repair subcommand can be invoked in Cloud Shell. Once the extension is installed, az vm repair create copies VM1 ' s operating system disk and attaches that copy to a new, temporary repair virtual machine so it can be examined and worked on without further risking the original VM. The optional az vm repair run step then executes a diagnostic or fix-up script against the disk that is now attached to the temporary repair VM, allowing an administrator to inspect or repair the file system, boot configuration, or other disk-level issue that is preventing VM1 from starting. Finally, az vm repair restore swaps the repaired disk back onto the original VM1 in place of its damaged disk and cleans up the temporary repair VM and its associated resources, completing the recovery process and allowing VM1 to start normally again with its repaired disk.

A DHCP reservation explicitly binds a chosen IP address to a specific client ' s hardware (MAC) address, so that whenever that specific client requests or renews a DHCP lease, the DHCP server always offers it that exact same reserved address rather than any other available address from the scope ' s pool. Creating one reservation for each of the five printers -- keyed to each printer ' s own MAC address -- guarantees that each printer consistently receives the same IP address every time it requests a lease, regardless of how many other DHCP clients come and go on the network or how the general address pool is otherwise being consumed.
This directly and completely satisfies the stated requirement, and it does so with the standard, purpose-built DHCP mechanism for exactly this scenario, requiring no additional configuration such as manually excluding addresses or manipulating scope-wide options that would otherwise affect every client rather than just the five printers. Therefore, creating a DHCP reservation for each printer does meet the requirement that the printers always be assigned the same IP address.