Jump to content











Photo
- - - - -

SANBOOT Windows on UEFI system?


  • Please log in to reply
105 replies to this topic

#51 misty

misty

    Gold Member

  • Developer
  • 1026 posts
  •  
    United Kingdom

Posted 18 May 2019 - 03:27 PM

Decided to do one last test before quitting for the day. Still no success.

StarWind version 8. Installed Windows 10 (1603) as it was handy. Ran setup.exe. Stage 1 completed fine. Rebooted WinPE and added EFI system partition and boot files to the Target disk. Rebooted and the T440 Client is hanging at the iPXE screen -
Registered SAN device 0x80
booting from SAN device 0x80
And the W530 running the iSCSI Target software is running hot. According to Taskmgr.exe, StarWind Virtual SAN is loading the CPU at 64% usage.

:frusty: :frusty:

#52 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 2693 posts
  • Location:Nantes - France
  •  
    France

Posted 18 May 2019 - 03:59 PM

for archive, below the partition scheme made by the windows setup.

with that partition scheme, windows will reboot fine in stage 2 and will complete the installation over efi/iscsi.

 

JYmneHZ.png


  • wimb likes this

#53 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 2693 posts
  • Location:Nantes - France
  •  
    France

Posted 18 May 2019 - 04:07 PM

Attached to this post the content of the EFI part (FAT32), i.e part #2 in previous screenshot.

That to me seems the be the result of bcdboot command.

 

The RECOVERY part i.e part #1 in screenshot above is formatted (NTFS) and empty.

 

The MSR part i.e part #3 in screenshot above is non formatted.

Attached Files

  • Attached File  efi.txt   16.67KB   39 downloads


#54 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 2693 posts
  • Location:Nantes - France
  •  
    France

Posted 18 May 2019 - 04:21 PM

Now having a clear layout of a working win10 efi/iscsi, I will perform a new installation :

 

-boot to winpe

-partition manually my iscsi disk mimicing the part layout i know to be working

-apply esd

-bcdboot targeting the EFI part (and not the SYSTEM part)

-reboot

-hopefully enter stage 2 ...



#55 wimb

wimb

    Platinum Member

  • Developer
  • 2585 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 18 May 2019 - 04:30 PM

for archive, below the partition scheme made by the windows setup.

with that partition scheme, windows will reboot fine in stage 2 and will complete the installation over efi/iscsi.

 

JYmneHZ.png

 

Strange, the GUIDs are not according to what is described here

 

I have for EFI partition GUID according to standard

DISKPART> detail part

Partition 1
Type    : c12a7328-f81f-11d2-ba4b-00a0c93ec93b
Hidden  : Yes
Required: No
Attrib  : 0000000000000000
Offset in Bytes: 1048576

  Volume ###  Ltr  Label        Fs     Type        Size     Status     Info
  ----------  ---  -----------  -----  ----------  -------  ---------  --------
* Volume 6         SSD_EFI      FAT32  Partition      8 GB  Healthy    System


#56 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 2693 posts
  • Location:Nantes - France
  •  
    France

Posted 18 May 2019 - 04:55 PM

 

Strange, the GUIDs are not according to what is described here

 

 

Might be a confusion actually.

GUID actually means ID here (i.e in clonedisk) of the partition and not partition type (which is also a GUID) which clonedisk displays in a "human" format (i.e system, recovery, etc).

The same GUID you will find in the volume guid for that partition.

 

There has been a few threads on reboot.pro touching on this confusion : both the partition ID and the partition type use a GUID format.



#57 wimb

wimb

    Platinum Member

  • Developer
  • 2585 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 18 May 2019 - 05:05 PM

There has been a few threads on reboot.pro touching on this confusion : both the partition ID and the partition type use a GUID format.

 

OK



#58 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 2693 posts
  • Location:Nantes - France
  •  
    France

Posted 18 May 2019 - 07:33 PM

Done for the day.

 

Currently I am trying the below (manual stage 1 as opposed to automatic stage 1 i.e thru windows setup).

Challenge is with stage 2 and with chainloading from bootmgr to winload.

 

