Diskless Windows 10 PC Setup Procedure

[scan80269]

I've started working on the write-up, but meanwhile here are a couple of scripts needed for this procedure:

 

Add_iSCSI.cmd:

===================================

set WindowsPE=C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\WinPE_OCs

if not exist C:\Mounted_WIM md C:\Mounted_WIM

Dism /Mount-Image /ImageFile:C:\WinPE\media\sources\boot.wim /Index:1 /MountDir:C:\Mounted_WIM

Dism /Add-Package /Image:C:\Mounted_WIM /PackagePath:"%WindowsPE%\WinPE-WMI.cab"

Dism /Add-Package /Image:C:\Mounted_WIM /PackagePath:"%WindowsPE%\en-us\WinPE-WMI_en-us.cab"

Dism /Add-Package /Image:C:\Mounted_WIM /PackagePath:"%WindowsPE%\WinPE-NetFX.cab"

Dism /Add-Package /Image:C:\Mounted_WIM /PackagePath:"%WindowsPE%\en-us\WinPE-NetFX_en-us.cab"

Dism /Add-Package /Image:C:\Mounted_WIM /PackagePath:"%WindowsPE%\WinPE-Scripting.cab"

Dism /Add-Package /Image:C:\Mounted_WIM /PackagePath:"%WindowsPE%\en-us\WinPE-Scripting_en-us.cab"

Dism /Add-Package /Image:C:\Mounted_WIM /PackagePath:"%WindowsPE%\WinPE-PowerShell.cab"

Dism /Add-Package /Image:C:\Mounted_WIM /PackagePath:"%WindowsPE%\en-us\WinPE-PowerSHell_en-us.cab"

Dism /Add-Package /Image:C:\Mounted_WIM /PackagePath:"%WindowsPE%\WinPE-StorageWMI.cab"

Dism /Add-Package /Image:C:\Mounted_WIM /PackagePath:"%WindowsPE%\en-us\WinPE-StorageWMI_en-us.cab"

copy C:\windows\system32\iscsicpl.dll C:\Mounted_WIM\windows\system32

copy C:\windows\system32\iscsicpl.exe C:\Mounted_WIM\windows\system32

copy C:\windows\system32\en-us\iscsicpl.dll.mui C:\Mounted_WIM\windows\system32\en-us

copy C:\windows\system32\en-us\iscsicpl.exe.mui C:\Mounted_WIM\windows\system32\en-us

Dism /Get-Packages /Image:C:\Mounted_WIM

pause

Dism /Unmount-Image /MountDir:C:\Mounted_WIM /commit

===================================

 

This script is used to customize WinPE to add iSCSI initiator functionality. Both this customized WinPE and the Win10 installation files are put into a small bootable iSCSI target drive used for over-the-network Win10 installation.

 

iscsi.ipxe:

===========================

#!ipxe

 

 

echo iscsi.ipxe script running...

ifopen net0

dhcp

set net0/gateway 0.0.0.0

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

set net0/keep-san 1

echo keep-san: ${net0/keep-san}

sanboot iscsi:192.168.0.105::::iqn.1991-05.com.microsoft:audioserver-win10p-client1-target ||

sanboot iscsi:192.168.0.105::::iqn.1991-05.com.microsoft:audioserver-win10p-client2-target ||

sanboot --drive 0x81 iscsi:192.168.0.105::::iqn.1991-05.com.microsoft:audioserver-win10p-install-target

===========================

 

This script is designed to support one-time Win10 OS installations into dedicated iSCSI targets for multiple clients. For this script to work, the iSCSI targets for each client must be created in advance. I go through partition creation and formatting for each, though the disks must not be marked active. Each iSCSI target should be structured to support only the MAC address of the intended client. The iSCSI target used for OS installation must be marked active, and is intentionally invoked last. The script example above shows sanboot lines for two clients, but can be extended to an arbitrary number of clients.

 

