Sounds like a new 'product' is being vetted out in the forums. Looking for knowledge, or being sneaky here?
On Tue, Jan 6, 2015 at 11:18 AM, Andreas Hammarskjöld < [email protected]> wrote: > Microsoft only does cloud stuff these days, not client/server stuff. ;-) > Will blog on this one once the iPXE things are sorted! > > > > Courtesy to the syslinux community member Alexandre Blanchette; here is > the closest I got to an explanation & guide on how to do this: > > > > I've found a way to support PXE booting both UEFI and BIOS architectures > > with Windows Server DHCP. > > > > This method uses a feature introduced in WinServer 2012: DHCP policies. > > > > First, in the the DHCP console, at the IPv4 root of the server, create a > > vendor class named PXEClient (UEFI x64) with the following value: > > PXEClient:Arch:00007 > > > > Then create your configuration for your BIOS clients in your scope or as > > global settings as usual by setting options 66 (IP or hostname of your TFTP > > host) and 67 (pxelinux.0). > > > > For the UEFI clients, you must then create a policy. In the condition page > > of the wizard, add a condition with the following settings: > > Criteria: Vendor Class > > Operator: Equals > > Value: PXEClient (UEFI x64) > > Tick Append wildcard(*) > > > > Do not configure an IP address range for the policy. > > > > Finally configure options 66 (TFTP server) and 67 (syslinux.efi). You must > > separate TFTP servers for your BIOS and UEFI clients because Microsoft DHCP > > server does not send option 210 (path prefix). Microsoft DHCP servers will > > only send options listed in the Parameter Request List in the DHCPDISCOVER > > packet. > > > > One could make a cleaner setup by creating a BIOS PXEClient vendor class > > and putting their options within a policy too. > > > > //A > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Phil Wilcock > *Sent:* den 6 januari 2015 17:06 > > *To:* [email protected] > *Subject:* [mssms] RE: PXE Service Point from DHCP Scope > > > > Would be nice if MSFT could update the docs to include this info, as it’s > a bit vague as to what is ‘supported’ and what isn’t. > > > > In this WP - http://www.microsoft.com/en-us/download/details.aspx?id=44598 > it states: > > > > An alternative to using IP Helpers is setting DHCP Options on the DHCP > server, specifically DHCP Options 60 (PXE Client), 66 (Boot Server Host > Name), and 67 (Boot file Name). However, DHCP Options can be problematic > and may not work reliably or consistently. 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. > > > > But in here > http://technet.microsoft.com/en-us/library/cc732351(WS.10).aspx#Using it > says that Microsoft ‘does not recommend’ this method. > > > > Bottom line here seems to be that it’s a bit complicated and therefore > we’ll shift blame over to the HW vendors and not support it. Which is a > shame because who wants to go to their Network guys and ask them to config > thousands of routers? > > > > MS own all the bits here – make em play nice together! > > > > Senior 2Pint > > > > *From:* [email protected] [ > mailto:[email protected] <[email protected]>] *On > Behalf Of *Andreas Hammarskjöld > *Sent:* 06 January 2015 13:11 > *To:* [email protected] > *Subject:* [mssms] RE: PXE Service Point from DHCP Scope > > > > Todd, we were wrong. DCHP server in Server 2012 got something called > Policies, which can control the response behavior. This means you can > control what we should reply to who. Just discovered this but think I can > get it to send different boot loaders to different HW capabilities. > > > > I can definitely set it to send my iPXE boot loader a different TFTP > server in option 66, so should be doable. If so, I will blog about it. > > > > So I will have to retract my statement, the MS DHCP server is pretty > capable. > > > > //A > > > > *From:* [email protected] [ > mailto:[email protected] <[email protected]>] *On > Behalf Of *Andreas Hammarskjöld > *Sent:* den 5 januari 2015 08:18 > *To:* [email protected] > *Subject:* [mssms] RE: PXE Service Point from DHCP Scope > > > > Yeah, MS DHCP is pretty much the same since NT4. I would consider moving > of MS DHCP to something like ISC since UEFI is unavoidable. > > > > //A > > > > *From:* [email protected] [ > mailto:[email protected] <[email protected]>] *On > Behalf Of *Mote, Todd > *Sent:* den 5 januari 2015 00:15 > *To:* [email protected] > *Subject:* [mssms] RE: PXE Service Point from DHCP Scope > > > > Yea, I don’t think MS DHCP has changed in quite a while. It would be > nice to see an architecture aware update for MS DHCP in Win10 server maybe, > but that’s probably reaching. I’ll defer crossing the UEFI river as long > as I can. > > > > > > > > *From:* [email protected] [ > mailto:[email protected] <[email protected]>] *On > Behalf Of *Andreas Hammarskjöld > *Sent:* Sunday, January 4, 2015 1:06 PM > *To:* [email protected] > *Subject:* [mssms] RE: PXE Service Point from DHCP Scope > > > > 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] <[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] <[email protected]>] *On > Behalf Of *Michael Niehaus > *Sent:* Sunday, January 4, 2015 12:06 PM > *To:* [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] <[email protected]>] *On > Behalf Of *Andreas Hammarskjöld > *Sent:* Sunday, January 4, 2015 4:59 AM > *To:* [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] <[email protected]>] *On > Behalf Of *Andreas Hammarskjöld > *Sent:* den 4 januari 2015 13:05 > *To:* [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 > > > > > > > > > > > > > > > > > > > > > > -- Hes Automate it
