# Update existing Linux iSCSI node settings after changing Elastic SAN client defaults

> DSE recommends inventorying the connected volume IQNs and target portals before editing global defaults.

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260917-061-update-existing-linux-iscsi-node-settings-after-changing-elastic-san-client/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-17T16:33:59+00:00
- Modified: 2026-09-17T16:38:45+00:00
- Last reviewed by DSE: 2026-09-17
- Resource type: Guide
- DSE priority: Information
- Topics: IT
- Reading time: 2 minutes

## What you need to know

DSE recommends inventorying the connected volume IQNs and target portals before editing global defaults.

## Potentially affected

This check is for an existing Linux client connected to Azure Elastic SAN when an operator is applying the documented iSCSI client configuration changes.

## DSE recommendation

DSE recommends inventorying the connected volume IQNs and target portals before editing global defaults.

## Article

## Source facts

Microsoft explains that connecting an Elastic SAN volume creates a node-specific configuration that inherits the global iSCSI settings at that time. If a volume was already connected before the global settings changed, its node-specific configuration must be updated directly or through the documented command. The guidance calls for restarting the VM after changing iSCSI configuration files. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/storage/elastic-san/elastic-san-best-practices)

## Applicability

This check is for an existing Linux client connected to Azure Elastic SAN when an operator is applying the documented iSCSI client configuration changes.

## DSE recommendation

DSE recommends inventorying the connected volume IQNs and target portals before editing global defaults. Separate settings for future connections from the node records that already exist. Review the required changes for each current volume with the storage owner, and schedule the documented restart with the workload owner. Preserve the original configuration and identify the exact node records so the change does not unintentionally target another storage connection.

## Verification

Inspect the node-specific values after the approved update and restart. Compare each affected IQN and portal with the inventory, then test the workload through its intended volumes. Record any connection failure or unchanged value before closing the change. A corrected global file alone should not be accepted as evidence that an existing connection uses the revised settings.

## Official references

- [Microsoft: Azure Elastic SAN configuration best practices | Microsoft Learn](https://learn.microsoft.com/en-us/azure/storage/elastic-san/elastic-san-best-practices)

## Primary reference

- Name: Azure Elastic SAN configuration best practices | Microsoft Learn
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/azure/storage/elastic-san/elastic-san-best-practices
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Update existing Linux iSCSI node settings after changing Elastic SAN client defaults,” DSE Security, https://update.dsesecurity.com/updates/dse-20260917-061-update-existing-linux-iscsi-node-settings-after-changing-elastic-san-client/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.