-boot to winpe (ipxe+sanhook+wimboot)
 
-partition manually my iscsi disk mimicing the part layout i know to be working (see this post).
part 1 recovery
part 2 efi (system)
part 3 reserved
part 4 windows (basic_data)
 
-apply esd
 
-bcdboot targeting the EFI part (bcdboot g:\windows /s e: /f UEFI)
g: being my "windows" drive where the esd was applied
e: being my efi partition
 
-reboot
 
-hopefully enter stage 2 ...
 
Almost there as the computer boots to windows (bootmgr) but never makes it to winload.efi  :(
 
I am putting the bcd "auto" and "manual" here if anyone is willing to have a look as I feel the issue could be there.
Something around the applicationdevice/osdevice? boot/locate vs hardcoded drive?
 
I also have an image of the "auto" and "manual" EFI partition if anyone is curious.
I have compared them and they look alike (same folders, files, etc).
 
Side notes :
 
-i have deleted the recovery and the microsoft reserved partition on a working iscsi win10, and it still works seamlessly so most probably these are not really needed.
 
-i have to "cheat" to apply bcdboot to the EFI part as by default you cannot mount  a partition of type PARTITION_SYSTEM_GUID as a volume - expect a vmount update soon :)


#59 wimb

wimb

    Platinum Member

  • Developer
  • 2585 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 19 May 2019 - 05:46 AM

Ok then the DiskPart script must be changed for UEFI/GPT as

rem ==
rem == CreaPartGPT-SSD-Disk0.txt ==
rem ==
rem == These commands are used in Win10PE with DiskPart to create 4 GPT partitions
rem == for Install of Win10 on a UEFI/GPT-based computer SSD harddisk
rem == In DiskPart use list disk to find disk number and adjust partition sizes and label as necessary.
rem ==
list disk
select disk 0
clean
convert gpt
rem === 1. Recovery partition NTFS 1000 MB ======== Size also Suitable for Win10XPE =====
create partition primary size=1000
format quick fs=ntfs label="Recovery"
assign
set id="de94bba4-06d1-4d40-a16a-bfd50179d6ac"
gpt attributes=0x8000000000000001
rem == 2. EFI Boot partition FAT32 300 MB ==========================
create partition efi size=300
format quick fs=fat32 label="0_EFI"
assign
rem == 3. Microsoft Reserved (MSR) partition =======
create partition msr size=16
rem == 4. Windows 10 partition NTFS ========================
create partition primary
format quick fs=ntfs label="0_W10"
assign
list volume
exit
rem ==
rem == Info https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/configure-uefigpt-based-hard-drive-partitions
rem == Info https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/configure-biosmbr-based-hard-drive-partitions
rem ==
rem == In admin command window use: DiskPart /s G:\DiskPart\CreaPartGPT-SSD-Disk0.txt
rem ==


#60 misty

misty

    Gold Member

  • Developer
  • 1026 posts
  •  
    United Kingdom

Posted 19 May 2019 - 06:17 AM

