Jump to content


  • 0
DPE

Strange PXE boot behaviour (SCCM 2007 / WDS)

Question

Hi guys,

 

Having a "funny" PXE boot experiece here at my company.

Last week, i realized that our branch office local DHCP server had not had its PXE options 66 and 67 set. Lucky enough they only have one server servicing PXE requests on the network, but just for good practice i added the both options so that all PXE requests were pointed to our SCCM/WDS server.

 

Now, heres the funny part.

 

Before i added the two DHCP options, clients sending a PXE request would have a normal PXE boot process.

1: Get an IP from DPCH and downloading WDSNBP.

2: Detecting architecture

3: Contacting WDS server, download smsboot\architecture\pxeboot.com

 

All good and normal.

 

Now after adding the two DHCP options, things have changed a bit. All clients (all 64 bit capable) now doing a PXE boot, now first detects as X86 architecture, trys to do a TFTP download of smsboot\x86\wdsnbp.com - then goes on to identify itself as a X64 client, trys a TFTP download of smsboot\x64\pxeboot.com which succeeds and then carrys on to the F12 which launches the boot image.

 

Any idea what could be the cause of this?

 

Attached is a picture of the PXE boot sequence after adding the DHCP options.

 

Thanks!

post-19515-0-43019400-1363246846_thumb.jpg

Share this post


Link to post
Share on other sites

5 answers to this question

Recommended Posts

  • 0

Ok, i've discovered a few differences between this branch office WDS server and the one i'm hosting at our main office.

 

First of all, the branch office WDS is an W2K8 R2 Std running WDS 6.1. Our main office is running W2K8 Std and WDS 6.0.

 

More interresting is the config output from WDSUTIL.

 

It seems that my branch office server has a boot file for X64 installed.

 

--------------------------------------------------------------------------------------
SETUP INFORMATION FOR SERVER XXXX
[----------------------------------------------------
Server State:
OS version: 6.1
WDS operational mode: Native
Installation State:
RemoteInstall location: D:\remoteinstall
RemoteInstall share up-to-date: Yes
Boot files installed:
x86 - Yes
x64 - Yes
ia64 - No
------------------------------------------------------------------------------
As opposed to my main office server:
------------------------------------------------------------------------------
SETUP INFORMATION FOR SERVER YYYY
[-----------------------------------------------------------------------------]
Server State:
OS version: 6.0
WDS operational mode: Native
Installation State:
RemoteInstall location: D:\RemoteInstall
RemoteInstall share up-to-date: Yes
Boot files installed:
x86 - Yes
x64 - No
ia64 - No
-----------------------------------------------------------------------------
I'm deploying a single x64 OS image which can be done with just the X86 boot image.
So, would it be an idea to try to remove the X64 boot file from the branch office server, thereby forcing it just to use the x86? And, how do i remove this boot file?
Thanks!

Share this post


Link to post
Share on other sites

  • 0

make sure to distribute both architecture boot images to your distribution points, have you tried that ?

 

Thats another thing i don't understand. Both architecture boot images are successfully distributed to all PXE enabled distribution points, and yet they appear with different boot file configurations.

I will try restarting the server and see if that does a difference.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...


×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.