Isaac
"Symore" <Sym...@discussions.microsoft.com> wrote in message
news:01BB20D7-CCA6-4506...@microsoft.com...
>i had some dns issues a few days ago we had 2 primary dns zones which were
> causing the issue so i removed one off of one of the servers and
> reinstalled
> only one primary dns server i gave it a few days to settle down and then i
> reinstalled the second dns server as a secondary it replicated just fine
> but
> when i went to the primary some of the zones were missing but were still
> on
> the secondary ? is there a way to get the entries from the secondary to
> the
> primary ?
> server 2003 r2 both servers 32 bit
>
> Thanks
> Steve
Actually, we'll need more info to provide specific help. Please post an
unedited ipconfig /all from both servers to help towards diagnosing.
Are these servers domain controllers? If so, are the zones AD integrated?
What exact issues did you see?
Are there any event log errors?
What change possibly occured about 1 to 7 days prior to the issues occuring?
Just a little backgriKeep in mind, if they are DCs, and the zone is AD
integrated, then it means the zone already exists in the AD database. Normal
replication updates the info from one DC/DNS to all DC/DNS servers in a
domain/forest, depending on replication scope. All AD intergrated zones in a
domain/forest are automatically all Primary, because AD integrated zones
follow a multi-master topology. AD integrated zones also means that if you
have one DC running DNS, then implemented DNS on another machine, the normal
action after the DNS installation is to walk away and let replication
populate the zone automatically. If there are any replication issues, then
the zone never populates. Not seeing the zone show up may cause some admins
to manually create the zone. However, AD will look at the zone as a
duplicate, and will cause numerous major issues with AD, which the DC
promptly will remove the zone from DNS. HOwever, removing the zone from DNS
does not remove the duplicate zone from the AD database. If something like
this did occur, the only way to find and remove them is to use ADSI Edit.
If you feel this applies to you, or we can determine if this was the issue
based on your responses, follow the following instructions on how to find
and remove the dupes. It gives you a background on zones and how AD handles
them, as well as how to fix it. I hope it helps.
==================================
==================================
Conflicting or duplicate AD Integrated DNS zones
You may have a duplicate zone if a zone either exists in both the Domain NC
and one of the
Application Partitions, if you get an unusal error message stating, "The
name limit for
the local computer network adapter card was exceeded," or you installed DNS
on another DC
and manually created the AD zone and didn't wait for it to automatically
populate.
Dupe zone errata:
A quick explanation: When you have an AD integrated zone, the DNS data is
stored in the
actual AD database and is replicated to all DCs and will be available to any
DC that has
DNS installed, depending on the zone replication scope setting. If rep scope
is set to the
bottom button, it will be store in the DomainNC partition of the AD database
and
compatible with Windows 2000. If the middle button, it will be stored in the
DomainDnsZones and only works with Windows 2003 and newer DCs. These two
scope types will
be replicated to all DCs only in the domain it exists in. The third type,
the top buttton,
is stored in the ForestDnsZones application partition and is available to
ALL DCs in the
whole forest. The data in any of the AD integrated zone types are truly
secured since you
can;t get at them without the proper tools.
If you have an AD integrated zone existing on a DC and you install DNS on
another DC in
the domain or forest, depending what zone type, it will automatically appear
on the new
DNS installation without any interaction on your part. If you attempted to
manually create
the zone, then you pretty much just introduced a duplicate in the AD
database, which will
cause problems and other issues as well.
A Primary or Secondary zone that is not stored in AD is stored in a text
file in the
system32\dns folder. This type of zone storage has nothing to do with the
above types ONLY
unless it is truly a secondary with the Master being a DC transferring a
copy of the zone.
This types of zone storage is obviously not secure.
Now **IF** you did manually create a zone on one DC while it already existed
on another
DC, then you may have a duplicate. If this is the case, you can use ADSI
Edit and look for
zone data that starts with a "CNF..." in front of it. Delete them and you;re
good to go.
Under Windows 2000, the physcial AD database is broken up into 3 logical
partitions, the
DomainNC (Domain Name Context, or some call the Domain Name Container), the
Configuration
Partition, and the Schema Partition. The Schema and Config partitions
replicate to all DCs
in a forest. However, the DomainNC is specific only to the domain the DC
belongs to.
That's where a user, domain local or global group is stored. The DomainNC
only replicates
to the DCs of that specific domain. When you create an AD INtegrated zone in
Win 2000, it
gets stored in the DomainNC. This causes a limitation if you want this zone
to be
available on a DC/DNS server that belongs to a different domain. The only
way to get
around that is for a little creative designing using either delegation, or
secondary
zones. This was a challenge for the _msdcs zone, which must be available
forest wide to
resolve the forest root domain, which contains the Schema and Domain Name
Masters FSMO
roles.
In Windows 2003, there were two additional partitions added, they are called
the
DomainDnsZones and ForestDnsZones Application Partitions, specifically to
store DNS data.
They were conceived to overcome the limitation of Windows 2000's AD
Integrated zones. Now
you can store an AD Integrated zone in either of these new partitions
instead of the
DomainNC. If stored in the DomainDnsZones app partition, it is available
only in that
domain's DomainDnsZones partition. If you store it in the ForestDnsZones app
partition, it
will be available to any DC/DNS server in the whole forest. This opens many
more design
options. It also ensures the availability of the _msdcs zone to all DCs in
the forest. By
default in Win 2003, the _msdcs zone is stored in the ForestDnsZones
application
partition.
When selecting a zone replication scope in Win2003, in the zone's
properties, click on the
"Change" button. Under that you will see 3 options:
To choose the ForestDnsZones:
"To all DNS servers in the AD forest example.com"
To choose DomainDnsZones:
"To all DNS servers in the AD domain example.com"
To choose the DomainNC (only for compatibility with Win2000):
"To all domain controllers in the AD domain example.com"
If you have a duplicate, that's indicating there is a zone that exists in
the DomainNC and
in the DomainDnsZones Application partition. This means at one time, or
currently, you
have a mixed Win2000/2003 environment and you have DNS installed on both
operating
systems. On Win2000, if the zone is AD Integrated, it is in the DomainNC,
and should be
set the same in Win2003's DC/DNS server to keep compatible. Someone must
have attempted to
change it in Win2003 DNS to put it in the DomainDnsZones partition no
realizing the
implications, hence the duplicate. In a scenario such as this where you want
to use the
Win2003 app partitions, you then must insure the zone on the Win2003 is set
to the
DomainNC, then uninstall DNS off the Win2000 machine, then once that's done,
you can then
go to the Win2003 DNS and change the partition's replication scope to one of
the app
partitions.
In ADSI Edit, you can view all five partitions. You were viewing the app
partitions, but
not the main partitions. You need to add the DomainNC partition in order to
delete that
zone. But you must uninstall DNS off the Win2000 server first, unless you
want to keep the
zone in the DomainNC. But that wouldn't make much sense if you want to take
advantage of
the _msdcs zone being available forest wide in the ForestDnsZones partition,
which you
should absolutley NOT delete. I would just use the Win2003 DNS servers only.
In ADSI Edit, rt-click ADSI Edit, connect to, in the Connection Point click
on "Well known
Naming Context", then in the drop-down box, select "Domain". Drill down to
CN=System.
Under that you will see CN=MicrosoftDNS. You will see the zone in there.
But make sure to decide FIRST which way to go before you delete anything.
Some reading for you...
Directory Partitions:
http://www.microsoft.com/resources/documentation/Windows/2000/server/reskit/en-
us/distrib/dsbg_dat_favt.asp
kbAlertz- (867464) - Explains how to use ADSI Edit to resolve app partitions
issues:
http://www.kbalertz.com/kb_867464.aspx
How to fix it?
-------------
What I've done in a few cases with my clients that have issues with
'duplicate' zone entries in AD (because the zone name was in the Domain NC
(Name Container) Partition, and also in the DomainDnsZones App partition),
was first to change the zone on one of the DCs to a Primary zone, and
allowed zone transfers. Then I went to the other DCs and changed the zone to
a Secondary, and using the first DC as the Master. Then I went into ADSI
Edit, (from memory) under the Domain NC, Services, DNS, and deleted any
reference to the domain name. Then I added the DomainDnsZones partition to
the ADSI Edit console, and deleted any reference to the zone name in there
as well. If you see anything saying something to the extent of a phrase that
says
"In Progress...." or "CNF" with a long GUID number after it, delete them
too. Everytime
you may have tried tochange the replication scope, it creates one of them.
Delete them all.
Then I forced replication. If there were Sites configured, I juggled around
the servers and subnet objects so all of the servers are now in one site,
then I forced replication (so I didn't have to wait for the next site
replication schedule). Once I've confirmed that replication occured, and the
zones no longer existed in either the Domain NC or DomainDnsZones, then I
changed the zone on the first server back to AD Integrated, choosing the
middle button for it's replication scope (which puts it in the
DomainDnsZones app partition). Then I went to the other servers and changed
the zone to AD Integrated choosing the same replication scope. Then I reset
the sites and subnet objects, and everything was good to go.
Keep in mind, I left the _msdcs... zone alone, since that wasn't causing any
problems and is located in the ForestDnsZones (default) in all of my client
cases I've come across with so far.
It seems like alot of steps, but not really. Just read it over a few times
to get familiar with the procedure. You may even want to change it into a
numbered step by step list if you like. If you only have one DC, and one
Site, then it's much easier since you don't have to mess with secondaries or
play with the site objects.
I hope that helped!
==================================
==================================
--
Ace
This posting is provided "AS-IS" with no warranties or guarantees and
confers no rights.
Ace Fekay, MCSE 2003 & 2000, MCSA 2003 & 2000, MCSA Messaging, MCT
Microsoft Certified Trainer
ace...@mvps.RemoveThisPart.org
For urgent issues, you may want to contact Microsoft PSS directly. Please
check http://support.microsoft.com for regional support phone numbers.