Yeah, since the PXE standard is a bit soft around the edges I can see why. It's
been interesting working with the Linux/*nix PXE people, they taught me a lot
about this. And they do it all by DHCP, not proxy at all, and never had any
issues. :-/
But their DHCP servers are way more sophisticated/complicated than MS DHCP.
Below is an example of ISC DHCP config:
allow bootp;
allow booting;
next-server 10.1.1.2; # core.smidsrod.lan
# Disable ProxyDHCP, we're in control of the primary DHCP server
option ipxe.no-pxedhcp 1;
# Make sure the iPXE we're loading supports what we need,
# if not load a full-featured version
if exists ipxe.http
and exists ipxe.menu
and exists ipxe.nfs
and ( ( exists ipxe.pxe
and exists ipxe.bzimage
and exists ipxe.elf
and exists ipxe.comboot
and exists ipxe.iscsi
) or (
exists ipxe.efi
) ) {
filename "nfs://nas.smidsrod.lan/raid/boot/boot.ipxe";
#filename "http://boot.smidsrod.lan/boot.ipxe";;
}
elsif exists user-class and option user-class = "iPXE" {
# We're already using iPXE, but not a feature-full version,
# and possibly an out-of-date version from ROM, so load a more
# complete version with native drivers
# Allow both legacy BIOS and EFI architectures
if option arch = 00:06 {
filename "ipxe-x86.efi";
} elsif option arch = 00:07 {
filename "ipxe-x64.efi";
} elsif option arch = 00:00 {
filename "ipxe.pxe";
}
}
elsif exists user-class and option user-class = "gPXE" {
# If someone has an old version of gPXE burned into their ROM,
# load a more recent iPXE
filename "ipxe.pxe";
}
elsif option arch = 00:06 {
# EFI 32-bit
# I like to use iPXE-provided drivers, so therefore give ipxe.efi
# to all non-iPXE clients, use snponly.efi if you have unsupported
# or misbehaving NICs
filename "ipxe-x86.efi";
#filename "snponly-x86.efi";
}
elsif option arch = 00:07 {
# EFI 64-bit
# I like to use iPXE-provided drivers, so therefore give ipxe.efi
# to all non-iPXE clients, use snponly.efi if you have unsupported
# or misbehaving NICs
filename "ipxe-x64.efi";
#filename "snponly-x64.efi";
}
elsif option arch = 00:00 {
# Legacy BIOS x86 mode
# I like to use iPXE-provided drivers, so therefore give ipxe.pxe
# to all non-iPXE clients, use undionly.kpxe if you have unsupported
# or misbehaving NICs
filename "ipxe.pxe";
#filename "undionly.kpxe";
}
else {
# Unsupported client architecture type, so do nothing
}
//A
From: [email protected] [mailto:[email protected]] On
Behalf Of Mote, Todd
Sent: den 4 januari 2015 19:18
To: [email protected]
Subject: [mssms] RE: PXE Service Point from DHCP Scope
Unfortunately, I don't control which networks all of our systems get put on.
All Windows on one network and all of our *nix systems on separate ones to make
use of IPHelpers is unrealistic here. I use DHCP to control whether to PXE to
SCCM, WDS, or Cobbler for *nix, on a per system basis with reservation options,
or scope with scope options where it makes sense. It's worked great for a
number of years, and we've never had any issues with it.
And Michael is right, any problems I've ever seen with WDS/PXE/DHCP/SCCM have
all been endpoint problems. i.e. PXE code on/in the NIC on the device being
PXE booted. When I get complaints about WDS not working, my first response is
always "Have you updated the BIOS on your computer?" And that usually clears
it up. We're a Dell/VMware shop mostly, and homogeneity helps a ton in this
regard.
We haven't come to the UEFI vs. non-UEFI bridge yet, so we haven't had to come
up with a way to cross it. I suspect it's closer than I'd like though.
Todd
From: [email protected]<mailto:[email protected]>
[mailto:[email protected]] On Behalf Of Michael Niehaus
Sent: Sunday, January 4, 2015 12:06 PM
To: [email protected]<mailto:[email protected]>
Subject: [mssms] RE: PXE Service Point from DHCP Scope
The problem with the statement is that it doesn't say "why." There have been a
number of support cases opened where DHCP options didn't work correctly (and in
some configurations, extra complications for UEFI vs. non-UEFI); these have
been traced back to problematic firmware revisions on random PCs.
So it's much easier to say "not supported" than to say "use at your own risk
and don't call us if it doesn't work."
Thanks,
-Michael
From: [email protected]<mailto:[email protected]>
[mailto:[email protected]] On Behalf Of Andreas Hammarskjöld
Sent: Sunday, January 4, 2015 4:59 AM
To: [email protected]<mailto:[email protected]>
Subject: [mssms] RE: PXE Service Point from DHCP Scope
Senior found it: http://www.microsoft.com/en-us/download/details.aspx?id=44598
"All bollocks" as the English would say though:
"Furthermore the use of DHCP Options to control PXE requests in Configuration
Manager 2012 is not supported by Microsoft. Therefore the recommended and
supported method of PXE booting client PCs that are on a different subnet than
the DHCP or WDS/PXE Service Point servers is the use of IP Helpers. "
I think the quote from the *nix community is more spot on:
"As I see it in the windows world nobody actually know how DHCP works - or are
just too lazy to try to understand it. And it is impossible to configure WDS
and it breaks if you even try to look at it."
So what we have here is a failure to communicate...
//Andreas
From: [email protected]<mailto:[email protected]>
[mailto:[email protected]] On Behalf Of Andreas Hammarskjöld
Sent: den 4 januari 2015 13:05
To: [email protected]<mailto:[email protected]>
Subject: [mssms] PXE Service Point from DHCP Scope
Hey,
I seem to recollect a discussion where it was mentioned that it wouldn't work
booting from a PSP using DHCP options or was that just a "not supported"
clarification?
Been doing some oogling on it but seems like people are confused mostly?
//A
Best regards,
//Andreas
Co-Founder
+46 727 253995
http://2pintSoftware.com
https://twitter.com/AndHammarskjold