The first time a diskless client PXE boots, the sanboot line for its dedicated iSCSI target drive will fail, since the drive is still blank and unbootable. The script will move on to booting from the OS install iSCSI target, so the customized WinPE boots up to the WinPE command prompt. A manual iSCSI connection to the dedicated iSCSI target is done using iSCSI Initiator GUI (or command lines, further automation here is possible). Once the iSCSI target is online, OS installation is launched from the booted OS install iSCSI target drive, by running Microsoft setup.exe. From here, OS installation should proceed normally like with a physical hard disk. Part way into OS installation, the dedicated iSCSI target drive will become bootable, and upon a system restart triggered by the installer, the iPXE script will boot from the iSCSI target to continue and complete the OS installation.

 

I'm very pleased to have found a way to make a single iPXE script support both one-time OS installation and subsequent diskless OS booting from the finished iSCSI target, for multiple clients.

[jabbr]

Great work!

 

 

Room treatments for headphone users

[scan80269]

Thanks, jabbr!

 

A couple of caveats:

 

- I tested with the latest Windows 10 Anniversary Edition (Version 1607) "Redstone 1" OS, but did not try older Windows 10 (Version 1511) or original build 10240.

 

- I succeeded with Intel I217V/I218-LM/I219-LM and Realtek NICs (down on motherboards). For NICs that happen to have no inbox driver support in Win10, offline injection of the appropriate NICs drivers into Win10 installation files and WinPE will likely be needed.

[bodiebill]

 

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.

 

Two questions in case of a JPLAY dual PC setup where both the audio and the control PC run under Windows 2012:

 

(1) Is it possible to use the control PC as server (with disk) and the audio PC as diskless client? And if yes, would that have a negative effect on SQ?

 

(2) After setting up the diskless audio PC, can both the client and the server run in core mode?

[scan80269]

Two questions in case of a JPLAY dual PC setup where both the audio and the control PC run under Windows 2012:

 

(1) Is it possible to use the control PC as server (with disk) and the audio PC as diskless client? And if yes, would that have a negative effect on SQ?

 

(2) After setting up the diskless audio PC, can both the client and the server run in core mode?

 

I am not familiar with JPLAY, but would guess the answer is yes to both questions.

 

You can install the "iSCSI Target Service" feature on the control PC to make it double as iSCSI target to support the audio PC running diskless.

 

I don't know how the additional network traffic over the network cable between the control and audio PCs would affect SQ, but the audio PC running diskless should be less electrically noisy, since the absence of electrical noise from local hard disk should more than offset any added electrical noise associated with higher network activity.

 

I'm currently working on an updated write-up on how to set up an iSCSI target system to support over-the-network OS installations for diskless clients. I've used my procedure to install Windows 10 for several types of diskless PCs, and believe it should also work for installing Windows Server 2012. Choosing core mode for an over-the-network installation of Windows Server 2012 into the audio PC should work, though it would take me at least a few more days to actually verify this.

 

For the control PC, I suspect it would be easier to run Windows Server 2012 in GUI mode first, then prepare iSCSI targets, set up the audio PC to run diskless core mode, then finally reconfigure the control PC from GUI mode to core mode.

[bodiebill]

I am not familiar with JPLAY, but would guess the answer is yes to both questions.

 

You can install the "iSCSI Target Service" feature on the control PC to make it double as iSCSI target to support the audio PC running diskless.

 

I don't know how the additional network traffic over the network cable between the control and audio PCs would affect SQ, but the audio PC running diskless should be less electrically noisy, since the absence of electrical noise from local hard disk should more than offset any added electrical noise associated with higher network activity.

 

I'm currently working on an updated write-up on how to set up an iSCSI target system to support over-the-network OS installations for diskless clients. I've used my procedure to install Windows 10 for several types of diskless PCs, and believe it should also work for installing Windows Server 2012. Choosing core mode for an over-the-network installation of Windows Server 2012 into the audio PC should work, though it would take me at least a few more days to actually verify this.

 

For the control PC, I suspect it would be easier to run Windows Server 2012 in GUI mode first, then prepare iSCSI targets, set up the audio PC to run diskless core mode, then finally reconfigure the control PC from GUI mode to core mode.

 

That all sounds promising. Also promising is that yesterday I succeeded to setup the server side on a spare laptop with Server 2012 R2. I hope to continue with the client soon. Fingers crossed...

 

Thanks Sam, for sharing all this, really appreciated! Looking forward to your updated write-up.

