A server administrator is troubleshooting a Windows Server 2022 that cannot connect to a remote iSCSI target. The server has two network adapters: one for LAN traffic and one dedicated to iSCSI. The administrator verifies that the iSCSI adapter has a valid IP address, can ping the target, and that the iSCSI service is running. However, the iSCSI initiator shows the target as unavailable. Which action should the administrator take next?
In iSCSI, the target often restricts access based on the initiator's IQN. If the IQN is not in the target's ACL, the target will be discovered but marked unavailable. Since IP connectivity and the service are confirmed, the next logical step is to verify that the initiator's IQN is authorized on the target. This is a common oversight when setting up iSCSI access.
Why this answer
The target is discovered but unavailable, while IP connectivity and the iSCSI service are confirmed. This points to an access control issue, such as the initiator IQN not being in the target's ACL. Verifying and adding the IQN to the target's allowed list is the correct next step.
Firewall, driver reinstallation, and IP changes are either less likely or inappropriate given the symptoms.
Exam trap
The trap here is assuming a network or driver problem when the target is reachable but access is denied by IQN-based ACLs.