@Erwan
I have attempted to use setup.exe and several different versions of Windows 10 and Windows 8.1. After running stage 1, all of the Operating Systems that I have used have created the following disk structure (documented in Post #7) -
 
DISKPART> list part

  Partition ###  Type              Size     Offset
  -------------  ----------------  -------  -------
  Partition 1    Reserved           128 MB  1024 KB
  Partition 2    Primary             29 GB   129 MB
I'm not sure what you have done differently for setup to create the disk structure that you have referred to in post #52? I'm guessing that your client system did not have a disk in it? Can you confirm please.

I've just tried removing the HDD from my client system to test my hypothesis, but it's wedged in there!

Your current test sounds interesting and will hopefully rule out whether disk structure is a factor, or whether setup is doing something else during stage 1. I'm still not convinced its down to the partition layout. BTW, I tried looking at the BCD stores you uploaded, however I have not been able to mount them as they are not recognised as registry hives.

I installed Windows Server 2012R2 and tried using the iSCSI Target included with it last night. Stage 1 completed ok but didn't create a system partition or boot files on the iSCSI Target disk. After manually creating the system partition and creating boot files using bcdboot (using the same process documented in Post #7) I rebooted to start stage 2. The system was hanging at the splash screen.

Misty

Edit - using DiskMgr to set my internal disk as readonly should avoid the need to remove it. Not sure what took me so long to think about using it - I was after all instrumental in its development and chief tester.

Edit 2 - the installation failed when the internal disk was marked as readonly and offline using DiskMgr. Running setup.exe created the following disk structure on the iSCSI Target...
  Partition ###  Type              Size     Offset
  -------------  ----------------  -------  -------
  Partition 1    Recovery           450 MB  1024 KB
  Partition 2    System              99 MB   451 MB
  Partition 3    Reserved            16 MB   550 MB
  Partition 4    Primary             29 GB   566 MB
...however it crashed when copying files. Error -
Windows installation encountered an unexpected error. Verify that the installation sources are accessible, and restart the installation.

Error code: 0xC0000005


#61 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 2693 posts
  • Location:Nantes - France
  •  
    France

Posted 19 May 2019 - 10:59 AM

@Misty

 

My laptop does have an internal SSD and I did not feel like disassembling it.

It appears that it did not interfere during my tests.

 

About the partition scheme, indeed I am wondering why it is generating this scheme (as opposed to a simple EFI+Windows scheme).

But like you I now tend to think that this is not the problem.

 

I am pretty confident about my ipxe network boot loader and ipxe script.

 

I am pretty confident about my iscsi target as I systematically get a successful stage1/stage2 result when using the default windows setup.

 

I am now looking close on the BCD side as I feel this is where the issue stands : bcdboot is lacking some intelligence which windows setup may have about iscsi.

 

FYI see below my latest modified partition scheme which works fine as well (initial scheme from windows setup modified by afterwards).

 

z3LPWaW.png



#62 misty

misty

    Gold Member

  • Developer
  • 1026 posts
  •  
    United Kingdom

Posted 19 May 2019 - 11:18 AM

@Erwan
So in your tests setup.exe is creating a system partition and boot files (inc BCD) on the iscsi target.
On my system the internal disk is used for boot files.
In my next test when I get home I will reformat the internal disk EFI partition and run setup, then copy the boot files created on my internal disk to the iscsi target.

#63 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 2693 posts
  • Location:Nantes - France
  •  
    France

Posted 19 May 2019 - 11:36 AM

@Erwan
So in your tests setup.exe is creating a system partition and boot files (inc BCD) on the iscsi target.
On my system the internal disk is used for boot files.
In my next test when I get home I will reformat the internal disk EFI partition and run setup, then copy the boot files created on my internal disk to the iscsi target.

 

Yes, over here, Windows setup creates 4 partitions :recovery, efi (aka system), reserved, windows.

Later on i demonstrated that 2 of them were not needed to boot in stage2

I have also demonstrated that the EFI part does not have to be PARTITION_SYSTEM_GUID but can be PARTITION_BASIC_DATA_GUID.

Why bother mentionning this partition type : because you cannot mount a partition if type=PARTITION_SYSTEM_GUID and you need to mount it to apply bcdboot.

 

And that same Windows setup is pushing EFI files to the EFI partition (similar to what bcdboot does).

Comparing (at the file level) a partition made by me manually (using bcdboot) and a partition made by the Windows setup automatically, i see the exact same files structure.

 

Hence me getting to the conclusion at this stage that if a manual process does not work, it could be down to the BCD itself.

There I can see clear differences.

It is a shame these cannot be mounted on your side as I would clearly value your inputs there. Try bootice?

 

When i say "it does not work the manual way", I mean : stage 1 goes fine, rebooting stage 2 gets to the bootmgr but does not move on to winload.

I have started to mess with my bcd and for now I am getting a nice windows error "cannot locate winload.efi".

 

And now, using words like BCD and LOCATE, I just remembered this excellent thread you and I were involved in : here.

I am going to use that "locate" trick to try to come with a good/universal BCD which hopefully will superseed the "dummy" BCD made bcdboot in this iscsi/uefi context we are working with.

 

EDIT : below latest simplest/most default partition scheme which still works in "auto/setup" mode.

Attributes too can be defaulted.

 

0s84TDW.png



#64 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 2693 posts
  • Location:Nantes - France
  •  
    France

Posted 19 May 2019 - 11:37 AM

@Wimb : thanks for the effort, much appreciated.

I am going to park for now the "is partition the issue?" question as my focus now is around BCD but i will definitely keep that new script on my side.



#65 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 2693 posts
  • Location:Nantes - France
  •  
    France

Posted 19 May 2019 - 01:24 PM

Tried the below (as stage 1) but got same result : not moving on to winload.efi - windows hourglass/circle hangs for ever and finally errors on a windows blue screen "innacessible device".

Advantage of the below method is that I can do the whole stage 1 from my own windows without having to boot to winpe on my test computer.

 

Sniffing with wireshark, I can see that my efi boot loader gets loaded from my fat32 partition.

 

My understanding of the boot loading process (quoting Wonko from another thread) :

UEFI->protective MBR (data only, i.e. first entry in partition table spanning the WHOLE disk)->GPT table->a loader BOOTMGR.EFI or bootmgfw.efi  or bootx64.efi either in \boot\efi\ or \EFI\Microsoft\boot\ (or in both places) of the ESP partition (that is normally FAT formatted and NOT mounted to a drive letter)->choice in \efi\microsoft\boot\BCD on the ESP partition ->\windows\system32\Winload.efi on *any* volume BUT the ESP one->Windows install on that volume.

 

I am still convinced the issue is around the BCD.

 

I am getting "dry" :(

rem stage 1
rem the below can be done while booted on winpe
rem or while the disk is mounted via your iscsi initiator
vmount-win64 deletedisklayout \\.\physicaldrive2
vmount-win64 createdisk \\.\physicaldrive2 GPT
vmount-win64 createpart \\.\physicaldrive2 GPT 1 1048576 103809024
rem format part1 to fat32
vmount-win64 createpart \\.\physicaldrive2 GPT 2 104857600 16585326592
rem format part2 to ntfs
rem apply windows wim/esd to part2
rem bcdboot part2:\windows /s part1: /f UEFI
rem modify BCD with bootice to point at the proper disk & part (in multiple places)


#66 wimb

wimb

    Platinum Member

  • Developer
  • 2585 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 19 May 2019 - 01:58 PM

How about after UEFI iPXE booting with Win10XPE,  then use DiskPart for the partitioning and then WinNTSetup for Install of Win10 ?

WinNTSetup will auto mount the EFI partition as drive Z:



#67 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 2693 posts
  • Location:Nantes - France
  •  
    France

Posted 19 May 2019 - 02:17 PM

How about after UEFI iPXE booting with Win10XPE,  then use DiskPart for the partitioning and then WinNTSetup for Install of Win10 ?

WinNTSetup will auto mount the EFI partition as drive Z:

 

Good idea : i'll try that and see how winntsetup copes with that challenge (i.e doing the stage1 without windows setup).



#68 wimb

wimb

    Platinum Member

  • Developer
  • 2585 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 19 May 2019 - 02:25 PM

Good idea : i'll try that and see how winntsetup copes with that challenge (i.e doing the stage1 without windows setup).

 

This approach was used here and works OK in case of iPXE wimboot (faster than sanboot)



#69 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 2693 posts
  • Location:Nantes - France
  •  
    France

Posted 19 May 2019 - 04:36 PM

Failure as well with WinNTSetup.

 

Actually, i have now ruled out all below items as being troublesome:

-ipxe/sanboot is not the issue,

-the partitioning is not the issue,

-the EFI part is not the issue,

-the BCD is not the issue,

-my win10 1703 is not the issue.

 

The registry is the issue (in manual mode that is).

When going thru windows setup, this one is smart enough to add a few registry entries :

-a network driver services key (e1express in my case)

-a mounteddevices key (\dosdevices\c: matching my GPT windows part GPT ID in mycase)

and possibly a few other registry modifications which I have missed.

 

My conclusion at this stage : installing windows 10 on a UEFI "only" hardware thru IPXE/ISCSI works nicely ONLY if you go thru the windows setup for stage 1 (i.e partition, apply files, etc) but it is challenging if you decide to perform stage 1 as manually and you will then get stuck in stage 2 resulting in a windows message "innaccessible device".

 

Actually, this challenge (manual stage 1 with iscsi) probably applies to all situations and not only to UEFI so this part may have been a disgression from the main topic ("sanboot-windows-on-uefi-system").

Apologies for the disgression then.

 

A few things I learned thus :

 

-windows is rather flexible regarding the partitions scheme : you can have 2 to 4 partitions, and you can change partition types and attributes 

-you cannot mount a GPT partition with type=system

-you can change attribute and type for a GPT partition back and forth (not sure if this is possible in diskpart thus) - see post here.

-bcdboot will take care of EFI folder and files on your EFI/FAT32 partition

-bcdboot, by indicating the source and destination on the command line, will take care of your BCD applicationdevice/osdevice entries (and although I did not check it out, stuff the disk/part signatures/id in there)

-the registry is needed very early in the boot process, possibly even before we get to winload?

-it seems that no virtual platform supports EFI and ISCSI : sanboot wont register in vmware workstation, sa,boot will register in Vbox but will not be seen anyway once the OS is loaded - probably to ACPI/IBFT not being updated

-while doing some mad googling i stumbled upon UEFI:NTFS from Rufus : may be there is a way have all MS files on one NTFS part (and use a FAT32 part only for UEFI:NTFS).

-it is worth always remembering the boot process (below) when testing/playing with boot matters

 

-device UEFI firmware->

-disk protective MBR (data only, i.e. first entry in partition table spanning the WHOLE disk)->

-disk GPT table->

-a loader BOOTMGR.EFI or bootmgfw.efi  or bootx64.efi either in \boot\efi\ or \EFI\Microsoft\boot\ (or in both places) of the ESP partition (that is normally FAT formatted and NOT mounted to a drive letter)->

-choice in \efi\microsoft\boot\BCD on the ESP partition ->

-\windows\system32\Winload.efi on *any* volume BUT the ESP one->

-Windows install on that volume.

 

That is probably the end of my journey on this topic :)

 

Cheers,

Erwan


  • wimb likes this

#70 wimb

wimb

    Platinum Member

  • Developer
  • 2585 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 19 May 2019 - 05:26 PM

Erwan,

 

Thanks for giving us detailed description of your experiments and results   :)