[bodiebill]

Alas, I was not successful so far. I followed scan80269's clear instructions (and appreciate his help via PM's!), up to successfully installing the iSCSI target on the server. However, when I start the client I get the following screen:

 

 

I have two NIC's on the client so the first NIC aborting is OK as this is not used.

 

The second NIC has a static IP address 192.168.1.202 assigned in Server 2012. However the Tiny PXE server, if set with ProxyDHCP, leaves the IP lease to the router and this gives an IP address of 192.168.1.119 (not strange as the router cannot know the static IP address as Windows has not yet started). When I turn off ProxyDHCP I can force the proper 192.168.1.202 address, but the result is the same: the startup screen above hangs and nothing is booted.

 

And when I re-attach the client's SSD, the OS finally boots from disk. Surprisingly, the iSCSI server then indicates "connected".

 

Not sure what is going wrong here (and whether this IP thing has something to do with it). I will let it rest for a while, and look forward to scan80269's new write-up...

[lmitche]

The TinyPXE log file should tell you what's happening here.

[scan80269]

bodiebill, did you allow Tiny PXE Server (pxesrv.exe) through the Windows Firewall?

[bodiebill]

bodiebill, did you allow Tiny PXE Server (pxesrv.exe) through the Windows Firewall?

 

The TinyPXE log file should tell you what's happening here.

 

Yes, I allowed pxesrv.exe in the firewall.

 

Tiny PXE Server logfile with ProxyHDCP disabled:

22:31:13 ROOT=P:\TFTProot\

22:31:13 DHCPd:67 started...

22:31:13 TFPTd started...

22:31:13 HTTPd started...

22:32:42 DHCPd: DISCOVER received, MAC:00-E0-4C-68-13-CD, XID:4D6813CD

22:32:43 DHCPd:OFFER sent, IP:192.168.1.202, XID:4D6813CD

22:32:46 DHCPd:REQUEST received, MAC:00-E0-4C-68-13-CD, XID:4D6813CD

22:32:46 DHCPd:ACK sent, IP:192.168.1.202, XID:4D6813CD

22:32:46 TFTPd: ReadFile:ipxe-undionly.kpxe B:1456 T:0

 

Tiny PXE Server logfile with ProxyHDCP enabled:

22:39:13 ROOT=P:\TFTProot\

22:39:13 DHCPd:67 started...

22:39:13 DHCPd:4011 started...

22:39:13 TFPTd started...

22:39:13 HTTPd started...

22:40:43 DHCPd: DISCOVER received, MAC:00-E0-4C-68-13-CD, XID:4D6813CD

22:40:43 DHCPd:OFFER sent, IP:0.0.0.0, XID:4D6813CD

22:40:47 DHCPd:REQUEST discarded, MAC:00-E0-4C-68-13-CD, XID:4D6813CD

22:40:48 PDHCPd:REQUEST received, MAC:00-E0-4C-68-13-CD, IP:192.168.1.119, XID:4D6813CD

22:40:48 Proxy boot filename empty?

22:40:48 PDHCPd: DHCP_ACK sent, IP:192.168.1.119:68, xid:4D6813CD

22:40:48 TFTPd: DoReadFile:ipxe-undionly.kpxe B:1456 T:0

 

In both cases the client bootscreen hangs and iSCSI on the server says "not connected".

[lmitche]

In both cases tftp can't find the ipxe-undionly.kpxe file. Is it in p:\tftproot\?

[bodiebill]

In both cases tftp can't find the ipxe-undionly.kpxe file. Is it in p:\tftproot\?

 

The ipxe-undionly.kpxe file in P:\TFTProot was empty. I replaced it with a file I found online: undionly.kpxe, which I renamed to ipxe-undionly.kpxe.

 

Or how do I otherwise get the ipxe-undionly.kpxe file?

 

Now the bootscreen continues but then halts with

 

A disk read error occurred

Press Ctrl-Alt-Del to restart

 

The logs read:

 

with ProxyHDCP on:

23:08:59 ROOT=P:\TFTProot\

23:08:59 DHCPd:67 started...

23:08:59 DHCPd:4011 started...

23:08:59 TFPTd started...

23:08:59 HTTPd started...

