Windows Server iSCSI Target: Provision VHDX LUNs and Control Initiator Access

Windows Server iSCSI Target Server publishes VHDX-backed block storage to remote iSCSI initiators. It is a different operational role from configuring a Windows host as an iSCSI initiator: the target server owns the backing files, target objects, initiator allow lists, and LUN mappings, while client-side initiator configuration and MPIO determine how a host connects to and uses the exported device. A working target login proves only that the protocol session was established; it does not prove that the VHDX is backed up consistently, that concurrent writers are safe, or that the service meets a SAN’s availability requirements.

Use the role for a clearly scoped lab, application block-storage requirement, diskless boot design, or other supported workload whose performance, recovery, and availability characteristics have been tested. Microsoft describes iSCSI Target Server as a role service that uses Ethernet and notes that high availability requires a suitable clustered design. Do not treat an ordinary standalone file server as automatically equivalent to a redundant storage array. Before deployment, name the storage owner, data classification, expected I/O pattern, capacity and growth envelope, recovery point and recovery time objectives, initiator identities, authentication method, network paths, and maintenance owner.

Define the target, disk, and ownership model

An iSCSI target is the server-side object an initiator logs into. A virtual disk is a VHDX file that represents block storage. A target can be assigned to one or more initiator identities and one or more virtual disks can be mapped to it with distinct logical unit numbers (LUNs). The initiator presents the remote device to the client operating system, where the disk may then be initialized, partitioned, and formatted. Keep those layers distinct in documentation and incident tickets: target discovery, authorization, login, LUN mapping, device enumeration, and filesystem access are separate transitions with different evidence.

Decide whether each VHDX will be fixed or dynamically expanding before sizing the filesystem. A fixed file consumes its configured backing capacity up front; a dynamic file can grow as blocks are written, so the logical size exposed to the initiator can substantially exceed current physical allocation. Monitor both logical provisioned capacity and free space on the backing volume. A thin-provisioned target can fail at the application layer when its host volume is full, even if the initiator still sees free space in the virtual disk. Reserve room for VHDX growth, filesystem metadata, temporary operations, backups, and normal server activity, and alert before the volume reaches a critical threshold.

The iSCSI Target module requires the Windows Server role service. Install it only after choosing an appropriate, supported server edition and storage volume, and record the change under the host’s normal role and patch management process. Query the installed feature before making a change:

Get-WindowsFeature -Name FS-iSCSITarget-Server
Get-Service -Name WinTarget
Get-Volume | Select-Object DriveLetter, FileSystem, HealthStatus,
    OperationalStatus, Size, SizeRemaining

The feature and service output are inventory, not a complete health test. Confirm the role is installed and the service state is appropriate, then inspect event records, backing-volume health, and actual initiator access. Do not install the role on a client Windows edition or assume that the existence of a WinTarget service means a target is configured.

Design an isolated, named storage path

Use a documented storage network with explicit source and destination addresses, routing, VLANs, MTU, firewall rules, and switch paths. iSCSI commonly uses TCP port 3260, but use the deployed target and network configuration as the authority rather than opening that port broadly. Permit only approved initiator subnets or host addresses to reach the target service. Do not expose iSCSI to untrusted or public networks, bridge a storage interface into general client traffic, or rely on a shared secret to make an otherwise uncontrolled path safe.

Record each initiator’s iSCSI Qualified Name (IQN) and stable host ownership before creating access rules. A target allow list can use identity types such as IQN, DNS name, IP address, IPv6 address, or MAC address; choose an identity appropriate to how the hosts are managed and how addresses change. Avoid wildcard initiator identity in production. An IQN:* rule may remove an authorization mismatch while troubleshooting, but it also removes the intended access boundary. If a host is rebuilt and receives a new IQN, make the identity change explicit, verify the replacement is the approved system, and remove the retired identity only after confirming no live session depends on it.

Use CHAP only as part of a planned authentication design, protect credentials in a vault, and coordinate both ends of the exchange. Do not place secrets in scripts, transcript logs, source control, or unencrypted change tickets. CHAP is not encryption for the storage payload and does not remove the need for network isolation. If mutual CHAP is required, verify which side sends and validates each challenge and test it in a controlled path before changing a target used by production hosts. Keep a separate test target so an authentication experiment cannot disconnect a critical workload.

Inventory current targets and mappings before edits

Capture the target objects, initiator identifiers, virtual disks, and target-to-disk associations before modifying access or removing storage. Use read-only Get-* cmdlets and store the output with server identity and UTC timestamp. These examples are intentionally scoped to inventory; protect the output because names, paths, initiator IDs, and storage topology can be sensitive:

