Jump to content


Rocket Man

Strange PXE behaviour after upgrade to SP1

Recommended Posts

I upgraded to SP1 a while back.

Basically everything was fine in relation to PXE booting pre the upgrade. Now I have an issue where by I set the Task sequence deployment as required to only media and PXE and to always re-run. This is the functionality SP1 offers in deploying task sequences and the main reason why I upgraded also so that I could leverage this capability.

 

What is happenening is that on the majority of the models present at this site is that they still look for an f12 to PXE to pull down the winPE image. They may even look twice for an f12. On the other hand the Optiplex 390 systems are fine, once the TS is deployed out to the collection with the same criteria set I just have to boot to PXE and the winPE image downloads without any user intervention, this is the what is expected with the criteria specified. A VM has the same outcome.

 

Anyone came across this behaviour before? I have removed boot files and added new boot files browsing to the ADK folder and selecting the new winpe images. Added Dell winPE drivers and distributed them back out.

The thing is once the f12 is pressed once or twice as needed on the affected models ...it loads and continues the task sequence as normal, but I know this is not normal to have to this with the criteria specified in the Task sequence deployment.

 

The model affected are Dell optiplex 380, Precision 390, M65 and T3400 models. The Optiplex 390 model is fine.

I also upgraded the BIOS version on the 380 but still the same outcome.

 

Thanks

Share this post


Link to post
Share on other sites

Hi mate,

 

I've never actually set a required deployment of a TS out over PXE before, only Available deployments - but i would have expected it still to ask to press F12 after booting from NIC? I've set required deployments of an OS to actual clients before and they've booted into WinPE ok, but i guess that's a whole different thing to what your doing at the moment.

 

I guess the other way around it is that you could rename the pxeboot.n12 to pxeboot in the RemoteInstall\SMSBoot folder - that'd remove the F12 option completely and they'll boot into WinPE as soon as you boot from the NIC.

Share this post


Link to post
Share on other sites

Hi Apexes

 

Thanks for the response.

 

 

but i would have expected it still to ask to press F12 after booting from NIC?

 

TBH i think the f12 prompt is only for available deployments. I have other sites that are SP1 and R2 and I never have to f12 if the Task sequence is deployed as required and to media and PXE and always re-run.

The symptoms i am having is strange. If I deploy the task sequence out to the unknown computer collection as available then I have to press f12, this is as expected and this still works even on affected models. To test i just deleted some of the systems and booted them as unknown clients again and all is good.

 

I deploy my dynamic Task sequence out to known computer collections as required and only to Media and PXE and always re-run. The PXE flag will then be set on these systems so it will have to be cleared if future deployments are needed. Works a treat.

 

As mentioned the strange behaviour is only on affected models. On the Optiplex 390 and Virtual machines there is no need to press F12 if the task sequence is deployed out to them with this criteria.

The affected models look for an f12, maybe even twice sometimes. If the f12 is not pressed the machine exits the PXE stage and looks for an F1 to retry. If f12 is pressed then the task sequence continues on successfully.

I think that something maybe corrupted in the remote install folder that is causing this? But on the other hand why is it only happening on specific models, so maybe nothing is corrupt.

Not sure what to do really as everything else works fine bar this.

 

 

 

I guess the other way around it is that you could rename the pxeboot.n12 to pxeboot in the RemoteInstall\SMSBoot folder

 

Would this have to be done in both the x86 and x64 directories?

 

Thanks

Share this post


Link to post
Share on other sites

Ahh ok, i wasn't aware of that with required deployments. useful to know! :)

 

RE: pxeboot.n12 - Yep, i use it at present on my lab environment - i've renamed in both x86 and x64. However, my boot's are picked up through x64 as standard. i just renamed the x86 one to be standard across both.

Share this post


Link to post
Share on other sites

Okay just an update on this if anybody else runs into a similar problem.

After some study of the remote install folder in particular the SMSBoot folder and the x86 & x64 directories it became apparent something was not right.

Inside these folders are the required files i:e pxeboot.com, wdsnbp.com etc etc..

The pxeboot.com, pxeboot.f12 and the wdsnbp.com files had a completely different time stamp than that of the rest of the files inside the directories (light bulb time).

I removed the boot.wim files from the DP and cut out all the files from the SMSBoot/x86 and SMSBoot/x64 directories to a temp folder (just incase).

I then restarted the WDS service then redistributed the boot wim files back out.

After this procedure I could see all files in these directories had the same time stamp, the correct time stamp!!

 

Now the strange behaviour is gone and all is good again, a few less hairs on the head though.

 

Apexes thanks for the help anyway and your idea is something I may indeed need for future reference.

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
Reply to this topic...

×   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.