Pxe e99 ошибка при загрузке

Hi All,

We have a PXE issue at one of our sites Distribution Point servers. That particular site is attempting to PXE build a desktop. I have tried to PXE from our HQ site using the exact same Make and Model of machine and it works perfectly from out local Distribution
Point. At least one other site has no problem either with the same make and model. 

The error they are getting is

>>Checking media presence……….

>>Media present…….

>>Start PXE over IPV4.

     Station IP address is xxx.xxx.xxx.xxx

     Server IP address is xxx.xxx.xxx.xxx

     NBP filename is smsbootx64wdsmgfw.efi

     NBP filesize is 0 bytes

     PXE-E99: Unexpected network error.

We have tried to PXE boot from another network cable but get the same problem. Confirmed that the network cables are  picking up a VLan connection and work on another machine. I have checked the DHCP Policies and all is set up correctly.
I can confirm there are enough free DHCP addresses available.

Could someone please help as this is stopping us from PXE booting at a very important stage in our migration.

Regards.

When UEFI network booting on a HyperV Gen 2 VM you might get PXE-E99: Unexpected network error.

I decided to blog this post as it might help someone with the same problem.

I had this annoying error recently which was PXE E99 when PXE booting using UEFI network boot on my gen 2 HyperV vm’s. These Gen 2 vm’s were on one of my 6 virtual switches in HyperV which I have created using a simple naming scheme to easily identify the network, eg: #1_CM12, #2_CM12 and so on.

Problem

While attempting UEFI network boot I was getting PXE E-99 on my Gen 2 vm’s (the Gen 1 vm’s cannot UEFI boot as they only have a legacy bios). The error translates to “PXE-E99: Unexpected network error.” No matter what I did server side (I tried installing new distribution points on Server 2012 R2, new X64 boot wims, etc, nothing helped,. even DHCP server options) all to no avail.

Network cable unplugged in Windows ?

Finally I got another problem (unrelated or so I thought) where my Gen 2 network adapters failed to get any ip address in Windows, and the cause according to Windows was that the network cable was unplugged, that was odd because they were definetly connected to my #1_CM12 HyperV Private Virtual Switch.

No amount of fiddling with the Gen 2 VM’s fixed that problem, I even deleted the nic on one of the Gen 2 VM’s and added a new one, that didn’t help either.

Finally I tried changing the HyperV Switch to the next in line #2_CM12, and the Gen 2 vm’s got connected immediately. The Network cable unplugged message went away and they got an ip from my other switch.

I set them back to #1_CM12 and again, network cable unplugged even though all my Gen 1 vm’s were working fine on the same switch, so in desperation I deleted that switch and recreated it, added my vm’s back to the ‘new’ #1_CM12 and lo and behold the ‘network cable unplugged’ issue was fixed.

Anyhow after fixing that issue I got back to what I was originally testing (UEFI network boot) and I PXE booted my Gen 2 v and voila, the PXE E99 error was gone and all worked fine after that point.

Summary

If you are getting strange things happening (network wise) on your Gen 2 vm’s and if nothing you do helps the situation then try what I did, delete the HyperV private virtual switch and recreate it, it worked for me !

Источник

PXE UEFI mode fails when DHCP server is not also TFTP server — IBM BladeCenter and System x

Troubleshooting

Problem

When the Unified Extensible Firmware Interface (UEFI) is set to Preboot eXecution Environment (PXE) mode, the boot fails when the Dynamic Host Configuration Protocol (DHCP) server is not also the Trivial File Transfer Protocol (TFTP) server. The following error message is displayed, and the system drops through to the next item in the boot sequence: PXE-E99: Unexpected network error.

Resolving The Problem

Source

RETAIN tip: H196402

Symptom

When the Unified Extensible Firmware Interface (UEFI) is set to Preboot eXecution Environment (PXE) mode, the boot fails when the Dynamic Host Configuration Protocol (DHCP) server is not also the Trivial File Transfer Protocol (TFTP) server. The following error message is displayed, and the system drops through to the next item in the boot sequence:

PXE-E99: Unexpected network error.

Affected configurations

The system may be any of the following IBM servers:

• BladeCenter HX5, type 1909, any model
• BladeCenter HX5, type 7872, any model
• BladeCenter HX5, type 7873, any model
• System x3690 X5, type 7147, any model
• System x3690 X5, type 7148, any model
• System x3690 X5, type 7149, any model
• System x3690 X5, type 7192, any model
• System x3850 X5, type 7143, any model
• System x3850 X5, type 7145, any model
• System x3850 X5, type 7146, any model
• System x3850 X5, type 7191, any model
• iDataPlex dx360 M2 Server, type 6380, any model
• iDataPlex dx360 M2 Server, type 7321, any model
• iDataPlex dx360 M2 Server, type 7323, any model

