Jump to content
IGNORED

Diskless Windows 10 PC Setup Procedure


Recommended Posts

bodiebill: The way I do is to keep the *.vhdx file clean of any AO, drivers, etc., so that we can always have a clean copy of Windows installation. All other things like drivers, PL, Fidelizer, etc., I have been able to install after diskless boot (except my Intel fiber NIC driver, that goes on before creating .vhdx). Drivers, PL, Fidelizer, etc. get updated, and I think of them as-needed basis, not cluttering .vhdx, but whatever works. Thanks.

 

sig8: I do not fully understand, but that is me as I am totally new to network booting. I was assuming that any change to the audio PC will be reflected in the *.vhdx file. When I restart the audio PC this change will still be there, or am I wrong? So how do you keep the *.vhdx file clean of such changes? Or do you mean an initial *.vhdx file which you keep as a backup?

 

audio system

 

Link to comment
sig8: I do not fully understand, but that is me as I am totally new to network booting. I was assuming that any change to the audio PC will be reflected in the *.vhdx file. When I restart the audio PC this change will still be there, or am I wrong? So how do you keep the *.vhdx file clean of such changes? Or do you mean an initial *.vhdx file which you keep as a backup?

When I read update .vhdx" file in your post, it made me think as if you recreate the file somehow, but what I meant is just to have a clean copy of .vhdx to fall back on, just in case we mess-up too much with boot .vhdx.

Link to comment

A new procedure to install Windows 10 directly into an iSCSI virtual disk is almost ready for posting. It is much more elegant and efficient than my original procedure, as it eliminates the need to use a temporary physical disk in the client, and no disk partition copying is needed.

 

However, there is one big caveat (well, probably more than one, but this one is big): I only got it to work with the latest Windows 10 Anniversary Edition (Version 1607, "Redstone 1") released by Microsoft earlier this month. All attempts with older Windows 10 Version 1511 "Threshold 2" and Windows Server 2012 R2 have failed. It appears that the latest Win10 Version 1607 has added support for over-the-network OS installation into remote iSCSI virtual disks. This OS has made a critical difference with my new procedure. With Win10 Version 1511 and WS 2012 R2, the recurring problem is OS installation crashing shortly after the first triggered system restart. Basically, as soon as the system restarts during OS installation, it fails to re-establish a connection to the iSCSI virtual disk that's partway into the process. This shows up as a blue screen crash "INACCESSIBLE BOOT DEVICE". I have not figured out a way to modify the OS install files for these editions of Windows to circumvent this issue. It appears to be non-trivial! Thus, at least for the time being, the Windows 10 Version 1607 "RS1" is the only OS that can be direct installed into an iSCSI virtual disk, without going through a physical hard disk and disk partition copying from the client.

 

It is also possible that my new procedure can fail for clients featuring network cards (NICs) that have no inbox driver support by Win10 Version 1607 OS. In this scenario, offline injection of a driver provided by NIC supplier into OS install files will be necessary, and I don't know if even that would be sufficient, as I do not have a client with a PXE bootable NIC that Win10 OS has no driver for. I have tested clients featuring various Intel and Realtek branded NICs (often down on motherboard) and they have all worked, so I have no idea how likely are NICs out there that are not supported natively by Win10 OS.

Link to comment

I am SO close, but stuck. I followed the instructions pretty faithfully. I get all the way to it trying to boot to my virtual disk and get "Disk Boot Error". When I ran Disk2VHD, I could choose either just the C:\ drive or the C: drive and the weird 100MB partition.

 

When I selected them both, it hangs at the boot. When I only select C:\, I get Disk Boot error.

 

I'm planning on setting up a half dozen machines, but just need this first one to work!

 

Oh, one major difference. I am setting up Windows 7. Some of the machines in use won't run Windows 10.

 

Sorry that this is my first post and truly appreciate the effort of those involved.

 

Thanks,

 

Tom!

Link to comment