$capturedAtUtc = [DateTime]::UtcNow

Get-IscsiServerTarget | Select-Object * |
    Export-Clixml -LiteralPath "C:\ProgramData\StorageOps\targets-$($capturedAtUtc.ToString('yyyyMMddTHHmmssZ')).clixml"

Get-IscsiVirtualDisk | Select-Object * |
    Export-Clixml -LiteralPath "C:\ProgramData\StorageOps\virtual-disks-$($capturedAtUtc.ToString('yyyyMMddTHHmmssZ')).clixml"

Get-IscsiVirtualDisk | Select-Object Path, Description, Size, Status, IsShared |
    Format-Table -AutoSize

Create the destination directory with access limited to the storage administrators before exporting. Property names can vary by module and OS build, so preserve raw object output when a selected property is absent. Supplement cmdlet output with the target server’s volumes, disk health, firewall policy, service events, initiator-side session state, and application ownership. A configuration export does not contain every dependent fact, such as network switch paths, application cluster registration, or the business meaning of a LUN.

Cross-check the target name and VHDX path against the asset inventory and storage owner. Never identify a disk solely by drive letter, display name, or a row number; these can change. Record stable identifiers on the initiator and correlate them with the target name and mapped LUN. If an unexpected mapping is found, investigate before removing it. A mapping can be unused by the operator who is logged in while a remote initiator still has an open session or application dependency.

Provision a new target with explicit identities

The following example illustrates the object sequence for a new test or approved workload. The names, IQN, and paths are placeholders; change them to values validated against the actual initiator and backing volume. The commands create storage and access state and are not dry-run operations. Review them as a change, confirm the target is new, and test with a nonproduction initiator before applying to a live storage service.

$targetName = 'APP01-Data-01'
$initiatorIqn = 'iqn.1991-05.com.microsoft:app01.contoso.example'
$vhdxPath = 'E:\iSCSIVirtualDisks\APP01-Data-01.vhdx'
$sizeBytes = 512GB

if (Test-Path -LiteralPath $vhdxPath) {
    throw "Refusing to create a virtual disk because the path already exists: $vhdxPath"
}

New-IscsiVirtualDisk -Path $vhdxPath -SizeBytes $sizeBytes -UseFixed `
    -Description 'Approved APP01 data LUN; change record CHG-000000'

New-IscsiServerTarget -TargetName $targetName `
    -InitiatorId @("IQN:$initiatorIqn")

