none
WDS Mixed Mode Problems RRS feed

  • Question

  • Having some trouble with WDS and could use a little guidance.  Here's the situation.

    1.  Upgraded my RIS server to WDS (Mixed Mode) using the latest patch availabe with the RC1 WAIK
    2.  Added (2) custom boot images to the WDS server, along with an install image
    3.  WDS is not running DHCP.  The actual DHCP server has the 066 option set to the WDS server name, and
        067 is set to use "OSChooser\i386\startrom.com"

    When I PXE boot I only see the old images and have no way of selecting any of the custom boot images.  I tried changing the 067 option in DHCP to use "boot\x86\pxeboot.com", and after doing that the client just returns a Windows Boot Manager error (0xc000000f.  Error occurred while attempting to read boot config data).

    The WDS Step-By-Step Guide makes it sound easy but I'm stumped.  How do I get a Mixed Mode WDS server to show me both legacy images and new boot/install images?

    Thursday, September 28, 2006 4:48 PM

All replies

  • There are actually two issues here :)

    Issue #1 - not seeing the new boot menu and Windows PE images.

    As you have already suspected, this issue is occuring because you are directing clients to download startrom.com, the legacy network boot program from RIS, instead of a newer boot program for WDS. In order to get the boot menu in WDS you need to get the new operating system loader, bootmgr.exe. Here are the sequence of downloads:

     RAMDISK boot WinPE 2.0:

    Pxeboot.com -> Bootmgr.exe -> Winload.exe (in the WinPE image)

     

    New boot menu but choose OSChooser from the new menu, common in Mixed Mode WDS:

    Pxeboot.com -> Bootmgr.exe -> Startrom.com -> NTLDR (TFTP restart into OSChooser.exe, renamed to NTLDR)

     

    Old RIS or WDS in Legacy Mode:

    Startrom.com -> NTLDR (OSChooser.exe renamed to NTLDR)

     

    Issue #2 - once you point the client to download pxeboot.com, you get an error message from bootmgr.exe

    This issue is caused by the fact that you are doing a PXE referral (that is what occurs when using DHCP Options 66 & 67) but are using the incorrect boot program. You should instead be pointing clients to download wdsnbp.com, a boot program specifically designed to fix-up the DHCP info in the BIOS as if the client directly contacted the PXE Server (as should be the case, per the PXE spec). In this manner, your download sequence would look as follows:

    WDSNBP.COM -> PXEBOOT.COM (the server default boot program for the client's architecture) -> Bootmgr.exe -> BCD (from the \Tmp directory)

    More Information taken from a WDS whitepaper the WDS Team is currently in the process of writing (probably more than you wanted to know...)

    The PXE protocol is really nothing more than an extension to DHCP. That is, the method of communication between the network booting client and the network booting server uses particular data fields, known as options, available within the format of DHCP packets.

     

    The Windows Deployment Services network boot solution works well in any of the following configurations:

     

    1.     The Windows Deployment Services PXE Server is located on a different physical machine than a Microsoft DHCP server.

    2.     The Windows Deployment Services PXE Server is located on the same physical machine as a Microsoft DHCP server.

    1. The Windows Deployment Services PXE Server is located on a different physical machine than a 3rd party DHCP server.

    4.     The Windows Deployment Services PXE Server is located on the same physical machine as a 3rd party DHCP server.

     

    The default (assumed) installation of Windows Deployment Services is that the Windows Deployment Services PXE Server and a DCHP server (Microsoft or 3rd party) are located on different physical machines. In this scenario, no additional configuration steps are required for interoperability between the PXE Server and DHCP.

     

    When the Windows Deployment Services PXE Server and a DHCP server exist on the same physical machine, there are two additional settings that must be configured to support this scenario.

    1.     The Windows Deployment Services PXE Server must be explicitly told not to listen on UDP port 67, as it will be used by the DHCP Server.

    2.     DHCP option tag 60, set to the string ‘PXEClient’, must be added to all active DHCP scopes. This allows booting PXE clients to learn about the presence of the Windows Deployment Services PXE Server from the DHCP response generated by the DHCP server.

    NOTE: Setting DHCP Option tag 60 does have one side effect – network booting clients are always notified that a Windows Deployment Services PXE Server is available, even if the server is not operational / stopped.

     

    The preferred method for setting both of these settings is via the Windows Deployment Services MGMT utilities. For more information, please see the appropriate chapter below. Also, for more information regarding DHCP server and Windows Deployment Services PXE Server interoperability during an upgrade from RIS, please see the appropriate chapter below.

     

     

    Methods of Directing a Client to the Appropriate Network Boot File

     

    There are two methods for directing a booting PXE client to the correct network boot file for it to download and execute –

    ·         The client may contact the network boot server directly to obtain this information

    • The client may be told this information by a DHCP server

    IP Helper Updates:

    The PXE network boot method uses DHCP packets as its communication mechanism. The DHCP packets really serve a dual purpose as they are intended to assist the client in obtaining an IP address lease from a DHCP server as well as locate a valid network boot server. If the booting client, the DHCP server, and the network boot server are located on the same network segment no additional configuration is usually necessary. The client’s DHCP broadcasts will reach both the DHCP server and the network boot server. However, if either the DHCP server or the network boot server are on a different network segment than the client or if they are on the same network segment but the network is controlled by a switch or router, it is usually necessary to update the networking equipment’s routing tables to ensure that DHCP traffic is directed appropriately. This process is generally known as performing IP Helper table updates. When performing this process, you must configure the networking equipment such that all DHCP broadcasts from the client machine will be directed to both a valid DHCP server and a valid network boot server. Note that the requirement here is not to simply rebroadcast the packet onto other network segments, but rather it is to perform a targeted forward of the packet to only those recipients as listed in the IP Helper table. Once the client machine has obtained its IP address it will contact the network boot server directly (again via DHCP packets) in order to obtain the name and path of the network boot file to download.

    The specific changes that need to be made are –

    1. All DHCP broadcasts on UDP port 67 by client computers should be forwarded directly to both the DHCP server and the Windows Deployment Services PXE Server
    2. All traffic to UDP port 4011 from the client computers to the Windows Deployment Services PXE Server is routed appropriately (these requests are direct traffic to the server, not broadcasts)

    Updating the IP Helper tables is the Microsoft recommended approach for solving scenarios where the client machines and the network boot server are not located on the same network segment.

     

    Use of DHCP Options 60, 66, and 67:

    In some environments, you may wish to use the following Dynamic Host Configuration Protocol (DHCP) options to direct Pre-Boot Execution Environment (PXE) clients to an appropriate network boot file to download.

    ·         60 = Client Identifier (set to the string “PXEClient”)

    ·         66 = Boot Server Host Name

    ·         67 = Boot File Name

     

    When using these DHCP options, client machines will receive an IP address lease, information on the relevant boot server, and information for the relevant boot file directly from the DHCP server. Clients will not contact the network boot server using DHCP but will simply proceed directly to downloading the file specified via TFTP. This method may be used as an alternative to the IP Helper update method as detailed above.

     

    Microsoft does not recommend this method for the following reasons:

     

    ·         Using DHCP Options is not as reliable as updating the IP Helper tables. In testing, Microsoft has observed some issues, mainly with older PXE ROMs, where clients will not correctly parse the DHCP options returned from the DHCP server. The result is that booting clients will error with a “TFTP Failed” message. Generally, this problem occurs when the PXE ROM ignores the boot server host name value and instead attempts to download the network boot program directly from the DHCP server, which likely does not have the file in question.

    ·         If there are multiple network boot servers available to service client requests, specifying the explicit network boot server’s name as part of the DHCP scope may prevent load-balancing from occurring.

    ·         Clients may be directed to a network boot server that is not available. As the client does not have to contact a network boot server directly to determine the appropriate network boot file to download, it may turn out that the DHCP server is directing clients to download a non-existent boot file or to a server that is not currently available on the network.

    ·         Clients may bypass the network boot server’s answer settings. Many network boot servers on the market today have an on/off mechanism that allows control over whether or not certain (or any) client requests should be answered. Per the PXE standard, client machines should contact the network boot server directly to obtain the path and filename of the network boot program and, in the process . Using DHCP options 66 & 67 may cause the client to bypass this communication with the network boot server completely and thus circumvent / ignore the network boot server’s settings regarding answering clients.

     

    Please note that use of DHCP Options 66 & 67 is considered a network boot referral. Thus, please ensure that your implementation meets the guidelines as defined in the ‘Network Boot Referrals’ section below.

    Network Boot Referrals

     

    A network boot referral, also known as a PXE referral, occurs when a client is directed to download a network boot program from a different server than the one it was in communication with via DHCP (as part of the process to discover the network boot server name and network boot file name). This referral may be initiated by either a network boot server or a DHCP server.

     

    Some scenarios where you might want to consider using PXE referrals:

     

    1)     To direct a client to download a file that physically resides on a different machine / network location

    This is particularly the case when using DHCP Options 66 & 67 as the client is generally answered directly by the DHCP server and is redirected to a different network location holding the appropriate boot file.

    2)     To enable load balancing

    It may be advantageous to direct a certain class of clients to a particular Windows Deployment Services server for the purposes of limiting network traffic to a particular server.

    3)     To support complex network and Active Directory topologies

    Sometimes the networking and/or Active Directory topology just don’t line up. It may be that incoming PXE requests are answered by a machine over a WAN link but you would like the actual WindowsPE boot image download to occur from a local server.

    4)     To remove the need for image replication/duplicate image maintenance

    Using referrals may allow you to keep only one copy of an image, thus maintaining a single release point to update / service. Additionally, you don’t have to incur the overhead associated with replicating an image and keeping the copies in sync.

    Configuration

     

    Configuration of network boot referrals involves two steps:

    1. Configuring front-end and back-end servers.

    A front-end server is the server that will answer the client’s PXE boot request and direct the client to the proper server and file to download. A back-end server is the server that the client will connect to for the purpose of TFTP downloading the network boot program.

    1. Pre-staging clients and directing them to a back-end referral server and, optionally, the network boot file to download

    NOTE: This step is only required if you are not using DHCP Options 66 & 67 to redirect clients.

     

    The recommended method for configuring these settings is to use the Windows Deployment Services management utilities. For more information, please refer to the management chapter below.

     

    Referral Scope

     

    Referrals are classified based on the number of “hops” the client must make before it downloads and executes its intended network boot program.

     

    First order referral from PXE Server.

    MachineA sends a DHCP broadcast packet and receives an IP address lease from a DHCP server and a network boot response from PXE Server1. MachineA contacts PXE Server1 directly on port 4011. PXE Server1 refers the client to download the file \boot\wdsnbp.com from Server2. The client machine downloads wdsnbp.com from Server2.

    o   Referral of X86 clients – this scenario is fully supported provided the requirements are met.

    o   Referral of IA64 clients – this scenario is not supported for this client architecture.

    o   Referral of X64 clients – this scenario is fully supported provided the requirements are met.

     

    Requirements:

    -          The network boot program the client machine is directed to download from the TFTP server (noted as Server2 in the example above) must be ‘wdsnbp.com’.

    -          The network boot server performing the referral (noted as PXE Server1 in the example above) must be running Windows Deployment Services.

     

    First order referral using DHCP options.

    MachineA sends a DHCP broadcast packet and receives an IP address lease from a DHCP server. The lease also contains values for DHCP options 66 and 67, referring the client to download the file \boot\wdsnbp.com from Server1. The client machine downloads wdsnbp.com from Server1.

    o   Referral of X86 clients – this scenario is fully supported provided the requirement is met.

    o   Referral of IA64 clients – this scenario is not supported for this client architecture.

    o   Referral of X64 clients – this scenario is fully supported provided the requirement is met.

     

    Requirement:

    -          The network boot program the client machine is directed to download from the TFTP server (noted as Server1 in the example above) must be ‘wdsnbp.com’.

     

    Second order referral using both DHCP options and PXE Server.

    MachineA sends a DHCP broadcast packet and receives an IP address lease from a DHCP server. The lease also contains values for DHCP options 66 and 67, referring the client to download the file \boot\wdsnbp.com from PXE Server1. The client machine downloads wdsnbp.com from Server1. Wdsnbp.com contacts PXE Server1 on port 4011. PXE Server1 refers the client to download the file \boot\wdsnbp.com from Server2. The client machine downloads wdsnbp.com from Server2.

    o   Referral of X86 clients – this scenario is fully supported provided the requirements are met.

    o   Referral of IA64 clients – this scenario is not supported for this client architecture.

    o   Referral of X64 clients – this scenario is fully supported provided the requirements are met.

     

    Requirements:

    -          The network boot program the client machine is directed to download from the PXE Server (noted as Server1 in the example above) must be ‘wdsnbp.com’.

    -          The network boot program the client machine is directed to download from the TFTP server (noted as Server2 in the example above) must be ‘wdsnbp.com’.

    -          The network boot server performing the referral (noted as PXE Server1 in the example above) must be running Windows Deployment Services.

     

    Thursday, October 5, 2006 2:20 PM
  • Scott,

    Thank you for the information.  It definitely answered some questions about WDS.  I'm still however having some problems and was hoping you or someone else might be able to help a bit more.  I'm using the network boot referral method and have changed my DHCP 067 scope option to use WDSNBP.COM instead of startrom.com.  I've also loaded (2) default boot.wim images taken from the Vista source directory, as well as added a custom WinPE image of my own to WDS.  Now when I PXE boot a client, I see the following:

    Downloaded WDSNBP

    Started using DHCP referral..........Contacting server x.x.x.x

    No response from Windows Deployment Server.....Launching pxeboot.com

    At this time, I get the same "Windows Boot Manager" error I was seeing before

    File: \Boot\BCD

    Status: 0xc000000f

    Info:  An error occured while attempting to read the boot configuration data.

    I've checked services, reviewed the event logs and don't see any WDS errors.  I just don't see what I might be missing here after going through your post and the deployment guide but obviously something isn't set right.

    Thanks again for the help. - jb

     

    Monday, October 9, 2006 6:24 PM
  • Same exact issues here using RC2 WAIK/WDS and Vista RC2 Enterprise media.  Is there anyone that has resolved this issue?  HELP!!

    Microsoft DHCP server running on a different machine than WDS.  WDS is installed on Windows Server 2003 SP1.  Using Option 66, pointing to the WDS serer, and option 67 with the path boot\x86\wdsnbp.com

    Situation occurs exactly the same as it does for jballgame.

    Friday, October 27, 2006 6:03 PM
  • I am experiencing the same issue as well. sbrown23 described my scenario exactly.

    I've been searching for a solution for a while now and have not found an answer.

     

    Friday, October 27, 2006 6:09 PM
  • There was an issue in previous builds of wdsnbp.com that would cause it to send a braodcast flag when it shouldn't have. This caused network boot failures like the ones you have described above in scenarios where you were using DHCP options 66 & 67 instead of IP Helper Updates and a switch / router was sitting between the clients and the WDS server. This issue is fixed in the RTM builds.

    Thanks -

    --Scott

    Monday, October 30, 2006 4:19 PM
  • hI

     

    I completely agree with Scott.There was a lot of issue with BDD 2007 RC!1 and beta version.The same was the problem with vista RC1

    All the problem has been solved in the RTM version.I have a WDS server on Win 2003 SP1 and DHCP on the other server

    I have entered th eIP of the WDS server on the IP helper as secondry IP address and the client are successfultyy booting up uding PXE boot.

    Thursday, February 1, 2007 5:59 PM
  • hi

    we had the same error with boot\BCD not found while the deployment server was not a dhcp and wds and dhcp are on other subnets.

    Solution: there is an error in the "wdsnbp.com" of the german version.

    After replacing "wdsnbp.com" with the english one, it is running with dhcp option 66 and 67.

    Monday, February 26, 2007 1:33 PM
  • Has anyone found a solution to this issue.

     

    I am using option 67 for specific IP reservations so that each system connecting to the DHCP server can have unique boot configurations.

     

    For example, I have option 67 for system A set to "\x86\pxeboot.n12(or wdsnbp.com)" and system B set to "\amd64\pxeboot.n12".  each directory tree \x86 or \amd64 has all the necessary files (BCD, bootmgr.exe and winpe.wim) to boot, but I always get the above error.

     

    However, if I create a third directory \boot and put one of the BCD files there, it works, but then I can't make unique BCD files for my x86 and amd64 systems????

     

    As far as I can tell, once bootmgr.exe loads, it automatically looks for \boot\BCD instead of looking for BCD in the current directory and appears to be hardcoded to this path.

     

    I don't want to put multiple configurations in one BCD and give control to the user, I need control by configuring option 67 for each ip reservation...

     

    Any direction would be helpful.....

    Wednesday, May 16, 2007 4:29 PM
  • Hi

    Took a shortcut and uninstall WDS then put in back so it became a native mode installation

    Then I wdsutil /initialize-server /reminst:{RemoteInstallFolder}, after that i change under properties/boot x86 architecture

    to OSChooser\i386\startrom.com. and voilá once again  your old nice RIS menu is back! Big Smile

     

    /R

    Friday, May 25, 2007 8:08 AM
  • I had the same issue, this is what I have done so far to get past it:

    Load boot.wim from vista dvd /sources directory to boot images in wds . You will be prompted to name the wim file. Once that loads, right-click the boot image you just named and select "create capture boot image", under "location" select the reminst\images directory. Name the file.

    Once that completes, remove the options 066 and 067 from DHCP. Make sure you have an ip-helper address (this will be the addy of your WDS server) in your router's interface on the subnet you are trying to image the machine from. No need to point to the wdsnbp.com file. My DHCP is on another machine (srv03) from the WDS machine.

    Though I have other issues on WDS I am working out (nic cards, unattend, etc.), this process got me to the point of seeing both the older RIS images and the new WIM format images.

    Hope this helps...

    Thursday, June 14, 2007 10:38 PM