[SOLVED] : iPXE and WDS Config

[Alphakarem]

Hello,
First of all thank you for the iPXE environment and it's simplicity.

I am having a problem setting up iPXE and WDS on the same subnet, the scenario is as follow :

192.168.1.7 is my TFTP Server
192.168.1.24 is my DHCP Server( Microsoft ) configured per the guide on the ipxe.org website, this server also has IIS and WDS for simplifying the deployments and management.

What I would ideally like to accomplish is to load mainly to iPXE (undionly.kpxe) and from there have a menu item to shoot me back to WDS whether that be by loading WDS straight or loading PXELinux first then to WDS ( which i already have such setup going... i.e PXELinux -> WDS via a menu selection).

the reason to have WDS is because of all the investment and images it's has right now which will take a very long time to move to a different environment and also the ability to manage it through Windows interface and adding new drivers if needed for odd devices.

If you would kindly help with some instructions or perhaps publish a guide on the website I would be very grateful.

Thank you for your time

[Sha0]

You might be interested in omitting the WDS interaction and simply booting the Windows PE environment using wimboot, using this article.

However, if you are really interested in a hand-off to WDS...

Microsoft's Windows NBP cares about the DHCP packets that have been stored according to the PXE specification. In a WDS scenario, it is usually the case that there is a stored packet of the DHCP server's offer as well as a stored packet of the proxyDHCP server's offer.

You need to modify the proxyDHCP packet before handing control to the Windows NBP. You can do this from the iPXE CLI or a script:

Code:

set proxydhcp/next-server AAA.BBB.CCC.DDD
set proxydhcp/filename startrom.n12
set proxydhcp/dhcp-server AAA.BBB.CCC.DDD

Note #1: A proxyDHCP offer must have been sent in order for you to be able to access the proxydhcp/ scope shown above. That usually means having the proxyDHCP service running.

Note #2: The Windows NBP most likely uses its own internal TFTP client, so it won't fetch files using iPXE's HTTP support.

But since you are doing iPXE -> PXELINUX, you can also use Gene Cumm's pxechn.c32 module. It has a variety of options that are documented in Syslinux' doc/pxechn.txt file. Gene's considerations included the WDS use-case.

[Sedorox]

For what it's worth, if it's what you are trying to do, you can have iPXE boot directly to a WDS server, that is not the TFTP server. Here is the code I've used successfully (as a iPXE script):

Code:

set wdsserver:ipv4 10.0.3.99
set net0/next-server ${wdsserver}
chain tftp://${wdsserver}/boot%5Cx86%5cwdsnbp.com

Notice that the TFTP path uses the windows directory delimiter, \... so with iPXE, this is done as hex. I found this out via a screenshot from http://ipxe.org/howto/wds_iscsi .

[Alphakarem]

(2012-11-09 04:31)Sedorox Wrote:  For what it's worth, if it's what you are trying to do, you can have iPXE boot directly to a WDS server, that is not the TFTP server. Here is the code I've used successfully (as a iPXE script):

Code:

set wdsserver:ipv4 10.0.3.99
set net0/next-server ${wdsserver}
chain tftp://${wdsserver}/boot%5Cx86%5cwdsnbp.com

Notice that the TFTP path uses the windows directory delimiter, \... so with iPXE, this is done as hex. I found this out via a screenshot from http://ipxe.org/howto/wds_iscsi .

Sedorox and Sha0 ... Thank you very much for this code !! this is EXACTLY what I needed to do, it even allows me to go to PXELinux.com instead of the regular pxeboot.com once I change the boot loader on the WDS ! however the download speed is EXTREMELY slow on a 1GB network ... any ideas on why is this behavior ?

[robinsmidsrod]

It is most likely due to the fact that the WDS components use TFTP to download the Windows PE environment. You can utilize wimboot to speed it up significantly by bypassing all of Microsoft's tools and directly loading the boot.wim file from a web server. See these links: http://ipxe.org/wimboot http://ipxe.org/howto/winpe http://ipxe.org/howto/sccm

[Alphakarem]

(2012-11-10 08:18)robinsmidsrod Wrote:  It is most likely due to the fact that the WDS components use TFTP to download the Windows PE environment. You can utilize wimboot to speed it up significantly by bypassing all of Microsoft's tools and directly loading the boot.wim file from a web server. See these links: http://ipxe.org/wimboot http://ipxe.org/howto/winpe http://ipxe.org/howto/sccm

the Slowness on WDS has been resolved, I verified the issue isn't with iPXE but rather a problem with BOOTMGR.EXE. you need an older version of BOOTMGR.EXE, the one from Windows Vista proved reliable and deliver good performance. This Solution was found here http://social.technet.microsoft.com/Foru...bd6faf02ef

From a Vista CD 32bit extract bootmgr.exe from the file boot.wim located under sources file, to extract you must have WAIK installed and from the WAIK CLI type :

imagex /mount e:\vistax86\boot.wim 2 e:/mounted_images

then simply copy the file bootmgr.exe from e:/mounted_images folder to both your x86 and X64 folders paste their overwriting what you have there.

Hopefully that helps someone else.

[Nicola V]

Hi everyone,
we solved it as well, yet in a very unexpected way:
Instead of using this command:

Code:

"chain tftp://${wdsserver}/boot%5Cx86%5cwdsnbp.com"

We used this one, escaping the backslashes in the path:

Code:

"chain tftp://${wdsserver}/Boot\\x86\\wdsnbp.com"

After this correction the tftp download started to perform optimally. Don't ask me why this would be related, but it was perfectly reproducible on our side.

