Windows 2003 DHCP / Dynamic DNS / Scavenging help

I have inherited what seems to be a pretty poorly configured DHCP /
DNS infrastructure. We have a bad problem with duplicate PTR records
and old stale A records. I've been trying to get everything under
control.

Basically, I'm asking for two things .... a) DHCP isn't consistently
creating DNS with A or PTR records and I have no idea why, and b) to
make sure I'm setting everything up correctly.

We have 1 DHCP server with 3 DNS servers.
The DHCP server and 1 of the DNS servers are running on a 2003
Standard SP2 Domain Controller (the PDC Emulator).
The 2nd DNS server is also on a 2003 Standard SP2 DC (the
Infrastructure Master) which is also a main file server.
The 3rd DNS server is on a 2003 Enterprise SP1 Member Server and is
configured as a Secondary (and another heavily used file server).

The DNS zone I'm trying to fix is AD-Integrated with "Secure only"
dynamic updates. I have enabled Aging on the PDC server only but not
the zone yet. This is just for preparation before actively deleting
records per this article:
http://blogs.technet.com/networking/...e-patient.aspx

Option 81 in DHCP is, and always has been, configured like this:
* Enable DNS dynamic updates according to the settings below:
* Always dynamically update DNS A and PTR records
* Discard A and PTR when lease is deleted
* Dynamically update DNS A and PTR records for DHCP clients that do
not request updates.

We also have a very flat network with 118 DHCP scopes (one for every
voice and data VLAN amongst other things).

Previously, DHCP was not configured to use any credentials and only
the 3rd, secondary, DNS server was in the DnsUpdateProxy AD security
group. I'm almost certain that secure dynamic updates have always
been enabled. Aging has never been used or configured.

The steps that I have taken so fare are:
* Created a normal AD user to use for dynamic registration from the
DHCP server
* Removed the 3rd DNS server from the DnsUpdateProxy group (the group
is empty now)
* Enabled aging on the primary DNS server (not the zone)
* Enabled and configured option 015 (DNS Domain Name) on the DHCP
server

I have about 50 pages of printed (and heavily highlighted!) Technet
and blog articles on configuring and troubleshooting DHCP and DNS but
none of them seem to mention if any steps are necessary after
configuring the user for dynamic DNS updates. Do I need to do
anything on the DNS servers to give that user write access? For
testing purposes, I gave that user Full Control to the Forward and
Reverse zones but there didn't seem to be a(n easy) way to update the
security on the already existing records. I would assume that's
necessary but I'm used to NTFS permissions and DNS could be entirely
different. Also, I'm noticing that SYSTEM is the owner for all of the
DNS records, including new ones. Is this correct or should my new
user be the owner?

I haven't been able to narrow it down but I'm puzzled by the way DHCP
and DNS has been acting lately. I'm only getting A and PTR records
periodically for some PCs and not at all for others. The records I'm
not getting at all are wireless laptops that connect to a Cisco WLC
which then connects to a radius and certificate server. Yes, a
completely different set of servers to troubleshoot. However, some of
the wireless laptops are working just fine. It's just a certain batch
of them that are not working. Also, almost all of my DHCP leases have
a pen beside them indicating that they cannot update their DNS
records ... even the ones that _are_ creating records. To add to it,
some clients can create A and PTR records just fine where other ones
need "Use this connection's DNS suffic in DNS registration" enabled.
I've read in several blog posts where that setting is needed but I
have 3000 PCs on my network. Is a startup script to enable this
setting really a best-practice approach to this?

What do I need to do from here to get this all under control?
Are there any DHCP/DNS logs that would contain any useful
troubleshooting information?
Should I try to fix the problems on this server or would it be easier
to build a new server that's not on a DC and slowly let everything
migrate over? If so, would you recommend staying with Windows 2003 or
going with 2008?

