DHCP server eventID 1059
Hello,
I've never experience this problem before with the DHCP server, where it says that
EventID 1059: The DHCP service failed to see a directory server for authorization.
I tried pinging the server and it returned
Reply from ::1: time<1ms
I also tried nslookup and it returned
DNS request timed out. Time out was 2 seconds. Default server : UnKnown. Address: 192.168.0.10
I ran dcdiag and it said
Doing initial required tests
Testing server: Default-First-Site-Name\SERVER
Starting test: Connectivity
The host 0278e2ef-7fbb-44c5-8145-fb5ee5a6fe6f._msdcs.impiana.local could not be resolved to an IP address.
Check the DNS server, DHCP, server name, etc.
Got error while checking LDAP and RPC connectivity. Please check your firewall settings.
......................... SERVER failed test Connectivity
Doing primary tests
Testing server: Default-First-Site-Name\SERVER
Skipping all tests, because server SERVER is not responding to directory service requests.
Any ideas on how to fix this problem?
October 22nd, 2010 7:30am
Please try to ping impiana.local and see what the results are; it sounds like you're missing a DNS record. Also verify that you can connect to tcp/389 of your AD server remotely.
Free Windows Admin Tool Kit Click here and download it now
October 22nd, 2010 8:26am
pinged impiana.local and it replied correctly. pinging server.impiana.local (FQDN) does not return the correct results. how do i verify the tcp/389? by the way i've just ran dcdiag and everything passed. however the error is still there.
October 24th, 2010 11:22pm
to verify connectivity to tcp/389 you could try to telnet.
ex. "telnet servername 389"
Try verifying there is a DNS A record for server.impiana.local, if not create one. Also You can see if you're firewall is blocking the ICMP requests. For a quick check, just turn the firewall off and see if your pings go through. If so, turn the firewall
back on and edit the rules to allow incoming for ICMP for IPv4.
Free Windows Admin Tool Kit Click here and download it now
October 25th, 2010 8:43am
I'm a little confused by your results... Ok, lets just do this the easy way. I'm assuming on the (2) servers you have their roles confined to only what they are serving, (1) DCHP, and (1) AD. If other servers/clients are using the AD server just fine, then
your issue should be strictly relative to the DHCP server. Try the following:
1. Remove the DHCP Server role from the DHCP server.
2. Remove domain membership from the DHCP server.
3. Join the domain from the DHCP server.
3a. Verify domain connectivity from DHCP server. (Log on as domain account, ping domain-name, ping AD server).
4. Install the DHCP server and configure your scopes, exceptions, etc.
5. Authorize and Activate your DHCP server
October 26th, 2010 4:26pm
Tried windows server 2008 R2 internal telnet client nothing comes out after typing in "telnet server.impiana.local 389" but connection was successful for an external telnet client.
There is a DNS A record with the correct IP add for the domain. Turned off firewall and tried pinging; same result. So does this mean that the TCP/389 is closed and I have to adjust it? And how do i do that?
Free Windows Admin Tool Kit Click here and download it now
October 26th, 2010 4:35pm
Removed and reinstalled DHCP server. Problem is still there though. Doesnt seemed to be affecting the system. Anything else i can do to troubleshoot?
October 28th, 2010 12:38am
after you removed the DHCP role, did you leave the domain, and rejoin the domain?
Free Windows Admin Tool Kit Click here and download it now
October 28th, 2010 8:12am
The DHCP service is actually installed in a DC so how should i leave the domain and rejoin the domain? do i have to remove the Active Directory service and reinstall the service?
October 29th, 2010 1:35am
Well therin lies a problem. You can't, at least not with out demoting it to a member server. What kind of errors are we seeing when you try to authorize this DHCP server? Both in the MMC and the Event logs.
Free Windows Admin Tool Kit Click here and download it now
October 29th, 2010 8:33am
it authorizes the server just fine. no errors or whatsoever in the event logs or the mmc. Funny thing is it has no effect on the client computers. All the computers run just fine, although the error comes out whenever the server is booted. And the same
error comes out only twice everyday after the booting up of the server. The error never occur more than 2 times in a day.
October 30th, 2010 12:27am
Well I'm still convinced you have some form of a networking issue going on. My advice would be try and recognize a pattern to when the errors occur, is DNS service restarting, or some other unusual activity.
Please check out the following TechNet article in order to assist with what procedures you could use to troubleshoot:
http://technet.microsoft.com/en-us/library/cc774849(WS.10).aspx
Free Windows Admin Tool Kit Click here and download it now
November 1st, 2010 8:44am
Tried windows server 2008 R2 internal telnet client nothing comes out after typing in "telnet server.impiana.local 389" but connection was successful for an external telnet client.
There is a DNS A record with the correct IP add for the domain. Turned off firewall and tried pinging; same result. So does this mean that the TCP/389 is closed and I have to adjust it? And how do i do that?
Windows Firewall with Advanced Security - Getting Started Guide
http://technet.microsoft.com/en-us/library/cc748991(WS.10).aspx
Basically... to allow TCP/389, verify that your GPOs are configured correctly to use Kerberos properly. It could be as simple as a kerberos issue. Also, configure your DHCP Service to start as Delayed. It could be trying to jump the gun ahead of
other services. Without those other services initializing first, they may interfere with DHCP. I don't believe DHCP will retry, once it's told no, it will sit there and sulk about its problems. So setting it to delayed, would help benefit the start process
for that server.
Additionally, every standard license of Server 2008 allots One Free Additional Guest OS. If you remove DHCP from that server and use Hyper-V on that server run "Server Standard - Core installation" for DHCP services on a stand-alone instance,
you would eliminate these issues all together. (Two reboots per day on a server? Why? Servers are meant to run... ) Remember the basic Server Core commands... It's minimal resources... on a server with ADDS, unless you have over 5000 people authenticating
with that single domain controller, its resources aren't going to be impeded with a virtual guest running DHCP via Hyper-V
Netdom join %computername% /domain:example.local /userd:example\Charlie /passwordd:*
shutdown -r
Netdom renamecomputer %computername% /newname:ServerName#
netsh advfirewall firewall set rule group="Remote Administration" new enable=yes
sconfig
%computername% is just easier then retyping the entire default computername out. Then just use Server Manager on any server to manage or install the RSAT on any Windows 7/Vista client.
As far as testing ports, Telnet isn't installed by default, and it should be kept that way because Telnet really isn't necessary for this.
Microsoft developed a tool called Portqry, it just didn't make the cut before product release. Allegedly supported back to Server 2000. Portqry is designed as a port connectivity testing tool.
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=89811747-c74b-4638-a2d5-ac828bdc6983&displaylang=en
Steve Kline
Microsoft Certified IT Professional: Server Administrator
Microsoft Certified Product Specialist
Microsoft Certified Network Product Specialist
This posting is "as is" without warranties and confers no rights.
November 1st, 2010 9:27am