It is a pity that also WinNTSetup is not succesful in this case.

 

Is WinNTSetup Not able to auto mount the EFI partition as drive Z:   ?

 

Probably the registry fixes of Windows Setup can also be applied by WinNTSetup.

 

You speak of \boot\efi\ but that must be EFI\Boot\



#71 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 2693 posts
  • Location:Nantes - France
  •  
    France

Posted 19 May 2019 - 06:15 PM

Erwan,

 

Thanks for giving us detailed description of your experiments and results   :)

It is a pity that also WinNTSetup is not succesful in this case.

 

Is WinNTSetup Not able to auto mount the EFI partition as drive Z:   ?

 

Probably the registry fixes of Windows Setup can also be applied by WinNTSetup.

 

You speak of \boot\efi\ but that must be EFI\Boot\

 

Actually, WinNTsetup does all fine and simplifies/automates all the tedious tasks.

Except that, as is, it does not know about ISCSI and therefore does not take the extra steps which Windows Setup does.

I believe these extra steps have been discussed/documented here and there so it may lead to an another thread/discussion at some point.

 

About boot\efi, you are correct.

The BCD is in \EFI\Microsoft\Boot\ .

And the computer EFI firmware is harcoded to look in a FAT32 partition and will load \EFI\Boot\bootx64.efi.

 

