Microsoft AZ-802 Dumps Questions Answers

DHCP1: Export-DhcpServer, Remove-DhcpServerInDC. DHCP2: Add-DhcpServerInDC, Import-DhcpServer.

Migrating a DHCP server ' s configuration together with its existing leases and reservations by PowerShell follows an export/unauthorize-then-authorize/import pattern across the two servers. On the source server, DHCP1, Export-DhcpServer captures the existing scopes, options, leases, and reservations into a migration file, which is what allows the existing leases and reservations to actually carry over to the replacement server. Remove-DhcpServerInDC is then run on DHCP1 to unauthorize it in Active Directory, which is what prevents DHCP1 from continuing to service client requests once DHCP2 is brought online, satisfying that specific migration requirement. On the target server, DHCP2, Add-DhcpServerInDC authorizes the new server in AD DS so it is permitted to lease addresses on the network, and Import-DhcpServer then applies the configuration file exported from DHCP1, causing DHCP2 to hand out the same address ranges as DHCP1 along with the existing leases and reservations that were captured during export. Add-DhcpServerv4Scope and Remove-DhcpServerv4Scope only create or delete an individual scope ' s address range and do not export, import, or preserve any existing lease or reservation data, so neither is part of this migration sequence. Therefore, DHCP1 requires Export-DhcpServer and Remove-DhcpServerInDC, while DHCP2 requires Add-DhcpServerInDC and Import-DhcpServer.

1. Add a disk resource to the cluster. 2. Create a Cluster Shared Volume (CSV). 3. Put the disk in maintenance mode. 4. Enable BitLocker on the volume. 5. Update the BitLockerProtectorInfo property of the volume.

BitLocker can only be enabled on a Cluster Shared Volume disk while that disk is taken offline to cluster I/O, so the CSV must exist and be placed into maintenance mode before encryption can be applied. The supported sequence begins by adding the disk resource to the cluster and converting it into a Cluster Shared Volume, since BitLocker-on-CSV support requires the disk to already be a CSV rather than a plain cluster disk. The disk is then put into maintenance mode, which takes it offline to the other cluster nodes so it can be safely encrypted without a node attempting to access it mid-operation. With the CSV disk offline in maintenance mode, BitLocker is enabled on the volume. Finally, the volume ' s BitLockerProtectorInfo property is updated so that Failover Clustering registers the unlock protector, allowing the volume to automatically unlock on every cluster node once maintenance mode ends and the CSV is brought back online. Performing these steps out of order either fails outright -- BitLocker cannot be enabled on a CSV disk that is still online and actively used by the cluster -- or leaves the other cluster nodes unable to bring the encrypted volume back online afterward, since they would lack the registered unlock protector. Therefore, the correct order is: add the disk resource, create the CSV, put the disk in maintenance mode, enable BitLocker, and update BitLockerProtectorInfo.

Storage Migration Service is purpose-built to inventory the data, security descriptors, and both share-level and NTFS-level permissions on a source file server such as Fileserver1, transfer that data to a destination server such as Fileserver2, and then perform a cutover that reassigns the source server ' s network identity -- its computer name and IP address -- to the destination server. That cutover step is precisely what allows the existing \\Fileserver1\Data UNC path, already relied upon by the Chicago office application, to continue working unchanged after the migration, since client requests to that path transparently resolve to Fileserver2 once it has taken on Fileserver1 ' s identity. The Microsoft File Server Migration Toolkit and Windows Server Migration Tools are older, largely superseded utilities that can move some file server settings but do not provide this automated inventory-transfer-and-cutover workflow, and neither preserves the source server ' s identity on the destination the way Storage Migration Service does, meaning the UNC path would need to be manually updated or redirected. File Server Resource Manager (FSRM) is a quota, file-screening, and storage-reporting feature entirely unrelated to migrating data between servers. Therefore, Storage Migration Service is the correct tool to perform this migration while preserving the existing UNC path.