iSCSI Target Setup on Windows Server: LUNs and MPIO

iSCSI target setup on Windows Server is a role service, not a separate product: you install a feature, create a VHDX, wrap it in a target, and map it to a LUN. That is four commands on the server and three on the client. The part worth slowing down for is the constraint list, because the Microsoft target enforces limits that shape the design: one connection per session, and no Unmap on dynamically expanding disks. The same role service ships in Windows Server 2016, 2019, 2022 and 2025.

Install the role and prepare the backing volume

The iSCSI Target Server role service installs with one command:

Install-WindowsFeature -Name FS-iSCSITarget-Server -IncludeManagementTools

In Server Manager it sits under File and Storage Services, then File and iSCSI Services. Microsoft positions it for diskless and network boot, block storage for applications that cannot use SMB, non-Microsoft initiators, and lab environments.

Sort the backing volume out before you create anything. The documented limits list NTFS and ReFS as supported hosting volumes, and FAT, FAT32 and exFAT as unsupported and enforced. Cluster Shared Volumes v2 is also unsupported. The New-IscsiVirtualDisk reference adds three more rules that produce confusing errors when broken: the path must be absolute, the file name must end in .vhdx, and the file cannot be a network file or live in a compressed, sparse or transacted folder.

Create the virtual disk, target and mapping

Three objects, in order. The virtual disk is the storage, the target is the login endpoint, and the mapping bolts one to the other at a LUN number.

New-IscsiVirtualDisk -Path "D:\iSCSI\sql-data.vhdx" -SizeBytes 500GB -UseFixed

New-IscsiServerTarget -TargetName "sql01" `
  -InitiatorIds @("IQN:iqn.1991-05.com.microsoft:sql01.lab.example")

Add-IscsiVirtualDiskTargetMapping -TargetName "sql01" `
  -Path "D:\iSCSI\sql-data.vhdx" -Lun 0

-UseFixed picks the fixed parameter set. Leave it off and you get a dynamically expanding VHDX, which is the default. Fixed disks are cleared during creation; the -DoNotClearData switch skips that, and Microsoft’s own note says it can reveal pre-existing data and is not recommended.

Dynamic is tempting and usually wrong here. The limits page lists thin provisioning and Unmap as unsupported, so a dynamic VHDX grows and never shrinks when the initiator deletes data. On capacity, VHDX caps at 64 TB in fixed, dynamic and differencing formats with a 3 MB minimum; legacy VHD caps at 16 TB fixed and 2 TB for parent and differencing disks.

The -InitiatorIds parameter takes IdType:Value pairs, where the type is DNSName, IPAddress, IPv6Address, IQN or MACAddress, per the New-IscsiServerTarget reference. IQN is the identifier to prefer. Its shape comes from RFC 7143 section 4.2.7.4: iqn. followed by a yyyy-mm date code for when the organisation held the domain, the reversed domain name, and an optional colon-delimited local identifier. The client’s own IQN is on the Configuration tab of the iSCSI Initiator control panel, iscsicpl.

Add-IscsiVirtualDiskTargetMapping assigns the lowest available LUN if you omit -Lun, and the number must be unique within a target. Pin it explicitly: it keeps disk identification stable as you add and remove disks later.

Connect the initiator

On the client, make sure the Microsoft iSCSI Initiator service is running and set to start automatically, then discover and log in:

New-IscsiTargetPortal -TargetPortalAddress 10.10.30.10
Get-IscsiTarget
Connect-IscsiTarget -NodeAddress "iqn.1991-05.com.microsoft:fs01-sql01-target" -IsPersistent $true

Discovery uses TCP 3260 unless you override -TargetPortalPortNumber. -IsPersistent $true is the parameter people forget: without it the session does not reconnect after a restart, and anything that depends on the volume fails to start on the next reboot. Once connected, the disk is raw and belongs to the client, so Get-Disk, Initialize-Disk, New-Partition and Format-Volume run on the initiator. The target server only ever sees an open VHDX file, which is why a backup taken there during a live session is crash-consistent at best. Quiesce from the initiator side.

