PXE Response
-
Tuesday, April 24, 2012 5:39 AM
When OSD deployment is set to client, PXE server respond to client immediately after client request.
PXE is not responding with abortpxe.com, when there is no OSD deployment set to client. Client wait long time for network boot....Is it a bug or is it something that is not configured correctly (WDS response time - 1 second, PXE response time - 0 seconds).
I also noticed that one more person has the same problem:
http://www.windows-noob.com/forums/index.php?/topic/5405-pxe-problem-missing-things-in-the-main-console-maybe-a-bug/Thanks for help in advance!
- Moved by Jim Dempsey [MSFT]Microsoft Employee, Moderator Thursday, April 26, 2012 7:16 PM moving to OSD-specific forum (From:Configuration Manager 2012 - General)
All Replies
-
Tuesday, April 24, 2012 7:33 AM
It depends ... WDS/PXE will not respond at all if the MAC or SMBIOSGUID are totally unknown to ConfigMgr (and unknown computer support is not enabled).
It will respond with abortpxe IF the MAC/SMBIOSGUID is known but there's no deployment available for it.Torsten Meringer | http://www.mssccmfaq.de
-
Tuesday, April 24, 2012 8:14 AM
Computer is known (client identity) but there is no response from PXE server.
When OSD deployment is set to client PXE respond immediately!!!SMSPXE log:
Set enterpirse certificate in transport SMSPXE 24.4.2012 10:01:13 1904 (0x0770)
Set media certificate in transport SMSPXE 24.4.2012 10:01:13 1904 (0x0770)
Set authenticator in transport SMSPXE 24.4.2012 10:01:13 1904 (0x0770)
In SSL, but with no client cert SMSPXE 24.4.2012 10:01:13 1904 (0x0770)
Set authenticator in transport SMSPXE 24.4.2012 10:01:13 1904 (0x0770)
In SSL, but with no client cert SMSPXE 24.4.2012 10:01:13 1904 (0x0770)
PXE::CBootImageManager::FindMatchingArchitectureBootImage SMSPXE 24.4.2012 10:01:28 1904 (0x0770)
Set enterpirse certificate in transport SMSPXE 24.4.2012 10:01:28 1904 (0x0770)
Set media certificate in transport SMSPXE 24.4.2012 10:01:28 1904 (0x0770)
Set authenticator in transport SMSPXE 24.4.2012 10:01:28 1904 (0x0770)
In SSL, but with no client cert SMSPXE 24.4.2012 10:01:28 1904 (0x0770)
Set authenticator in transport SMSPXE 24.4.2012 10:01:29 1904 (0x0770)
In SSL, but with no client cert SMSPXE 24.4.2012 10:01:29 1904 (0x0770)
Client boot action reply: <ClientIDReply><Identification Unknown="0" ItemKey="16777222" ServerName="" ServerRemoteName=""><Machine><ClientID/><NetbiosName/></Machine></Identification><PXEBootAction LastPXEAdvertisementID="" LastPXEAdvertisementTime="" OfferID="" OfferIDTime="" PkgID="" PackageVersion="" PackagePath="" BootImageID="" Mandatory=""/></ClientIDReply>
SMSPXE 24.4.2012 10:01:29 1904 (0x0770)
Client Identity: b21564b8-05e9-4d2a-85a6-35a200247fa5 SMSPXE 24.4.2012 10:01:29 1904 (0x0770)
Set enterpirse certificate in transport SMSPXE 24.4.2012 10:01:29 1904 (0x0770)
Set media certificate in transport SMSPXE 24.4.2012 10:01:29 1904 (0x0770)
Set authenticator in transport SMSPXE 24.4.2012 10:01:29 1904 (0x0770)
In SSL, but with no client cert SMSPXE 24.4.2012 10:01:29 1904 (0x0770)
Set authenticator in transport SMSPXE 24.4.2012 10:01:29 1904 (0x0770)
In SSL, but with no client cert SMSPXE 24.4.2012 10:01:29 1904 (0x0770)
PXE::CNotifyTimer::TimerSignalFunc SMSPXE 24.4.2012 10:03:12 3512 (0x0DB8)
PXE::CNotifyTimer::ProcessTimer SMSPXE 24.4.2012 10:03:12 3512 (0x0DB8)
PXE::CBootImageManager::PerformMaintenenceTasks SMSPXE 24.4.2012 10:03:12 3512 (0x0DB8)
PXE::CBootImageManager::PurgeOldImages SMSPXE 24.4.2012 10:03:12 3512 (0x0DB8)
PXE::CNotifyTimer::Init SMSPXE 24.4.2012 10:03:12 3512 (0x0DB8)
PXE::CNotifyTimer::CancelTimer SMSPXE 24.4.2012 10:03:12 3512 (0x0DB8)
PXE::CNotifyTimer::RegisterTimeout SMSPXE 24.4.2012 10:03:12 3512 (0x0DB8)
PXE::CNotifyTimer::TimerSignalFunc SMSPXE 24.4.2012 10:13:16 2660 (0x0A64)
PXE::CNotifyTimer::ProcessTimer SMSPXE 24.4.2012 10:13:16 2660 (0x0A64)
PXE::CBootImageManager::PerformMaintenenceTasks SMSPXE 24.4.2012 10:13:16 2660 (0x0A64)
PXE::CBootImageManager::PurgeOldImages SMSPXE 24.4.2012 10:13:16 2660 (0x0A64)
PXE::CNotifyTimer::Init SMSPXE 24.4.2012 10:13:16 2660 (0x0A64)
PXE::CNotifyTimer::CancelTimer SMSPXE 24.4.2012 10:13:16 2660 (0x0A64)
PXE::CNotifyTimer::RegisterTimeout SMSPXE 24.4.2012 10:13:16 2660 (0x0A64) -
Tuesday, April 24, 2012 8:28 AMThat should result in abortpxe delivered to the client, see Scenario 2: http://www.mssccmfaq.de/2012/02/04/cm12-pxe-boot-szenarien/ (logfiles and screenshots are in English, so you should get the point).
Torsten Meringer | http://www.mssccmfaq.de
-
Tuesday, April 24, 2012 8:59 AMYes, client should get abortxpe, but network boot finished with PXE-E53: No boot filename received.
I don't know why.... -
Tuesday, April 24, 2012 12:22 PM
I would like to add that we have non-microsoft DHCP server.
Thanks for help!
-
Tuesday, April 24, 2012 1:05 PM
The DHCP server has no impact on PXE booting unless you are using DHCP scope options.
If so, how do you have them configured?
Is there a reason you are not using iphelpers? They are much simpler to configure and generally prefered.
Jason | http://blog.configmgrftw.com | Twitter @JasonSandys
-
Thursday, April 26, 2012 9:12 PM
I enabled debug logging on server.
1.
When OSD task is deployed to client and client boot from network, PXE receive BootRequest(1) from client:
Operation : BootRequest (1) SMSPXE 26.4.2012 21:52:20 3124 (0x0C34)
Transaction ID : 36B64D5E SMSPXE 26.4.2012 21:52:20 3124 (0x0C34)
Client IP Address : 000.000.000.000 SMSPXE 26.4.2012 21:52:20 3124 (0x0C34)
Server IP Address : 000.000.000.000 SMSPXE 26.4.2012 21:52:20 3124 (0x0C34)
Relay Agent IP Address : 000.000.000.000 SMSPXE 26.4.2012 21:52:20 3124 (0x0C34)
Hardware Address : XX:XX:XX:XX:XX:XX: SMSPXE 26.4.2012 21:52:20 3124 (0x0C34)
And after identification of client:
Client Identity: b21564b8-05e9-4d2a-85a6-35a200247fa5 SMSPXE 26.4.2012 21:52:20 4720 (0x1270)
PXE respond with BootReply(2):
Operation : BootReply (2) SMSPXE 26.4.2012 21:52:20 4720 (0x1270)
Transaction ID : 36B64D5E SMSPXE 26.4.2012 21:52:20 4720 (0x1270)
Client IP Address : 000.000.000.000 SMSPXE 26.4.2012 21:52:20 4720 (0x1270)
Server IP Address : YYY.YYY.YYY.YYY SMSPXE 26.4.2012 21:52:20 4720 (0x1270)
Relay Agent IP Address : 000.000.000.000 SMSPXE 26.4.2012 21:52:20 4720 (0x1270)
Hardware Address : XX:XX:XX:XX:XX:XX: SMSPXE 26.4.2012 21:52:20 4720 (0x1270)
And after request of client with client IP server sends BootReply(2) with:
BootFileName "smsboot\x86\wdsnbp.com" SMSPXE 26.4.2012 21:52:24 4720 (0x1270)2.
When OSD is not deployed to the same client PXE (normal boot) and client boot from network, PXE receive BootRequest(1) from client:
Operation : BootRequest (1) SMSPXE 26.4.2012 22:20:54 3100 (0x0C1C)
Transaction ID : 36B64D61 SMSPXE 26.4.2012 22:20:54 3100 (0x0C1C)
Client IP Address : 000.000.000.000 SMSPXE 26.4.2012 22:20:54 3100 (0x0C1C)
Server IP Address : 000.000.000.000 SMSPXE 26.4.2012 22:20:54 3100 (0x0C1C)
Relay Agent IP Address : 000.000.000.000 SMSPXE 26.4.2012 22:20:54 3100 (0x0C1C)
Hardware Address : XX:XX:XX:XX:XX:XX: SMSPXE 26.4.2012 22:20:54 3100 (0x0C1C)
And after identification of the same client:
Client Identity: b21564b8-05e9-4d2a-85a6-35a200247fa5 SMSPXE 26.4.2012 22:20:54 4720 (0x1270)
THERE IS NO BOOTREPLY(2) FROM PXE SERVER.
WHY? What is wrong?Thank you very much for reply in advance!!!!
- Edited by si124 Thursday, April 26, 2012 9:13 PM
-
Tuesday, May 01, 2012 5:41 PM
That client identity in the log is not for the client. That is the identity of the PXE service point - it acts as a client when it talks to the MP.
You can see from the previous line above that the ClientID for the booting client is blank.
-
Saturday, May 05, 2012 11:13 AM
This is almost offical answer:
We found following workaround: When DHCP Option 66 & 67 are configured, everything works (in contradiction to SCCM 2007) !! In any case, it should not work this way...Now PXE works!!!
- Marked As Answer by si124 Saturday, May 05, 2012 11:13 AM
-
Saturday, May 05, 2012 12:33 PMYou can either use IPhelpers or DHCP options (not supported) and both ways will work - for CM07 and CM12.
Torsten Meringer | http://www.mssccmfaq.de
-
Saturday, May 05, 2012 2:48 PM
Not sure what "in contradiction to [ConfigMgr] 2007 means? The actual PXE process has absolutely nothing to do with ConfigMgr and is entirely controlled by the NIC. The actual PXE server behaves exactly the same no matter how the NIC contacted it.This is almost offical answer:
We found following workaround: When DHCP Option 66 & 67 are configured, everything works (in contradiction to SCCM 2007) !! In any case, it should not work this way...Now PXE works!!!
Jason | http://blog.configmgrftw.com | Twitter @JasonSandys
-
Monday, May 07, 2012 7:04 PM
@Jason Sandys
I have to disagree with your opinion....
Configuration manager 2007 responds to client, while 2012 does not WHEN OSD IS NOT DEPLOYED!!!
-
Monday, May 07, 2012 8:07 PMHuh? Not following...
Jason | http://blog.configmgrftw.com | Twitter @JasonSandys
-
Thursday, May 10, 2012 4:20 PM
I am having the same issue as:
@Jason Sandys
I have to disagree with your opinion....
Configuration manager 2007 responds to client, while 2012 does not WHEN OSD IS NOT DEPLOYED!!!
-------------
When you deploy an image to a machine it boots fine, the PXE service point responds and it runs the install no problem. However, the issue is when you don't have anything advertised to the client they just sit there waiting to timeout. Abortpxe is never run. This didn't happen under Configuration Manager 2007 but after migrating to 2012 we can't get it to send the Abortpxe.
I have recreated images, recreated pretty much everything in the system.
-
Thursday, May 10, 2012 7:39 PM
That's not true. I've listed some PXE boot scenarios on my blog: http://www.mssccmfaq.de/2012/02/04/cm12-pxe-boot-szenarien/. Szenario 2 deals with the situation you are describing (MAC and/or SMBIOSGUID are existing in the database and there's no OSD deployment advertised to that device => this results in abortpxe).However, the issue is when you don't have anything advertised to the client they just sit there waiting to timeout. Abortpxe is never run. This didn't happen under Configuration Manager 2007 but after migrating to 2012 we can't get it to send the Abortpxe.
You should examine smspxe.log to get an idea what's happening.Torsten Meringer | http://www.mssccmfaq.de
-
Saturday, May 12, 2012 6:39 PM
I also noticed that ConfigMgr 2012 does not send abortpxe to known clients without advertised osd, if dhcp options 66 and 67 are not set. I did not test IP helper (client and servers on different networks).
My test setup: client, dhcp server (options 66 & 67 not set) and configmgr are on the same network. OSD works, but abortpxe does not work (no boot filename received after timeout).
My second test setup: client, dhcp server (66=10.0.0.2, 67=smsboot\x86\wdsnbp.com) and configmgr are on the same network. OSD and abortpxe work.
- Edited by TimoH Saturday, May 12, 2012 6:44 PM Fixed dhcp options
-
Thursday, June 14, 2012 8:26 PM
I opened a case with PSS on this a couple of weeks ago and after two escalations was just told today that it is a known issue that is being investigated, not a design change. The additional detail that the engineer provided (which doesn't apply to my scenario, but it is worth sharing with others) is that if WDS and DHCP are on the same SCCM server it will send abortpxe like 2007 whether or not a task sequence is assigned even if you aren't using DHCP options 66/67.
There is of course no ETA on a fix (or even a guarantee that it will be fixed). Still, nice to know that they are looking into it.
-
Tuesday, July 03, 2012 1:42 PMI received confirmation yesterday that this is a bug and will be fixed in SP1.
-
Tuesday, January 15, 2013 2:00 PMExactly the same issue here!
.png)
