First, remember that Microsoft neither invented or owns PXE in any way and that PXE is a standard protocol so PXE functionality has *nothing* to do with SMS 2003, ConfigMgr 2007 ConfigMgr 2012 or any version of any PXE server from any vendor - they are all just implementing an industry standard. Also remember that PXE booting a system is up to that system's NIC - Microsoft is not involved at all (on the client side). This leads to the support statement by Microsoft - remember as discussed that "supported" means it's just something they didn't test but also is often indicative of something they expect not to work or know not to work - for DHCP scope options to work you are counting on the NIC to do the right thing and is thus is completely outside the control of Microsoft (kind of hard for them to guarantee a process they have no part in). Does it work most of the time: Yes, almost always. Are there NICs that have been known to not do the right thing? Yes. It's not common at all, but there are NICs that freak out and don't know how to properly handle the options. The worst part of this is that there almost no way to troubleshoot this because as mentioned, it's the NIC not doing what's expected.
Even using iphelpers are outside the control of Microsoft but in this case the burden is on the network and not on the NIC; although it's still possible for the NIC to do wonky things, it's a much simpler thing and can be troubleshot by watching/tracing/sniffing the network traffic. They support this method because it's how PXE was designed to work and what they test against. The reason many article on the Internet say to use DHCP scope options is because the authors simply don't know any better - that's what worked for them so that's what they used and wrote about. Finally, the reason that the DHCP scope options are actually required when the PXE server is co-located with a DHCP server is because they use the same protocol and thus listen on the same port which is not possible to have happen on a single system. Thus you must adjust the PXE server to listen on another port which means the normal PXE process would never work without telling the NIC directly that something slightly different is going on; this of course is done using the DHCP scope options. This generally works quite well, but it's no-standard and to be avoided if at all possible. Do nonstandard "things", get non-standard results (kind of like Murphy's law). J From: [email protected] [mailto:[email protected]] On Behalf Of Mohamed, Hatem (ext) Sent: Tuesday, August 27, 2013 8:39 AM To: [email protected] Subject: [mssms] RE: DHCP / PXE / SCCM 2012 I think the first statement you are referring to is when DHCP and the PXE service point reside on the same server. That is the only situation where you would be forced to configure the dhcp options. http://blogs.technet.com/b/system_center_configuration_manager_operating_system_deployment_support_blog/archive/2011/10/14/troubleshooting-the-pxe-service-point-and-wds-in-configuration-manager-2007.aspx "The only exception where a DHCP Option needs to be used is when DHCP and WDS reside on the same server. In this instance, DHCP Option 60, and only DHCP Option 60, needs to be set. DHCP Options 66 and 67 should still NOT be set in this scenario. For more information, please see the below section "Co-hosting DHCP and WDS On The Same Server"." This still applies to 2012 when dealing with PXE, IPHelpers and scope options if necessary. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Steve Wouden Sent: Tuesday, August 27, 2013 6:38 AM To: [email protected]<mailto:[email protected]> Subject: [mssms] DHCP / PXE / SCCM 2012 I,ve been using SMS 2003 for almost 9 years. As far as I know, it was a must to configure the DHCP server with the PXE options 66 and 67 for PXE, although everything is on the same subnet. Configure ip helpers only when crossing subnets or vlans. 2 years ago I upgraded to SCCM 2007, and changed the values for those PXE options. Now I'm in the process of migrating to SCCM 2012, and came across a few articles claiming that I don't have to configure the PXE options on the DHCP server. And that those options also are not supported by Microsoft.. But there are more articles and documents on the internet, saying to configure the PXE options on the DHCP server. Confusing.. Now I know( I think), that I don't need to configure the DCHP server with the PXE settings. Just looking for some confirmation. And SCCM PXE Service point handling the PXE request, is that faster, better, more secure?? Thanx [http://www.stibbe.nl/upload/43a9253f012549947f43011f03.jpg]<http://www.stibbe.com/> Amsterdam - Brussels - Luxembourg - Dubai - Hong Kong - London - New York Visitors address: Strawinskylaan 2001 - 1077 ZZ Amsterdam - The Netherlands Postal address: P.O. Box 75640 - 1070 AP Amsterdam - The Netherlands This e-mail may contain information which is privileged or confidential. If you have received this e-mail in error, please notify us immediately by e-mail or telephone and delete the e-mail without copying or disclosing its contents to any other person. Stibbe is a business name of Stibbe N.V. The practice is conducted by Stibbe N.V. (registered with the Trade Register of the Chamber of Commerce under number 34198700), whose objective is to practise the profession of attorneys at law ('advocaten') or civil law notaries of the Netherlands; admitted to the bar in Amsterdam. The general conditions of Stibbe N.V. are applicable to every instruction accepted by Stibbe and include a clause on limitation of liability. The client's general conditions (if any) do not apply to an instruction accepted by Stibbe and are hereby expressly rejected. The legal relationship between the client and Stibbe is governed exclusively by Dutch law, with the exception of rules of private international law. Disputes shall be decided exclusively by the competent court in Amsterdam, the Netherlands. The general conditions have been deposited at the Amsterdam District Court and are published on www.stibbe.com/generalconditions<http://www.stibbe.com/generalconditions>. They are also available on request from Stibbe and will be sent to you free of charge. P Before printing this e-mail, please consider the impact on the environment.
