🦔 The "Cursed" USB-Stick NAS (Windows Server 2022)

How I bypassed Windows Server's removable media restrictions to build a Parity RAID (RAID 5) and a Simple Volume (RAID 0) entirely out of nested VHDXs on 9 mismatched USB drives.

🚨 The Problem

My goal was to build a redundant, multi-tier Storage Spaces pool using 9 random, mismatched USB sticks and SD cards (ranging from 14GB to 250GB). This storage array was split across a powered USB hub and a secondary USB 3.0 hub, sharing precious bandwidth with my mouse and keyboard. But Windows Server 2022 strictly refused to cooperate. It forbids "Removable Media" from being pooled. Native support? Non-existent.

🛠️ The Workaround

If Windows won't accept the drives natively, we abstract them.

1. Detecting all 9 individual USB drives via the diskpart utility.

2. Formatted all 9 drives to NTFS.
3. Created a dynamically expanding Virtual Hard Drive (very.save.raid.vhdx) on every single USB stick.
4. Mounted the 9 VHDXs. Windows now sees them as standard fixed disks.
5. Combined the 9 VHDXs into a massive 400GB+ Storage Pool.

🏗️ Architecture: The Multi-Tier USB Pool

To not waste the capacity of the largest 250GB drive, I created two distinct Virtual Disks on the same pool:

• Z:\ Cursed_Vault: A Parity layout (RAID 5) scaling up to the limit of the smallest drives. This is the "secure" vault.
• Y:\ Leftover_Dump: A Simple layout (RAID 0) using the remaining space. Maximum speed, zero redundancy.

• To actually turn this monstrosity into a functioning NAS (Network Attached Storage), both volumes were exposed as standard SMB network shares.

• The final masterpiece: Windows Server Manager proudly displaying a perfectly healthy, fully provisioned 400GB+ Storage Pool. As far as the OS is concerned, these are standard enterprise fixed disks—completely unaware that it's actually managing 9 nested VHDXs dangling from a shared USB hub.

🚧 Network & Boot Hacks (The Scripts)

Windows Server fought back on multiple fronts, which required custom scripts (see /scripts folder):

1. The Reboot Amnesia: Windows unmounts VHDXs on USB drives after a reboot, killing the pool.

   👉 Solution: Start-CursedNAS.bat - A script that scans all USB letters, mounts very.save.raid.vhdx, and magically brings the RAID back online.

2. The Offline SMB Block: Windows disables SMB shares (Error 0x800704cf) if no ethernet cable is plugged in.

   👉 Solution: Installed a fake Microsoft KM-TEST Loopback Adapter (IP: 10.10.10.10) to trick the OS into thinking it has a network connection.

3. The Security Cleanup: During troubleshooting, I had to completely disable the firewall to test routing.

   👉 Solution: Ran Force-Offline-SMB.ps1 to create a highly specific Allow-Rule for Port 445 (SMB) and immediately re-enabled the global Firewall (Set-NetFirewallProfile -All -Enabled True). The NAS stays reachable, but the server is professionally secured again.

📊 Benchmarks

Testing via CrystalDiskMark across the Loopback adapter. Testing via CrystalDiskMark across the Loopback adapter revealed exactly what happens when you push a protocol to its absolute breaking point:

1. The Simple Volume (Y:\ - RAID 0)

• Read: ~155 MB/s – Actually decent! Windows efficiently stripes the reads across the drives.

• Write: ~12 MB/s – The USB hub bandwidth limit is screaming for help, but it works.

2. The Parity Volume (Z:\ - RAID 5)

• Read: ~217 MB/s – Surprisingly impressive! Striping the reads across 8+ drives simultaneously actually yields solid network speeds.

• Write: ~1.6 MB/s – Pure nightmare fuel. The CPU calculating Parity logic over 9 nested VHDXs connected to a single, shared USB controller creates a massive bottleneck. Look at the 4K Random Write: 0.00 MB/s. The drive essentially freezes in time.

🔥 The Ultimate Fail-Test

What happens if you pull a drive while copying data to a VHDX-nested USB Parity Pool? Total chaos.

1. The Crash: Yanking a stick from the overloaded USB hub actually hung the entire host system, requiring a hard reboot.

2. The "Dirty Bit" Lockout: After the reboot, my Start-CursedNAS.bat script threw an "Access Denied" error. Windows had set the "dirty bit" on the ungracefully disconnected USB sticks, locking them into Read-Only mode and blocking the Mount-DiskImage command.

3. The Recovery: I manually clicked the drives in Explorer to clear the dirty bit, allowing the VHDXs to mount and the Storage Pool to show up.

4. The Result:

• ❌ Y:\ (Simple / RAID 0): Completely dead. Red 'X' in Server Manager. Unrecognized by the OS.

• ⚠️ Z:\ (Parity / RAID 5): Threw a "Degraded" warning, but successfully came back online. The 4.4GB test file (Ubuntu ISO) was perfectly intact.

The parity logic survived a pulled drive and a hard system crash.

Disclaimer: Do not use this in production.