Boot X64 Wdsnbp.com

[Bonifacia Cramm]

Ive removed it from all other DP's in the domain so I'm hoping that fixes it but I'm wondering why would the client choose to grab that one, when there are other boot images on the server it could have used?

The wdsnbp.com file is the file on the DP after we enable PXE on DP. The file path is: C:\RemoteInstall\SMSBoot\x64 or C:\RemoteInstall\SMSBoot\x86. Although we don't configure wdsnbp.com in the task sequence, this is what the boot process needs.

2,==>but I'm wondering why would the client choose to grab that one, when there are other boot images on the server it could have used?

Here is an awesome article that detailed explains which boot image will be delivered to a PXE booted client at PXE time.

-image-selection-configmgr/

In short, the last boot image associated with the last TS deployed will be the one used.

If the response is helpful, please click "Accept Answer" and upvote it.

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

So after finally figuring out how to add the DHCP options 66 and 67 to my DHCP Scope on the Sophos XG Firewall I am now having trouble with how it's presenting the values. I know ip helpers are the preferred way of doing things but my setup doesn't allow for that. Here's what I have and what's happening:

Running Wireshark I can see that the PC sends out DHCP Discover, Offer, Request and finally the ACK and get's the IP address. I see this also in Sophos, so I know the DHCP part is working. Drilling down I can see the DHCP options that it's sending and this is where I think things are going wrong.

Depending on the version of the NIC (I'm using a Hyper-V VM for testing) option 66 wont get sent at all (Generation 1 using Legacy NIC for PXE boot). Generation 2 does receive option 66. Option 66 being the IP address of the WDS server.

However, option 67 which is the bootfile name which should be boot\x64\wdsnbp.com will always remove the '\' character, no matter how many times I try and escape it. When I add this option in the CLI I enter it as boot\\\\x64\\\\wdsnbp.com and when I list the bindings it shows 'boot\x64\wdsnbp.com' which is correct but that's not what it's sending to the client.

That's kind of a long winded way of saying I don't think the DHCP options are being sent correctly from Sophos or I am doing something really really wrong. However, I have also added boot options for my VOiP phones and that works perfectly for auto-provisioning them (again on a different VLAN) so that piece works.

The first step of this, of course, is to put the existing image on the VM, and in order to do that, I need to PXE boot the VM. This is failing on Virtualbox on a Windows host, Virtualbox on a Mac host, and VMWare Workstation on a Windows host, but I am able to PXE boot a physical computer and image it with no issues.

Last edit:

Worked-around. Since it's a VM that's not booting, we built boot .isos that could just live on the virtual host, using these instructions: -deployment-services-how-to-create-a-bootable-deployment-iso/

we have just recently made a change in where we moved clients from one segment to a new one. We are using WDS for PXE boot and the WDS server (MDT 2013) is on a different segment than the clients. The Palo is our DHCP server for clients and we have defined some options in our DHCP scope (option 66 pointing to the WDS server and option 67 pointing to the bootfile).

Hi Slawek and thanks for your response. I will change the boot file name to the one you are using. When it comes to security policies I'm not sure and will have to check this closer. I guess there will some policy in regards of TFTP needed?

I'm guessing we have some problems with TFTP and I'm just thinking we might have to create a Policy-Based Forwarding rule for TFTP (port 69) between the client net and the server net? If you have any suggestions I'd be really happy!

When your client receives a TFTP server information from the palo DHCP server, what can you see in the traffic logs on palo? Is your TFTP server in the same subnet as client or not (looks like it is not)? Are they in the same zone (same zone traffic is allowed by default).

Client subnet and the server subnet are they in the same zone? If yes can you please override default Intra-zone policy or make sure you have login enabled on your current policy so you can see client attempts:

We have a zone where the TFTP/WDS server is located (Frontend) and a zone where the PXE clients are located (Client). We have a security rule that permitts TFTP application (service > application default) between these zones. Could it be I'm not allowing the correct services, eventhough TFTP is permitted?

I have a Linux PXE server.

Can boot into Linux ISO installers using PXE with no problems.

But how can I do it with Windows ISO? Just start the installation. Without creating some stuff (winpe) under Windows.

What should I do to continue booting process?I also created a Samba share with ISO contents, but how to connect all this?

All the tutorials I've found are either outdated or (most) require to create an additional boot image under Windows using its tools. Is it really so sad sad situation?

From what I remember, its still open source but they are an excellent project. I have done custom boots of either Barts Duke and Nuke ISO or Ultimate Boot CD (at the moment I cannot remember which one as the last time I was employed their was two years ago.) as a boot option from their PXE menu so I know it would help solve your problem if you only need to boot from an ISO instead of install an image. If you need to install an image its perfect for that too. From what I remember its a simple file change to add a boot option. Its all documented though on the website above. FOG is very powerful, my last job was using it for their main imaging solution. Here's an example where they boot ISO files by simply specifying a path to the ISO file:

There are third party -Automated PXE Server Solution Accelerators- able to do exactly what you want but run in Windows.Basically you extract the ISO content in a directory, you create a network share and the Automated PXE Server does the rest injecting the corresponding code within Boot.wim and automatically creating the corresponding boot menu entry for the booting PXE clients.

WindowsDeployment Services (WDS) is a set of services and APIs tofacilitate Windows operating system installation by using PXE, DHCPand TFTP to bootstrap WinPE, theWindowsPreinstallation Environment. You can think of it as providingsimilar functionality to iPXE with server-side scripting, whereclients are served boot configuration and images based on variouscriteria, such as hardware architecture.

The WDS TFTP service relies on a registry keyHKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/WDSServer/Providers/WDSTFTP/ReadFilterthat controls which TFTP paths are mapped to the directory containingthe various installation files defined by the RootFolder registry key in the same location.

This allows all relavant combinations of forward and backward slashes,with or without a prefix slash. The last entry is particularly odd,but is actually used by the initial WDS network boot program once ithas been chainloaded by iPXE, as seen in the example below.

Loading the initial WDS network boot program wdsnbp.com can bedone either directly from the iPXE shell or via a menu entry. The onlything that needs to be modified is the DHCP next-server parameter,which will let wdsnbp.com know which server to communicate with.

Once wdsnbp.com starts, it initiates a session with the WDS serverthat was specified in the DHCP next-server parameter. The sessionprotocol uses a combination of DHCP requests and responses and TFTP toprovide the client with the appropriate boot loader (such asbootmgr.exe or bootmgfw.efi) and boot configuration data(BCD).

The wdsnbp.com program performs client architecture detection andreports it back to the server via the WDS session. This sessionprotocol uses DHCP as an RPC service endpoint, and the data passedback and forth (such as architecture information) is encoded in DHCPoption 250. Together with option 252 (used by WDS to indicate BCD filename) and the DHCP file field (pointing the client to the nextnetwork boot program), the DHCP+TFTP negotiation completes the WDSsession.

Due to the poor error reporting in the WDS boot programs, the go-totroubleshooting tool should be a network packet analyzer likeWireshark. Packets can be dumped usingother tools like tcpdump or tshark before being loaded intoWireshark for analysis.

Ensure that the DHCP next-server parameter is specified correctlyin the iPXE commands. If it is not configured correctly, it should beevident from the network capture that either the first DHCP or TFTPrequest from wdsnbp.com is directed towards the wrong IP.

Make sure the WDS TFTP server's read filter has mapped the relevantpath names. Inspect the use of slashes in the DHCP packets to see howthey are used, and check that the ReadFilter registry setting isconfigured appropriately.

If either wdsnbp.com or pxeboot.n12 gets stuck in a requestloop, it is likely that the initial TFTP download worked, butsubsequent ones are failing. This can happen because iPXE uses forwardslashes in the TFTP file path, while the WDS boot programs are proneto using a mix of forward and backward slashes.

The upside of chainloading WDS from iPXE is that it provides a fullyworking and isolated WDS setup, while iPXE remains in control as theinitial boot program with WDS supplied as just another choice amongstthe variety of alternate boot options. WDS remains in full control ofits own configuration.

3a8082e126