This tip is not software specific.

This tip is not option specific.The following system BIOS or uEFI level(s) are affected:

Solution

This behavior is corrected in the following UEFI versions:

BladeCenter HX5:

• UEFI version HIE170A and higher.

DataPlex dx360 M2:

System x3690 X5:

• UEFI version 1.40 build ID mle142a and higher.

System x3850 X5:

• UEFI version G0E170A and higher.

The file is or will be available by selecting the appropriate Product Group, Product name, Product machine type, and operating system on IBM Support’s Fix Central web page, at the following URL:

Workaround

There are two (2) workarounds for this issue.

Select PXE legacy mode instead of PXE UEFI mode.

Configure the DHCP server to be the same server as the TFTP server, and then PXE UEFI mode boots successfully.

Additional information

If the DHCP server specifies a different server as the TFTP server, then the UEFI PXE firmware should send the TFTP request for the bootfile to that server. However, in the fail case, the request is instead sent to the DHCP server. Because the fail symptom is caused by PXE UEFI firmware, PXE legacy mode should still work normally.

Источник

This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

Answered by:

Question

We have a PXE issue at one of our sites Distribution Point servers. That particular site is attempting to PXE build a desktop. I have tried to PXE from our HQ site using the exact same Make and Model of machine and it works perfectly from out local Distribution Point. At least one other site has no problem either with the same make and model.

The error they are getting is

>>Checking media presence. …….

>>Start PXE over IPV4.

Station IP address is xxx.xxx.xxx.xxx

Server IP address is xxx.xxx.xxx.xxx

NBP filename is smsbootx64wdsmgfw.efi

NBP filesize is 0 bytes

PXE-E99: Unexpected network error.

We have tried to PXE boot from another network cable but get the same problem. Confirmed that the network cables are picking up a VLan connection and work on another machine. I have checked the DHCP Policies and all is set up correctly. I can confirm there are enough free DHCP addresses available.

Could someone please help as this is stopping us from PXE booting at a very important stage in our migration.

Answers

Jason | https://home.configmgrftw.com | @jasonsandys

Something at the network layer is interfering with the PXE boot — this is completely outside the scope of visibility or control of ConfigMgr. You need to get your network folks involved to help determine why the network is not properly transferring the NBP file to the target systems.

Checking smspxe.log on the DP may be helpful, but probably not as once again, the issue is at the network layer.

Jason | https://home.configmgrftw.com | @jasonsandys

Thanks for the information. Are you pretty certain this is nothing to do with SCCM or ConfigMgr? I will try the smspxe.log file for further information.

In general, yes. As noted SMSPXE.log may reveal something like file corruption on the server side leading to the issue, but that’s an outside possibility IMO (it doesn’t care about MO though so that’s why we check log files 😀).

Jason | https://home.configmgrftw.com | @jasonsandys

Hi Thanks Jason,

We have checked the smspxe.log and there are no updates since 9-01-2020. I probably don’t think it’s even getting that far. A check of the local Event Viewer Application logs do reveal some interesting errors. For example we are seeing WDSServer errors. This starts on the 9-01-2020 and carries on through to today. Another interesting fact is that we are unable to start the WDS Server service. When I try to start the service I get.

Windows could not start the windows deployment services server on Local computer. For more information, review the system event log. If this is a non Microsoft service, contact the service vendor, and refer to service-specific error code 2.

We have been thinking of uninstalling the WDS role and then reinstalling, but we don’t know what the consequences might be. Do you think this might be an option?

Appreciate any comments.

Are you actually running ConfigMgr 2012 (which is what this forum is for) or are you running ConfigMgr CB?

Jason | https://home.configmgrftw.com | @jasonsandys

1.May we know if TFTP is running? If not, please start TFTP and then try again to start the WDS service.

3.May we know if the DHCP server and the WDS server are installed on the same computer? If yes, please refer to: The WDS server may not start, and an error is logged in the System log when you start the WDS server

Thanks for your time.

Best regards,
Simon

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

• Edited by Simon Ren Microsoft contingent staff Thursday, January 23, 2020 2:55 AM

When you say TFTP I am unsure where I check if this is running?

Thanks for the thread I will check and get back to you.

