Blog: DHCP

I had needed to make a change to a customer’s WPAD file to add a direct access  location. I made my changes and tested it only to find out that it didn’t work. I decided that I would check and make sure the client could access the WPAD file, so I tested access to HTTP:// SERVERNAME/ WPAD.dat. I was able to see the changes I had saved in the file.  However, the client still didn’t seem to be following the rules. I tried changing the  Automatic Settings in Internet Explorer Proxy settings to use HTTP:// SERVERNAME/ WPAD.dat specifically as the proxy script to use.  As long as I had the Automatic Settings unchecked and the path to the WPAD file defined in the script box, it worked. However, I needed to make sure it would work with Automatic Settings instead. [more]

What I found out was that a client gets it’s instructions about the location of the WPAD file to use through DHCP option 252. Upon checking the settings of this option, I found that it was using HTTP://WPAD/WPAD.dat instead of SERVERNAME. The DNS entry for WPAD was an alias that pointed to SERVERNAME. I went back to the web browser and went to HTTP://WPAD/WPAD.dat.  I discovered that it did not have the changes that I had made even though HTTP://SERVERNAME/WPAD.dat was correct.  On the WPAD server, I restarted IIS and checked it again.  This time, both WPAD.dat files had my changes and the Automatic Settings began working successfully.

It appeared to me what happened was that IIS was serving a cached version of the WPAD.dat file when browsers tried to connect to the DNS alias while the actual server name was not cached. 


 

1.  From the command prompt on the source DHCP server run the following command:

        netsh dhcp server export c:\dhcp.dat all

2.  Copy the “dhcp.dat” file to the new, or destination, DHCP server and run the following command:

        netsh dhcp server import c:\dhcp.dat all

While running the export command, the DHCP service will be temporarily stopped and won’t respond to DHCP requests.  Also, the import will fail if there are any existing DHCP scopes that overlap with the original DHCP servers configuration.


 

My iPhone connects in my office to wi-fi which also is able to connect through my VPN router.  For my laptop, I had set the DHCP settings on my wireless router to include the internal CoNetrix DNS server.  When I connected my phone which uses Exchange active-sync to connect, it would get an error about the certificate authority being untrusted and hit OK to continue. 

Later on I noticed that my phone kept getting synchronization errors and would get the pop up about the certificate authority being untrusted.  What I later noticed was that the server name would change from our internal to external back and forth.  [more]

I later realized that our DNS server had a host record that was the same as our external mail server address.  Each time the phone went on and off my wireless network, it would keep switching server names because the internal DNS would resolve to the actual internal server name. 

I removed the DNS server for the CoNetrix internal network from my wireless router and the phone has only connected to webmail externally.  It no longer tries internal access.


 

Small Business Server 2008 has several "Connect to the Internet" wizards under Getting Started Tasks in the SBS Console.  Depending on your order of setup, running the "Set up your Internet Address" task may activate DHCP without telling you it is doing so.  A key problem here is that, when activating it, a scope is auto-created which includes the entire subnet on which the SBS server sits.  The only exclusions auto-created might be the SBS address and that of the SBS’ gateway.  This could occur on a production subnet and cause IP-address conflicts with other live devices if not noticed quickly.


 

If you're running DHCP on a Windows 2003 domain controller that is also running DNS, you may see Event 1056 (see link) errors in the System log.  This is because DHCP does not have separate credentials (a domain-user 'service' acct is recommended) for DNS dynamic registration.  The danger here is that DNS records could be overwritten.  This is not a default config, but Microsoft recommends you use separate 'DNScredentials' or not run DNS and DHCP on the same domain controller. [more] See the link below to enter the credentials into the DHCP mgmt console.

http://support.microsoft.com/kb/282001


 

The other day I was setting up a Disaster Recovery DHCP server. Part of the testing process was to set up a test branch with an additional 'ip helper' command in the router so that it would start forwarding DHCP broadcasts across the WAN to the Disaster Recovery site. I entered the command and immediately started seeing traffic at the DR DHCP server. However, i was seeing more UDP traffic than just DHCP. I also started seeing errors like this in the event logs:

The master browser has received a server announcement from the computer <MACHINE> that believes that it is the master browser for the domain on transport NetBT_Tcpip_{66AC525D-CD06-401. The master browser is stopping or an election is being forced.

[more]Its not uncommon to see these messages from time to time, but i was seeing these non-stop for about an hour. After some searching i found that the 'ip helper-address' command that is standard in our Cisco router config turns on UDP broadcast forwarding for 8 different protocols. DHCP is one of them, but i wanted to turn it off for all the others. So, i found this command:

ip forward-protocol upd <protocol/port>

The previous command was supposed to fix it. The router would accept 'ip forward-protocol udp dhcp' , but it would not show up in the running config. Finally, I realized it is one of those commands that that you have to turn off what you don't want instead of turn on what you do, so i entered in these commands to stop the NETBIOS broadcast traffic:

no ip forward-protocol udp netbios-ns
no ip forward-protocol udp netbios-dgm


 

Be aware that DHCP option 43 breaks a lot of stuff. In the past, I noted that using APCs necessary binary value in DHCP option 43 will break DHCP configuration on HP JetDirect boxes. Now, I have also found that it breaks PXE boot on HP DL360 G3 and G4 servers. With the option enabled on scopes serving machines that need to boot PXE to talk to an HP SIM (Systems Insight Manager) or RDP (Altiris Remote Deployment Pack for SIM), the PXE boot fails and displays a PXE boot menu error and automatically reboots. This option is normally deployed globally on the DHCP server. I suggest removing it and only adding it back at the scope level in situations when you must have it. Then remove it when you are done with it.


 

Occasionally, when I am in a hotel, the IP address (or subsequent routing) conflicts with our own internal IP addresses or routing.  For example, I was in a hotel in Dallas recently and I got a 10.1.0.x address from their DHCP server.  Since the hotel was using the same IP addressing scheme as our office network, I was unable to VPN into our office. [more]

This is when it comes in handy to have a portable router.  [more] I personnaly carry with me a Linksys WTR54GS:

This is a wireless router but can be used as a wired router.  If I plug the router into the hotel's network then plug into the other side of the router, I get a 192.168.x.x address from the router and then I can VPN through the router to our internal network.

 The router I use also is handy since it's a wireless router with one Internet and one Ethernet RJ45 connection.  If the hotel is wireless only, I could configure the router to connect to the hotel’s wireless and then I could plug into the internal port to get behind the router.


 

When configuring an HP JetDirect device, a common practice is to hook up the device and let it pull a DHCP address so it can be initially configured. Be aware that if you are using a DHCP scope with vendor specific scope options defined (either global or at the scope level), it will most likely cause your JetDirect device to configure its TCP/IP settings incorrectly. There is a bug in the JetDirect software that sets an incorrect subnet mask for the device which makes it inaccessible. Vendor specific options are not that common, however, any organization that has APC PDUs is likely to have one set because APC PDUs will not pull a DHCP address unless a vendor specific DHCP option “cookie” is set on DHCP option 43. To get the JetDirect device to work correctly, you must remove the vendor specific option, reboot the device, and then put the option back.