I recently setup a new SBS 2003 server for a customer. Everything worked fine for several months but suddenly the network clients (all set to use dhcp) could no longer retrieve an IP address from the SBS DHCP server - they just do not get a response. It is a very standard DHCP configuration, nothing out of the ordinary.I have tryed everything i can think of (several times) but cannot get the server to issue addresses any more. I have tried: rebooting the server, restarting the dhcp server service; de-authorizing the scope (and re-authorizing), deleting the scope and recreating it but nothing seems to work. I have also tried (several times) ipconfig /release then ipconfig /renew as well as the local area connection repair option. This is the only dhcp server on the network, there is a router but the dhcp server part of it is turned off. I have manually given all pc's a static address which is working but would like to fix the issue. There are no event log entries relating to DHCP.If anyone can give advice on this problem i would greatly appreciate it.Many thanks,Paul Hollings.

Paul, I'm a bit confused as to why you keep using SMTP and DHCP interchangeably. They are not the same technology. It sounds like you are having a DHCP problem, not an SMTP problem. (Small Business Server handles many different functions). First, have you tried rebooting the SBS server? Maybe it is just a stuck service. Second, what IP addresses do you clients have? Are they 169.254.x.y addresses? Jim

Jim,Thabks for your reply.Please accept my apologies re the SMTP & DHCP confusion. The question should only have mentioned DHCP (i must have had SMTP on the brain at the time of posting). I amended the question.They should have 192.168.17.? addresses as per the scope but before i gave them physical addresses i do believe they were 169.254.?.?I have tried so many things i am seriously thinking about re-installing the DHCP windows component from the CD.Cheers,Paul.

Don't worry about SMTP on the brain. I'm an Exchange nerd. I *always* have SMTP on the brain. Anytime you see an IP that starts with 16.254.x.y, that means the workstation tried to get an IP and failed so it resorted to generating an IP in that range. When you look in the DHCP console, is there an error or a red X or something on the DHCP server? I don't remember exactly what it is supposed to look like, but I'm pretty sure it is obvious that there is something wrong with the DHCP server or that it is not authorized. Has the IP of your server changed recently? Is the server on the same IP subnet as the rest of your clients?

Jim,No the DHCP console looks absolutly fine. I am used to SBS and tried many obvious things (see my original post). I am sorry to say i dont think this is a standard config error. The DHCP had been renewing fine for a couple of months after the original install then suddenly stopped (dont you just LOVE computers) without showing any form of error on the server.One thing you may have hit on in your last question. When the server was setup and the OS installed it had an IP scheme of 192.168.1.? when delivered to site it had to be changed to 192.168.17.? (due to building network setup). This did mean the DHCP server details had to be changed, they were and all client PC's renewed their DHCP lease on the new scheme correctly.I do wonder what is the easiest way (if one exists) to completly reset the DHCP server setting back to pre-setup. I just think it's confused!!Cheers,Paul.

If your server is on the 192.18.17.0 / 255.255.255.0 subnet, make sure that the DHCP scope is set for 192.18.17.0 subnet also. If not, delete the DHCP scope and recreate it. Just make sure you document all of the scope options first.

I am having the EXACT same problem, and it just started today! Still haven't figured it out...

A temporary fix is to configure the clients for static IPs...The computers that had already received DHCP assignments are all still working, even if i repair them. But once their lease runs out, they cannot renew.

Jim,The DHCP scope and all server settings have been set correctly for 192.168.17.0 / 255.255.255.0.Like i said, it had been working, suddenly stopped working without errors, now wont respond to client requests even after the scope has been deleted and recreated and everything looks perfect on the server. I dont get it!?!?!?!?Any further ideas??Cheers,Paul.

wrness,Good problem eh? NOT!I have already assigned static addresses so at least the network works while we can hopefully come up with some kind of fix.I discovered the problem following a lease expiring which would then not renew. When i tried other clients that already had a DHCP assigned address they would not renew either. I tried the network properties repair button and good old ipconfig several times but with no success. I then started on the server and ended up deleting the scope and recereating it. But still no success.How is your problem doing?Cheers,Paul.

We haven't figured it out yet...

Fixed the issue -- turns out that some changes were made to our ISA firewall config (magically!) that were causing the requests and replies to be denied. if you want more info, let me know.

Thanks for the update and glad you have fixed your problem. The sad news for me though is I don't have ISA server installed, but it does prompt me to have a look at the firewall configuration.I will check it out.Many thanks.

