It's timely that this topic came up, as I just recently put a request in to our network team to change from DHCP options to IP helper. I came across this blog post as a nice write up of two approaches. http://techthoughts.jakemorrison.name/pxe-booting-wds-dhcp-scope-vs-ip-helpers/
From: listsad...@lists.myitforum.com [mailto:listsad...@lists.myitforum.com] On Behalf Of Phil Wilcock Sent: Tuesday, January 6, 2015 11:06 AM To: mssms@lists.myitforum.com 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: listsad...@lists.myitforum.com<mailto:listsad...@lists.myitforum.com> [mailto:listsad...@lists.myitforum.com] On Behalf Of Andreas Hammarskjöld Sent: 06 January 2015 13:11 To: mssms@lists.myitforum.com<mailto:mssms@lists.myitforum.com> 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: listsad...@lists.myitforum.com<mailto:listsad...@lists.myitforum.com> [mailto:listsad...@lists.myitforum.com] On Behalf Of Andreas Hammarskjöld Sent: den 5 januari 2015 08:18 To: mssms@lists.myitforum.com<mailto:mssms@lists.myitforum.com> 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: listsad...@lists.myitforum.com<mailto:listsad...@lists.myitforum.com> [mailto:listsad...@lists.myitforum.com] On Behalf Of Mote, Todd Sent: den 5 januari 2015 00:15 To: mssms@lists.myitforum.com<mailto:mssms@lists.myitforum.com> 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: listsad...@lists.myitforum.com<mailto:listsad...@lists.myitforum.com> [mailto:listsad...@lists.myitforum.com] On Behalf Of Andreas Hammarskjöld Sent: Sunday, January 4, 2015 1:06 PM To: mssms@lists.myitforum.com<mailto:mssms@lists.myitforum.com> 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<https://urldefense.proofpoint.com/v2/url?u=http-3A__10.1.1.2&d=AwQFAw&c=aLnS6P8Ng0zSNhCF04OWImQ_He2L69sNWG3PbxeyieE&r=pQGVi_ygWZb0EWR_EeMFzgKJCQ8AFTQI7Ck6iiIPItI&m=cZluzP0ZAZQajeemcsS_kq4K4kBeb_6alPVZG5d4RQI&s=-wa8cq_CvvUo7w3tgWe31X6Zo0v56Y2B5Bk7usXKX_w&e=>; # 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<https://urldefense.proofpoint.com/v2/url?u=http-3A__boot.smidsrod.lan_boot.ipxe&d=AwMFAw&c=aLnS6P8Ng0zSNhCF04OWImQ_He2L69sNWG3PbxeyieE&r=pQGVi_ygWZb0EWR_EeMFzgKJCQ8AFTQI7Ck6iiIPItI&m=cZluzP0ZAZQajeemcsS_kq4K4kBeb_6alPVZG5d4RQI&s=0E2WHfMa14PjrdbGqYWlCLRdHnrGhHPXj0SXAb8uY4w&e=>"; } 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: listsad...@lists.myitforum.com<mailto:listsad...@lists.myitforum.com> [mailto:listsad...@lists.myitforum.com] On Behalf Of Mote, Todd Sent: den 4 januari 2015 19:18 To: mssms@lists.myitforum.com<mailto:mssms@lists.myitforum.com> 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: listsad...@lists.myitforum.com<mailto:listsad...@lists.myitforum.com> [mailto:listsad...@lists.myitforum.com] On Behalf Of Michael Niehaus Sent: Sunday, January 4, 2015 12:06 PM To: mssms@lists.myitforum.com<mailto:mssms@lists.myitforum.com> 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: listsad...@lists.myitforum.com<mailto:listsad...@lists.myitforum.com> [mailto:listsad...@lists.myitforum.com] On Behalf Of Andreas Hammarskjöld Sent: Sunday, January 4, 2015 4:59 AM To: mssms@lists.myitforum.com<mailto:mssms@lists.myitforum.com> 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: listsad...@lists.myitforum.com<mailto:listsad...@lists.myitforum.com> [mailto:listsad...@lists.myitforum.com] On Behalf Of Andreas Hammarskjöld Sent: den 4 januari 2015 13:05 To: mssms@lists.myitforum.com<mailto:mssms@lists.myitforum.com> 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://urldefense.proofpoint.com/v2/url?u=http-3A__2pintSoftware.com&d=AwMFAw&c=aLnS6P8Ng0zSNhCF04OWImQ_He2L69sNWG3PbxeyieE&r=pQGVi_ygWZb0EWR_EeMFzgKJCQ8AFTQI7Ck6iiIPItI&m=cZluzP0ZAZQajeemcsS_kq4K4kBeb_6alPVZG5d4RQI&s=nHkM3VZS-iKmMvSDAf3UcNUYrPglutjGhZQCFW36Hos&e=> https://twitter.com/AndHammarskjold<https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_AndHammarskjold&d=AwMFAw&c=aLnS6P8Ng0zSNhCF04OWImQ_He2L69sNWG3PbxeyieE&r=pQGVi_ygWZb0EWR_EeMFzgKJCQ8AFTQI7Ck6iiIPItI&m=cZluzP0ZAZQajeemcsS_kq4K4kBeb_6alPVZG5d4RQI&s=7_WfxfLLKBz4tRzb3vbyLxcXxESX0IYjFOiFJ6m3M5k&e=> ________________________________ CONFIDENTIALITY NOTICE: This email contains information from the sender that may be CONFIDENTIAL, LEGALLY PRIVILEGED, PROPRIETARY or otherwise protected from disclosure. This email is intended for use only by the person or entity to whom it is addressed. If you are not the intended recipient, any use, disclosure, copying, distribution, printing, or any action taken in reliance on the contents of this email, is strictly prohibited. If you received this email in error, please contact the sending party by reply email, delete the email from your computer system and shred any paper copies. Note to Patients: There are a number of risks you should consider before using e-mail to communicate with us. See our Privacy & Security page on www.henryford.com for more detailed information as well as information concerning MyChart, our new patient portal. If you do not believe that our policy gives you the privacy and security protection you need, do not send e-mail or Internet communications to us.