I'll also admit that I'm a complete Windows DNS noob so please let me
know if I'm doing something wrong. If I left something our of it it
doesn't make sense please let me know. I've been working on this for a
while (when I'm not being called off for something else!) and I can't
seem to make any progress on it.

Thanks in advance for your help.

I hope my following blog doesn't confuse you, but I tried to put it together
so it's readable and helpful. I hope it helps.

DHCP, Dynamic DNS Updates, Scavenging, static entries & timestamps, and the
DnsProxyUpdate Group (How to remove duplicate DNS host records)
http://msmvps.com/blogs/acefekay/arc...ate-group.aspx

I actually had your article sitting on my
printer when I created this post...

I took another look at some recently created DNS records and they are,
in fact, owned by my new DHCP user. Is there a way to change the
ownership of all of my existing A and PTR records? Right now they are
either owned by SYSTEM or the client workstation that originally
created the record.

Your link to Kevin Goodnecht's article on setting the DNS options
using a GPO also answered my question regarding how to properly tackle
that.

One thing that bit me when I first started this project was that I
couldn't see any of the timestamps on the DNS records. I have a
dedicated management station and I use a custom MMC for everything and
I finally figured out that I needed to enable the Advanced view (click
on View, then select Advanced). I haven't seen that mentioned on any
article I've ran across.

Also, these links have proven to be very valuable during my
troubleshooting:
http://blogs.technet.com/networking/...c-records.aspx

Thank you again for your article. It is definitely one of the best
I've ran across.

I tried to explain it the best I could
while making it easy to understand.

I have never tried to change ownership of a record, but I would imagine
possibly using ADSI Edit, that is if the zone is AD integrated, but
then again, I am not sure where that info is stored, whether DHCP
stores a reference to it, or it uses AD permissions on the record. I'm
thinking the latter because if the zone is not AD Integrated, it's a
text file, and that DHCP feature still works. I would think the easiest
way is to simply delete the client's A record, then release and renew
the client.

As far as the pen icon, it means it is stuck (loosely put), meaning
that it cannot update the record in DNS because it already exists and
DHCP server does not own the record. In this case, you have to manually
delete it. This is all of course is you've configured credentials or
used the DnsUpdateProxy group, forced DHCP to register everything, and
set scavenging. But it doesn't work for existing records, which have to
be manually deleted to kick it off.

Yes. Here's one of those Technet articles that you mentioned.

<URL:http://technet.microsoft.com/en-us/library/dd759178.aspx>

I'm finally in a position to troubleshoot this again.

I had a problem where some clients would register and some wouldn't. I read
that missing PTR zones would cause intermittent record creation problems ...
even for unrelated zones. After I got my DHCP scopes and DNS zones in sync
everything appears to be working fine. I was just testing this last night so
I could have just been lucky.

I do have a few questions that I haven't been able to find an answer to:

* Who should be the owner of the A and PTR records? Currently, mine all
seem to be owned by SYSTEM. is this correct or should the owner be my dhcp
update user?

* Does the dhcp user need to be in the permissions for any of the zones?

In order for DHCP to update the record in DNS, it would need to own the
record, not System. To do that, if DHCP is on a DC, you can either add the
DC to the DnsUpdateProxy group, or provide credentials. If on a member
server, you can configure credentials. It's outlined in my blog with more
detail information on how to do that.

I would also suggest to create a reverse zone as well, if you have not
already done so. I look at that as a 'best practice' and follow that with
all of my customers. It prevents other issues, even the benign nslookup
message (some look at as an error, but it is not) that the 'server' does not
exist.

Trust me, I have read every word of your blog entry and I still think it's
one of the very best out there.

I know there are security risks in adding the DC computer account to the
DnsUpdateProxy group and would like to avoid that if possible. Instead, I
have created a user and added it to the DNS credentials for my DHCP scopes.
I can confirm that the password is correct and not mistyped as I can see
Success entries in the Security event logs.

Does that user need to be added to the security permissions for my forward
and reverse DNS zones? I haven't found anything about what to do with that
user after creating him other than adding him to the DNS credential for the
DHCP scopes. Is that enough?

We are currently swamped in old, stale records so our process so far has
been to delete the DNS A and PTR records and then reboot the systems. This
allows us to basically start over but I'm afraid we're spinning our wheels
since the records still have the wrong ownership.

Also, to answer your question, there is a reverse DNS zone for every DHCP
scope.

Our DNS records are being created with no errors nor any pencil icons next
to the DHCP lease entries. We're getting records in both the forward and
reverse zones. They're just owned by SYSTEM.

If it helps, DHCP option 81 is configured like so:

Enable DNS dynamic updates according to the settings below:
Always dynamically update DNS A and PTR records
Discard A and PTR records when lease is deleted
Dynamically update DNS A and PTR records for DHCP clients that do not
request updates.

Thank you again for taking the time to help me with this.

Thank you for the great feedback!

Yep, that's all. Keep in mind, any machine with any user can update DNS
using Kerberos. The plain-Jane user account (not an admin) just gives DHCP
the ability to own the record in order to update it when it changes. No
other action required, of course other than setting up Scavenging.

All the old records have to be deleted to start fresh. Are the records you
are referring to workstation records from prior to setting up credentials on
the DHCP server?

Good. I meant actually a reverse for each subnet that exists in the org, not
necessarily each DHCP scope.

New records owned by System after credentials configured? That actually
sounds possibly correct, but never bothered to actually look at a record in
Advanced Mode after Ive configured a system with this method, because it
just works, meaning tehre are no more dupes being created, and scanvenging
is yanking old stuff out.

That sounds perfect. :-)

