Remote Terminal

Hello Andreww,

Thank you for posting question on Microsoft Windows Forum!

Based on your query of any Windows Built-in Tools being able to expose a Physical Disk Over iSCSI. Afraid the answer is NO. The Microsoft iSCSI Target in modern Windows Server only exposes virtual disks (VHD/VHDX), it does not present a raw \.\PhysicalDriveN as an iSCSI LUN. That is probably the reason why your Add-IscsiServerTargetMapping -DevicePath "\.\PhysicalDrive1" failed and why the VHDX route either looks empty (if you created a new VHDX) or consumes space (if you convert/copy the disk into a VHDX).

The plausible explanation to the reason why Windows behaves this way is of that the built-in iSCSI Target implementation treats each LUN as a virtual disk file (VHDX) and uses Hyper-V / VHD APIs under the hood. Microsoft’s documented guidance and community answers confirm there is no supported way to export a raw physical device as a target LUN using the shipping Microsoft iSCSI target.

Regarding why your VHDX attempt looked wrong. If you create a new VHDX and publish it as a target you will see an “empty” disk on the initiator. Converting the physical disk into a VHDX copies the data (so it’s visible). But that consumes space on the host because you now have a VHDX file containing your data. That is the limitation you ran into.

If you must stay within the native Windows ecosystem, there are two options, though neither perfectly matches your "Physical View" requirement. The first one is SMB Direct / File Sharing. This is the native Windows way to share data. You get the logical view (files/folders) but lose the sector-level/physical layout view on System A. The other one is the Discrete Device Assignment (DDA). If System A was a Virtual Machine running on System B (Hyper-V), you could "pass through" the physical disk directly to the VM. However, for two standalone physical systems, this is not applicable.

You can consult below article for more information regarding your concern.

• https://techcommunity.microsoft.com/blog/filecab/understanding-virtual-disks-in-iscsi-target-server/425071

Hope the above information is helpful! If it is. Free feel to hit "Accepted" for benefitting others in community having the same query too.

I want this feature

https://www.ufsexplorer.com/manual/standard/iscsi-target-server-control/?srsltid=AfmBOoro4G4wju9Oa9GT5uV8_V72LuKMkZfx8zpeAZMrZBTzUfKr4Myl

Hello,

your requirement is technically clear: you want System A (Windows 11) to see the raw disk of System B (Windows Server 2019) over the network, with full visibility of partitions, sectors, and file systems, as if it were locally attached. The limitation you’ve hit is by design. The built‑in Windows iSCSI Target Server role does not allow direct exposure of \.\PhysicalDriveX. It only supports exporting VHD/VHDX files as iSCSI LUNs. That’s why your attempt with Add-IscsiServerTargetMapping -DevicePath "\.\PhysicalDrive1" fails — the cmdlet enforces the requirement that the device path must be a virtual disk file, not a raw physical disk.

The reason is that Microsoft’s iSCSI Target implementation is designed for block‑level storage virtualization, not raw disk passthrough. It ensures consistency, snapshotting, and portability, but it does not expose the underlying physical disk directly. Tools like UFS Explorer succeed because they implement their own target service that bypasses these restrictions, but that is outside of native Windows capabilities.

To answer your core question: no, it is not possible to achieve this requirement using only Windows built‑in features. You cannot expose a physical disk over IP and have another system mount it as if it were locally attached, with sector‑level visibility, without converting it into a VHDX or using third‑party target software. The closest native option is to use the iSCSI Target Server with a VHDX, but as you’ve seen, that creates a new virtual disk and does not reflect the existing partitions and data of the physical drive.

If your goal is to access the logical file system of System B from System A, the supported approach is SMB file sharing or DFS. If your goal is block‑level remote access, the supported approach is iSCSI with VHDX. Direct raw disk export is not supported by Microsoft’s stack. If this requirement is critical, you will need to rely on third‑party target software, because Windows does not provide this functionality natively.

I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!