DHCP lease renewal issue

The way that DHCP is set up, a client will try to renew the lease repeatedly until it actually expires, then give up. If the machine is turned on, the lease should never expire, since it automatically tries to renew after 1/2 of the lease is gone. If the machines are being turned off over the weekend, they should get a new IP when they reboot. It sounds like the client machines are being left on but a server or hub is down over the weekend, preventing them from getting a new lease.

One solution is to make the lease long enough to avoid the problem (e.g. three days) if you have enough addresses. The other way is to have your users turn their machines off over the weekend. They should get a new IP when they boot on Monday.

Good luck.

Three days isn't long enough since DHCP trys to renew when the lease is half done. I have my network set to 7 days and have never had any trouble.

Don

It may be a problem with slow network communication between the server and these particular workstations. If you can renew manually, it sounds like they're not getting a response from the server when they first start up after the weekend. Also, ifyou're not seeing any NACKs or other DHCP errors on the server, it probably means that they are not actually seeing the server during startup. Look at other similarities between these workstations that differ from the other workstations - do they all have the same NIC? Do they perhaps have a different (older) NIC driver version than other workstations? Are they all on the same hub or switch? Do they run some other software or something in the login script that other workstations don't have? Just a few things to look at/think about. Hope this helps!

At a guess, I'd say that the clients involved are on the other side of a router that isn't passing on the broadcasted information required to request the lease.

By default, routers dont pass broadcasts on - thats partly why people use routers to segment their networks - to keep the traffic down...

Is this the case for you?

Cheers,
Tim.

Have you checked the network wire at the client? I remember spending about a week on a server with remote drive mounts (old RFS). It was a bad cable. The cable would allow "normal" traffic like pings and terminal sessions but not the heavy load of an RFS drive mount. I know that DHCP is not a heavy load but It is worth looking at since only 6 machines are affected I would be looking at the client not the server.

Everybody I know sets their DHCP leases to 30 days for the network. This provides them plenty of time to research issues with either the server or the individual machines when a problem occurs. The only thing the user needs to do is answer No the question "Do you want to receive further notifications..."

Anything showing in the Event log on the clients? Enable DHCP logging on the DHCP server by selecting the server in DHCP Manager and doing Properties. This creates log files named DhcpSrvLog.mon, .tue, etc. that might contain some helpful info if it's truly a server problem.

More things to consider; are you PDC and BDC both acting as DHCP servers, or only one of them? If both, do their DHCP scopes overlap? Overlapping scopes, even with one disabled, can sometimes cause conflicts. Anything specific to the failing clients, like network segment? Is the system time vastly different on the server vs. the clients?

This question was closed by the author