No DHCP and WDS are on different servers.

We are no better off and still cannot PXE boot on one of our DP’s.

I have uninstalled / Reinstalled the WDS role as suggested. The files in the Remoteinstall folder is the same as other DP sites around our estate. The local IT engineer still gets the issue.

What we are seeing now — The IT engineer gets to the splash screen where you have to choose the network card option. He presses the IPV4 option but it immediately returns to the same screen.

Any ideas — is there any further troubleshooting I can do?

Any help would be very greatfull as we cannot build any machines in this location until this is fixed.

the error we are getting now when we attempt to PXE boot is PXE-E23: Client received TFTP error from server. Further research reveals that PXE-E23: BIS initialization failed. BIS could not be initialized. No more data is available.

Any ideas what this could mean.

What about my question above about the version you are running?

Also, smspxe.log is always created so you are most likely looking at an old version of that log file as it did move at some point between ConfigMgr versions.

Finally, same answer here ultimately about this being a network-related issue.

Have you tried different system models though? It’s not unheard of for bad firmware on systems to cause PXE boot issues.

Jason | https://home.configmgrftw.com | @jasonsandys

Thanks for your hard work and detailed information.

May we know what version of Configuration Manager you are running as Jason mentioned, Configuration Manager (Current Branch) or Configuration Manager 2012?

As Jason mentioned this is a network-related issue.A good way to troubleshoot these errors is to monitor the network by using Netmon or Wireshark.

Please also make sure that the TFTP port is open between the client computer and the DP. And then reduce the block size on the PXE-enabled DP to have a try.

For more information, please refer to the official article: PXE Troubleshooting TFTP Transfer

Thanks for your time.

Best regards,
Simon

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

We are on configuration manager 2012 and have version 1910 with site version: 5.0.8913.1000. I have made a search for SMSPXE.log on the SCCM server on site and have picked up the log in two locations, however, neither seem to be up-to-date. Last entries posted are for 09/01/2020. No entries past this date.

Just for information I am assuming I would install Netmon or Wireshark on the offending SCCM server? You mention the TFTP port, can you let me know where I would look for the TFTP server as I don’t recollect even setting this up — unless it’s embedded into some SCCM software application?

We have checked the port on the switch this a.m. and we cannot see any problems on the port, however, we were also unable to ping the client machine on the port. I guess this is because it would not be pingable until it past the PXE option properly?

Thanks very much for your keen interest. We are under a bit of pressure to get this resolved as they are not able to PXE boot from this location any more. Any help in troubleshooting this would be very helpful.

Источник