You are welcome!

"Ace Fekay [MVP-DS, MCT]" wrote:

> Responses inline...
>
> "John Smith" <JohnSmith@discussions.microsoft.com> wrote in message
> news:DD307664-7ACB-4200-91CA-1E9C83744E0B@microsoft.com...
> >
> > Thank you again for your help.
> >
> > Trust me, I have read every word of your blog entry and I still think it's
> > one of the very best out there.
>
> Thank you for the great feedback!
>
> >
> > I know there are security risks in adding the DC computer account to the
> > DnsUpdateProxy group and would like to avoid that if possible. Instead, I
> > have created a user and added it to the DNS credentials for my DHCP
> > scopes.
> > I can confirm that the password is correct and not mistyped as I can see
> > Success entries in the Security event logs.
>
> Good.
>
> >
> > Does that user need to be added to the security permissions for my forward
> > and reverse DNS zones? I haven't found anything about what to do with
> > that
> > user after creating him other than adding him to the DNS credential for
> > the
> > DHCP scopes. Is that enough?
>
> Yep, that's all. Keep in mind, any machine with any user can update DNS
> using Kerberos. The plain-Jane user account (not an admin) just gives DHCP
> the ability to own the record in order to update it when it changes. No
> other action required, of course other than setting up Scavenging.
>
>
> >
> > We are currently swamped in old, stale records so our process so far has
> > been to delete the DNS A and PTR records and then reboot the systems.
> > This
> > allows us to basically start over but I'm afraid we're spinning our wheels
> > since the records still have the wrong ownership.
>
> All the old records have to be deleted to start fresh. Are the records you
> are referring to workstation records from prior to setting up credentials on
> the DHCP server?
>
>
> >
> > Also, to answer your question, there is a reverse DNS zone for every DHCP
> > scope.
>
> Good. I meant actually a reverse for each subnet that exists in the org, not
> necessarily each DHCP scope.

I'll make it a point to conduct an audit of all our subnets and get this
added to DNS. We have an absolute ton of subnets and VLANs so this won't be
an easy task.

> > Our DNS records are being created with no errors nor any pencil icons next
> > to the DHCP lease entries. We're getting records in both the forward and
> > reverse zones. They're just owned by SYSTEM.
>
> New records owned by System after credentials configured? That actually
> sounds possibly correct, but never bothered to actually look at a record in
> Advanced Mode after Ive configured a system with this method, because it
> just works, meaning tehre are no more dupes being created, and scanvenging
> is yanking old stuff out.

Once I get this mess in order, which won't be long at the rate we're all
moving, I'll be able to get scavenging turned on and then it should be smooth
sailing for us.

> > If it helps, DHCP option 81 is configured like so:
> >
> > Enable DNS dynamic updates according to the settings below:
> > Always dynamically update DNS A and PTR records
> > Discard A and PTR records when lease is deleted
> > Dynamically update DNS A and PTR records for DHCP clients that do not
> > request updates.
>
> That sounds perfect. :-)
>
> >
> > Thank you again for taking the time to help me with this.
> >
>
> You are welcome!
>
> Ace

Thank you very much again for your time and help. It looks like we're in
good shape here now.

