• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 508
  • Last Modified:

Icons in Microsoft DHCP are not reflecting dynamic DNS registrations

We are eliminating a domain controller in our Maine office to reduce costs. Currently the DC in Maine is running DHCP and in an effort to keep DHCP local to the office, we have installed DHCP on a plain, old Windows 2003 server that will remain in the Maine office and we have deactivated the scope on the Maine DC.

Note that the domain controller in our Maine office is also runniing DNS and the DNS zone where dynamic DNS registrations occur is located on this DC and the forward and reverse zones are defned as active directory integrated zones as all of our DHCP clients in 12 states register in the same zone.  As soon as we remove the domain controller from the Maine office the site definitions for this office will become part of the site defined in our Connecticut office.  Note that the Connecticut DC is also running DNS and it too contains the same AD integrated zones found on the current Maine DC.  Once the Maine DC goes away, the dynamic DNS registrations will need to be made through the Connecticut DC or another DC somewhere in another office.

To complicate things a bit more, we also decided that we would also install DNS on the same plain, old Windows 2003 server that will remain in the Maine office.  The idea was to keep DNS queries local to the office by creating secondary copies of all zones located on the Connecticut office domain controller.

After we installed DNS on the plain, old Windows 2003 server with secondary zones we installed DHCP on that same server and we activated the scope while at the same time deactivating the same scope on the DC.  When a client registers itself with DHCP on the plain, old Windows 2003 server we have DHCP setup to automatically perform DNS dynamic registrations on behalf of the cleint and since the DC in the Maine office is still active, we expected there wouldn't be any problems with the clients registering in DNS on the domain controller until we removed the DC and moved the site.

Our problem is this.......

If we clear out the forward and reverse lookup zones for a workstation in the Maine office and renew the workstation's lease via an IPCONFIG command, we note that the DNS registrations are being made and zones on the domain controller are being dynamically updated.  IN DHCP, however, the little client icon next to the address indicates that the DNS registration was not successful and the logs for DHCP also show that the registration was not successful.  Since we can obviously see that the dynamic DNS registrations ARE being made we are trying to determine why DHCP shows that the registrations are not being made.  Does anyone know how we can make DHCP understand that  the DNS registrations are being made successfully?

My guess is that it has something to do with DNS and DHCP being on the same Windows 2003 server and the zone in DNS are only secondary copies.  What we are looking for is some way for DHCP to understand that it needs to confirm the dynamic DNS regisrations are taking place on a different DNS server.

Any help in resolving this would be greatly appreciated.
1 Solution
If I am reading this correctly it sounds like you have your AD-integrated DNS zones set to accept only secure updates.  The workstation is creating its own A and PTR records and then the DHCP server doesn't have permission to modify those records.  There are a few potential solutions.

A. Uncheck the "Register this connection's addresses in DNS" box under the DNS tab of TCP/IP Properties on each of the Maine workstations.  The DHCP server should then be the only one registering records for the workstations.

B. Add the DHCP server to the DnsUpdateProxy security group.  This will allow it to overwrite existing records.  This is slightly less desirable from a security standpoint.

C. Change the dynamic updates setting on the AD-integrated DNS zones from "Only secure updates" to "Yes".  This is the least-desirable choice security-wise, but should prevent the errors.
wchullAuthor Commented:
1.  The zone is already set to accept unsecured dynamic updates.
2.  The DHCP servers are in the DNSUpdateProxy security group in Active Directory.
3.  A logonID and PSWD has been setup on the advance tab on the DHCP server for the DHCP server to use when making dynamic updates to DNS

Note that dynamic updates ARE being made to the domain controller running the AD integrated DNS zone.  If we clear out the old forward and reverse records for a Windows XP worksation and then renew the lease we can see forward and reverse records reappear in DNS.  The problem is that even though DNS is being updated, DHCP thinks that it isn't happening.
I think you're going to find that DHCP is not Authorized in this site.  Is this server a member server?  If so, you should be able to Authorize it.  If it's standalone, I'm not sure you can.

Try unchecking the boxes on the properties of the DHCP server in DHCP management that register on behalf of the client.

Cloud Class® Course: Microsoft Office 2010