[{«Type»:»HW»,»Business Unit»:{«code»:»BU016″,»label»:»Multiple Vendor Support»},»Product»:{«code»:»QU03TEU»,»label»:»System x->System x iDataPlex dx360 M2 server->7323″},»Platform»:[{«code»:»PF025″,»label»:»Platform Independent»}],»Line of Business»:{«code»:»»,»label»:»»}},{«Type»:»HW»,»Business Unit»:{«code»:»BU016″,»label»:»Multiple Vendor Support»},»Product»:{«code»:»QU03VIF»,»label»:»System x->System x iDataPlex dx360 M2 server->7321″},»Platform»:[{«code»:»PF025″,»label»:»Platform Independent»}],»Line of Business»:{«code»:»»,»label»:»»}},{«Type»:»HW»,»Business Unit»:{«code»:»BU054″,»label»:»Systems w/TPS»},»Product»:{«code»:»QU03WSY»,»label»:»System x->System x iDataPlex dx360 M2 server->6380″},»Platform»:[{«code»:»PF025″,»label»:»Platform Independent»}],»Line of Business»:{«code»:»»,»label»:»»}},{«Type»:»HW»,»Business Unit»:{«code»:»BU016″,»label»:»Multiple Vendor Support»},»Product»:{«code»:»QU04SRF»,»label»:»System x->System x3850 X5->7146″},»Platform»:[{«code»:»PF025″,»label»:»Platform Independent»}],»Line of Business»:{«code»:»»,»label»:»»}},{«Type»:»HW»,»Business Unit»:{«code»:»BU016″,»label»:»Multiple Vendor Support»},»Product»:{«code»:»QU04SRH»,»label»:»BladeCenter->BladeCenter HX5->7872″},»Platform»:[{«code»:»PF025″,»label»:»Platform Independent»}],»Line of Business»:{«code»:»»,»label»:»»}},{«Type»:»HW»,»Business Unit»:{«code»:»BU016″,»label»:»Multiple Vendor Support»},»Product»:{«code»:»QU04SRO»,»label»:»System x->System x3850 X5->7145″},»Platform»:[{«code»:»PF025″,»label»:»Platform Independent»}],»Line of Business»:{«code»:»»,»label»:»»}},{«Type»:»HW»,»Business Unit»:{«code»:»BU016″,»label»:»Multiple Vendor Support»},»Product»:{«code»:»QU04UNG»,»label»:»BladeCenter->BladeCenter HX5->1909″},»Platform»:[{«code»:»PF025″,»label»:»Platform Independent»}],»Line of Business»:{«code»:»»,»label»:»»}},{«Type»:»HW»,»Business Unit»:{«code»:»BU016″,»label»:»Multiple Vendor Support»},»Product»:{«code»:»QU04WDX»,»label»:»System x->System x3690 X5->7149″},»Platform»:[{«code»:»PF025″,»label»:»Platform Independent»}],»Line of Business»:{«code»:»»,»label»:»»}},{«Type»:»HW»,»Business Unit»:{«code»:»BU016″,»label»:»Multiple Vendor Support»},»Product»:{«code»:»QU04WDY»,»label»:»System x->System x3690 X5->7148″},»Platform»:[{«code»:»PF025″,»label»:»Platform Independent»}],»Line of Business»:{«code»:»»,»label»:»»}},{«Type»:»HW»,»Business Unit»:{«code»:»BU016″,»label»:»Multiple Vendor Support»},»Product»:{«code»:»QU90ABO»,»label»:»System x->System x3850 X5->7191″},»Platform»:[{«code»:»PF025″,»label»:»Platform Independent»}],»Line of Business»:{«code»:»»,»label»:»»}},{«Type»:»HW»,»Business Unit»:{«code»:»BU016″,»label»:»Multiple Vendor Support»},»Product»:{«code»:»QU90ABQ»,»label»:»System x->System x3690 X5->7147″},»Platform»:[{«code»:»PF025″,»label»:»Platform Independent»}],»Line of Business»:{«code»:»»,»label»:»»}},{«Type»:»HW»,»Business Unit»:{«code»:»BU016″,»label»:»Multiple Vendor Support»},»Product»:{«code»:»QU90ABX»,»label»:»System x->System x3850 X5->7143″},»Platform»:[{«code»:»PF025″,»label»:»Platform Independent»}],»Line of Business»:{«code»:»»,»label»:»»}},{«Type»:»HW»,»Business Unit»:{«code»:»BU016″,»label»:»Multiple Vendor Support»},»Product»:{«code»:»QU90ACM»,»label»:»System x->System x3690 X5->7192″},»Platform»:[{«code»:»PF025″,»label»:»Platform Independent»}],»Line of Business»:{«code»:»»,»label»:»»}},{«Type»:»HW»,»Business Unit»:{«code»:»BU016″,»label»:»Multiple Vendor Support»},»Product»:{«code»:»QU90ACW»,»label»:»BladeCenter->BladeCenter HX5->7873″},»Platform»:[{«code»:»PF025″,»label»:»Platform Independent»}],»Line of Business»:{«code»:»»,»label»:»»}}]

This entry was posted in Uncategorized. Bookmark the permalink.

This topic has been deleted. Only users with topic management privileges can see it.

• Good morning,

  After a lot of trial and tribulation myself and a network engineer were able to get our Fog (Ubuntu 18.04) server to deploy to the location we need it to. Bad news, it is only deploying to legacy machines. The laptops we need to image are Panasonic CF-54 Toughbooks, and they are all UEFI. Secure boot is disabled. We finally managed to snag the pop up message and it read as follows.

  Station IP address is 172.25.25.60
  Server IP Address is 172.25.25.50
  NBP filename is ipxe.efi
  NBP filesize is 0 bytes
  PXE-E99: Unexpected Network Error.

  If anybody has a clue, please let me know because I am lost. Unfortunately, I cannot provide screenshots of the activity or provide logs.

• @george1421 @Sebastian-Roth Just wanted to give you an update. From what I can tell, the section of dhcpd.conf where you declare options, was missing a } so the file wasn’t reading the options I guess? I compared the file to an old server and that was the only difference I could find. I probably deleted it while editing the file at some point. Works like a charm now.

• @alexnoel2 said in PXE-E99: Unexpected Network Error:

  NBP filesize is 0 bytes

  Not sure if I get this right but this might point to the file ipxe.efi not being available on the TFTP server? What do you get when running ls -al /tftpboot/ipxe.efi?

  If you are missing that file you can quickly download it here: https://github.com/FOGProject/fogproject/tree/master/packages/tftp