Restrict who can log in

The initiator ID list is your access control, and it is easy to disable by accident. Set-IscsiServerTarget documents -InitiatorId "IQN:*", which assigns the target to every initiator that connects, and its own guidance is to be very cautious with it because no validation is performed. It is a troubleshooting tool, not a configuration.

CHAP is the next layer:

$secret = ConvertTo-SecureString -String "a-long-random-secret" -AsPlainText -Force
$chap = New-Object System.Management.Automation.PSCredential("iscsiuser", $secret)
Set-IscsiServerTarget -TargetName "sql01" -EnableChap $true -Chap $chap

The initiator then logs in with -AuthenticationType ONEWAYCHAP plus -ChapUsername and -ChapSecret; the accepted values are NONE, ONEWAYCHAP and MUTUALCHAP, uppercase only. -EnableReverseChap and -ReverseChap add the target-authenticates-to-initiator direction, which is what MUTUALCHAP expects.

CHAP authenticates a login. It does not encrypt anything, and iSCSI payloads are plaintext on the wire. Keep the traffic on a dedicated storage network, and use IPsec if it has to cross anything shared; the limits page lists IPsec, jumbo frames and CRC offload as supported, and iSCSI offload as not supported. The same background applies to any target implementation, which the iSCSI fundamentals guide covers in more depth.

Limits that decide the design

Item	Support limit	Enforced
Targets per target server	256	No
Virtual disks per target server	512	No
Virtual disks per target	256	Yes
Sessions per target	544	Yes
Connections per session	1	Yes
Error recovery level	0	Yes
Snapshots per LU	512	Yes
MPIO paths	4	No
Failover cluster nodes	8	No
Portal IP addresses	64	Yes

Two rows carry most of the weight. Connections per session is fixed at 1, so MC/S is unavailable and MPIO is the only way to get a second path. And converting a stand-alone target server to a clustered one, or back, is listed as not supported, with target and virtual disk configuration lost in the attempt. Decide clustering before you build.

Add MPIO properly

Install-WindowsFeature -Name Multipath-IO
Enable-MSDSMAutomaticClaim -BusType iSCSI

Enable-MSDSMAutomaticClaim accepts only SAS and iSCSI, and you run it once per bus type. Plan a restart after the feature install. Then create one session per path, pinning both ends so the paths actually traverse different NICs:

$iqn = "iqn.1991-05.com.microsoft:fs01-sql01-target"
Connect-IscsiTarget -NodeAddress $iqn -TargetPortalAddress 10.10.30.10 `
  -InitiatorPortalAddress 10.10.30.21 -IsMultipathEnabled $true -IsPersistent $true
Connect-IscsiTarget -NodeAddress $iqn -TargetPortalAddress 10.10.31.10 `
  -InitiatorPortalAddress 10.10.31.21 -IsMultipathEnabled $true -IsPersistent $true

Skipping -InitiatorPortalAddress lets Windows choose the source interface, which is how two “paths” end up on one NIC. If a second path logs in and then drops, the login timeout and path error checklist is the faster route than guessing at MPIO policy.

Snapshots, backup and when to use something else

The target supports snapshot create and restore with a 512-per-LU ceiling, but writable snapshots, online rollback and snapshot conversion are listed as unsupported, and disks based on differencing VHDs cannot be snapshotted at all. LUN cloning is unsupported; the documented substitute is differencing VHDs, capped at 256 children per parent and two levels deep for VHDX. VSS or VDS operations driven from the application server need the iSCSI Target Storage Provider role service installed there, running the same Windows Server version as the target.

That feature set is the honest dividing line. If you want cheap snapshots, replication and pool-level integrity checking under your LUNs, that belongs to a storage appliance rather than a file on an NTFS volume, and the protocol comparison for NAS-hosted block storage is the better starting point. The Windows target earns its place when the capacity already lives on a Windows file server, when you need diskless boot, or when a test cluster needs shared block storage today. For multi-host designs with zoning and masking on SAN hardware, see the iSCSI SAN setup guide.