iPXE deployment with WDS

[Draculea]

Dear all,

Trying to iSCSI boot some VM's for test purposes. Will use that experience as base for day to day use and booting physical machines.

Have carefully read the tutorials on site and others i could find. Tried some of them in my lab environment.

So here is the setup: Hyper-V server with DHCP, WDS, IIS and file server + ISCSI target. Domain controller (VM) + some other test VM's all domain joined.

Tried chainloading the "undionly.kpxe" with WDS TFTP server. It does not work because i think the WDS answers first and never get to load the file. Is that even possible with the limited TFTP from WDS?

If not please advise me on a quick to install TFTP. Do note i have the capability to install a new server (unlimited windows licences but only for the lab) but as i am heavily relying on WDS for machine deployment i would like to use what i have so far and not complicate things too much.

Also note i am a complete noob outside of windows but willing to do some learning and trial and error work.

Please advice.

Thank you very much,
Draculea

[robinsmidsrod]

You might find some help at http://ipxe.org/howto/msdhcp in terms of how to setup the Windows DHCP server to send out the iPXE boot loader to clients.

[Draculea]

(2013-11-27 21:46)robinsmidsrod Wrote:  You might find some help at http://ipxe.org/howto/msdhcp in terms of how to setup the Windows DHCP server to send out the iPXE boot loader to clients.

Let me be more explicit.

My lab infrastructure is the latest MS has to offer, Server 2012 R2. Clients are Win 7 and Win 8.1 but that is irrelevant.

If i boot the iPXE ISO all is fine, DHCP can hand out whatever i put in option 67. But than means i am already an IPXE client.

But i do not want the ISO, i want chainloading. If i try to hand out "undionly.kpxe" from the TFTP server (WDS) i always get the pxeboot.n12 instead.

I need to somehow chainload iPXE and after the pxeboot.n12 or maybe have iPXE as option in the pxeboot.n12.

Is there something i have done wrong or misunderstood? If someone has more experience with this kind of setup, please ideas or advice.

Thank you!

[Draculea]

So after a lot of trial and error i got part of my problem solved.

If you disable WDS to respond to the PXE Responses in the management window the "undionly.kpxe" will load just fine. iPXE client response configured in dhcp to boot up a script file from the local webserver.

In the script used the following:

#!ipxe
set initiator-iqn iqn.1991-05.com.microsoft:win7e-iscsi.ipxe.local
set iscsi-target iscsi:192.168.1.2:::0:iqn.1991-05.com.microsoft:one-win7e-target
set root-path ${iscsi-target}
set keep-san 1
sanhook ${root-path}
#WDS Init
set wdsserver:ipv4 192.168.1.2
set net0/next-server ${wdsserver}
chain tftp://${wdsserver}/boot\\x86\\wdsnbp.com

all good it hooks up to the target just file. was not able to do it without setting the initiator.

it falls back at the end to the WDS boot menu just fine. well except the speed which is crap but i was expecting that after reading the forums.

The problem now is that after the WINPE boot, the WDS does not receive an IP from the DHCP.

Also been watching the iSCSI target and it cycles from "connected" to "not connected" after 1-2 minutes.

Any advice how to progress further?

(2013-11-28 11:30)Draculea Wrote:  

(2013-11-27 21:46)robinsmidsrod Wrote:  You might find some help at http://ipxe.org/howto/msdhcp in terms of how to setup the Windows DHCP server to send out the iPXE boot loader to clients.

Let me be more explicit.

My lab infrastructure is the latest MS has to offer, Server 2012 R2. Clients are Win 7 and Win 8.1 but that is irrelevant.

If i boot the iPXE ISO all is fine, DHCP can hand out whatever i put in option 67. But than means i am already an IPXE client.

But i do not want the ISO, i want chainloading. If i try to hand out "undionly.kpxe" from the TFTP server (WDS) i always get the pxeboot.n12 instead.

I need to somehow chainload iPXE and after the pxeboot.n12 or maybe have iPXE as option in the pxeboot.n12.

Is there something i have done wrong or misunderstood? If someone has more experience with this kind of setup, please ideas or advice.

Thank you!

[Draculea]

Further clarification.

made a print screen from the WDS PE envinronment. Seemns to me that all is OK.

https://skydrive.live.com/redir?resid=EF...oto%2c.png

Tried to add the pic to the forum but could not. "The file upload failed"

Anyone with the same issue? Ideeas?

[robinsmidsrod]

It is normal that the iSCSI server reports that the connection is dropped and re-established. This is part of the hand-over from iPXE to Windows. Which is done using the iBFT memory region.

Is WinPE having problems getting an IP if iSCSI is not connected (no sanhook command used)? If so, the iSCSI connection might be causing some form of problem.

You might also have the typical routing issue in your network, which can be worked around with set netX/gateway 0.0.0.0 to ensure Windows will connect directly to your iSCSI target instead of going through your router. Obviously you can't do that if your iSCSI client and server are on different subnets.
You put it before the sanhook command.

[Draculea]

Robin you were right. These 2 seem to exclude each other:

no san hook means WDS works flawless. San hook or boot without the gateway to 0.0.0.0 does not work.

I do have a Pfsense VM i can use as a router to make debugging faster and some other physical routers.

Also i copy pasted much of your menu work to do some fallback menus for WDS and some other stuff. Thanks for that.

So you have some other ideeas?

(2013-11-29 23:40)robinsmidsrod Wrote:  It is normal that the iSCSI server reports that the connection is dropped and re-established. This is part of the hand-over from iPXE to Windows. Which is done using the iBFT memory region.

Is WinPE having problems getting an IP if iSCSI is not connected (no sanhook command used)? If so, the iSCSI connection might be causing some form of problem.

You might also have the typical routing issue in your network, which can be worked around with set netX/gateway 0.0.0.0 to ensure Windows will connect directly to your iSCSI target instead of going through your router. Obviously you can't do that if your iSCSI client and server are on different subnets.
You put it before the sanhook command.

[robinsmidsrod]

None other than going deep into Windows debugging to figure out what is actually happening. But that is outside my comfort zone.

[Draculea]

(2013-12-04 18:00)robinsmidsrod Wrote:  None other than going deep into Windows debugging to figure out what is actually happening. But that is outside my comfort zone.

obviously, i am already outside my comfort zone here. Will wait it out until technology gets available or has matured more.

Thanks again.