none
Surface pro 4 does not PXE boot RRS feed

  • Question

  • Hello, 

     

    I am trying to PXE boot surface pro 4 and for some reason it does not boot. I get the attached message. It tries to PXE over IP v4, then reaches my correct DP that has PXE and WDS, it finds the correct NBP file SMSBoot\x64\wdsnbp.com (this is specified in DHCP option), it appears to be downloading and NBP file is successfully downloaded. Then without prompting to press Enter key for PXE boot, it moves to IPV6.

     

    I have tried below but no luck

     

    • Upgrade firmware to latest
    • disable secure boot
    • Removed DHCP option - but this time it doesn't even finds my PXE server
    • Verified and made sure MAC address of network adapter is not registered with SCCM DB
    • Tried docking station and no luck

    I can PXE boot a desktop on same network with no issues. 

     

    Any suggestions would be helpful

     

    SCCM Hierarchy - 1 primary and 1 secondary. 

    SCCM = 2012 R2 SP1 CU1

    Server = Windows server 2012 R2 Datacenter


    Thanks. 

    Thursday, December 31, 2015 8:28 PM

All replies

  • Instead of using DHCP Options 66/67, use ip helpers;

    https://support.microsoft.com/en-us/kb/2602043


    Don [doesn't work for MSFT, and they're probably glad about that ;]

    Friday, January 1, 2016 12:21 AM
  • Are you using a Surface Pro USB Gigabit Ethernet Adapter when attempting to PXE Boot?

    Cheers

    Damon

    Friday, January 1, 2016 10:08 PM
  • hi Jack

    you really should use ip helpers instead of DHCP options as called out in another post here,

    however if you cannot do so try setting the below options

    Option 60: PXEClient
    Option 66: IP address of your WDS Server
    Option 67: SMSBoot\x64\wdsnbp.com

    note that while this might make the Surface Pro 4 UEFI network bootable, it will probably stop all your non x64 bit legacy devices from PXE booting.

    cheers

    niall



    Step by Step Configuration Manager Guides > 2012 Guides | 2007 Guides | I'm on Twitter > ncbrady


    Monday, January 4, 2016 8:41 AM
    Moderator
  • Thanks all.

    I am using a dock. Tryed with USB adapter as well and same behaviour

    As suggested, I have configured IP helper. My clients is on a different LAN, DHCP and WDS is on different VLAN. So IP helper is added to VLAN one entry pointing to local SCCM server that has PXE and WDS installed and another entry pointing to DHCP server. Still no go. 


    Restarted WDS, no go. Added IP helper on both vlan and no go. There is no antivirus on local SCCM server. If i add DHCP options, then i can PXE boot desktop so that tells everything else is working. 

    Am i missing anything? 

    Monday, January 4, 2016 9:15 PM
  • If you use DHCP then you have to point it to the .EFI file versus the .com if I am not mistaken, which breaks non UEFI ability to PXE boot.  This is why IP Helpers should be used instead ;-)

    To see if your machine is making contact, monitor the SMSPXE.log file on the DP when you attempt to PXE boot.  If you see the device show up (by GUID or MAC) in the log then you know its talking to the server and can give you a clue why its not being offered a deployment.

    If you see no action in the log when you PXE boot, then the device is unable to reach the server (helper or dhcp issue likely)

    Monday, January 4, 2016 9:22 PM
  • Thanks. I looked at SMSPXE.log and there are no entries. That is why it makes me think there is something i am missing on IP helper side

    Monday, January 4, 2016 10:12 PM
  • Hey guys,

    I'm experiencing the same exact issue as Jack. We have IP Helpers configured on our switches but still cannot PXE boot a Surface Pro 4. Microsoft released new drivers today (151216_0) and I am currently testing these.

    I feel like something is missing either from firmware or drivers because I can PXE boot other devices just fine.

    I'll update the thread if I have any success with the drivers.

    Has anyone had success with adding the options 60,66, and 67 or any of the other talked about resolutions?

    Tuesday, January 5, 2016 12:08 AM
  • Hey guys,

    I'm experiencing the same exact issue as Jack. We have IP Helpers configured on our switches but still cannot PXE boot a Surface Pro 4. Microsoft released new drivers today (151216_0) and I am currently testing these.

    I feel like something is missing either from firmware or drivers because I can PXE boot other devices just fine.

    I'll update the thread if I have any success with the drivers.

    Has anyone had success with adding the options 60,66, and 67 or any of the other talked about resolutions?

    *Update* I double checked my VLAN for the port I was trying to PXE boot from and it was not the same VLAN as my Distribution Point. I switched the VLAN to match the server VLAN and was able to PXE boot successfully.

    Jack, I would recommend you check your drops VLAN as well.

    Tuesday, January 5, 2016 12:15 AM
  • Thanks Jarryd,

    My client computers on in a VLAN and servers on a different VLAN. We do not have a option to switch all clients and server to one VLAN. My understanding is IP helper should take care of this 

    Tuesday, January 5, 2016 1:43 PM
  • Yeah, its typically recommended to not have your workstations and servers on the same vlan and is certainly not required.  IP Helpers (or DHCP if you must) allow you to traverse VLANs for PXE requests.

    So Jack when you watch the SMSPXE.log while your machine is attempting to PXE boot you see no entries relating to the machine?  If this is indeed the case then your machine is not talking to SCCM and thus is not an SCCM issue.  It would be a network issue since you are getting an IP.  I would reach out to your network team and ensure the IP Helper is setup, then ensure DHCP options 66/67 are NOT configured.

    Friday, January 8, 2016 2:23 PM
  • Thank you William,

    I did not see any entry in SMSPXE log. DHCP option 66/67 is not configured. I have reached to network team and asked them to check IP helper set up. 

    Friday, January 8, 2016 2:28 PM
  • Let us know how it goes!
    Friday, January 8, 2016 4:26 PM
  • Hi Jack,

    If the issue has been resolved, we'd love to hear your solution. By sharing your experience you can help other community members facing similar problems.


    Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Monday, January 18, 2016 9:52 AM
    Moderator
  • Hi Jack,

    This is not a fix, but a workaround that we used.

    After many hundreds of choice profanities, pulling of hair and pleading with the device to "just ****ing work!", i gave up and used a bootable USB to boot into WinPE and then imaged it that way.

    It was a solution that worked for us given the limited number we have, but may or may not be suitable for your environment.

    Regards,

    Dean


    • Edited by Dean McGinnes Monday, January 18, 2016 10:04 AM
    • Marked as answer by Jack_SCCM Monday, January 18, 2016 3:39 PM
    • Unmarked as answer by Jack_SCCM Monday, January 18, 2016 3:39 PM
    Monday, January 18, 2016 10:01 AM
  • Thanks Dean,

    This is what exactly we did. Used boot image on USB to boot Surface pro. 


    Monday, January 18, 2016 3:39 PM
  • I had trouble booting to PXE from a Surface Pro 4, but I found out the problem is because the Surface tablets use UEFI instead of legacy BIOS, so you need to update your DHCP server to load the proper NBP file at startup. This is done by using the following DHCP options:

    • Option 60: PXEClient
    • Option 66: IP address (or hostname) of your WDS Server
    • Option 67: Boot\x64\wdsmgfw.efi

    Obviously make sure you're using the correct path to your WDS boot files when setting Option 67. However, the most important part is to use the EFI file and not the COM file that is there already.

    But take note that if you change the boot file to support UEFI machines, you'll be disabling support for BIOS-only machines. There's a way to do both, but you will need to create DHCP policies and custom vendor classes. If you need those instructions, I can provide them.

    • Edited by Brandon Hann Tuesday, February 9, 2016 10:33 PM Added list format
    • Proposed as answer by Brandon Hann Tuesday, February 9, 2016 10:36 PM
    • Unproposed as answer by Brandon Hann Tuesday, February 9, 2016 10:36 PM
    Tuesday, February 9, 2016 10:33 PM
  • Just commenting here.

    Opened up our first Surface Pro 4 - PXE booted straight away without any problems using the latest Surface Pro 4 Ethernet Adapter.

    Running Server 2012 R2. WDS and DHCP running on the same box so haven't had to add any custom PXE options.

    Cheers

    Damon

    Sunday, February 14, 2016 10:04 PM
  • i set the boot optioin and move PIXI boot to the first option, 

    what i think happens from here is you actually need to let windows load and then re-boot for the settings to save, 

    after doing that that the Surface booted to PIXi on its own???

    good luck

    Thursday, February 25, 2016 12:01 AM
  • Please provide the steps for the vendor classes, pertaining to the surface pro 4.
    Monday, July 25, 2016 8:40 PM
  • Can you please provide the details of the dual way of booting using DHCP policies & custom vendor classes that you had mention?
    Tuesday, September 13, 2016 6:41 AM
  • Can you please provide the details of the dual way of booting using DHCP policies & custom vendor classes that you had mention?

    here's a useful example, provided by the FOG project

    https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence

    some MSFT doco about Policy Based Assignment: https://technet.microsoft.com/en-us/library/dn425039(v=ws.11).aspx

    an older WS2003 example: https://blogs.technet.microsoft.com/troubleshooting_walk_through/2013/11/01/what-comes-with-option-43-and-configuring-in-dhcp/


    Don [doesn't work for MSFT, and they're probably glad about that ;]

    Tuesday, September 13, 2016 9:34 AM
  • If you use IP Helpers vs DHCP, you will get support for both UEFI and BIOS PXE booting.  This is the preferred method and much easier to manage IMO.
    Wednesday, September 14, 2016 2:47 PM
  • Can you explain a little more about the "IP Helpers" you referred to?  To my knowledge, "IP Helper" is the feature on Cisco switches/routers that forwards DHCP broadcasts to a specific DHCP server address.  I think the server address is the only parameter used in Cisco's ip-helper setting. What other "IP Helper" is there?  How do we implement it so that it works for both UEFI and BIOS PXE booting?
    Tuesday, October 4, 2016 8:17 PM
  • Not only is IP Helper the "preferred" method, it is the "correct" method.

    Wednesday, October 5, 2016 5:45 AM
  • To my knowledge, "IP Helper" is the feature on Cisco switches/routers that forwards DHCP broadcasts to a specific DHCP server address.  
    ... and also PXE traffic so you have to configure it to forward traffic to both the DHCP and PXE server. Done.

    Torsten Meringer | http://www.mssccmfaq.de

    Wednesday, October 5, 2016 5:54 AM
  • Can you explain a little more about the "IP Helpers" you referred to?  To my knowledge, "IP Helper" is the feature on Cisco switches/routers that forwards DHCP broadcasts to a specific DHCP server address.  I think the server address is the only parameter used in Cisco's ip-helper setting. What other "IP Helper" is there?  How do we implement it so that it works for both UEFI and BIOS PXE booting?

    Basically, the Cisco 'ip helper-address' is a method to 'forward' and 'return' the DHCP DORA sequence.
    This will also forward and return a bootp/PXE sequence.
    So if you configure the 'ip helper' / 'boot forwarder' so that the router i/f will forward DHCP *and* PXE to *both* your DHCP server *and also* your PXE server, that's then up to the DHCP server and the PXE server to issue the correct response in return.
    A PXE boot request sent by the client will include a client_type inside Option 60, the DHCP server would not return anything useful in response inside Option60, but the PXE server will return a useful response inside the response options to the client, i.e. the bootserveraddress/bootfilename. This is how the PXE/UNDI ROM comes to know what bootfilename to request, and that's why you don't need to explicitly configure the bootserver/bootfilename within DHCP Options66/67.

    there are a few articles around the web which explain, but this PDF by the iPXE guys talks about that and more (like another example of how you can use DHCP options, which work, but are not officially "supported" by MSFT, and, are fiddly to implement)

    http://2pintsoftware.com/whitepaper-using-dhcp-uefi-bios-pxe-booting/


    Don [doesn't work for MSFT, and they're probably glad about that ;]

    Wednesday, October 5, 2016 6:52 AM