Home | Contact
whichnas.com

Using a NAS as an iSCSI target for a Windows file server

A NAS can provide more than shared folders for a Windows file server. By presenting an iSCSI logical unit number (LUN), it supplies block storage that Windows sees as a local disk. The Windows server then formats the volume with NTFS or ReFS, manages permissions, and publishes files through SMB to workstations.

This arrangement suits small businesses, branch offices, and home labs that need centralised storage without buying a traditional storage-area network. It can work well with QNAP and Synology hardware, provided the network, RAID layout, backups, and access controls are designed carefully. Australian offices also need to consider NBN performance, local power reliability, and where business data is physically stored.

Understand the storage roles

An iSCSI target is the service running on the NAS. It offers storage across an IP network. The Windows file server acts as the iSCSI initiator, connecting to that target through its network adapter. The NAS exposes a LUN, while Windows treats the LUN like a locally attached disk.

The file server should remain the only system that mounts a writable LUN intended for NTFS. Workstations should connect to the Windows server through SMB shares rather than connecting directly to the iSCSI volume. Allowing several independent Windows systems to write to the same ordinary NTFS LUN can corrupt the file system unless a suitable cluster-aware configuration is in place.

This approach gives Windows control over file permissions, auditing, quotas, and applications that expect local block storage. The NAS handles the physical disks, RAID, snapshots, replication, and often backup integration. It is different from simply creating a shared folder on the NAS, where the NAS itself manages the file system and SMB service.

Check whether the NAS and network are suitable

Begin with the NAS specifications and software edition. Confirm support for iSCSI targets and LUNs, thin or thick provisioning, snapshots, alerts, and backup jobs. QNAP and Synology systems commonly provide these functions, although menu names and advanced features vary by model. A useful comparison of storage hardware and capabilities is available through NAS buying guides.

Use a NAS with enough memory, CPU capacity, and disk performance for the workload. Office documents place modest demands on storage, while virtual machines, databases, video editing, and large accounting systems can create sustained random I/O. SSD caching may help in some workloads, but it cannot compensate for slow disks, an overloaded CPU, or a congested network.

A dedicated or segmented storage network is preferable. Two 1GbE links may be adequate for a small file server, but 2.5GbE, 10GbE, or faster connectivity is sensible for larger teams. Connect the NAS and server to the same managed switch, use suitable Cat6 cabling, and avoid sending iSCSI traffic over an unreliable Wi-Fi bridge. In a Perth warehouse or a regional New South Wales office, a local wired storage path is far more dependable than relying on an internet connection.

Design the LUN and RAID layout

Choose RAID according to the number and type of disks, the required capacity, and the consequences of failure. RAID 1 suits two-drive systems, RAID 6 offers stronger protection on larger arrays, and RAID 10 can deliver useful random-write performance where capacity efficiency is less important. Synology Hybrid RAID and QNAP storage pools may simplify expansion, but administrators still need to understand the underlying redundancy.

A LUN should be sized with room for Windows updates, file growth, shadow copies, and temporary workloads. Thick provisioning reserves space immediately and makes capacity easier to track. Thin provisioning can be flexible, but it creates a serious risk if the storage pool fills unexpectedly. Configure alerts well below the critical threshold and review them rather than dismissing them as routine notifications.

RAID protects availability after certain disk failures; it does not protect against accidental deletion, ransomware, fire, or a failed NAS controller. A second NAS, removable backup media, or encrypted cloud storage should hold independent copies. For an Australian business, an off-site copy is particularly important where bushfire, flood, or extended power disruption could affect the primary premises.

Configure the iSCSI connection in Windows

On the NAS, create an iSCSI target with a clear name, then create and map a LUN to that target. Use a thick LUN for predictable capacity unless there is a specific reason to use thin provisioning. Enable CHAP authentication where supported, restrict access to the file server’s IP address or initiator name, and avoid exposing iSCSI ports to the public internet.

In Windows Server, open the iSCSI Initiator, enter the NAS address, and connect to the target. Set the connection to reconnect automatically after a reboot. Windows Disk Management should then show the new disk as offline or uninitialised. Bring it online, initialise it with GPT, create a volume, and format it with NTFS or ReFS according to the application and Windows Server version.

Give the volume a meaningful label and document its size, LUN identifier, NAS address, and purpose. Do not place the Windows operating system and all business data on an untested single LUN without a recovery plan. If the server hosts virtual machines, consider separate LUNs or volumes for operating systems, application data, and backups.

Improve resilience, performance, and security

For a production server, use separate network paths where possible. Multiple network adapters, switch paths, and MPIO can reduce the impact of a failed cable or network port. MPIO requires compatible NAS support and correct Windows configuration; simply plugging in two cables does not automatically provide load balancing or failover.

Keep iSCSI traffic on a trusted VLAN or physically separate network. Block unnecessary inbound access with firewalls, use strong administrator credentials, enable multifactor authentication on the NAS where available, and keep QTS, QuTS hero, DSM, Windows Server, and switch firmware current. Disable unused services such as internet-facing administration and UPnP.

Performance should be measured rather than guessed. Test file transfers and application response during normal and busy periods, watching NAS CPU usage, disk latency, network throughput, and Windows event logs. Australian offices may see different conditions between a cool Melbourne server room and a hot Brisbane comms cupboard, so temperature alerts and reliable air conditioning matter. A UPS with USB or network shutdown signalling can prevent file-system damage during short outages.

Useful configuration decisions to record include:

Back up and maintain the file server

Backups must operate at the Windows file and application level as well as the NAS storage level. NAS snapshots can provide quick recovery from accidental changes, but snapshots usually remain on the same physical system and may be affected by ransomware or hardware failure. Replication to another device is stronger, especially when the second device is in another building or region.

Use a schedule that reflects the business. A small Adelaide office might take frequent snapshots during working hours, nightly image backups, and weekly off-site copies. A design firm handling large media files may need shorter recovery point objectives and a second high-speed storage system. Cloud backup can help with remote retention, although Australian upload speeds and data egress costs should be checked before committing to a large dataset.

Test recovery by restoring files, mounting a backup, and rebuilding a spare Windows server or test LUN. Verify NTFS permissions, shared-folder paths, applications, and user access. Keep at least one backup isolated from ordinary administrator credentials. If personal information is stored, review the Privacy Act obligations, contractual requirements, and whether the chosen cloud provider stores data within Australia or overseas.

Maintain a change log for firmware upgrades, disk replacements, LUN expansion, and network changes. It can sit beside vendor documentation and archived technical material when older systems or inherited infrastructure need to be traced. Clear records reduce guesswork when a contractor, managed service provider, or internal administrator takes over.

A NAS-based iSCSI design can give a Windows file server reliable, expandable storage without the cost of a dedicated SAN. Start with a supported NAS, a stable wired network, carefully sized RAID and LUNs, restricted access, and tested backups. Build the setup in a lab or maintenance window first, then document every setting before placing business data on it.