So, I present you with a way to change that: bcdedit.  Microsoft has a TechNet article that gives the necessary commands to run on your WDS server to make changes to this timeout value.

You can view the current BCD Store settings via this command (insert your own value for the bold text):

bcdedit /enum all /store <full path and file name of store>

An example return will be something like this:

C:\>bcdedit /enum all /store e:\RemoteInstall\Boot\x86\default.bcd
Windows Boot Manager
--------------------
identifier              {bootmgr}
inherit                 {dbgsettings}
timeout                 30

Real-mode Application (10400009)
--------------------------------
identifier              {40fe5c41-285e-412b-b4cd-0ce498e470a2}
device                  boot
path                    OSChooser\i386\startrom.n12
description             Remote Installation Services
pxesoftreboot           Yes

Debugger Settings
-----------------
identifier              {dbgsettings}
debugtype               Serial
debugport               1
baudrate                115200

Device options
--------------
identifier              {68d9e51c-a129-4ee1-9725-2ab00a957daf}
ramdisksdidevice        boot
ramdisksdipath          \Boot\Boot.SDI

You can choose whether to edit your x86 or your x64 store by changing the “bold “x86” above to the appropriate architecture.  Now, we can see here that the timeout is currently set for 30 seconds.

Here are the commands to change that timeout (insert your own values for the bold text):

bcdedit /store <full path and file name of store> /set {bootmgr} timeout <value in seconds>

After you change the timeout value, you need to force the BCD store to regenerate:

sc control wdsserver 129

After this you’ll see an output similar to this:

SERVICE_NAME: wdsserver
TYPE: 20
WIN32_SHARE_PROCESS
STATE: 4  RUNNING
(STOPPABLE, NOT_PAUSABLE, ACCEPTS_SHUTDOWN)
WIN32_EXIT_CODE: 0  (0×0)
SERVICE_EXIT_CODE: 0  (0×0)
CHECKPOINT: 0×0 WAIT_HINT: 0×0

And you’re done.

So, I’ve been creating custom images this week and capturing them to my MDT machine.  I got around to the x86 image, customized it, updated it, captured it, imported it, then tested and failed.  I couldn’t figure out why – hence the hair pulling.  And then I found it.  Like a glowing pot of gold hidden under a rock in the deepest part of the forest, I found the problem:

The DVD I got the source files from in the top image was build number 6.1.7600.16385.  Some update that I was running on the image I was customizing was updating this build to 6.1.7600.16481.  So, when I would go back to try to test the customized image, I’d get an error at the start of the task sequence that goes something like this:

Operating System deployment did not complete successfully.

Error: Unable to find SETUP , needed to install the image
\\MDT_Server\DeploymentShare$\Operating Systems\W7x86_CAP_3-4-10\W7x86_CAP_3-4-10.WIM

I tried the Google route, and found a bunch of unrelated stuff.  Turns out, if the build number is the same on a custom image as on an image with the full source files, MDT will not require setup sources for the custom image.  It will take it from the existing sources in another OS.  So, when it was looking for the setup sources for my 16481 build, it couldn’t find it.

There you have it.  Be careful running updates on custom images.  Make sure you have the sources with the same build number or it won’t work.

So, every time you make a change in MDT, you have to update the deployment point, which in most cases will regenerate the boot wims.  When you have four deployment points, this can be a pain just to update a task sequence.  After a bit of Googling, I found this:

You’ve probably gone through this cycle if you are using WDS to PXE boot computers to start bare metal Lite Touch deployments:

• Import new drivers or change bootstrap.ini.
• “Update deployment share” to generate new WIMs.
• Import new WIMs into WDS.

Fortunately, with the new “update” process in MDT 2010 … it’s pretty simple to add a script to automate this process.

So, there’s a script you can create to do this job for you.  For posterity, the procedure is copied below.

First, create a script file – we’ll call it “UpdateExit.vbs” – and save it – we’ll save it in C:\Scripts\ for the purpose of this demonstration.  Paste the following into UpdateExit.vbs:

Option Explicit

Dim oShell, oEnv

Set oShell = CreateObject("WScript.Shell")
Set oEnv = oShell.Environment("PROCESS")

If oEnv("STAGE") = "ISO" then

    Dim sCmd, rc

    sCmd = "WDSUTIL /Replace-Image /Image:""Lite Touch Windows PE (" & oEnv("PLATFORM") & ")"" /ImageType:Boot /Architecture:" & oEnv("PLATFORM") & " /ReplacementImage /ImageFile:""" & oEnv("CONTENT") & "\Sources\Boot.wim"""
    WScript.Echo "About to run command: " & sCmd

    rc = oShell.Run(sCmd, 0, true)
    WScript.Echo "WDSUTIL rc = " & CStr(rc)

    WScript.Quit 1

End if

Now, edit “C:\Program Files\Microsoft Deployment Toolkit\Templates\LiteTouchPE.xml” and change the following (starting around line 90):

<!– Exits –>
<Exits>
  <Exit>cscript.exe "%INSTALLDIR%\Samples\UpdateExit.vbs"</Exit>
</Exits>

to look like this:

<!– Exits –>
<Exits>
  <Exit>cscript.exe "%INSTALLDIR%\Samples\UpdateExit.vbs"</Exit>
  <Exit>cscript.exe "C:\Scripts\UpdateExit.vbs"</Exit>
</Exits>

Instructions are include in the link above if MDT is installed on a different server than WDS.

Credit: Automatically Update MDT 2010 boot images in WDS

Log Name: System/Application
Source: BINLSVC
Date: Date
Time: Time
Event ID: 1803
Description: An error occurred while attempting to locate the Service Control Point object for this Windows Deployment Services server in Active Directory Domain Services. There was an error reading the ‘netbootSCPBL’ attribute from the Computer object.