Regards

[skyman]

This way works for me.

cpuid --ext 29 && set arch x64 || set arch x86
set filename wdsnbp.com
#set next-server 0.0.0.0 # uncomment and replace 0.0.0.0 with your wds ip if different than pxe/tftp server
chain -ar tftp://${next-server}/boot/${arch}/${filename}

[jamesosbourn]

I am seeing the exact same situation with WDS grinding to a halt when booting from iPXE.

I have tried the suggestions from this thread and only the \\ rather than %5C options seems to make any difference.

I cannot see how the same machine on the same cable with the same IP etc can perform differently. The only thing that I can think of is that iPXE is changing the networking some howso it is behaving differently when handed over to the WDS server.

Does anyone have any other suggestions?

Thanks

James

(2013-02-18 15:53)Nicola V Wrote:  Hi everyone,
we solved it as well, yet in a very unexpected way:
Instead of using this command:

Code:

"chain tftp://${wdsserver}/boot%5Cx86%5cwdsnbp.com"

We used this one, escaping the backslashes in the path:

Code:

"chain tftp://${wdsserver}/Boot\\x86\\wdsnbp.com"

After this correction the tftp download started to perform optimally. Don't ask me why this would be related, but it was perfectly reproducible on our side.

Regards

[robinsmidsrod]

@jamesosbourn: I'd suggest using wimboot if WDS is giving you too much trouble. http://ipxe.org/howto/winpe

[jamesosbourn]

Hi,

I tried the wimboot solution as a way to get round the WDS problem and this did not work at all. Following the documentation to get the correct files needed whe the wim actually booted it could not talk to the correct server.

This may be related to the fact that I am using WDS to boot a MDT configuration.

James

(2013-06-05 09:23)robinsmidsrod Wrote:  @jamesosbourn: I'd suggest using wimboot if WDS is giving you too much trouble. http://ipxe.org/howto/winpe

[robinsmidsrod]

Have you tried the SCCM howto? http://ipxe.org/howto/sccm

[Alphakarem]

(2013-06-05 10:09)robinsmidsrod Wrote:  Have you tried the SCCM howto? http://ipxe.org/howto/sccm

I have tried to follow the SCCM guide you mentioned in the link, however I think this is targeted to SCCM 2007 not to 2012 ... I can't find the folder "SMS" required for changing the boot.wim image as the guide says in this command "xcopy /e /f /y sccmfiles\sms mntpnt\sms" also I can't find a boot.wim image in the extracted files from the ISO.

could you please guide us to the process to chain from iPXE to SCCM 2012 SP1 ?

Thank you in advance

[robinsmidsrod]

Unfortunately I'm not familiar with SCCM myself, and I didn't write that howto you read. I've pinged someone else that might help you. If anyone else has any experience, feel free to chime in.

[Alphakarem]

(2013-06-08 20:38)robinsmidsrod Wrote:  Unfortunately I'm not familiar with SCCM myself, and I didn't write that howto you read. I've pinged someone else that might help you. If anyone else has any experience, feel free to chime in.

Any Update on this please ? ... we are really moving to SCCM 2012 SP1 Production and we would like to keep our current iPXE environment and simply chain to SCCM through iPXE ... any help or guidance wil lbe very much appreciated.

Thank you

[robinsmidsrod]

You said you couldn't find boot.wim in the SCCM files inside the ISO. Can you find any other .wim file in there?

[Alphakarem]

(2013-06-17 08:18)robinsmidsrod Wrote:  You said you couldn't find boot.wim in the SCCM files inside the ISO. Can you find any other .wim file in there?

Well .. there are .wim files that install to the following path:
C:\Program Files\Microsoft Configuration Manager\OSD\boot where there are a couple i386 and x64 folders with wim files in them .. but other than this, nothing really in the ISO ...

[robinsmidsrod]

Well, then those are the ones you need to boot with wimboot. If they are around 100-200MB, then you have the right ones.

[EvilBart]

For me this helped to get a first successfull boot - client and wds in different subnets. I want to share it:

WDS: 10.10.10.10 subnet /24 [windows 2012 server]
clients in subnet 10.10.90.0/24 [test VMs]
ISC DHCP 10.10.90.1
Linux tftp 10.10.90.1

It is little dirty but it is a base to build a menu around it:
- hit ctrl+b when iPXE starts booting
- type 2 commands:
dhcp
boot wds

wds - put on root of tftp:

Code:

#!ipxe
set user-class wds
autoboot

isc dhcp:

Code:

.....
if exists user-class and option user-class = "wds" {
        next-server 10.10.10.10;
        filename "boot\\x86\\wdsnbp.com";
}
else
{  
        filename "undionly.kpxe";
        next-server 10.10.90.1;
}
        .....

I am posting this because getting to work wds from another subnet was a nightmare for me.
I also noticed that with some PXE implementations ovveriding from iPXE like:
set next-server 10.10.10.10
set dhcp/next-server 10.10.10.10
does not give any effects wdsnbp.com still try to boot from 10.10.90.1 instead of 10.10.10.10.

I was unable to boot wds without giving the next-server via dhcp.
I had not success trying to chainload wds with other methods.

Regards,
BZ

[robinsmidsrod]

With the current master branch of iPXE (2016-01-21), this has been reported to work properly:

Code:

#!ipxe
set wdsserver:ipv4 192.168.XX.XX
set netX/next-server ${wdsserver}
chain tftp://${wdsserver}/SMSBoot\x64\wdsmgfw.efi

See https://git.ipxe.org/ipxe.git/commitdiff...3c65315ff0 for details.