I'll blame Wonko for this typo as I shamelessly copy/pasted this from another thread on this forum :)



#72 misty

misty

    Gold Member

  • Developer
  • 1026 posts
  •  
    United Kingdom

Posted 20 May 2019 - 10:56 PM

@Erwan
I finally managed to create the same (or at least very similar) partition structure as you when running setup.exe. The trick was to have an MBR type disk in the Client PC - Windows Setup then ignored it and created the EFI SYSTEM partition and boot files on the iSCSI Target disk.

So it looks like if the Client PC has a GPT type internal disk with an existing SYSTEM partition, then setup.exe will add the boot files to that drive. I have not tested where setup.exe creates boot files if the internal disk does not have an EFI SYSTEM partition (e.g. it is temporarily deleted).

I've still not had any luck in completing the installation though. Stage 1 completes. When running Stage 2 I just see a messed up/distorted image on the screen (as reported in post #43) and cannot tell what is happening. iSCSI Target is StarWind 5.2.

I have lost track of just how many times I've tried installing Windows to an iSCSI Target and have now run out of ideas.

:frusty:

:cheers:

Misty

2019.05.20_1.jpg


2019.05.20_2.jpg

#73 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 2693 posts
  • Location:Nantes - France
  •  
    France

Posted 21 May 2019 - 06:34 AM

