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

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics