Jump to content
IGNORED

Diskless Windows 10 PC Setup Procedure


Recommended Posts

Following is a procedure for setting up a PC to run Windows 10 diskless (i.e. with no local storage).

 

This procedure should also work for setting up diskless Windows Server 2012/ Windows Server 2012 R2, though I have not tried it.

 

This is a Windows-only procedure with no Linux involvement, so no Linux expertise is required. "Server" refers to the PC running Windows Server 2012 with iSCSI target service acting as remote disk server. "Client" refers to the diskless PC booting OS remotely over Ethernet.

 

It is up to the individual user to decide which of their audio PCs to run diskless. In a dual PC setup it should be possible for both control PC and audio PC (using AO terminology) to run diskless, though a 3rd PC or NAS will be needed to fulfill the role of iSCSI target. The procedure below only covers setting up a PC with Windows Server 2012 R2 to act as iSCSI target.

 

As there are many alternatives possible, please consider this procedure as a guide, as it represents just one solution. A Linux-based iSCSI target is much more cost-effective than a WS2012-based iSCSI target.

 

 

*************************

Diskless Windows 10 Setup

 

 

Jan 17, 2015

Sam Chau

 

 

 

Client PC Requirements

- Gigabit Ethernet NIC with PXE boot support

 

 

Server PC Requirements

- Gigabit Ethernet NIC, with driver for Windows Server 2012 R2

(note: some consumer class NICs lack driver for Windows Server 2012 R2 and cannot be used)

 

 

Ethernet Switch

- Gigabit Ethernet switch

- Connection to home wireless/wired router as DHCP server

- Alternative: use static IPs on the same subnet for both server and client

 

 

Contents of iscsi.ipxe (text) file:

#!ipxe

 

 

echo iscsi.ipxe script running...

ifopen net0

dhcp

set net0/gateway 0.0.0.0

echo IP: ${net0/ip}, Gateway: ${net0/gateway}

set keep-san 1

echo keep-san: ${keep-san}

sanboot iscsi:<server IP>::::iqn.1991-05.com.microsoft:<server name>-win10-target

boot

 

 

Note:

- replace <server IP> with server static IP address: e.g. 192.168.0.100

- replace <server name> with server name, e.g. audioserver. This name must match what the client sees within iSCSI Initiator

- setting gateway address to 0.0.0.0 is a workaround to avoid Windows 10 suffering an "INACCESSIBLE BOOT DEVICE" blue screen crash during boot

 

 

Setup Procedure

Hardware setup:

1. Connect client PC to server PC via their NICs

2. Options for client PC IP address assignment

A. Connect client PC to home wireless/wired router - use router DHCP server

B. Configure DHCP server on Windows Server 2012 R2 to assign IP address to client

C. Set static IP address on same subnet for client

For options B & C, internet connection for client is optional

3. Enable PXE boot option in client PC BIOS setup

 

 

Server:

1S. Install Windows Server 2012 R2 (Standard, Essentials, etc.)

2S. Assign static IP address to NIC

3S. Enable Remote Desktop feature ("Allow remote connections to this computer") for allow client to remote manage server running "headless"

4S. Using Server Manager, install iSCSI target feature

5S. Create a disk folder to carry VHDX files, e.g. C:\iSCSIVirtualDisks

6S. Share C:\iSCSIVirtualDisks folder with rear/write permission for client username

7S. Create C:\TFTProot folder

8S. Put ipxe-undionly.kpxe and iscsi.ipxe files in C:\TFTProot

9S. Download and set up Tiny PXE Server (Tiny PXE Server - reboot.pro)

- Update config.ini:

- root=C:\TFTProot

- filename=ipxe.undionly.kpxe

- altfilename=iscsi.ipxe

- proxydhcp=1

- poolsize=0

- Click "Online" to launch pxesrv

10S. At Control Panel\System and Security\Windows Firewall\Allowed apps

- Enable iSCSI Service

- Add entry for pxesrv.exe

 

 

Client:

1C. Connect client PC to home network via gigabit Ethernet NIC and cable

2C. Attach local storage (HDD/SSD)

3C. Install Windows 10 OS into hard disk

- Copy OS install files into FAT32 formatted USB flash drive to use for OS installation

4C. Install NIC driver and other device drivers (graphics, audio, etc.) as needed

5C. Ensure client can properly browse on Internet

6C. Launch iSCSI Initiator

- Type "iscsicpl" <Enter> at the Command Prompt window and answer Yes to the prompt

- This will configure Win10 to auto launch the iSCSI initiator service at OS startup

7C. Launch Registry Editor (regedit.exe) to set boot flag for LAN driver

- Locate the LAN driver service name under HKLM\SYSTEM\CurrentControlSet\Services

- Example: for motherboards featuring Intel I217V/LM, I218V/LM, I219V/LM LAN the driver service name is: e1dexpress

- Click on the driver service name, locate the Start key (REG_DWORD), double-click it and change its value to 0

- Repeat this Start key value change to 0 in HKLM\SYSTEM\ControlSet001\Services and HKLM\SYSTEM\ControlSet002\Services

- Close Registry Editor

8C. Download and run Disk2VHD.exe (from Microsoft Sysinternals: https://technet.microsoft.com/en-us/sysinternals/ee656415.aspx)

- Ensure "Use Vhdx" and "Use Volume Shadow Copy" checkboxes are checked

- In "VHD File Name" box, enter "\\<Server IP>\<share name>\Win10.VHDX (e.g. \\192.168.0.100\c\Win10.VHDX)

- Run Disk2VHD to create VHDX file on server

 

 

Server:

11S. Set up iSCSI target LUN

- Use "existing VHDX" option to select Win10.VHDX

- Add MAC address of client to iSCSI initiator list

 

 

Client:

9C. Launch "iSCSI Initiator"

- On "Discovery" tab, click "Discover Portal" and enter IP address or DNS name of server

- on "Targets" tab, ensure a target appears on "Discovered targets" list

- target name should look like: iqn.1991-05.com.microsoft:<server name>-Win10-target

10C. Shut down Windows and detach hard disk from client

11C. Power up client and it should proceed to PXE boot

- PXE boots to iPXE from server, then chains to iSCSI target LUN to start Windows 10 boot

 

 

 

Notes:

A. This procedure sets up a fixed size VHDX on the server. An alternative is to create a new dynamic VHDX (of desired max size) on the server, mount it locally (using iSCSI Initiator running on the server), connect the client disk to the server via USB-to-SATA adapter, then partition copy the client disk to the mounted VHDX. This preserves the dynamic nature of the VHDX file and helps conserve disk space on the server.

 

-end-

Link to comment
  • 3 weeks later...

Thank you for this! I am going to give it a try though I will admit these instructions look a bit daunting. I know enough about computing to be a hack but this looks over my head.

12TB NAS >> i7-6700 Server/Control PC >> i3-5015u NAA >> Singxer SU-1 DDC (modded) >> Holo Spring L3 DAC >> Accustic Arts Power 1 int amp >> Sonus Faber Guaneri Evolution speakers + REL T/5i sub (x2)

 

Other components:

UpTone Audio LPS1.2/IsoRegen, Fiber Switch and FMC, Windows Server 2016 OS, Audiophile Optimizer 3.0, Fidelizer Pro 6, HQ Player, Roonserver, PS Audio P3 AC regenerator, HDPlex 400W ATX & 200W Linear PSU, Light Harmonic Lightspeed Split USB cable, Synergistic Research Tungsten AC power cords, Tara Labs The One speaker cables, Tara Labs The Two Extended with HFX Station IC, Oyaide R1 outlets, Stillpoints Ultra Mini footers, Hi-Fi Tuning fuses, Vicoustic/RealTraps/GIK room treatments

Link to comment
  • 4 weeks later...
Thank you for this! I am going to give it a try though I will admit these instructions look a bit daunting. I know enough about computing to be a hack but this looks over my head.

 

I have been trying to set this up, but it just does not boot over the network for me. Have you had any success?

Link to comment
I have been trying to set this up, but it just does not boot over the network for me. Have you had any success?

 

Assuming your pc is trying to pxe boot?

 

I had to fiddle with the iscsi.ipxe script and make sure it had a line to set the initiator-iqn as below: (change to reflect your devices names/addresses and take out the < & >)

 

#!ipxe

 

 

echo iscsi.ipxe script running...

ifopen net0

dhcp

set net0/gateway 0.0.0.0

set initiator-iqn <MAC OF CLIENT>

echo IP: ${net0/ip}, Gateway: ${net0/gateway}

set keep-san 1

set root-path iscsi:<server ip>::::iqn.1991-05.com.microsoft:<server target>

echo keep-san: ${keep-san}

sanboot ${root-path}

boot

 

 

 

In Tiny pxe set as below

 

Capture.JPG

Link to comment
Assuming your pc is trying to pxe boot?

 

I had to fiddle with the iscsi.ipxe script and make sure it had a line to set the initiator-iqn as below: (change to reflect your devices names/addresses and take out the < & >)

 

#!ipxe

 

 

echo iscsi.ipxe script running...

ifopen net0

dhcp

set net0/gateway 0.0.0.0

set initiator-iqn <MAC OF CLIENT>

echo IP: ${net0/ip}, Gateway: ${net0/gateway}

set keep-san 1

set root-path iscsi:<server ip>::::iqn.1991-05.com.microsoft:<server target>

echo keep-san: ${keep-san}

sanboot ${root-path}

boot

 

 

 

In Tiny pxe set as below

 

[ATTACH=CONFIG]24552[/ATTACH]

Thank you. What is the Boot File jpeg at the bottom? I don't remember coming across that.

Link to comment
It's a snip from the Tiny PXE server app which you need to have running on your ISCSI server..If you watch that as your client is booting you'll see if it's made contact and any errors

 

Thanks. Let me try this and I will report back. I have been struggling with this for many days now.

Link to comment
It's a snip from the Tiny PXE server app which you need to have running on your ISCSI server..If you watch that as your client is booting you'll see if it's made contact and any errors

 

I was trying to connect, but was not able to do that;

 

screen5.png

IMG_1043.jpg

Link to comment

Here's a screen shot of my Tiny PXE Server running. The ProxyDhcp and HTTPd checkboxes are checked, and IP Pool Size is set to 0, since my wireless router serves as DHCP server, so I don't need this functionality from Tiny PXE Server. I also have a static IP assigned to the server box NIC.

 

The iscsi.ipxe script is transferred from the server to the diskless client via TFTP. Depending on where iscsi.ipxe is located, the config.ini for Tiny PXE Server needs to have a line to specify the root folder to be used by TFTPd. For example:

 

root=C:\TFTProot

Tiny_PXE_Server.png

Link to comment

Finally it booted last night by following all the instructions given here. Big thanks to scan80269, would't be able to do it without these instructions. Also thanks to Possum Jenkins; I did add the line in as he mentioned above. Now some questions;

 

1. How I add one more target to same server? I think I will have to add two more lines in the iscsi.ipxe script, one for the additional MAC of Client-2, and one for additional target for Client-2;

 

#!ipxe

 

 

echo iscsi.ipxe script running...

ifopen net0

dhcp

set net0/gateway 0.0.0.0

set initiator-iqn <MAC OF CLIENT-1>

set initiator-iqn <MAC OF CLIENT-2>

echo IP: ${net0/ip}, Gateway: ${net0/gateway}

set keep-san 1

echo keep-san: ${keep-san}

sanboot iscsi:<server IP>::::iqn.1991-05.com.microsoft:<server name>-win10A-target

sanboot iscsi:<server IP>::::iqn.1991-05.com.microsoft:<server name>-win10B-target

boot

 

2. I would like to use another computer as Server. If I set the IP for the new server NIC same as old server NIC and name this server same as the old server, would that work, without having to create new target. I will move the current Win10.VHDX to new server and create the second target with different name on new server.

 

3. I am not sure how to find the registry entries for the NIC's. For my Mellanox NIC I was lucky because the files were named mlxxxx, etc. I do not know how to find that for my Intel x520.

 

Let me know please. Thanks.

Link to comment

Congratulations, sig8!

 

1. Adding a second sanboot command into iscsi.ipxe script *may* work. You need to set up the win10A target to include only the MAC address of client1's NIC as initiator, and the win10B target to include only the MAC address of client2's NIC. Then, when client2 attempts to diskless boot, the first sanboot command intended for client1 would fail, but the second sanboot command should work. I haven't tried this myself, and would be interested to hear if it works for you.

 

2. I think this can work. If client1 and client2 will be running different apps, then in addition to separate targets for each client, there should be two VHDX files. This enables each client to boot Win10 and auto-launch different apps (HQPlayer, etc.) i.e. customized independent of the other client, and should also minimize Windows activation issues.

 

3. The service/driver name for your Intel x520 is likely ixn65x64. I don't have an Intel x520 myself, but I looked up the name by checking INF files within Intel's Ethernet driver package.

Link to comment

What if you wanted to install a program after diskless boot, such as Process Lasso or Audiophile Optimizer, etc. Can you do that after the diskless boot, or you should do it before creating the image, or one should not use these types of optimizing programs altogether.

 

Thanks.

Link to comment

Running Windows diskless places no restrictions whatsoever on what programs you can install. The image is just the starting point, so you can install anything afterwards. Any app you install will make it into the VHDX virtual disk file. I see no reason why AO, Process Lasso, Fidelizer, etc. cannot be installed for a diskless Windows box.

Link to comment
Running Windows diskless places no restrictions whatsoever on what programs you can install. The image is just the starting point, so you can install anything afterwards. Any app you install will make it into the VHDX virtual disk file. I see no reason why AO, Process Lasso, Fidelizer, etc. cannot be installed for a diskless Windows box.

 

Thanks scan80269. I did not think VHDX file will get update. I am impressed.

Link to comment

I figured out how to get different clients to boot from different iSCSI virtual disks using a single iscsi.ipxe script:

 

#!ipxe

 

echo iscsi.ipxe script running...

ifopen net0

dhcp

set net0/gateway 0.0.0.0

echo IP: ${net0/ip}, Gateway: ${net0/gateway}

set keep-san 1

echo keep-san: ${keep-san}

sanboot iscsi:<server IP>::::iqn.1991-05.com.microsoft:<server name>-win10A-target || # for client1

sanboot iscsi:<server IP>::::iqn.1991-05.com.microsoft:<server name>-win10B-target # for client2

boot

 

 

Note the first sanboot command having a "||" (two vertical bars, not the letter l) at the end. This prevents the iPXE script from aborting immediately when the first sanboot command fails for client2 bootup, so it can move on to the second sanboot command which works.

 

This trick can be generalized to multiple clients. Just add "||" to the end of each sanboot command.

 

The client MAC address will need to be set properly for each iSCSI target to make each client boot exclusively from its dedicated target.

Link to comment

Cool, you can also manipulate which boot image is mapped on the ISCSI target side. Curiously if you enable two virtual drives simultaneously, the first will be booted and the second will be mapped as a local disk. I use this second disk to backup and install additional boot images using the Linux dd command to and from the second virtual disk and then later remap that disk as the primary boot drive.

Pareto Audio aka nuckleheadaudio

Link to comment

My subjective impressions:

 

Listened for the first time last night with pxe boot and Mellanox fiber NIC in NAA. Was little disappointed, it seemed as if noise level increased a bit, gave it few hours, this morning also it was the same. I know diskless boot cannot do that, so the only difference was the NIC. I was using Intel x520 before in my NAA, but since it did not boot on iSCSI, I placed Mellanox in NAA to set it up for PXE per instructions here and it booted up as reported earlier.

 

So I thought let's put the Intel back in NAA and see what that dose, but it was flashed to do iSCSI, I had some ideas about the commands, so I flashed it to do PXE (jabbr will be proud). I found this on-line guide very helpful for Intel x520 flash utility: ftp://ftp.supermicro.com/CDR-B9_1.00_for_Intel_B9_platform/Intel/LAN/v16.8.1/APPS/BOOTAGNT/DOCS/boot_util.htm

 

Now I can say that there is a decent improvement in SQ, and I am staying here.

 

My this Intel NIC does have the sticker in the back suggesting it is authentic. My other Intel NIC which was in HQPC did not have the sticker (whatever that means).

Link to comment
Very very interesting.

 

So putting together a few impressions, is it correct that the Intel x520 with the sticker has a better SQ than the one without?

 

I have not tried both Intel's in one location yet, but certainly Intel (with sticker) sounds better than Mellanox in NAA. I have not put the Intel without sticker in the NAA.

 

When I put the Intel (without sticker) in HQPC it made it worst compared to Mellanox.

 

I will try Intel without sticker in NAA in few days.

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...