Link to home
Start Free TrialLog in
Avatar of Clarksville
Clarksville

asked on

Windows Event ID: 1053 DHCP Service keeps crashing

The error message I'm getting is:

Source: DhcpServer
EventID: 1053

The DHCP/BINL service on this Small Business Server has encountered another
server on this network with IP Address, 192.168.10.1, belonging to the
domain: .

This gets followed by:

The DHCP/BINL service on this computer is shutting down. See the previous
event log messages for reasons

I manually start DHCP Service.  This process repeats itself every few days.

Have Windows SBS 2003 running DHCP servicing 192.168.2.x only on HyperV, 1 vNIC.   I don't have a 192.168.10.x subnet anywhere.   Any thoughts about what might be causing this appreciated.   thanks, Russell
Avatar of Sushil Sonawane
Sushil Sonawane
Flag of India image

Make sure other active DHCP servers not available in network. Becuase in SBS environment only one dhcp server can work.

Reconfigure the Routing and Remote Access service. If Routing and Remote Access is set up incorrectly, it can act as a second DHCP server.

As the event mention your dhcp server conflict with the server on this network with IP Address, 192.168.10.1.

Make sure the ip address 192.168.10.1 server not act as dhcp server in network.

For more info please refer below link :

http://technet.microsoft.com/en-us/library/cc774845(v=ws.10).aspx
Are there any other devices on your network that could be acting as a DHCP server?  A wireless access point or a router for example.  Have you installed anything new on the network which ties in to when the problem started?

Other than it happening every few days are there any patterns to this behaviour?  Does it coincide with a particular person being in the office?  Could someone be bringing in a laptop or other device with some kind of Internet sharing software installed on it which is somehow acting as a DHCP server on your network?

When this happens it could be worth trying to get an IP address from this "rogue" DHCP server if that's what it is.  You'd need to do this on a client while the real DHCP server is off.  If you can get an IP address then you could try browsing to 192.168.10.1 to see what happens.  If you get a config page or at least an admin login then it might give you some clue as to what's going on.  If not then you could PING 192.168.10.1 from a client and then check your ARP cache (arp -a from a command prompt in Windows) to see if the MAC address ties into to any records you have (for example I use AVG on one network and the management console gives a nice list of MAC addresses for managed clients).  If that doesn't work then you could start systematically unplugging network cables (make notes of what you've done!) until you can't get an IP address any more.  Once this happens at least you have a better idea of where the offending device is plugged in even if you don't know what it is yet.

Although this link does relate to SBS 2008 it is for the same error code and mentions Routing and Remote Access as a possible cause.  This could be worth ruling out too.

Hope this helps.
Avatar of Clarksville
Clarksville

ASKER

Thanks for the fantasticly thoughtful troubleshooting ideas.   Unfortuneately, the problem is not being caused by another dhcp server since network clients receive no ip address when this dhcp service has crashed and in a stopped state.   I confirmed that Routing and Remote Access is not running on any servers too.   Thinking about running WireShark to see if any device on network is really claiming to be from source 192.168.10.1....
ASKER CERTIFIED SOLUTION
Avatar of Clarksville
Clarksville

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Wireshark packet capture ended up being necessary to isolate the networked device causing the problem.
So was the VOIP gateway acting as a DHCP server or was there some other compatibility issue between the VOIP gateway and your SBS server?  I notice from an early post that you say no other devices were handing out IP addresses, I'm just intrigued as to what you spotted in the Wireshark capture to identify the problem.