Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Shaun E on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

DCHP Startup in Morning

Status
Not open for further replies.
Jan 14, 2005
5
CA
Hi, I was wondering if anyone could help me. Each and every morning, when I login to Windows, it appears I get the infamous 169.254.x.x address, in other words, my DHCP request doesn't get answered in time. Is there something that has built up any any sort of queue that I am unaware of that bogs down the server to deliver the lease for the IP. Any help would be appreciated. Only happens in the morning when as a user I login.
 
I am assuming you turn off your machine at night and turning it on in the morning? Do you receive an address once you perform IPCONFIG /RELEASE and /RENEW?.
 
What do you do after reeiveing the 169.254.x.x, do you restart the PC or request a new IP. Just to be sure, if you can, connect another computer to that data port and chack if the same happens. Also, try to check out the status of the data cable and port; and for last, try changing your network card.

My advice is to connect another PC or laptop first.
 
All good stuff, don't forget about "ipconfig /fluchdns" "ipconfig /registerdns" cmd's to re-set dns info as this is held in cache memory. There is a method for increasing the ttl for ack packet requesting the lease.Curious to know your resolution, me I've done release & renew, reset my router, and rebooted and have not seen this since.

Paul
 
How long has this been going on? Does this happen to anybody else? I had a similar issue with this laptop, because my provider wouldn't help me set this up. I finally made a batch file which did what the others have suggested. Batch file was simple.
Ipconfig /release
Ipconfig /renew
Pause
Named it ip.bat. I threw the pause in so I could see if it was succesful. Let us know some more details. Thanks.

Click here to learn How to help with tsunami relief... Glen A. Johnson
If you're from Northern Illinois/Southern Wisconsin feel free to join the Tek-Tips in Chicago, Illinois Forum.
Don't forget to shop @ theTek-Tips Store
 
I see that I'm not the only one having these types of problems. Thanks for some of the suggestions. It is laptop users that are having these problems and its beginning to happen to a lot of users.
ipconfig /release
ipconfig /renew
This does indeed solve the problem after the computer first starts up, but I have many users that are on laptops and no login scripts to create or go around to all the users and create batch files to allieviate the problem. I need to get to the core of the problem. I can't remember this happening when my DHCP server was on an NT box, but now its on a 2003 Server.

Could this have something to do with it? I'd like to narrow it down. The network seems to be running fine. I really think there is something else going on with the server itself.
 
You need to tell us more about your setup. How many servers? This only happening to laptops? Do the laptops go home at night or stay plugged in? Is there anything these laptops have in common? What does ipconfig /all show on one of the problem machines? Thanks and good luck.

Click here to learn How to help with tsunami relief... Glen A. Johnson
If you're from Northern Illinois/Southern Wisconsin feel free to join the Tek-Tips in Chicago, Illinois Forum.
"A child of five would understand this. Send someone to fetch a child of five."
Groucho Marx
 
I remember seeing something similar a few years back at a company were I was then working. Laptops where running NT4 and DNS/DHCP were provided by Solaris boxes though, so your issue may be unrelated.

But here is what I can remember from it :

Only laptops were affected, and only when users were just returning from visiting a remote office, where they had connected their laptop to the local network.

I can only vaguely remember that the issue seemed to be related to 'sticky' dynamic DNS host name registration. I can't exactly tell you why now.
It would appear that on returning, the remote office's domain name appeared kinda 'stuck' inside the local configuration, so the machines would appear unable to bind to the local DHCP/DNS servers, or were simply not accepting local DHCP offers.
This may sound odd, but manually correcting the machine's domain name back to the local domain and rebooting was enough to solve the problem.

Unfortunately, because of poor communication with Unix and remote sites administrators and too little time available, we were never actually able to investigate the problem down it true cause(s).
We instead concentrated of solving the problem for the users affected.

Manually releasing/renewing the address was also enough to solve the problem, though the machines' own startup DHCP requests were not. But you had to have admin rights to do this, so I ended up renewing the address using a batch file that ran at startup via the AUTOEXNT service, specifically installed for that purpose (from the MS Resource kit).

Also, you might want to look into possible issues related to switching off vs. hibernating the laptops.

IMPORTANT NOTE : Because the AUTOEXNT service runs as system, you have to properly protect the batch file so only admins can make changes to it. Otherwise you would be creating a serious potential security issue.
Of course, desktops not travelling nearly as often were never affected. ;+D

Hope this helps.

 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top