Hello,

I am trying to understand how DHCP Server authorization works in AD. Here is what occurred:

1. DHCP Server is in SITE A and DHCP server is a DNS Server and points to itself.

2. DC is in SITE A.

3. DC is rebooted which takes about 10 minutes.

4. DHCP Server as a member of domain, requests authorization (which is by default: 60 minutes).

5. The DC is still down and the DHCP Server is unable to get authorization and writes the even log entry: Source: DHCPServer, event id 1046 which is understandable.

My question in trying to understand this, is why did the DHCP Server not try to request authorization from another DC at another site? Since the DC is down at the site only, there are other DCs at other remote sites. We only have one DC at this site.

Any help would be appreciated.

check out this links:

http://technet.microsoft.com/en-us/library/cc781697(v=ws.10).aspx

http://computernetworkingnotes.com/70-291-study-guide/how-to-authorize-dhcp-server.html

Thank you for the reply, but I do understand the authorization process, I am trying to find out why the DHCP Server did not attempt to get authorization from another DC at another site. Instead, it attempted to contact the DC at its site which failed and then did not make any other attempts until the DC came back up after the reboot.

Hi,

May be this can help a bit

Unauthorized Domain Member DHCP Servers

A domain member DHCP server queries Active Directory. The DHCP server compares its IP address and server name to the list of authorized DHCP servers. If either the server name or IP address is found on the list of authorized DHCP servers, the server is authorized as a DHCP server. If no match is found, the server is not authorized in Active Directory, the server does not respond to DHCP traffic, and a system event is logged.

http://technet.microsoft.com/en-us/library/cc780760(v=ws.10).aspx

Hope that helps :)

Thank you for your help.

However, please understand the DHCP Server is authorized in Active Directory, the problem is that the DHCP Server and DC are in the same AD SITE. The DC in the site is down from a reboot, the DHCP Server during its hourly authorization request sees that the DC is down. As a result, the DHCP Server is unable to get its authorization.

My question is, why did the DHCP Server NOT attempt to contact another DC for authorization in another SITE if the DC in the same site is down.

Thank you for your help.

However, please understand the DHCP Server is authorized in Active Directory, the problem is that the DHCP Server and DC are in the same AD SITE. The DC in the site is down from a reboot, the DHCP Server during its hourly authorization request sees that the DC is down. As a result, the DHCP Server is unable to get its authorization.

My question is, why did the DHCP Server NOT attempt to contact another DC for authorization in another SITE if the DC in the same site is down.

It should try its own AD site first, then if no DCs are available, it should look elsewhere. But there's another thing that you MUST take into account - if a DC goes down, then it acts like any other machine when it logs on and it will "lock" on to that server. You can check on any machine, DC, member server or workstation, to see what DC logged it on by running echo %logonserver%

A lot of this has to do with the client resolver service, too. If the AD client side extensions have bound to a DC, then it will not send a GetDcList query to look for another and will wait until the client side resolve cache times out for the records. Apparently your DC taking that long to boot, is probably still under the timeout of 15 minutes, assuming you didn't change TTLs on the records.

So in essence, I see your member server doing exactly what it should be doing. Now if you restart it while the DC is down, then it will find a DC in another site. You can test that with the above command.

More info on the way this works:

This blog discusses:
WINS NetBIOS, Browser Service, Disabling NetBIOS, & Direct Hosted SMB (DirectSMB). Troubleshooting the browser service.
Client side resolution process chart.
The DNS Client Side Resolver algorithm.
If one DC or DNS goes down, does a client logon to another DC or use the other DNS server in the NIC?
DNS Forwarders Algorithm and multiple DNS addresses (if you've configured more than one forwarders or more than one IP in the NIC's DNS list)
Client side resolution process chart
Published by Ace Fekay, MCT, MVP DS on Nov 29, 2009 at 10:28 PM  1764  1
http://msmvps.com/blogs/acefekay/archive/2009/11/29/dns-wins-netbios-amp-the-client-side-resolver-browser-service-disabling-netbios-direct-hosted-smb-directsmb-if-one-dc-is-down-does-a-client-logon-to-another-dc-and-dns-forwarders-algorithm.aspx

DNS Clients and Timeouts (Part 1 & Part 2), karammasri [MSFT] Dec 2011 6:18 AM
http://blogs.technet.com/b/stdqry/archive/2011/12/02/dns-clients-and-timeouts-part-1.aspx
http://blogs.technet.com/b/stdqry/archive/2011/12/15/dns-clients-and-timeouts-part-2.aspx

-

FYI, regarding DC DNS NIC settings, if you have one DC in each site, I would point the first entry to itself, and the second to the other guy. Usually if there are two DCS in one site, DNS1 would be the other guy, and DNS2 would be itself or the Loopback. This is the accepted method now after all of the debates and arguments on how to set it up since AD's inception in 1998. Matter of fact, if you have 2008 or newer, the AD BPA looks for this configuration.

