UEFI/BIOS Coexistence Help
-
@mrawesome987 I see what you did, its right there… UEFI properties.
I’ll give you a peek into my campus configuration. Now I did a few things different than the wiki page but its basically the same.
Here is my Vendor Classes. You really need just arch 7 and 9 but I created all 4.
Now I have a policy for each UEFI vendor class (what you missed)
Note the value ties back to the Vendor Class name not the filter property
Lastly here is my scope definition
So things to note here is that I set the default values of 66 and 67 to be for bios. So if any of the filters match it override dhcp option 67 only. Since I only had 1 fog server in this scope and it is use for both uefi and bios there was no reason to set both 66 and 67 in each override filter. Only 67 changed between each policy filter.
-
@george1421 Ok, I fixed that. I removed my current policy, and created two new policies. I didn’t change any of the Vendor policies. I just made policies for 00007 and 00009 for now.
This is what it looks like now:
Does this look like it should work? I tested it with the Dell 3080, and it still gets the undionly.kpxe file, not the ipxe.efi.
Thanks again!
-
@mrawesome987 Sorry you still have it wrong (maybe) unless the name of your vendor class is “PXEClient (UEFI x64) 00007”
Again refer to my vendor class picture, the NAME needs to go in there not the description. So for arch 0007 in my case I would enter EFI BC (x64) into that field. Again this is assuming your vendor class properties appear similar to mine.
-
Let me try a different graphic to see if I can show how they are linked
-
@george1421 I actually had my vendor classes named similarly to the Arch number before. I just removed all of them and copied exactly what you have in the screenshots you sent. Here is what it looks like now:
It still doesn’t seem to work on the 3080:
-
@mrawesome987 I hate to keep telling you nope, but nope.
The for the dhcp vendor class, the Description needs to be the match filter. Look at mine. BUT you are super close here.
EDIT: Oh wait, I forgot we set the byte code, the description doesn’t matter.
-
@mrawesome987 Looking at my dhcp server configuration and comparing it to the wiki. I have my policies defined at / on the scope and not on the ipv4 global level. I had to it that way because we didn’t want the dev environment to be ruled by what we have in production. I know this works because we use it every day when pxe booting both bios and uefi systems.
-
@george1421 I guess I just don’t get it. I have the DHCP settings exactly like yours, down to the descriptions for the Vendor Classes. My polices are also only applied to a single scope, not the IPv4 global policies.
Here are the current screenshots:
I also tried UEFI PXE booting on a Probook 440 G5, and it did not work. It’s like the polices are just doing nothing at all, which makes no sense.
Thanks again for your help!
-
@mrawesome987 The other possibilities are we have another actor involved with pxe booting. Do you have a backup/secondary proxy server?
additional through: do you have a computer that you can load wireshark on, on the same subnet as the target computer. If so and you know how to use wireshark, setup a capture filter of
port 67 or port 68Start the capture and then pxe boot the target computer. Once you get the error on the target computer stop the capture. Look at the dhcp OFFER packet. See if there are more than one OFFER packet. You will get an OFFER from each dhcp server that hears the DISCOVER packet.
Look at the DISCOVER packet I think it dhcp option 93 or 94. The pxe booting computer will tell the dhcp server what arch it is. That should align with the filter you created.
-
@george1421 Ok, I just installed Wireshark and did as you suggested. The Arch type is: PXEClient:Arch:00007:UNDI:003016
I added a new Vendor Class and created a new policy with it, and then reran the test, but I got the same result - the DHCP server sent undionly.kpxe.
Here are some screenshots:
-
@mrawesome987 Ok just a few questions and I think we can rule out an external actor.
In the last picture the dhcp OFFER, the redacted IP address IS that of your main dhcp server?
If that is the case we now know that we don’t have some outside dhcp server messing with the pxe booting process so you know the problem IS IN your main dhcp server and not someplace else.
In your new vendor class the “:UNDI:003016” part should not be there because its too specific. It should stop in the binary code at “007”
As you see in dhcp option 93, the client IS saying that its an EFI x64 (class 00007). So that part is working right.
In wireshark in the OFFER from the dhcp server, in the ethernet header there should be something like your IP address. That is the dhcp server saying to the client this is your new ip address. That your address, the IP address that IS from the scope where you have the policies defined?
On the surface, this should be working. All of the bits are in place.
-
@george1421 Yes, the IP is of the main (only) DHCP server.
I removed the :UNDI:003016 policy and class, since, like you said, its redundant and too specific.
I just confirmed the DHCP offer’s IP, and it is indeed on the same network as the policy is applied to on my DHCP server.
I also checked my firewall to make sure it was not blocking anything. It does not appear to be blocking any traffic between the test PC and the DHCP server.
Any other ideas? I feel like I’m missing something basic, but I have gone over the settings many times and it looks right.
-
I’ve been doing a lot of reading about DHCP polices and such, and I still have no idea why this is not working. I’ve followed multiple other guides, with no change. It’s like the policy is just not enabled or something (however, it clearly is).
A lot of people have suggested using IP helpers instead of DHCP policies. Does anyone know what this is? I have tried researching it, but I can’t seem to figure out what it is.
-
@mrawesome987 This issue has to be something unique with your dhcp server, I know my dhcp server works and its windows 2016.
The dhcp-helper/dhcp-relay service won’t do it for you. What that does is monitor subnets where the dhcp server isn’t listening for dhcp DISCOVER packets from computers on these subnets and then forwards the DISCOVER packet to the main dhcp server, so the main dhcp server can respond with dhcp information. The helper service doesn’t have an impact on booting, it only relays packets.
You have one picture of a boot screen with blacked out IP addresses. You have confirmed that the Server IP address is the correct one for your dhcp server?
If you absolutely can’t get the microsoft dhcp server to give out the right boot file, then we can load dnsmasq on the fog server and let the fog server give out the boot information only. All other data comes from your main dhcp server. dnsmasq will fit in nicely with poorly behaving dhcp servers. If you have multiple subnets then you will need to add the FOG server IP’s address as the last server in the dhcp-relay/helper service. That is the only infrastructure change needed.
-
@MrAwesome987 Do you have more than one DHCP server - replicating settings? I think we had someone in the forums who couldn’t get it to work because the replication had a hick up and prevented from the settings to work.
-
@george1421 Finally figured it out. I feel like an absolute idiot, but I’m blaming Microsoft for a big portion of it.
The “Policies” under IPv4 MUST be enabled, even if there are no policies under that folder. That fixed the problem completely.
By default, this was disabled, and since I did not have policies in that particular folder, I did not see the need to enable it.
-
@mrawesome987 that is crazy obsecure, but I’m glad you found it.
This sounds like a perfect tip to add to the wiki @Wayne-Workman
