As a Microsoft certified partner, we have access to the software bits for OEMs for build Windows Storage Server 2008 R2. One of those bits is the Microsoft iSCSI Target 3.3. This software publishes VHDs over TCP/IP, and therefore does at least a part of the job that StarWind, DataCore, Open-E, OpenFiler, Linux IET and the like do. It’s intended to be an add-on to Windows Storage Server 2008 R2, but in reality it can run on any x64 Windows platform, including Windows 7. Sure, it’ll barf if you run he installer on Windows 7, or regular 2008 R2, but a quicj tweak with Orcas is all that is required to remove the artificial installation constraint. Shh!
The specific scenario I have is a rented Windows Server in a Hosting Datacentre, which I need to backup to a server in our office, behind a NATing firewall. So to start with, I knobble the installer with Orcas and install the Microsoft iSCSI Target 3.3 software on our Windows Server 2008 R2 Enterprise, Server Core machine. It’s day job is as a Hyper-V server, to the only things on it’s RAID5 set are VMs and VHDs, so another VHD or two won’t make any difference.
Next up, I run the knobbled installer on my Windows 7 workstation – just to give me the admin tools. It’s possible to avoid installing the iSCSI target itself by messing with MSIEXEC command lines, but hey – it might be interesting, so I install it, but then stop the service and reset it to manual. If you run MMC.exe, then add the Microsoft iSCSI Target Add-in, you can select the target computer, which is how I manage the iSCSI target on my Server Core installation from my workstation.
The first disappointment is that the iSCSI Target won’t play with variable-sized VHDs, so I have to allocate 127 MB VHD (our hosted server has about 90 GB in use).
After publishing the iSCSI service on TCP 3260 with a non-web publishing rule on my Microsoft ISA Server 2006 firewall, I’m immediately able to add the iSCSI target server from the hosted server. The next disappointment is that I can’t log in to the target. The problem is all too apparent when I “netstat –n” on the hosted server – the iSCSI target has returned its 192.168.x.y LAN address to the discovery process and so I can’t connect to the external IP of the firewall to get a connection – boo!
What I want is to be able to alter the address that is handed back by discovery, but even though I can see it in the registry, the value is hex, and I don’t think I can fake it. I think the proper thing at this point is to create an iSNS server, or create the connection with the command-line tools (eewwww!) but here’s a bodge that really works – add the firewall’s external IP (as a CIDR /32 address (netmask 255.255.255.255)) to the LAN card of the iSCSI Target server. This creates a new “portal” entry on the iSCSI target server with the correct external address that you can select in the Microsoft iSCSI Initiator on the external hosted server. Yay – the hosted server now sees the disks in the NATed firewalled iSCSI target, and I’m good to go with the Windows Server Backup…