Research ensued, and a quick Googling (sorry Google) revealed the following:

When the computer starts, BINLSVC queries for the information that is contained in the Service Control Point (SCP), this operation is performed before the creation of the SCP, and then BINLSVC logs an error message in the Application log or the System log. This error message states that the server’s SCP is missing. This is expected behavior on new WDS servers and in other instances where the SCP has not yet been created for the server. In this case, you can safely ignore the error that is logged in the Application log or the System log.

However, the problem here is that this is not a new WDS server.  So, I came across this from another Google result.  It doesn’t really apply to my situation (as I was not moving the Computer object to a different OU), but it fixed the error and restored the SCP.

For posterity:

To resolve this problem, reinitialize the WDS server after you move the WDS server to a different organizational unit. To do this, follow these steps:

1. Click Start, click Run, type cmd, and then click OK.
2. At the command prompt, type wdsutil /uninitialize-server, and then press ENTER.
3. Move the WDS account to Active Directory in the new organizational unit.
4. To reinitialize the WDS service, type wdsutil /initialize-server /reminst:{RemoteInstallFolder} at a command prompt, and then press ENTER.

This is useful to inject one-time drivers or see ipconfig information.  At least for me.

Go figure.

The link:  http://support.microsoft.com/kb/923834/en-us.

Now, the problem description isn’t exactly the issue we were experiencing, so the part that applied to us:

3. Update the WDS boot image to include the new third-party network driver. To do this, follow these steps.

Note The following procedure assumes that the Windows Automated Installation Kit (AIK) is installed on the WDS server. If the Windows AIK is not installed on the WDS server, you can perform the same procedure on another computer that does have the Windows AIK installed. Then, map a network drive to the WDS server.

a. On the WDS server, click Start, click Run, type wdsmgmt.msc, and then press OK.
b. Under your WDS server, double-click Boot images.
c. Right-click the boot image that you want, and then click Disable.
d. Right-click the same boot image, click Properties, and then click General.
e. Note the name and location of the boot image that is displayed in the File name box.
f. At a command prompt, type the following:

C:\Program Files\Windows\aiktools\petools\copype.cmd x86 c:\windowspe-x86
Note Keep this command prompt window open for the next step.
Imagex /info Drive:\remoteinstall\bootx86\images\boot.wim

Notes
• Drive:\remoteinstall represents the path at which the Remoteinstall folder is installed.
• Boot.wim is the name of the boot image.

g. Note the boot index number of the bootable image that is displayed. To identify the boot index number, locate the line that contains “boot index: X.”

Note X is the boot index number. The number indicates that image number X is marked as bootable and that the image is to be updated. The second image is the default image that you would typically modify. However, always verify which image is marked as bootable.

h. At a command prompt, type the following:

Imagex /mountrw Drive:\remoteinstall\bootx86\images\boot.wim 2 mount
peimg /inf=driver.inf mount\Windows
imagex /unmount /commit mount

Notes
• Drive:\remoteinstall represents the path at which the Remoteinstall folder is installed.
• Driver.inf is the name of the third-party driver.
• The Imagex /mountrw command mounts the specified image, with read/write permissions, to the specified directory.

4. Enable the boot image on the WDS server. To do this, follow these steps:
a. On the WDS server, click Start, click Run, type wdsmgmt.msc, and then click OK.
b. Under WDS server, double-click Boot images.
c. Right-click the boot image that you want, and then click Enable.

It would be useful the note at this point that we use Server 2008 Standard x64 (not x86) and these steps worked just fine.

We’ve been trying for a day or two to get Windows Deployment Services up and running over PXE to eliminate our need for boot disks to image with, but ran across some issues getting the client (in this case, an Optiplex 745) to boot via PXE. During my Google Marathon, I found the one and only article that was of any use to me:

“DHCP….” followed by “PXE-E53: No boot filename received”

SYMPTOM

When being started, the PXE client comes up with the PXE copyright message, then displays

DHCP….

After a while, the following error message is displayed:

PXE-E53: No boot filename received

Depending on the PXE client’s system setup boot device list configuration, the PC then either stops or tries to boot from the next boot device in the system setup boot device list.

CAUSE

The “PXE-E53″ error indicates that the PXE client received a reply to its DHCPDISCOVER message, but the “boot filename” information was missing in this reply.

RESOLUTION

Make sure that the “boot filename” option is present on your DHCP or BOOTP server, and that its value is set to the filename of the boot loader.

When using Microsoft DHCP server, add option 067 (Bootfile Name) to your scope. When using a Unix/Linux based (ISC) DHCP server, use the “filename” parameter for this purpose.

In the context of the BootManage Administrator, the boot loader filename is “pxboot” for PXE clients and “bpboot” for TCP/IP BOOT-PROM clients. So, if you have exclusively PXE clients, set the boot filename option to the value “pxboot”. If you have exclusively TCP/IP BOOT-PROM clients, set the boot filename option to the value “bpboot”. In a mixed PXE and TCP/IP BOOT-PROM client environment, you must configure your DHCP or BOOTP server so that it provides the PXE clients with the “pxboot” boot loader, and the TCP/IP BOOT-PROM clients with the “bpboot” boot loader.

As it says, the PXE client is receiving DHCP replies, but is unable to locate a useable boot file/image. Once I changed DHCP option 66 to my WDS server’s name and option 67 to “bootx86wdsnbp.com” (which is the WDS boot file that loads the PXE environment), the machine didn’t hesitate to boot.

It took about 15 minutes or so to image the machine from start to finish (all it was doing, though, was installing Vista – we would use custom images so the timing may change). This is about the time it takes with our current Ghost setup, but with WDS deployment points can be created. This would allow us to have a deployment server in each office and would streamline the way we share updates to images.

Credit: bootix.