Can you ping your DHCP server? What happens if you try to make a MAC add reservation?

It sounds like it's time to roll up your sleves and start doing some network packet inspection. You should installed the Network Monitor on your server if you haven't already (it's under Add/Remove components in one of the sub-menus). You can also use Ethereal if you don't want to use the native MSFT tool. Once you have a tool installed installed, you can use to it capture all the packets going in and out of the server. You should see DHCP broadcast packets going into the server, and hopefully it responds to the machines with DHCP lease information. Here is a packet walk through I found in a quick search: http://www.eng.tau.ac.il/~netlab/resources/booklet/Ethereal_DHCP.pdf If you scroll down, then you can see the network activity with a DHCP Discover (the client looking for a DHCP server), and the DHCP server repsonding with a DHCP offer. If you don't see the packet coming into the server, then for some reason the broadcast packet from the client (hopefully on the same subnet as the DHCP server, otherwise you need a DHCP relay/helper) isn't making it to the server. If you see the packed comign into the server, but no response from the server, then there is something wrong with the DHCP service. Either the scopes were configured wrong, or the service isn't running/authorized. If you see it respond, and the data it's handing the client (you can see some of it in the packet) looks correct, then you need to check to see if the packet is making it back to the client (you may have to install NetMon/Ethereal on the client to do this). In either case you need to validate that the packets are going where they need to. Like with the ISA server, ISA was blocking the inbound packets from getting to the DHCP service, so the DHCP service would have never responded. BTW why is a question about SBS and DHCP on the Exchange\Admin forum? Good Luck!

Hotfix,Many thanks for your detailed post. Sounds like great advice. I will do this when i am next on site. Re: why is a question about SBS and DHCP on the Exchange\Admin forum - Well, i had posted in another forum but no one even read my post never mind respond for several days so i tried somewhere else. I don't make many posts and i must admit, got a bit confused as to where the best place would have been. My apologies.Thanks again,Paul.

Jim McBee - Exchange MVP wrote: Don't worry about SMTP on the brain. I'm an Exchange nerd. I *always* have SMTP on the brain. Anytime you see an IP that starts with 16.254.x.y, that means the workstation tried to get an IP and failed so it resorted to generating an IP in that range. When you look in the DHCP console, is there an error or a red X or something on the DHCP server? I don't remember exactly what it is supposed to look like, but I'm pretty sure it is obvious that there is something wrong with the DHCP server or that it is not authorized. Has the IP of your server changed recently? Is the server on the same IP subnet as the rest of your clients? Hi Jim,I have the same issue here. But I did change the NIC address in the server. I first assigned the ip to 192.168.x.x network and I change it to 10.x.x.x subnet because of the network requirement. Followed by the change of ip address, I also added the new subnet to AD sites and services, change DNS and change DHCP scope. After all the changes, DHPC worked fine for 1 day, and the next day, client could not get ip address from the server. I have done same thing as Paul did but it just did not work.At the moment, I setup a dhcp server on cisco router and all the client could pick up ip address. Anyone can help?

Well if everything looks correct to you, the best recommendation I can make is to use a network packet sniffer to see where the breakdown is occuring. I.E. Is the DHCP server even getting the requests? If so is it responding and are those responses getting to the client? Otherwise all I can recommend is to do the standard check the event logs, make sure the DHCP server is authorized and running, etc... Oh and make sure you aren't using the Superscope setting in DHCP, this has caused issues with machines moving subnets in the past with DHCP.

I was looking for a solution over the weekend to this very problem, and almost everything I found on the subject ended like this thread... no solution and no ongoing conversation. I am recounting my process and solution so that others in the same boat may find it and be helped. A couple of months ago I rolled a second domain controller on a client's network and configured it to serve DNS and DHCP. Over some time I realized several things happened that are now easy to explain and yet mysterious at the time. Mainly, the DHCP server on the main SBS DC crashed after reboot and could not be made to run. There were network wide problems with browsing as well, with only a partial browse list available but not the same machines visible from view to view. DNS and filesharing were both OK, and server side applications worked fine. Since the second DC was handling DHCP OK and everyone was working, I left it alone until I had time to deal with it. Last week I had a little time, and I decided to work on the problems. Knowing now that SBS won't tolerate a second DHCP server on the network, I decided to re-enable the DHCP on it, hoping that might solidify other areas of function.I backed up the office scope and updated the DHCP server on the PDC(SBS) machine, shut down DHCP on the newer DC and started DHCP on our SBS server. I reregistered the server in AD so it could talk to DNS and it came up and said it was serving clients in the event logs. When I tested I found that clients sending DHCP discover packets timed out with no response from the server. Wireshark captures indicated that the discover packets were arriving at the server, but it did nothing to respond. Here is where I really started looking online for answers, and I found many threads that asked the same questions but came to no conclusions. After searching for a couple of hours for any answer, I was stumped. I found solutions related to no response to other packet types, but none mentioned DHCP failures. I had already checked hours before and knew that the Windows firewall was off, but I decided to look at the properties. When I tried, this is what I got. "Windows Firewall cannot run because another program or service is runningthat might use the network address translation component (Ipnat.sys)." Upon further examination I discovered that the SBS server did not respond to ICMP either, a common problem known to be related to ipnat.sys loading on demand. Curiously, this virtual device driver doesn't seem to have ever before been identified as causing the specific DHCP failure discussed herein. Anyway, going into Device Manager (Show hidden devices) and changing the setting on the address translator from "Demand" to "Disabled" fixed ICMP, network browsing and DHCP. Hope this helps someone else who is looking for an answer. I do not know what enabled ipnat.sys, but I suspect that things somehow changed when I installed SP2 or some other updates. DHCP on the SBS server was working fine before, so something changed during the time it was down. As always, YMMV.

I had the exact same problem, turned off the firewall and everything is working again. And I know that firewall was off previously.

bytegeek, thanks, worked perfectly!

I was looking for a solution over the weekend to this very problem, and almost everything I found on the subject ended like this thread... no solution and no ongoing conversation. I am recounting my process and solution so that others in the same boat may find it and be helped. A couple of months ago I rolled a second domain controller on a client's network and configured it to serve DNS and DHCP. Over some time I realized several things happened that are now easy to explain and yet mysterious at the time. Mainly, the DHCP server on the main SBS DC crashed after reboot and could not be made to run. There were network wide problems with browsing as well, with only a partial browse list available but not the same machines visible from view to view. DNS and filesharing were both OK, and server side applications worked fine. Since the second DC was handling DHCP OK and everyone was working, I left it alone until I had time to deal with it. Last week I had a little time, and I decided to work on the problems. Knowing now that SBS won't tolerate a second DHCP server on the network, I decided to re-enable the DHCP on it, hoping that might solidify other areas of function.I backed up the office scope and updated the DHCP server on the PDC(SBS) machine, shut down DHCP on the newer DC and started DHCP on our SBS server. I reregistered the server in AD so it could talk to DNS and it came up and said it was serving clients in the event logs. When I tested I found that clients sending DHCP discover packets timed out with no response from the server. Wireshark captures indicated that the discover packets were arriving at the server, but it did nothing to respond. Here is where I really started looking online for answers, and I found many threads that asked the same questions but came to no conclusions. After searching for a couple of hours for any answer, I was stumped. I found solutions related to no response to other packet types, but none mentioned DHCP failures. I had already checked hours before and knew that the Windows firewall was off, but I decided to look at the properties. When I tried, this is what I got. "Windows Firewall cannot run because another program or service is running that might use the network address translation component (Ipnat.sys)." Upon further examination I discovered that the SBS server did not respond to ICMP either, a common problem known to be related to ipnat.sys loading on demand. Curiously, this virtual device driver doesn't seem to have ever before been identified as causing the specific DHCP failure discussed herein. Anyway, going into Device Manager (Show hidden devices) and changing the setting on the address translator from "Demand" to "Disabled" fixed ICMP, network browsing and DHCP. Hope this helps someone else who is looking for an answer. I do not know what enabled ipnat.sys, but I suspect that things somehow changed when I installed SP2 or some other updates. DHCP on the SBS server was working fine before, so something changed during the time it was down. As always, YMMV. WOW! I spent 6 hours doing phone support with a client with this exact issue! So glad I found this easy fix! I was about 30 mins. short of wiping the hard drive and reinstalling SBS 2003 when I stumbled on this. Thank you so much, bytegeek!! Does anyone know what the ramifications are for disabling this though? I mean, will disabling it have a negative effect on other components? What services rely on this that I can expect a call about in a few weeks?