I am concerned that it takes your DC 10 minutes to come back up. I thought to post some additional info below that you may find useful to make sure your AD infrastructure is sound, properly configured and running:

Please check all Event log errors (Application, System, and under Application and Services Logs on a DC for the AD Web services, DFS Replication, Directory Services, DNS Server & File Replication Server logs. Copy and paste the Event ID errors, please.

If any of the DCs multihomed (more than one NIC, IP, iSCSI interface, backup interface, and/or RRAS installed on them)? If yes, multihomed DCs can cause AD site issues, among numerous other issues.

-

You can check AD replication and communication status with the following:

1. ReplDIAG:  (run it as repldiag > c:\repldiag.txt, then open it as a CSV in Excel choosing comma separated, to be able to clearly read the output)
   Explained here:
     Troubleshooting replication with ReplDiag.exe [part 1 of 4], Rob Bolbotowski [MSFT], 13 Oct 2010 12:04 PM
     http://blogs.technet.com/b/robertbo/archive/2010/10/13/troubleshooting-replication-with-repldiag-exe-part-1-of-4.aspx
        replDiag Downloadable from:
        http://activedirectoryutils.codeplex.com/releases/view/13664

2. Download The Active Directory Replication Status Tool:
   http://www.microsoft.com/en-us/download/details.aspx?id=30005
     This tool requires .Net Framework 4. If it's not installed, download and install it:
       Microsoft .NET Framework 4 (Web Installer)
       http://www.microsoft.com/en-us/download/details.aspx?id=17851

3. Third Party Utility: Dynamic AD Replication Checker Tool not only checks AD Replication for all domain controllers in your organization but also provides monitoring capabilities. For any non-working Domain Controller you can use the various options available to troubleshoot the issue.
 Dynamic AD Replication Checker Tool Version 2.0 Released
 http://blog.dynamicitkit.com/dynamic-ad-replication-checker-tool-version-2-0-released/
 Download Dynamic AD Replication Checker Tool Version 2.0 (part of "Dynamic Pack")
 http://www.dynamic-spotaction.com/index.html

-

If there are any replication issues, let's determine if there are any ports being blocked by making sure the antivirus on each DC has exclusions properly configured for what a DC needs. For example, SEP automatically excludes everything when it is installed on a DC, but not if it was installed prior to promotion. They have a step by step with 14 different things to configure including registry entries. I find it easier uninstalling it and reinstalling it. Other AVs have their own methods - check with the vendor site.

You can also check firewall ports being blocked between DCs using PortQry:

Run PortQry GUI choosing the "Domains & Trusts" option between each other (DCs). Run the test from a DC to a DC from both sides to each other, or you can also run it from a client to a DC. Post only errors with "NOTLISTENING, 0x00000001, and 0x00000002.
       PortQryUI - GUI - Version 2.0 8/2/2004
       http://www.microsoft.com/download/en/details.aspx?id=24009

Thank you for your help.

However, please understand the DHCP Server is authorized in Active Directory, the problem is that the DHCP Server and DC are in the same AD SITE. The DC in the site is down from a reboot, the DHCP Server during its hourly authorization request sees that the DC is down. As a result, the DHCP Server is unable to get its authorization.

My question is, why did the DHCP Server NOT attempt to contact another DC for authorization in another SITE if the DC in the same site is down.

I'm not sure why this was marked as an Answer when it was clearly a question?

Can someone explain that, please?

Thank you. 

Hi,

According to your issue, we did a test.

The DHCP server in the site A will only query a DC in the same site for authorization. If the only DC in the site is down, the DHCP server's authorization will fail and it will try to contact the DC in the site A again. Almost about 10 times later, you will receive an error message.

I hope this helps!

Hi,

According to your issue, we did a test.

The DHCP server in the site A will only query a DC in the same site for authorization. If the only DC in the site is down, the DHCP server's authorization will fail and it will try to contact the DC in the site A again. Almost about 10 times later, you will receive an error message.

I hope this helps!

Hi Susie. Interesting results. I would have assumed it would authenticate to a DC outside its Site.

Is there any documentation on this at Microsoft's Site?

Hi Ace,

I am afraid I have not found any document talking about this particular behavior yet. The information I provided was based on a test in the lab environment as follows: 

Site A:

Server 1: Domain Controller
Server 2: DNS server, DHCP server (on the same server) 

Site B:

Server 3: Domain Controller

Site A and Site B are in the same domain. In addition, both Domain Controllers are pointed to the DNS server in site A.

Then I turned down the DC (Server 1) in Site A, manually initiated the DHCP authorization and used Netmon.exe to capture packets on the DHCP server (Server 2), and I found the behavior.

Best regards,

Susie Long