23:10:24 DHCPd: DISCOVER received, MAC:00-E0-4C-68-13-CD, XID:4D6813CD

23:10:24 DHCPd: OFFER sent, IP:0.0.0.0, XID:4D6813CD

23:10:28 DHCPd: REQUEST discarded, MAC:00-E0-4C-68-13-CD, XID:4D6813CD

23:10:29 PDHCPd: REQUEST received, MAC:00-E0-4C-68-13-CD, IP:192.168.1.119, XID:4D6813CD

23:10:30 Proxy boot filename empty?

23:10:30 PDHCPd: DHCP_ACK sent, IP:192.168.1.119:68, xid:4D6813CD

23:10:30 TFTPd: DoReadFile:ipxe-undionly.kpxe B:1456 T:0

23:10:36 DHCPd: DISCOVER received, MAC:00-E0-4C-68-13-CD, XID:AD345B76

23:10:36 DHCPd: iPXE user-class detected

23:10:36 DHCPd: OFFER sent, IP:0.0.0.0, XID:AD345B76

23:10:36 DHCPd: REQUEST discarded, MAC:00-E0-4C-68-13-CD, XID:AD345B76

23:10:37 DHCPd: REQUEST discarded, MAC:00-E0-4C-68-13-CD, XID:AD345B76

23:10:37 TFTPd: DoReadFile:iscsi.ipxe B:1432 T:264

23:10:37 DHCPd: DISCOVER received, MAC:00-E0-4C-68-13-CD, XID:FEC9B59

23:10:37 DHCPd: iPXE user-class detected

23:10:37 DHCPd: OFFER sent, IP:0.0.0.0, XID:FEC9B59

23:10:37 DHCPd: REQUEST discarded, MAC:00-E0-4C-68-13-CD, XID:FEC9B59

23:10:38 DHCPd: REQUEST discarded, MAC:00-E0-4C-68-13-CD, XID:FEC9B59

 

with ProxyHDCP off:

23:13:15 ROOT=P:\TFTProot\

23:13:15 DHCPd:67 started...

23:13:15 DHCPd:4011 started...

23:13:15 TFPTd started...

23:13:15 HTTPd started...

23:13:17 ProxyDhcp disabled

23:13:17 restart service

23:14:51 DHCPd: DISCOVER received, MAC:00-E0-4C-68-13-CD, XID:4D6813CD

23:14:52 DHCPd: OFFER sent, IP:192.168.1.202, XID:4D6813CD

23:14:55 DHCPd: REQUEST received, MAC:00-E0-4C-68-13-CD, XID:4D6813CD

23:14:55 DHCPd: ACK sent, IP:192.168.1.202, XID:4D6813CD

23:14:55 TFTPd: DoReadFile:ipxe-undionly.kpxe B:1456 T:0

23:15:02 DHCPd: DISCOVER received, MAC:00-E0-4C-68-13-CD, XID:CD095379

23:15:02 DHCPd: iPXE user-class detected

23:15:02 DHCPd: OFFER sent, IP:192.168.1.203, XID:CD095379

23:15:03 DHCPd: DISCOVER received, MAC:00-E0-4C-68-13-CD, XID:CD095379

23:15:03 DHCPd: iPXE user-class detected

23:15:03 DHCPd: OFFER sent, IP:192.168.1.203, XID:CD095379

23:15:05 DHCPd: REQUEST received, MAC:00-E0-4C-68-13-CD, XID:CD095379

23:15:05 DHCPd: iPXE user-class detected

23:15:05 DHCPd: ACK sent, IP:192.168.1.203, XID:CD095379

23:15:05 TFTPd: DoReadFile:iscsi.ipxe B:1432 T:264

23:15:05 DHCPd: DISCOVER received, MAC:00-E0-4C-68-13-CD, XID:8DCECC65

23:15:05 DHCPd: iPXE user-class detected

23:15:05 DHCPd: OFFER sent, IP:192.168.1.203, XID:8DCECC65

23:15:06 DHCPd: DISCOVER received, MAC:00-E0-4C-68-13-CD, XID:8DCECC65

23:15:06 DHCPd: iPXE user-class detected