"John Smith" <JohnSmith@discussions.microsoft.com> wrote in message
news:904C6444-6B7D-425D-9F5D-C19057DB768A@microsoft.com...
>
>
> "Ace Fekay [MVP-DS, MCT]" wrote:
>
>> Responses inline...
>>
>> "John Smith" <JohnSmith@discussions.microsoft.com> wrote in message
>> news:DD307664-7ACB-4200-91CA-1E9C83744E0B@microsoft.com...
>> >
>> > Thank you again for your help.
>> >
>> > Trust me, I have read every word of your blog entry and I still think
>> > it's
>> > one of the very best out there.
>>
>> Thank you for the great feedback!
>>
>> >
>> > I know there are security risks in adding the DC computer account to
>> > the
>> > DnsUpdateProxy group and would like to avoid that if possible.
>> > Instead, I
>> > have created a user and added it to the DNS credentials for my DHCP
>> > scopes.
>> > I can confirm that the password is correct and not mistyped as I can
>> > see
>> > Success entries in the Security event logs.
>>
>> Good.
>>
>> >
>> > Does that user need to be added to the security permissions for my
>> > forward
>> > and reverse DNS zones? I haven't found anything about what to do with
>> > that
>> > user after creating him other than adding him to the DNS credential for
>> > the
>> > DHCP scopes. Is that enough?
>>
>> Yep, that's all. Keep in mind, any machine with any user can update DNS
>> using Kerberos. The plain-Jane user account (not an admin) just gives
>> DHCP
>> the ability to own the record in order to update it when it changes. No
>> other action required, of course other than setting up Scavenging.
>>
>>
>> >
>> > We are currently swamped in old, stale records so our process so far
>> > has
>> > been to delete the DNS A and PTR records and then reboot the systems.
>> > This
>> > allows us to basically start over but I'm afraid we're spinning our
>> > wheels
>> > since the records still have the wrong ownership.
>>
>> All the old records have to be deleted to start fresh. Are the records
>> you
>> are referring to workstation records from prior to setting up credentials
>> on
>> the DHCP server?
>>
>>
>> >
>> > Also, to answer your question, there is a reverse DNS zone for every
>> > DHCP
>> > scope.
>>
>> Good. I meant actually a reverse for each subnet that exists in the org,
>> not
>> necessarily each DHCP scope.
>
> I'll make it a point to conduct an audit of all our subnets and get this
> added to DNS. We have an absolute ton of subnets and VLANs so this won't
> be
> an easy task.
>
>> > Our DNS records are being created with no errors nor any pencil icons
>> > next
>> > to the DHCP lease entries. We're getting records in both the forward
>> > and
>> > reverse zones. They're just owned by SYSTEM.
>>
>> New records owned by System after credentials configured? That actually
>> sounds possibly correct, but never bothered to actually look at a record
>> in
>> Advanced Mode after Ive configured a system with this method, because it
>> just works, meaning tehre are no more dupes being created, and
>> scanvenging
>> is yanking old stuff out.
>
> Once I get this mess in order, which won't be long at the rate we're all
> moving, I'll be able to get scavenging turned on and then it should be
> smooth
> sailing for us.
>
>> > If it helps, DHCP option 81 is configured like so:
>> >
>> > Enable DNS dynamic updates according to the settings below:
>> > Always dynamically update DNS A and PTR records
>> > Discard A and PTR records when lease is deleted
>> > Dynamically update DNS A and PTR records for DHCP clients that do not
>> > request updates.
>>
>> That sounds perfect. :-)
>>
>> >
>> > Thank you again for taking the time to help me with this.
>> >
>>
>> You are welcome!
>>
>> Ace
>
> Thank you very much again for your time and help. It looks like we're in
> good shape here now.



Seems like you are getting closer to having a more efficient DHCP setup. One
more thing I would like to add, if you have that many subnets that are not
inventoried, then it indicates you do not have your AD Sites setup properly.
Sites control logon traffic and replication traffic between DCs. Assuming
you have only one AD domain, all DCs should be GCs, which is the
recommendation by Microsoft and other engineers. This is because in a single
domain, the IM role has nothing to do. But as far as logons, if all subnets
are part of the Default-First-Site, then that means if you have a user in
LA, querying DNS for a GC, one in NJ may be responding. To control that,
create IP subnet objects in AD Sites and Services, then create AD Sites, and
associate the subnet objects cooresponding to their site. This way if a user
in NJ queries DNS for a GC to logon, it will get the one in its own site.
Not that this has anything to do with DHCP, which it doesn't, rather it
helps to make the infrastructure more efficient.

I hope that helps.

Ace