• @alexnoel2 I don’t think we are too far apart. So let me explain.

  If you are using the same network connection, same computer and the only thing you are changing is putting the computer into one more or another, then we’ve ruled out a bunch of possibilities. Its either the computer, the dhcp server configuration, or ipxe.efi is missing on the fog server (for some reason).

  I understand these computers in question only have uefi mode. So do you have a different model that supports both modes for testing? We need to test everything the same except the computer mode bios/uefi because you said bios mode works perfectly.

• @george1421 1. Yes. 2. No.
  I only have an issue in UEFI. The laptops I need to image, do not have a legacy option. Why is the laptop, not able to pull from ipxe.efi? I am sorry, I just feel like we are on 2 different pages right now.

• @alexnoel2 Ok so let me ask again because I’m not absolute about your answer.

  1. You can take the same computer and in bios mode does it boot into the iPXE menu?

  2. If you switch that same computer into uefi mode does it boot into the iPXE menu?

  We are trying to find the exact point of failure. If the answer is yes in bios mode and no in uefi mode then lets focus on uefi boot file.

  For the uefi boot file, if you have a computer on the same network install the tftp client in windows, you will need to temporary drop the windows firewall on the test computer, but then use tftp to get ipxe.efi from the fog server. We are only concerned that it download the file. We don’t need it only to download the file.

  If the tftp works then we need to find out exactly what the network admin did to make this work.

• @alexnoel2 said in PXE-E99: Unexpected Network Error:

  We were able to deploy to laptops with legacy bios from the same location

  So if you take (for a test) switch one of these laptops from bios to uefi mode (on the same network jack) can you get into the iPXE menu? We don’t need to image them only get into the iPXE menu.

• @george1421 Just to clarify, the server is specifically not deploying to these laptops. We were able to deploy to laptops with legacy bios from the same location.

• @alexnoel2 Well it could be a few things and nothing its hard to explain because there is a lot of exceptions. You want to look in the OFFER in both the ethernet header there is a next-server and boot-file that should point to the ip address of fog server and ipxe.efi file. Also dhcp option 66 and 67 should be the same.

  Do you see the tftp query from the target computer to the FOG server asking for the ipxe.efi file?

  You said something earlier that the network engineer did something to make this work. What did the engineer touch? Because this should have just worked out of the box.

  Just to be clear if you put a bios computer on this network it will pxe boot into the iPXE menu just fine? The only thing that is changing is bios to uefi? On the bios computer does it also support uefi mode? So on the same computer if you change it from bios to uefi mode does it pxe boot into the iPXE menu?

  Understand I’m coming cold into the problem not knowing your environment or what might have been changed. So I have to give a lot of guesses until we narrow in on where the problem is.

• @george1421 The Fog server does have 2 interfaces, they are just using the same physical nic. So I looked through the pcap in Wireshark and came across the following.

  Option (129-135)
  Parameter Request List Item: PXE — undefined (Vendor Specific)
  Option (60)
  Vendor class identifier: PXEClient:Arch:00007:UNDI:003016

  Does that ring any bells? Other than that I didnt find anything glaring. If you know of something specific to look for it would be helpful.

• @alexnoel2 And when you installed FOG you select the right interface to bind the dhcp server too? I assume from your post that FOG was working fine on bios but uefi not so good?

  If you are using the FOG server for dhcp services, then it should automatically support both bios and uefi computers. There should be nothing you need to do to make it pxe boot into the iPXE menu.

  EDIT: sorry i missed you have it virtualized and the fog server might not have 2 interfaces but the host server does.

• @george1421 The FOG Server is the DHCP server, it is an Ubuntu 18.04.5 VM hosted on ESXi 6.5, which is hosted on a Dell R340. 2 Interfaces across one physical NIC, one to the corporate network, and the other for PXE boot.

• @alexnoel2 Since the FOG server and target computer are on the same subnet I would use tcpdump on the fog server to see what communication is going on between the dhcp, client, and fog server. https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

  You can review the captured pcap with wireshark. Since you are not able to provide the file you will need to look through it to see what is failing. You should see the DISCOVER, OFFER, REQUEST, ACK process of dhcp and right after that you should see the target computer connect to the FOG server first to confirm the file size and second to download the file. I suspect this is where its failing.

  Just out of curiosity, what device is your dhcp server (mfg and model)?