23:15:06 DHCPd: OFFER sent, IP:192.168.1.203, XID:8DCECC65

23:15:08 DHCPd: REQUEST received, MAC:00-E0-4C-68-13-CD, XID:8DCECC65

23:15:08 DHCPd: iPXE user-class detected

23:15:08 DHCPd: ACK sent, IP:192.168.1.203, XID:8DCECC65

 

The client should have 192.168.1.202 as a static IP address, but apparently doesn't.

 

I am probably clumsy, this is all new to me...

[bodiebill]

Clumsy indeed... I just found the ipxe-undionly.kpxe file in Tiny PXE Server's 'files' folder. Using that I still get:

 

A disk read error occurred

Press Ctrl-Alt-Del to restart

 

Maybe I should run Disk2VHD again.

[scan80269]

bodiebill, I don't think setting static IP for the client PC is necessary, unless that's what you really want. My diskless clients are all assigned IP address by DHCP server, though the server PC running Windows Server 2012 R2 pretty much needs a static IP to work so that's how I configured it.

 

Selecting the proxyDHCP checkbox in Tiny PXE Server is intended to work with an existing DHCP server on the network, such as a wireless router. Unselecting proxyDHCP means TPS will act as standalone DHCP server, based on the settings you provide. I have used TPS successfully with proxyDHCP checked and unchecked for different network environments.

 

My TFTP folder is in C:, i.e. C:\TFTP.

[scan80269]

I'm still working on writing the new procedure, and testing is ongoing.

 

I just found that this new procedure works well with the latest Windows 10 Anniversary Edition (Version 1607, a.k.a. "Redstone 1") but not with the previous Windows 10 (Version 1511, a.k.a. "Threshold 2"). Because of this, I'm holding off posting the complete procedure until the issues can be resolved.

 

In the mean time, here are the high level steps (subject to changes):

 

One-time Server setup:

1. Set up iSCSI target server

- Windows Server 2012 R2, Tiny PXE Server & iPXE used in this tutorial

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

B. Add "iSCSI Target Server" feature

C. Allow "iSCSI Service" through the Windows Firewall

 

 

2. Set up a small (8-10GB) bootable iSCSI virtual disk for Windows OS installation

A. Add client MAC addresses to iSCSI target for this iSCSI virtual disk

B. Prepare customized WinPE with iSCSI Initiator enabled

- See add_iscsi.cmd batch file example to customize WinPE

C. Mount iSCSI virtual disk to drive letter

D. Transfer customized WinPE and OS installation files into iSCSI virtual disk

- WinPE files to root (\sources, \boot, \efi, \bootmgr, \bootmgr.efi, etc.)

- OS installation files to a folder, e.g. \Win10

E. Set iSCSI virtual disk partition to Active for booting

- e.g. DISKPART - sel dis 1, sel par 1, active

F. Unmount/Eject iSCSI virtual disk

 

 

3. Set up iPXE & Tiny PXE Server to support PXE->iPXE->WinPE booting on diskless clients

- Configure iPXE boot script to support both OS installation (once per client) and diskless booting for clients

- See iscsi.ipxe script example

A. Allow Tiny PXE Server (pxesrv.exe) through the Windows Firewall

B. Configure Tiny PXE Server to auto launch by adding pxesrv.exe into startup group (shell:startup)

 

 

4. Create one iSCSI virtual disk for each diskless client

- Recommend using dynamically expanding VHDX file with Windows Server 2012 R2

A. Create and quick format iSCSI virtual disk partition to NTFS

B. Add client MAC address to iSCSI target IQN for its dedicated iSCSI virtual disk

 

 

 

Diskless PC setup:

1. Initiate PXE boot on diskless client to boot to WinPE command prompt

 

 

2. Launch iSCSI Initiator (iscsicpl) and connect to iSCSI virtual disk prepared previously

 

 

3. Change drive & folder to OS installation files

- e.g. C:\Win10\sources

 

 

4. Launch setup.exe to start OS installation. Select the iSCSI virtual disk partition to install OS into.

 

============

 

Part of what's new is the creation of a iSCSI virtual disk to carry customized WinPE to support over-the-network OS installation for the diskless client. I won't cover the custom WinPE creation at this point.

