Azure Elastic SAN supports iSCSI but does not support CHAP authorization or initiator registration. Microsoft also lists iSCSI Error Recovery Levels 1 and 2 and more than one LUN per target as unsupported. Network access is configured at the volume-group level through private endpoints or service endpoints, and volumes inherit that configuration. Microsoft Learn.
\nUse this compatibility gate before moving an existing iSCSI workload to Elastic SAN. Identify the source target’s actual authentication, recovery and target-to-LUN assumptions; protocol naming alone does not establish equivalent features.
\nMake unsupported initiator assumptions an explicit migration decision. Have the storage and security owners compare the existing design with Elastic SAN’s current support list. If CHAP or another excluded feature is required by the approved architecture, do not remove that requirement silently to make a connection succeed. Assess whether a separately approved network and access design can meet the workload’s needs, or whether another target service is required.
\nIn a controlled pilot, inspect the intended volume-group network boundary and the initiator’s target configuration. Test the agreed permitted and denied client paths and the application’s recovery behavior using the supported feature set. Record every requirement that remains unmet. Do not accept a basic iSCSI login as evidence that CHAP, initiator registration or advanced recovery behavior was preserved from the source system.
\n