One thing I've assumed is that Disk2VHD will take care of marking the iSCSI disk as bootable, but perhaps this is not always the case. The iPXE sanboot command will fail if the iSCSI disk is not seen as a bootable disk.

 

To ensure the iSCSI disk residing on the server is bootable, do the following (on the server):

1. Disable the iSCSI virtual disk (in Server Manager, under iSCSI)

2. In File Explorer, locate the VHDX file for the iSCSI virtual disk (e.g. under c:\iSCSIVirtualDisks folder)

3. Right-click the VHDX file and select "Mount". The iSCSI virtual disk will get a drive letter (e.g. D and File Explorer should display the drive contents at root level

4. Open an Administrator (elevated) command prompt, then launch diskpart

5. At the diskpart command prompt, select the mounted iSCSI virtual disk by its drive number, e.g. select disk 1

6. Select disk partition 1 (there should only be one disk partition if you do a "list partition" command)

7. Type "detail partition". Look at the returned info

8. If "Active" displayed as "No", type "active" to mark the partition active

9. Exit diskpart.

10. Locate the drive letter for this mounted iSCSI virtual disk. Right click on the drive icon and select "Eject". This drive letter should now disappear.

11. Enable the iSCSI virtual disk in Server Manager (reverse of step 1).

 

One more comment. My procedure depends on the C: drive partition on the temporary physical drive to be bootable by itself. Sometimes, when installing Windows OS, a small (~100MB) System partition gets created by the Windows installer along with the C: disk partition that will carry the OS files. In such a disk configuration, the small System partition is marked bootable, and carries boot critical files such as the BCD (under \Boot folder), and the C: disk partition will not have a \Boot folder. This type of disk configuration will very likely have trouble with sanboot as an iSCSI virtual disk. You need to ensure the \Boot folder (including the BCD file, etc.) is present in the C: disk partition along with the rest of the OS files. If you look at the files in the iSCSI virtual disk (after step #3 above) and do not see a \Boot folder at root, then you will have to redo my procedure from the beginning, and also find a way to get the physical hard disk formatted with a single NTFS partition occupying the entire disk (thus leaving no free disk space for Windows installer to create a System Reserved partition that we don't want), before proceeding to installing Windows OS (Win10 or Windows Server 2012 R2) into it.

 

Another possible solution is to copy all the files in the System partition, including the \Boot folder, back into the C: partition. The BCD may need editing (with BCDedit). The System partition is normally hidden and does not get a drive letter, so assigning a drive letter (using diskpart) will also be needed. All this may or may not be easier than starting the procedure over (with a single C: NTFS partition for the physical disk), depending on your comfort level in messing with OS boot structure.

Link to comment

I've made progress. I gave a drive letter to the 100MB partition. I created \Boot on the C:\ drive (only) VHDX. I used Diskpart to make that partition active.

 

Then I moved it to the server that is the Tiny PXE host and re-setup the iSCSI.

 

When booting, I get a lot farther as it tries to boot. Then I get a Black screen.

 

I think the problem is the BCD, but I can't figure out how to edit the BC.D in this mounted VHDX. It wants to edit the actual machine on which it is running, which is bad.

 

Any thoughts? I'm so close and this would give instructions for anyone with the 100MB partition problem

Link to comment
I've made progress. I gave a drive letter to the 100MB partition. I created \Boot on the C:\ drive (only) VHDX. I used Diskpart to make that partition active.

 

Then I moved it to the server that is the Tiny PXE host and re-setup the iSCSI.

 

When booting, I get a lot farther as it tries to boot. Then I get a Black screen.

 

I think the problem is the BCD, but I can't figure out how to edit the BC.D in this mounted VHDX. It wants to edit the actual machine on which it is running, which is bad.

 

Any thoughts? I'm so close and this would give instructions for anyone with the 100MB partition problem

 

To edit the BCD in the mounted VHDX, you need to use the /store option. For example,

 

bcdedit /store D:\Boot\BCD /enum

 

where D: is the drive letter assigned to the mounted VHDX.

 

The entries within the BCD that may need editing:

 

Windows Boot Manager

--------------------------

device partition=D:

 

Windows Boot Loader

------------------------

device partition=D:

osdevice partition=D:

 

You need to verify the drive letter matches what Windows actually assigned to the mounted VHDX. Since the server already has its own C: for server OS, the mounted VHDX can only get D:, E:, etc.

 

Example command: bcdedit /store D:\Boot\BCD /set {bootmgr} device partition=D:

 

I recommend you make a copy of the existing BCD before doing any edits. If you trash the BCD by accident, you can rebuild it by using:

 

bootrec /rebuildbcd

 

after booting up into recovery mode.

Link to comment
  • 2 weeks later...
Did anyone succeed in running disk2vhd from a client in core mode and make the network boot work? Or should that be done in GUI mode, and then convert to core after network booting to the GUI version?

 

Sent from my SM-T310 using Computer Audiophile mobile app

 

I haven't tried core mode yet, but I suspect either method can work. There should be no difference in networking between core and GUI modes. The virtual disk can start with booting a GUI OS, then get converted to core mode. Getting the physical disk to run in core mode first should also work, provided you can do the disk2vhd step properly.

 

I recently found that connecting the prepared client hard disk to the server to run disk2vhd gets the job done faster, as SATA (or even USB 3.0) has much higher throughput than gigabit Ethernet. I can't wait to see the 2.5GBASE-T and 5GBASE-T networking standards get ratified by IEEE, followed by the USB3-to-5GBASE-T adapter dongles appearing in the market. Gigabit Ethernet is slow compared to modern interfaces like SATA, USB3, PCI Express, Thunderbolt...

Link to comment
I haven't tried core mode yet, but I suspect either method can work. There should be no difference in networking between core and GUI modes. The virtual disk can start with booting a GUI OS, then get converted to core mode. Getting the physical disk to run in core mode first should also work, provided you can do the disk2vhd step properly.

 

I recently found that connecting the prepared client hard disk to the server to run disk2vhd gets the job done faster, as SATA (or even USB 3.0) has much higher throughput than gigabit Ethernet. I can't wait to see the 2.5GBASE-T and 5GBASE-T networking standards get ratified by IEEE, followed by the USB3-to-5GBASE-T adapter dongles appearing in the market. Gigabit Ethernet is slow compared to modern interfaces like SATA, USB3, PCI Express, Thunderbolt...

Thanks. I was asking because before I left on vacation I had a problem booting and when I tried to set it up again I did not succeed. When I am back I will try running disk2vhd from the client in GUI (or with its disk attached to the server - good idea!), but first I will reinstall the client disk on one partition, i.e. without the small system reserved partition.

 

Sent from my SM-T310 using Computer Audiophile mobile app

 

audio system

 

Link to comment
  • 2 weeks later...
Did you finish that write up yet?

 

I encountered another technical snag with my new procedure, so I'm still testing and refining.

 

I'm also holding off publishing the new procedure for a separate reason that I cannot mention. Once things get worked out I'll be posting, but at present the ETA is a bit uncertain.

Link to comment

I'm interested in this subject because I recently had an encounter with CryptoLocker ransomware and it was unpleasant. I thought if I could boot from an iSCSI device that was actually a zfs volume on a NAS4Free storage server I could use the zfs snapshot/rollback capability to quickly recover from such problems. I've gotten this to work when the iSCSI drive is used as data drive in Windows 10 but having it be the boot drive would solve a lot of problems.

Link to comment
I'm interested in this subject because I recently had an encounter with CryptoLocker ransomware and it was unpleasant. I thought if I could boot from an iSCSI device that was actually a zfs volume on a NAS4Free storage server I could use the zfs snapshot/rollback capability to quickly recover from such problems. I've gotten this to work when the iSCSI drive is used as data drive in Windows 10 but having it be the boot drive would solve a lot of problems.

 

The procedure in the first post of this thread does allow the iSCSI virtual drive to be the boot drive for any edition of Windows 10, and also Windows Server 2012 R2. There is just no coverage for direct Win10 OS install over the network into a freshly prepared iSCSI virtual drive, but that's what I've been working on as a new procedure.

 

The thread title doesn't mention booting Windows from iSCSI drive as it is implied. I wouldn't have bothered if the procedure yielded an iSCSI drive that is not bootable and therefore usable only as a data drive.

Link to comment
Thanks. I was asking because before I left on vacation I had a problem booting and when I tried to set it up again I did not succeed. When I am back I will try running disk2vhd from the client in GUI (or with its disk attached to the server - good idea!), but first I will reinstall the client disk on one partition, i.e. without the small system reserved partition.

 

Just a short note, that my Audio PC again boots diskless to my Control PC. I first installed the client OS on one partition (which includes a boot folder) and this seems to make things more reliable and also somewhat faster.

 

audio system

 

Link to comment
Just a short note, that my Audio PC again boots diskless to my Control PC. I first installed the client OS on one partition (which includes a boot folder) and this seems to make things more reliable and also somewhat faster.

 

I've also noticed Win10 RS1 OS booting faster with my new over-the-network installation procedure (still under development). The LAN activity lights on the RJ45 connector go out for a shorter duration (<6 seconds) during the diskless boot, and the overall OS boot time is noticeably reduced vs. the original procedure of cloning a bootable local hard disk to the iSCSI virtual disk.

 

One big caveat with the over-the-network installation method is that I only got it to work for latest Windows 10 RS1 (Version 1607) OS. I've been testing with Win10 TH2 (Version 1511) and Windows Server 2012 R2 and they don't work with this procedure. The procedure in the first post of this thread is still the working solution for these OS.

Link to comment
Just a short note, that my Audio PC again boots diskless to my Control PC. I first installed the client OS on one partition (which includes a boot folder) and this seems to make things more reliable and also somewhat faster.

 

I forgot to add that it did not work when, on the Control PC (= iSCSI server), in Audiophile Optimizer the services are disabled OR in Fidelizer Pro i choose the 'Purist' setting. So On the Control PC I let AO keep the services enabled, and I choose the FP 'Audiophile' setting.

 

On the Audio PC (= iSCSI client), I use AO and FP with the more rigorous settings.

 

audio system

 

Link to comment
  • 4 weeks later...

Thread has gone quiet...

 

Just wanted to add my experience to combine diskless audio PC (client) with Audiophile Optimizer, with both PC's (audio- and control PC = server) running on WS2012 R2 in core mode. I mention these here as I think similar applies to Windows 10.

 

For diskless to work I found out that the following AO settings are required:

- disable SCSI-MiniPort Drivers: no on both PC's

- disable drivers and services: no on server

- disable network related services: no on both PC's

- disable Windows Management Instrumentation: no on server

 

Is this recognized by others who tried to run diskless with AO?

 

audio system

 

Link to comment
Thread has gone quiet...

 

Just wanted to add my experience to combine diskless audio PC (client) with Audiophile Optimizer, with both PC's (audio- and control PC = server) running on WS2012 R2 in core mode. I mention these here as I think similar applies to Windows 10.

 

For diskless to work I found out that the following AO settings are required:

- disable SCSI-MiniPort Drivers: no on both PC's

- disable drivers and services: no on server

- disable network related services: no on both PC's

- disable Windows Management Instrumentation: no on server

 

Is this recognized by others who tried to run diskless with AO?

 

This is good info. I was thinking that the diskless audio PC will need to keep drivers and services enabled as well, but overall it makes sense as diskless means remote storage accessed over network, so networking and iSCSI related services cannot be disabled on both PCs.

 

Today I achieved a breakthrough in getting WS2012 R2 to install over the network into a virtual disk for an audio PC. I'm continuing to test to ensure this success is not by accident. I've also played with WS2016 and it looks like it can be remotely installed in much the same way as Windows 10 RS1.

 

Part of what messed me up for weeks was my lack of realization that Intel I217-V/I218-V/I219-V Ethernet solutions are supported with Windows Server 2012 or 2016. Since I've been testing with an Intel NUC featuring I219-V LAN, I kept getting blue-screen STOP 0x7B crashes part way into OS installation, and it turns out to be the Intel LAN driver not installing against Windows Server OS. I finally figured it out when I tried another NUC with I219-LM LAN and it got through installing WS2016 without a hitch. Basically, any motherboard featuring Intel I217-V/I218-V/I219-V LAN can support direct OS installation into virtual disk with Windows 10 RS1 but not Windows Server 2012, R2, or 2016. There are likely other Intel LAN solutions in the same situation, as Intel driver support for Windows Server OS has always been selective and spotty. My original procedure of installing OS to local hard disk first then cloning it to the virtual disk still works, though.

Link to comment
This is good info. I was thinking that the diskless audio PC will need to keep drivers and services enabled as well, but overall it makes sense as diskless means remote storage accessed over network, so networking and iSCSI related services cannot be disabled on both PCs.

 

Today I achieved a breakthrough in getting WS2012 R2 to install over the network into a virtual disk for an audio PC. I'm continuing to test to ensure this success is not by accident. I've also played with WS2016 and it looks like it can be remotely installed in much the same way as Windows 10 RS1.

 

Part of what messed me up for weeks was my lack of realization that Intel I217-V/I218-V/I219-V Ethernet solutions are supported with Windows Server 2012 or 2016. Since I've been testing with an Intel NUC featuring I219-V LAN, I kept getting blue-screen STOP 0x7B crashes part way into OS installation, and it turns out to be the Intel LAN driver not installing against Windows Server OS. I finally figured it out when I tried another NUC with I219-LM LAN and it got through installing WS2016 without a hitch. Basically, any motherboard featuring Intel I217-V/I218-V/I219-V LAN can support direct OS installation into virtual disk with Windows 10 RS1 but not Windows Server 2012, R2, or 2016. There are likely other Intel LAN solutions in the same situation, as Intel driver support for Windows Server OS has always been selective and spotty. My original procedure of installing OS to local hard disk first then cloning it to the virtual disk still works, though.

 

I gave a procedure of how to install Intel I217-V/I218-V LAN in Windows Server 2012. If one makes a search in CA, it is possible to find it.

However, I do not know if the hacked driver can be inserted in Win Server iso.

Link to comment
I gave a procedure of how to install Intel I217-V/I218-V LAN in Windows Server 2012. If one makes a search in CA, it is possible to find it.

However, I do not know if the hacked driver can be inserted in Win Server iso.

 

I'm aware of the Intel driver hack, but Windows Server OS will not load unsigned drivers by default, and I didn't want to go out of my way to force OS to take unsigned drivers.

 

Separately, it is possible to force feed the Intel signed driver for I217-V/I218-V/I219-V by manually selecting I217-LM/I218-LM/I219-LM during driver install, and I have done this for a couple of years. Unfortunately, the procedure I'm working on to install OS directly into virtual disk for diskless client depends on the network driver installing via OS PnP without extraordinary intervention, and the Intel LAN drivers for Windows Server 2012, R2 & 2016 are missing PnP IDs for I217-V/I218-V/I219-V (only I217-LM/I218-LM/I219-LM are supported), so Intel has broken my procedure for installing Server OS into I21x-V. This leaves the original method of going through a local hard disk as a working solution.

Link to comment
I wanted to let you guys know that I may give up diskless boot. A LPS-1 is on order, and I'm going to compare ssd boot with LPS1 power vs. ISCSI boot.

 

Expect a report in the next few weeks.

 

Larry

That would be an interesting comparison, though watch out for some SSDs that can consume more than the max 1.1A output of the LPS-1.

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...