1/

About the distorted screen, it could be a vesa/png issue (i believe you use a picture in your menu) and/or a wrong ipxe build.

It could be as "silly" as a vesa module messing up your experiment.

 

Therefore, I would say go for the simplest ipxe script ever (see at the bottom of this post) and use ipxe-x86_64.efi from tps.zip (not the latest one but working over here).

 

2/Probably not important but worth mentionning, in my config.ini - this to ensure the proper ipxe is always served.

[arch]
;will over rule the bootp filename or opt67 if the client arch matches one of the below
00000=ipxe.pxe
00006=ipxe-i386.efi
00007=ipxe-x86_64.efi
00009=ipxe-x86_64.efi

3/

If still not work, possibly consider a firmware upgrade on your hardware (although my lenovo hardware has the original firmware).

That should be a last resort.

 

4/

Side note, in starwind, by clicking on your target, on the lower part of the screen, you can see list connected initiators (refreshed auto).

Useful to see who does what and when.

 

 

stage 1

#!ipxe
dhcp
set gateway 0.0.0.0
sanhook iscsi:${next-server}::::iqn.2008-08.com.starwindsoftware:win10
set boot-url http://${next-server}
kernel ${boot-url}/wimboot
initrd ${boot-url}/BOOTMGR.EFI    BOOTMGR.EFI
initrd ${boot-url}/EFI/MICROSOFT/BOOT/BCD BCD
initrd ${boot-url}/BOOT/BOOT.SDI    BOOT.SDI
initrd ${boot-url}/SOURCES/X64/BOOT.WIM BOOT.WIM
boot

stage 2

#!ipxe
dhcp
set gateway 0.0.0.0
sanboot --keep iscsi:${next-server}::::iqn.2008-08.com.starwindsoftware:win10


#74 misty

misty

    Gold Member

  • Developer
  • 1026 posts
  •  
    United Kingdom

Posted 21 May 2019 - 06:16 PM

@Erwan
Thanks for your suggestions and the ipxe scripts.

Before the weird display issues I can see a BCD boot menu (I tweaked the BCD store to ensure that it's displayed) and also a background image - both of which are displayed correctly. Then the weird stuff.

I will try using my gigabit network switch rather than a crossover cable to rule that out, and will then try your suggestions.

Fingers crossed I'll get the time to try tonight.

:cheers:

Misty

#75 misty

misty

    Gold Member

  • Developer
  • 1026 posts
  •  
    United Kingdom

Posted 21 May 2019 - 07:36 PM

@Erwan
I am writing to report SUCCESS!!!!!! :clapping: :happy_dance3: :1st: :party_time:

Thank you so much for all of the troubleshooting and the amazing tech support. You are a wizard :magic:

I am not sure what actually worked and need to do more testing to trace which change made the difference - I introduced several changes at once.

- I used my ipxe.efi with the scripts you posted in #73.
- Client PC was a W530 - on this system setup.exe created all partitions (including UEFI SYSTEM partition) on the iSCSI Target.
- Client PC connected via my internet router to the Server (running Windows Server 2008 R2 and StarWind 5.2).

:cheers:

Misty




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users