Difference between revisions of "Active Directory/Documentation/WDS/Separating DHCP From WDS"

From WolfTech
Jump to navigation Jump to search
(→‎The quick and easy way: Update server/DHCP template names)
(Tag as migrated)
 
(One intermediate revision by the same user not shown)
Line 25: Line 25:
 
==Credit==
 
==Credit==
 
This research was performed by Alan Gerber in the College of Natural Resources and William Brocklesby from ComTech.
 
This research was performed by Alan Gerber in the College of Natural Resources and William Brocklesby from ComTech.
 +
[[Category:Migrated to AD]]
 +
[[Category:WDS Management]]
 +
[[Category:WDS]]

Latest revision as of 16:55, 8 July 2011

One of the problems we've faced since day one is the problem of utilizing a Windows Deployment Services (WDS) server across VLANs. For some, this has meant that you must install a WDS server in each building you want the ability to PXE-boot. For others, it has meant having a lab environment that you physically move machines to when you want to reinstall them. Fortunately, with a little help from ComTech, we've recently been able to circumvent this restriction.

The quick and easy way

For those who just want the quick instructions to take advantage of this research, instruct ComTech to copy the settings from the WDS-Main DHCP template into your own template, adjusting DHCP Option 66 to be the hostname or IP address of the server you want to use for WDS. Once you've brought up a Windows 2008 WDS server, you'll be able to PXE-install Windows from other VLANs. If you want to test this, set a test machine's entry in QIP to use the WDS-Main template. After the next QIP push, you'll be able to PXE-boot to a server (munin.wolftech.ad.ncsu.edu) and you should be able to perform a WDS installation.

The technical implementation

The way this works is by doing something called "PXE referral" - the DHCP server is referring the PXE client to TFTP a bootloader from a specific host (your WDS server). That bootloader then rereads the DHCP settings and TFTPs another program from the server, which will then prompt you for a boot image to use.

Specifically, the DHCP options used are:

  • 43: set to "010400000000FF"
  • 60: set to "PXEClient"
  • 66: set to the IP address or hostname of your WDS server
  • 67: set to the boot program to use...the default is Boot\x86\wdsnbp.com

The coolest part about this is that what we are doing is removing the need for the WDS machine to run its own DHCP server. You can turn off PXE responses (in the server properties, under "PXE Response Settings" you can specify "Do not respond to any client computer") AND you no longer have a need for a domain admin to log into your computer to authorize its DHCP server.

You'll need to set the correct boot program in the server properties window, under "Boot">"Default boot program" specify pxeboot.com or pxeboot.n12 (these only exist after loading a boot.wim file onto your server) for your various architectures. The difference between the two is that the .n12 file does not require the client to press the F12 key to PXE boot - some people prefer this because they have to press F12 already to get the boot menu to tell the machine to attempt a network boot, so pressing F12 a second time is just extra.

Once you've done all of this, you'll have a WDS system that you can PXE-boot to from other VLANs - so you don't have to have as many WDS servers, nor do you have to physically move computers across campus to an installation lab.

The caveat

You'll have to have a Windows Server 2008 system to make this work, however. Attempts to make this work using a Windows Server 2003 R2 system just don't quite get there. Of course, the down side to being on Windows Server 2008 is that you cannot make use of RIS - so you cannot natively install Windows XP without first transferring that install into a .wim file.

Credit

This research was performed by Alan Gerber in the College of Natural Resources and William Brocklesby from ComTech.