none
DHCP server eventID 1059 RRS feed

  • Question

  • 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?

    Friday, October 22, 2010 11:27 AM

Answers

  • 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.
    Monday, November 1, 2010 1:22 PM

All replies

  • 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.
    Friday, October 22, 2010 12:24 PM
  • 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.
    Monday, October 25, 2010 3:19 AM
  • 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.

     

    Monday, October 25, 2010 12:41 PM
  • 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?

    Tuesday, October 26, 2010 4:39 AM
  • 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

    • Edited by David.Mathis Tuesday, October 26, 2010 12:38 PM typo
    Tuesday, October 26, 2010 12:37 PM
  • Removed and reinstalled DHCP server. Problem is still there though. Doesnt seemed to be affecting the system. Anything else i can do to troubleshoot?
    Thursday, October 28, 2010 4:33 AM
  • after you removed the DHCP role, did you leave the domain, and rejoin the domain?
    Thursday, October 28, 2010 12:08 PM
  • 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? 
    Friday, October 29, 2010 5:32 AM
  • 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.

     

    Friday, October 29, 2010 12:29 PM
  • 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.
    Saturday, October 30, 2010 4:24 AM
  • 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

    • Edited by David.Mathis Monday, November 1, 2010 12:39 PM typo
    Monday, November 1, 2010 12:39 PM
  • 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.
    Monday, November 1, 2010 1:22 PM