[bodiebill]

bodiebill, I don't think setting static IP for the client PC is necessary, unless that's what you really want. My diskless clients are all assigned IP address by DHCP server, though the server PC running Windows Server 2012 R2 pretty much needs a static IP to work so that's how I configured it.

 

Selecting the proxyDHCP checkbox in Tiny PXE Server is intended to work with an existing DHCP server on the network, such as a wireless router. Unselecting proxyDHCP means TPS will act as standalone DHCP server, based on the settings you provide. I have used TPS successfully with proxyDHCP checked and unchecked for different network environments.

 

My TFTP folder is in C:, i.e. C:\TFTP.

 

After verifying all the steps from scan80269's initial procedure and re-running Disk2VHD, my Audio PC has now booted diskless into an iSCSI virtual disk that resides on my control PC! Thank you, scan80269 and lmitche! Without your help I would still be struggling on...

 

Soon time to go back to core mode on both PC's and listen to some music...

 

@ scan80269:

Indeed, the client IP address with which the initial connection is established, seems unimportant; once the OS has started the intended static IP address is applied. (JPLAY dual PC setup requires static IP addresses.)

[scan80269]

After verifying all the steps from scan80269's initial procedure and re-running Disk2VHD, my Audio PC has now booted diskless into an iSCSI virtual disk that resides on my control PC! Thank you, scan80269 and lmitche! Without your help I would still be struggling on...

 

Soon time to go back to core mode on both PC's and listen to some music...

 

@ scan80269:

Indeed, the client IP address with which the initial connection is established, seems unimportant; once the OS has started the intended static IP address is applied. (JPLAY dual PC setup requires static IP addresses.)

 

Congratulations, bodiebill! You may have just saved me the trouble of testing the dual WS2012 PC setup with my new procedure, though I may go through the exercise anyway just to convince myself.

 

For some NICs (especially in plug-in card form) it may be possible to set a static IP in the ROM that will take effect even before OS is booted. In your case, the NIC gets an IP address from a DHCP server shortly after power-up, but changes to a static IP once Windows is booted. It's a happy ending.

 

I really hate having to mess with local hard disk or disk copying (Disk2VHD, etc.) just to set up a diskless client, thus the motivation for creating a new procedure. So far, I have only succeeded with Windows 10 Anniversary Edition as the client OS, but hope to add Windows Server 2012 R2 to the list soon.

 

Once your PCs are reconfigured to core mode, do let us know what the SQ is like with the audio PC running diskless.

[bodiebill]

Congratulations, bodiebill! You may have just saved me the trouble of testing the dual WS2012 PC setup with my new procedure, though I may go through the exercise anyway just to convince myself.

 

For some NICs (especially in plug-in card form) it may be possible to set a static IP in the ROM that will take effect even before OS is booted. In your case, the NIC gets an IP address from a DHCP server shortly after power-up, but changes to a static IP once Windows is booted. It's a happy ending.

 

I really hate having to mess with local hard disk or disk copying (Disk2VHD, etc.) just to set up a diskless client, thus the motivation for creating a new procedure. So far, I have only succeeded with Windows 10 Anniversary Edition as the client OS, but hope to add Windows Server 2012 R2 to the list soon.

 

Once your PCs are reconfigured to core mode, do let us know what the SQ is like with the audio PC running diskless.

 

Thanks, scan80269. With both PC's in core mode and AO running on the control PC (server), everything worked as it should. However, after running AO also on the audio PC (client), this would no longer connect to the server. I will do some troubleshooting, starting with restoring my WS2010.vhdx file on the server...

[bodiebill]

Thanks, scan80269. With both PC's in core mode and AO running on the control PC (server), everything worked as it should. However, after running AO also on the audio PC (client), this would no longer connect to the server. I will do some troubleshooting, starting with restoring my WS2010.vhdx file on the server...

 

Update:

• restored last working version of WS2010.vhdx on server
  
• client was able to connect again
  
• converted client to WS2012 core mode
  
• ran disk2VHD to replace WS2010.vhdx
  
• client still able to connect
  
• installed Fidelizer Pro and AO (order is important, when I did this first, disk2VHD was unable to do its job)
  