Add-IscsiVirtualDiskTargetMapping -TargetName $targetName `
    -Path $vhdxPath -Lun 0

Get-IscsiServerTarget -TargetName $targetName | Format-List *
Get-IscsiVirtualDisk -Path $vhdxPath | Format-List *
Get-IscsiVirtualDisk -TargetName $targetName | Format-List *

In this pattern, the fixed VHDX avoids demand-driven growth on the backing volume but consumes the full allocated capacity; choose dynamic provisioning only when its oversubscription risk is measured and monitored. The module rejects an existing VHDX path for New-IscsiVirtualDisk; importing an existing compatible disk is a different operation and must not be used to overwrite or reinterpret an active production file. The virtual disk path must be absolute and use the required VHDX extension. Microsoft documents additional restrictions: the backing file cannot be on a network share or in a compressed, sparse, or transacted folder. Use a supported local storage path, verify its filesystem and backup design, and do not point two independently managed targets at the same file.

The target’s initiator allow list should be the smallest set of known host identities needed for the workload. Do not add every server in a subnet just because the first login failed. Check the initiator IQN on the client, target identity rule, route, firewall, and service logs. After mapping, confirm the LUN number is unique for that target and the initiator sees the expected device identifier. A successful New-* response confirms object creation, not client-side disk correctness or application readiness.

Protect against concurrent-write and filesystem damage

Block storage presents sectors, not a distributed locking policy. If multiple initiators can write the same ordinary NTFS volume, each host can cache and update filesystem metadata without knowing about the other host. Do not assign one writable LUN to multiple independent Windows hosts unless the filesystem and application are explicitly designed and configured for concurrent access, such as a supported failover-cluster design with its required disk, reservation, and quorum semantics. For a clustered role, follow the Windows Server Failover Clustering and storage-vendor compatibility guidance for the exact target and application. A shared VHDX path or a shared IQN list alone does not provide cluster coordination.

Match each LUN to one documented ownership model: standalone host, clustered disk, guest-cluster shared disk, or application-specific storage. Record which host or cluster owns initialization, partitioning, formatting, and online/offline state. Do not initialize, format, or run repair utilities against a device merely because it appears as RAW or offline; first prove it is the intended new LUN and check the storage owner’s state. A duplicate signature, stale disk record, or cluster reservation may be deliberate protection rather than a formatting defect.

Use separate targets or access identities to reduce accidental cross-workload exposure. Avoid giving an initiator access to every VHDX on the server, and do not reuse a single generic target identity for unrelated tenants or trust boundaries. If you need read-only access for a specialized scenario, confirm the target and initiator feature support and application expectations rather than assuming NTFS read-only state on one side protects the backing data from all other paths.

Measure service health and performance at both ends

Investigate the complete I/O path: application latency and queue depth, initiator disk and iSCSI session, NIC error/drop counters, network congestion and retransmission, target CPU and memory, backing-volume latency, and the underlying physical storage. Record a healthy baseline during a representative workload. A target service being Running or a client reporting a connected session says little about sustained I/O latency, tail behavior, or durability under failure.

For a bounded incident window, inspect relevant System and iSCSI events on both the initiator and target. Compare timestamps, target IQN, initiator IQN, portal addresses, session IDs, mapped LUN, and device identifiers. Do not clear logs or reboot before collecting transient evidence. A client timeout can originate in an overloaded backing volume or failed storage path even while the target process remains alive. Conversely, an available backing volume does not prove a firewall, network route, or authentication path is healthy.

Run throughput, latency, failover, and recovery tests before production acceptance using the actual application I/O shape and storage path. A synthetic sequential read benchmark does not validate database random writes, queue saturation, flush behavior, or recovery after path interruption. During a controlled fault test, verify that the application responds appropriately, outstanding writes are handled according to its contract, and the initiator re-establishes sessions without mounting a second writable copy. Coordinate with storage and application owners and never disrupt a production path to create a test result.

Back up and restore the target as a storage service

Back up both the data and the configuration that makes it addressable: VHDX content, target-to-disk mappings, initiator access rules, CHAP handling, storage paths, firewall policy, service role, and application-level metadata. A copy of the VHDX by itself does not preserve the target name, access control, LUN number, or application ownership. Conversely, configuration export without a recoverable backing file recreates an empty or broken presentation rather than the workload’s data.

Use a backup method that produces a consistent image while initiator writes are active. Coordinate snapshots or VSS processing with the application and storage stack; an arbitrary live file copy of a changing VHDX can be incomplete or inconsistent. For databases and transactional workloads, application-aware backup and recovery testing are essential. Document whether the workload is quiesced, how long it may pause, where backup data is retained, how encryption keys are restored, and which team is authorized to present recovered storage.

Test restoration to an isolated target first. Use a different target name, a restricted initiator allow list, and a segregated network so a restored LUN cannot accidentally compete with the original. Verify VHDX integrity, expected filesystem and application data, target mapping, disk identity, and application-level recovery. Only after the test passes should an approved cutover replace the original endpoint. Keep rollback available until application owners confirm consistency and service operation.

Use a controlled change and incident workflow

For planned creation, review backing-volume headroom, VHDX sizing, fixed or dynamic choice, initiator IQN, target and LUN names, access rules, authentication, firewall scope, backup coverage, and change-window impact. Capture the current target configuration before changes, and confirm that no target name or file path already belongs to another workload. Create and map one new test LUN, connect one approved test host, and validate read/write behavior and recovery before extending access.

For an outage, identify whether the symptom is target discovery, login/authentication, authorization, LUN mapping, session recovery, device enumeration, filesystem state, or application I/O. Compare client and server evidence at the same UTC interval. Check Get-IscsiServerTarget, Get-IscsiVirtualDisk, target service status, server events, firewall rules, backing-volume health, and target-side access assignments. On the initiator, capture portal, target, session, connection, MPIO, disk identity, and event state. Do not reset CHAP, remove a target, detach a VHDX, or initialize a disk until the owning application and storage teams approve the impact.

After a change, confirm from the real initiator that the expected target is discoverable, the correct LUN is present, the disk identifier matches the change record, application read/write checks pass, and monitoring sees the expected latency and free-space headroom. Save the before-and-after evidence and notify the storage owner of any unexpected identity or path. This separates a configuration that merely exists from a service that is actually usable and recoverable.

Windows Server iSCSI Target Server can provide useful Ethernet-backed block storage, but safe operation depends on identity, isolation, capacity, LUN ownership, application consistency, and proven recovery. Treat a target as an explicitly managed storage service rather than a shortcut for turning a file share into a SAN.

Related:

Sources: