You have your MDT task sequence perfected! All of your machines are configured in the MDT database. When you boot a machine into MDT, it looks up its name and images without any prompts. If only you didn’t have to physically PXE boot the computer! If only you had a way to remotely PXE boot a computer…
Rethinking a PXE Boot
Your goal isn’t to PXE boot a computer; your goal is to set the onboard-NIC as the primary boot device. That small difference is so important! When a machine is online, changing the boot order this way will allow it to boot into a MDT task sequence the next time it starts up. This post will focus on remotely PXE booting a Dell computer. This same concept can be applied to any make/model that allows you to edit the boot order.
Your first step is to build a BIOS settings package that sets the onboard-NIC as the primary boot device. If you haven’t made a BIOS package yet, this guide covers the steps in detail. Download and install the Dell Client Configuration Toolkit. The download can be found here.
Launch the Client Configuration Toolkit, select Create Package, and choose Multi-Platform file. In the boot management section, double click on bootorder. Select View/Change – Edit – Add Device. Your first device should be the embedded NIC with a Device Instance of 0. The second device should be the Hard Disk with a Device Instance of 1.
Save the boot order and export the configuration as an EXE. If your machines contain a BIOS password, specify it now. Copy this EXE to a network share.
Running a Batch File Remotely
Now we need to create a batch file to execute this package on remote machines. We will be using the PSTools suite. A download can be found under the Desktop Management section here.
Copy the psexec and psshutdown tools to the root pf your local profile. Create a new batch file in the same folder. Paste in the following:
xcopy "\\SERVER\SHARE\Dell\forcepxe.exe" "\\%1\\C$\Users\Public\" psexec \\%1 -u DOMAIN\USERNAME-p PASSWORD -h "C:\Users\Public\forcepxe.exe" psshutdown.exe -r -t 60-c -m "This computer has been scheduled for a remote image. If you would like to delay this process, please select cancel" \\%1 pause
You will need to edit the xcopy path to point to your BIOS settings EXE. You will also need to specify credentials for the psexec line. The user specified needs to be an admin on the remote machine. You can now run this script from the run box. I named my batch file forcepxe.bat. By pressing WIN + R, I can simply type forcepxe REMOTECOMPUTERNAME to run this script.
In the script output, you should see that the BIOS package successfully copied and executed on the remote machine. The machine will pause for 60 seconds to allow a user to cancel the reboot. After a minute, it will restart and boot off of the NIC! Pretty awesome right? One problem though – we are now stuck in an endless loop. The machine will install the OS and reboot back into a MDT task sequence. On the bright side, you don’t need deepfreeze anymore. 🙂
In our next post, we will edit our task sequence to prevent this endless loop by changing the boot sequence in Windows PE. Do you have another way of PXE booting a remote machine? What hurdles prevent you from getting to a Zero Touch image?
Good morning. I know this thread is old, but I found a great script to enable/disable BIOS functions on HP machines:
$Device=Get-WmiObject -computername $Computer -Namespace root/hp/instrumentedBIOS -Class HP_BIOSSettingInterface
$Device.SetBIOSSetting(“Network (PXE) Boot”,”Enable”)
This script enables the PXE Boot option.
Replace “Network (PXE) Boot” with the BIOS feature you’d like to enable/disable. The phrasing needs to be exactly as it is listed in BIOS, e.g., CD-ROM Boot, NumLock on at Boot, Audio Device, Fingerprint Device, etc. Then type “enable” or “disable” in the 2nd field as seen above.
Hope this helps someone!
With Dells specifically. Is it possible to achieve this without pushing new BIOS settings if you use the Dell Command | PowerShell Provider ? I see some cmdlets like ForcePxeNextBoot and was wondering if this is too good to be true?
Hey Lee – that command did not always work for me, especially on older dells.
Any follow up to this article? This was exactly what I was looking for, but after doing tons of research I haven’t found a good way to change the boot order back again during the deployment. Any advice is appreciated at this point!
In a very rough order, I handle it this way:
1. Load the command line version of your BIOS editing tool (ex: CCTK.exe for Dell). into your Windows PE image. You can put it in your Tools sub-folder. If you need instructions for this, look up how to integrate the DaRT tools into Windows PE.
2. Add a task to your imaging process (MDT, SCCM, etc) calls your command line BIOS tool. Have it change your BIOS back to the HD first mode right after the OS is applied to the disk but before it boots into Windows for any customization.
I have a question.
We are using Dell Kace. If you’re not familiar with it, it’s a Help Desk, Network Inventory, Management, and Imaging application broken into two piece.
The K1000 is the inventory, managed distribution, and Help Desk side and the K2000 is the imaging side.
I’m relatively new to Kace, but have gotten the imaging down, and am making progress with managed installations.
What I would need to do is:
1. Remotely reboot a machine
2. Boot to NIC.
3. Select an imagining environment from within Kace (there are several)
5. Select the correct image.
6. Kick it off.
From the sounds of it, this write up would work if I had a one image system, which did not require authentication, and auto-applied the image.
Does you have any experience with Kace and how this might work?
Are you sure Kace doesn’t support remotely PXE booting already? SCCM does. Kace and SCCM seem to share many features.
It does and I figured it out.
I install Dell Command | Control and pass a cmd to flip the boot order to NIC and then initiate a restart.
In the meantime, I set an automated deployment (environment and image) based on MAC address. When my target reboots to NIC, it goes PXE, connects to Kace, and the image goes out.
Awesome Ray! Good luck with your deployments!
I would love to see the followup article and how to fix the endless boot!
I can’t believe I forgot to finish that part up! I moved it to the top of my drafts folder. Expect a follow-up in a week or so.
I was really excited when I first came across this article. It contains many things that do exactly what I am trying to accomplish. Use of MDT. Fully automated install. Conquering the PXE boot monster.
I do have some questions however.
1. If your intention is to automate through the use of MDT, why are you not running the batch file in MDT?
2. If you allow users to respond, wouldn’t that break MDT just like installing an application that required a response?
3. The same is true for rebooting, right? If you let MDT reboot, all is well. If an application (or a batch file) reboots, MDT takes a nose dive.
4. Although this is a great starting point, the article is a teaser. It’s worthless without the follow-on article.You create a perpetual loop on purpose to draw people to the next article. Bad form. Such a great start. Such a terrible finish.
Even so, given the hints in the article one should be able to get to the Promised Land. Alter the batch file so it does not prompt or reboot. Put the batch file in the /scripts folder of mdt. Create a second batch file that shuts off pxe booting and put it there as well. Run the first script before your no-touch automated process. Run the second one after. If you worry about security, you can let MDT prompt for the Admin password. At least that seems like that should work to me? Am I off base?
I look forward to your comments.
1. The batch file allows me to pick which computers should be imaged remotely. Running it separate gives me that flexibility.
2. The response is seen on the IT side.
3. As long as you do it before the task sequence starts, you are fine.
4. Thank you! 🙂 Life got super busy so I haven’t been able to post a follow up (or other articles). You are close. I actually use the CCTK utility to change the bios boot order in MDT. See this guide: https://deployhappiness.com/manage-the-dell-bios-remotely/
Excellent post. I am working on finishing my Dell deployment task sequence (seems like a never ending project!) and I plan on using this feature. I have a suggestion though. To avoid the endless loop you mention, create a configuration file that does not modify the boot order, but instead sets the ForcePXEOnNextBoot. That flag gets reset each time the machine is reboot (or so the docs say, I have yet to independently verify it, but I do plan on trying it).
Thanks James! How is your project coming?
I had issues with that setting on two models that we support: 380s and 390s. The machine would report that the option was not available. Let me know if you see that issue.
Its a shame this is only for Dells and not a more universal method. Still helped me move an entire sweet over to win 8 over night.
That is pretty cool tom!! I am in all dell environment so I don’t get much other experience. If anyone has a more universal method, I would love to see it!
We have a GPO that executes this exe as a shutdown script and removes the computer from a security group. We simply place the computer in the security group and wait for it to restart. Self imaging doesn’t get much easier!
Everyone at work keeps telling me im going to automate myself out of a job. hahaha
Not a bad goal to have! 🙂
Just think if everyone took that view – the police would work to stop crime from occurring, doctors would help you before you got sick, etc.
The project is moving along, it just seems to be taking forever. It always seems like I find a new wrinkle that needs to be worked out in my quest to automate everything. Like just recently, I thought I had my entire custom disk partitioning process in place. I’ve written a script to do the formatting and partition of the disk just the way I like if it detects a Dell machine because I like to keep the OEM tools partition since I usually find Dell asks me to run this if I am having a problem with the machine. Well, we got some Latitude 10 tablets a while ago and while testing my process with these, I noticed a whole other issue, mainly they only use UEFI w/ GPT disks! So, I had to account for that little possibility when scripting the partitioning.
Seems to be working OK though. Do you support any devices with UEFI? One quirk I’ve found is reimaging leads to multiple Windows Boot Manager entries in UEFI. Doesn’t seem to cause any harm, but is just something that clutters things up.
I know that feeling! Hang in there though – the more you automate, the more time you will have to automate.
We support a few dell UEFI machines but are still using them in legacy mode. I haven’t seen that issue yet. When you find out a solution, post back and let me know.