• connection still OK and SQ already wonderful with server in GUI mode
  

(client = audio PC, server = control PC)

 

HQPlayer worked immediately. Hysolid did not work at first, but did work after re-installing.

 

Next step is to convert the server to core mode and also try BHE/IB. Maybe tomorrow...

 

Quite a project! And before long I plan to optically isolate the connection between both PC's NIC's.

And then I plan to stop tweaking and listen to music... (famous last words).

 

I really appreciate the help I found on this wonderful forum, thanks again!

[lmitche]

Great to know that you are up and running! I look forward to hearing more about the resulting SQ.

[bodiebill]

Great to know that you are up and running! I look forward to hearing more about the resulting SQ.

 

Today I also converted the server (control PC) to core mode. Everything worked fine. Then I ran Fidelizer Pro and AO. Connection was lost. But I should have read the AO manual more closely:

 

SCSI-MiniPort Drivers: Be very careful if you want to use this option. Only use it if you have IDE or SATA drives. Do not use this option under any circumstances if you have SAS, SCSI or RAID drives. If you still do so your system might not be able to boot again!

 

And so it was. I ran AO again, keeping the SCSI-MiniPort drivers enabled, and I was back in business.

Even JPLAY hibernation is working fine.

 

As for the SQ: deep, wide and dark, but with a silver lining (airy highs!). Can't wait to listen some more...

[bodiebill]

As for the SQ: deep, wide and dark, but with a silver lining (airy highs!). Can't wait to listen some more...

 

Wow, this was waiting for! Biggest leap in SQ since I finished my (single) audio PC two years ago.

 

(Now listening to Beate S Lech aka Beady Belle's very restrained album with Norwegian folk tunes 'Min song og hjarteskatt'. Player is Hysolid – I did not try BHE/IB yet as it is hard to imagine it can get any better than this.)

[sig8]

Update:

• restored last working version of WS2010.vhdx on server
  
• client was able to connect again
  
• converted client to WS2012 core mode
  
• ran disk2VHD to replace WS2010.vhdx
  
• client still able to connect
  
• installed Fidelizer Pro and AO (order is important, when I did this first, disk2VHD was unable to do its job)
  
• connection still OK and SQ already wonderful with server in GUI mode
  

(client = audio PC, server = control PC)

bodiebill: I have been booting my audioPC and controlPC diskless as suggested by scan, but so far I have not tried to run them in core mode, or installed AO altogether. I would like to run AO on both and run audioPC in core mode.

 

I do not understand the fourth step here, "ran disk2VHD to replace WS2011.vhdx", once converted and connected, why you need to create another .vhdx. Please let me know. Thanks.

[bodiebill]

bodiebill: I have been booting my audioPC and controlPC diskless as suggested by scan, but so far I have not tried to run them in core mode, or installed AO altogether. I would like to run AO on both and run audioPC in core mode.

 

I do not understand the fourth step here, "ran disk2VHD to replace WS2011.vhdx", once converted and connected, why you need to create another .vhdx. Please let me know. Thanks.

 

Hi sig8, good question. Coming to think of it, the first two bullets are not correct as I think I had to reconnect the disk for lack of vhdx backups. Then I ran AO again, this time with SCSI-MiniPort Drivers enabled. Then I ran disk2VHD to replace WS2011.vhdx with the working one including AO with the right settings, and I could unplug the disk and connect with PXE.

 

Now I am taking care to make vhdx backups so that I can revert to a previous version instead of having to re-connect the disk and run disk2VHD.

 

The good news is: core mode with AO and FP work on both PC's. In my case only the audio PC is diskless.

[sig8]

Hi sig8, good question. Coming to think of it, the first two bullets are not correct as I think I had to reconnect the disk for lack of vhdx backups. Then I ran AO again, this time with SCSI-MiniPort Drivers enabled. Then I ran disk2VHD to replace WS2011.vhdx with the working one including AO with the right settings, and I could unplug the disk and connect with PXE.

 

Now I am taking care to make vhdx backups so that I can revert to a previous version instead of having to re-connect the disk and run disk2VHD.

 

The good news is: core mode with AO and FP work on both PC's. In my case only the audio PC is diskless.

 

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.