This course will introduce you to the interfaces and features of Microsoft Office 2010 Word, Excel, PowerPoint, Outlook, and Access. You will learn about the features that are shared between all products in the Office suite, as well as the new features that are product specific.

wchullAuthor Commented:
The server is a member server in the domain and the member server is authorized for DHCP.  I have confirmed this as the server name appears on the list of authorized DHCP servers that you can add to the DHCP snap-in.

Why would I want ot uncheck all the properties of the DHCP server in DHCP management that rigisters on behalf of the client.  We perfer that DHCP haldle the registration on behalf of the client.
The put the member server in the DNSUpdateProxy group in AD.  This was mentioned previously.

wchullAuthor Commented:
As previously noted in one of my threads, the member server name is already in the DNSUpdateProxy group in AD.
wchullAuthor Commented:
I had this question re-opened so I could post the solution to the problem just in case someone else experiences this problem.

The problem was that we had moved DHCP off some of our domain controllers onto member servers in some of our offices.  When we did that we noticed that the ICONs in DHCP on the member servers were showing the "PEN" or pending icon instead of the regular icon for all DHCP clients in all scopes serviced by the member servers.  The PEN icon indicated that a lease was granted but the DNS registration was incomplete.  We thought that this was quite odd as we had DHCP set to always register on behalf of the client and we could verify that the DNS records were being created on the domain controller where the AD integreated forward and reverse zones existed.  
Note that there were many things we verified such as having a valid user account and password with sufficiant update credentials defined on the DHCP advanced tab and that we had the server names in the DNSUPDATEPROXY group but yet nothing seemed to fix the issue.
After opening a ticket with Microsoft the problem came down to a group policy issue.  Dispite the fact that we had everything else correctly, there is a group policy that was enabled in the following hive that was active and was set for Secure Only:
GPO - Computer - Default Server
    Computer Configuration
        Administrative Templates
                DNS Client
                    Update Security Level
If I undersand this correctly the GP that was set to "Secure Only" was causing the DHCP server to send a secured request to DNS to register the Client workstation but the setting of "Unsecured and then Secured" in DNS was causing an Unsecured reply to be retuned to DHCP.  DNS was accepting the request and was registering the PTR record but since DHCP sent a secured request it expected to get a secured reply back but got an unsecured reply back instead.  From a DHCP point of view, until it received a secure reply back it was going to show a "PEN" or pending icon in DHCP but from DNS's point of view it didn't need to send anything more through as it had properly registered the PTR record.   This is why when we changed the DNS zone to Secured Only"  it accepted a secured request and replied with a secured reply making DHCP happy.  This is also why when we changed the group polcy to Unsecured and then Secured DHCP is now sending an unsecured request and DNS is responding with a unsecured reply, again making DHCP happy.  I'm also assuming that if we changed the DNS zone to Secure only it would still work as the DHCP server would attempt to send a unsecured reqeust that would be rejected and would then resend the request as secured and DNS would accept the second one and reply accordingly.

Just thought that some of you might be interested in the solution.
Thanks for sharing this.  I wonder why the GPO was set in the first place?
wchullAuthor Commented:

You raise an interesting question as to why the GPO was set in the first place.  I don't know if it, by default is enabled, or whether someone enabled it for some reason.  Since all of our server IP's are statically defined and manually added to DNS there shouldn't have been a reason for setting it otherwise.  Note also that in the 4 years we have been running Microsoft DNS and DHCP it was never an issue until we moved these functions off the domain controllers onto member servers.  Evidently, the communication between DNS and DHCP was internal to the domain controller but after the switch we now have to send packets between the member server and the DC and we never thought that there might be a GPO in play.  
It's not a default setting - that's certain.  It had to have been defined purposely.

Regardless, you are correct in your assumption that once off the DCs the member installation of DHCP needs to communicate across the wire to the DNS/DC and therefore is governed by a slightly different set of rules than if it was co-located.

Question closed.

Site Admin
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Cloud Class® Course: Python 3 Fundamentals

This course will teach participants about installing and configuring Python, syntax, importing, statements, types, strings, booleans, files, lists, tuples, comprehensions, functions, and classes.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now