Windows Server - Error 4515 - Duplicate zone information

Asked By Ce
26-Nov-08 08:04 AM
Hi,

I am currently in the process of building up two new DC's to replace to
older DC's on our network. I have set them up on our network to replicate, GC
etc and they are quite happy.

Recently I added the DNS role to both of them. Our DNS is set up on all
servers as "All domain controllers in Active Directory Domain" for our
company.internal zone. And our _msdcs.company.internal zone is set as "All
DNS servers in Active Directory Forest".

The DNS information is all stored in AD.

When I stop and start the two new DCs I keep getting the 4515 warning come up,

partition MicrosoftDNS but another copy of the zone has been found in
directory partition DomainDNSZones.company.internal. The DNS Server will
ignore this new copy of the zone."

Now I have read up a lot of articles on this but I am still not 100% clear
on what actually needs to be done.

One set of instructions is to delete one of the partitions for the
company.internal zone using ADSI edit (something I am very cautious about
doing) but doesn't specify which partition clearly enough. I am going to
guess I want to delete the MicrosoftDNS copy because this is an older method
of replication for Win2000 servers but as my DNS is set to "All DCs" rather
then "All DNS servers" maybe this is not right?

Another set says I should switch all DNS servers off except one, change its
replication method to "All DNS servers in Active Directory Domain", restart
the DNS service and then turn on all other DNS servers so the change
replicates.

Can anyone give me some clear instruction on what method to do?

If I delete the MicrosoftDNS DNS partition information do I first need to
set all DNS servers replication method to "All DNS servers in Domain"?

We are running on 5 Win2k3 servers with one forest and one domain.

The zones set up for each partitions as,

ForestDNS -> _msdcs.mercia.internal
DomainDNS-> company.internal, RootDNSServers
MicrosoftDNS -> company.internal, RootDNSServers

Cheers!
--
Thanks, Cep.
Windows Server 2003
(1)
Active Directory
(1)
RootDNSServers
(1)
ADSIEdit
(1)
MicrosoftDNS
(1)
RegisterDNS
(1)
DomainDNS
(1)
ForestDNS
(1)
  Ace Fekay [Microsoft Certified Trainer] replied...
27-Nov-08 12:45 AM
Cep <Cep@> requesting assistance, typed the
following:


The easiest way to clear this up is to go into ADSI Edit, drill down the
DomainNC to Services, Microsoft DNS, and delete the dupe zone. You will be
able to tell immediately if it is a dupe. It will have a "CNF...." or
DomainDnsZones and ForestDnsZones partitions too for the same type of
entries. If you see them, delete them.

The problem probably occurred while both 2000 and 2003 DCs were co-existing
and at least one of the 2000 DCs was still running the DNS service. When
switching over to 2003, or even 2003 to 2008, you have to keep the two
different replication scopes to be backward compatible until you uninstall
DNS (not delete the zone from 2000). Once you've uninstalled DNS from ALL
2000 DCs, then is it safe to change the replication scope.

I have more detailed instructions if you need it, but I believe you'll be
ok. Post back if you would like to see them.

--
Ace

This posting is provided "AS-IS" with no warranties or guarantees and
confers no rights.

Ace Fekay, MCSE 2003 & 2000, MCSA 2003 & 2000, MCT
Microsoft Certified Trainer

For urgent issues, you may want to contact Microsoft PSS directly.
Please check http://support.microsoft.com for regional support phone
numbers.
  Ce replied...
27-Nov-08 07:19 AM
Hi Ace :)

Thanks for the reply.

I have drilled down to MicrosoftDNS under DomainNC and it contains one zone
company.internal with a load of records. I could not find any prefixes with
CNF or PRE as you mentioned. I also can see a RootDNSServers zone but this is
completely empty.

So I then thought I would check the DomainDNSZones parition and I now appear
to have alongside the company.internal two other zones with DC=....In
Progress and a guid with company.internal.

I guess I need to delete these two zones under DomainDNSZones and then
delete the MicrosoftDNS, company.internal zone from the DomainNC partition,
is that right? :)
--
Thanks, Cep.
  Ace Fekay [Microsoft Certified Trainer] replied...
28-Nov-08 09:48 AM
Cep <Cep@> requesting assistance, typed the
following:

Before you delete anything, good you found which partition it is in. Since
the dupe, as AD sees it, is in the DomainDnsZones partition, go to all your
DCs, and make sure the replication scopes are set to the Windows 2000
compatible setting (the bottom button). Let replication occur. If you have
multiple sites, and AD sites configured, allow the time to replicate based
on the site schedule and frequency. Once you are sure replication occured
between all DCs, then go back into ADSI Edit (open a fresh console to get a
refreshed view), delete the conflicting zone, NOT the partition. Now allow
that to replicate. Look at it later to insure the offending zone is gone.
Then go back to only ONE of your DCs, and change the scope to the middle
button, which will put it in the DomainDnsZones partition. Check ADSI Edit
after replication occurs to make sure all is as desired.

I hope that helps.

Ace
  Ce replied...
28-Nov-08 11:39 AM
Hi Ace,

I have followed your instructions but when I reach the last point about
changing the replication scope I get a really daft error coming up saying
something about the name of the network device and then it fails to complete.
I believe I have heard this mentioned but I don't think I have seen a fix.

Do you know what this means?
--
Thanks, Cep.
  Ace Fekay [Microsoft Certified Trainer] replied...
01-Dec-08 10:29 PM
Cep <Cep@> requesting assistance, typed the
following:
Sounds like you may have had a replication issue at one point as well. It
could have been caused by this, it may not have been caused by this. Either
way, the error, even though it doesn't make sense, is due to the dupe. The
following is a copy/paste from my blog at www.fekay.com showing the full
method to clean it all up. It involves picking one DC (only one), and
removing the zone from AD (make it no AD integrated), so it is now a Primary
Standard zone. Then allow replication to happen. Then do the ADSI Edit
deletions, but this time delete ALL references to the zone (not the
ForestDnsZones, just the zones in DomainNC and DomainDnsZones).

==================================
==================================

Conflicting AD Integrated zones if they exist in both the Domain NC and
one of the Application Partitions or if you get a weird error message
stating:

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 choose DomainDnsZones:

To choose the DomainNC (only for compatibility with Win2000):


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
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\
  Ce replied...
05-Dec-08 06:32 AM
Hi Ace,

Sorry for the late reply, I've been on First Aid training and a conference
this week!

Anyway I have read through your steps and I believe for me this would be,

1. In DNS Manager select the Forward lookup zones tree node
2. Expand company.internal zone tree node
3. Right click company.internal node and select properties
4. Change Type to primary if not already set and remove the checkbox from
store in active directory.
5. Apply ok, exit DNS manager
6. Go to every other DC/DNS server, repeating steps 1 to 5, except at step 4
set to secondary zone not primary.
7. On the primary DNS zone server, open ADSI edit
8. Expand the DC=company, DC=internal tree node, drill down to System->
MicrosoftDNS
9. Delete all company.internal zones
10. Expand the DC=DomainDNSZones, DC=company, DC=internal tree node, drill
down to MicrosoftDNS
11. Delete all company.internal zones
12. Force replication from AD Sites and Services
13. Check on each DC/DNS server that the replication has taken place
14. Go back to primary DC/DNS server and switch back to AD integrated
through DNS manager
15. Set replication to middle option All DNS servers in Domain
16. Go back to each DC/DNS server and set them back to AD Integrated, and
the same replication scope.*
17.Check everything is good.

*At point 16 do I make all these secondary zones, primary's once more?

Is there anything here I am missing or anything else I should be wary of?

Cheers
--
Thanks, Cep.
  Ace Fekay [Microsoft Certified Trainer] replied...
06-Dec-08 11:26 PM
Cep <Cep@> requesting assistance, typed the
following:

Changes to your steps:

Step 5: Just hit apply and leave the MMC open.

Step 6: Eliminate your step # 6. As I said, only pick ONE DC to do this on.
Once it is removed from AD, all the others will reflect that change through
AD replication. Remember, anything to do with or changes made in AD on one
machine, is replicated to ALL in the domain or forest (depending on the type
of change). That was why I said pick one DC.

Step 7: This can be done from ANY domain controller or workstation provided
the adminpak tools are installed and you are logged in as an enterprise
admin.

Step 9 & 11: Don't forget to delete anything zone you see with a prefix of
duplicate zones AD found.

Step 14: Go back to the original DC that you changed the zone to a non-AD
Integrated zone to do this. Just an FYI, there really is no such thing as a
Now if you meant to go back to the DC that now holds the Primary Standard
Zone that you changed, I apologize for the misunderstanding.

Let me know how you make out!

Ace
  Ce replied...
09-Dec-08 11:49 AM
Hi Ace,

Yep your right I did mean primary zone, not PDC. I did make a few other
steps in addition to the ones we discussed which were to add a new machine to
the network and test to see where the DNS record was created first. After
this I powered down two DCs and kept them on the sidelines in case things
went horribly wrong.

After the duplicate zone was deleted in DomainDNSZones (not DomainDC
afterall!) I tried restarting DNS, got no more errors. Allowed the others to
boot up and then replicate. Once they had I changed the scope and its all
good!

Thank you ever so much for all your help Ace, you are a star!

--
Thanks, Cep.
  Ace Fekay [Microsoft Certified Trainer] replied...
11-Dec-08 01:47 AM
following:

No problem and glad I was able to help, Cep. My pleasure! Thanks for the
plug. We're all out here to help and share the knowldge.

Cheers!

Ace
  Uncle_Nick replied...
21-Jan-09 10:39 AM
Looks like I have a similar issue - but with invisible duplicate zones
!

Will the procedure work if the duplicate domain zone was created by a
bad DCPromote/demote/re-promote, which led to the bad newDC copying a
perfectly good zone in ForestDNSZones down into DomainNC and replicating
that to the other 9 DCs on 5 sites ?
event type:	information
event source:	dns
event category:	none
event id:	713
date:		12/01/2009
time:		13:13:15
user:		n/a
computer:	gp-d83614-dc
description:
an administrator has moved the zone suffolk.nhs.uk to a new location in
active diretory. the zone will be stored in active directory at
dc=suffolk.nhs.uk,cn=microsoftdns,cn=system,dc=suffolk,dc=nhs,dc=uk.

Now I have a domain whose zone is win2k-compatible and not updating
properly, whilst the forest has a good instance of the zone, stored in
ForestDNSZones, that is not being used.

When the event occurred, I found your comments, found a Conflict copy
of the zone using ADSIEdit and deleted it... but after restarting the
DNS Service, DCs begain reporting TWO problems:
the zone suffolk.nhs.uk was previously loaded from the directory
partition microsoftdns but another copy of the zone has been found in
directory partition domaindnszones.suffolk.nhs.uk. the dns server will
ignore this new copy of the zone
the zone suffolk.nhs.uk was previously loaded from the directory
partition microsoftdns but another copy of the zone has been found in
directory partition forestdnszones.x.lhp.nhs.uk. the dns server will
ignore this new copy of the zone

I figure that I can more-or-less follow the process Cep discussed with
you, making a DC from elsewhere in the forest the definitive Primary,
and converting all DCs in the affected domain to Secondaries.

My unique problem is this:
Using ADSIEdit,  I can find the bad copy of the zone in the Domain NC /
CN=System,CN=MicrosoftDNS  container and delete it... but I -cannot- see
another instance of the zone in the DomainDNSZones partition, despite DC
eventlogs complaining about it, as shown above in the event snips.
As the zone was apparently moved deliberately, neither zone is marked
CNF.

It is conceivable that the badDC -may- have originally been configured
with the zone in the DomainDNSZones partition....in fact it is possible
the zone was manually added as an empty forward lookup before DCPromo
was first run.   I don't know if the zone move in AD, event713 at top of
my post, resulted in the zone coming out of DomainDNSZones, but leaving
some kind of ghost that produced the event4515 that I inserted above.
Ahh - replication latency may be the cause:  I just restarted DNS on a
server and only logged one 4515, for
the zone suffolk.nhs.uk was previously loaded from the directory
partition microsoftdns but another copy of the zone has been found in
directory partition forestdnszones.x.lhp.nhs.uk.

So - my question boils down to:
Is it ok to use a forest DC from outside my damaged domain as the
non-AD-Integrated primary.... and will configuring all DCs in the domain
into Secondaries have a bad effect upon the domain ?

I would welcome your advice
thanks in advance
Nick


--
Uncle_Nick
------------------------------------------------------------------------
Uncle_Nick's Profile: http://forums.techarena.in/members/uncle_nick.htm
View this thread: http://forums.techarena.in/server-dns/1078042.htm

http://forums.techarena.in
  Ace Fekay [Microsoft Certified Trainer] replied...
22-Jan-09 01:25 AM
Uncle_Nick <Uncle_Nick.3mdfrb@DoNotSpam.com> requesting assistance, typed
the following:


Yes, it should work fine. As long as all zones are out of AD, and all DCs
are using one commong DNS server that is not AD integrated, it will help
isolate the problem. Be sure to check both DomainDNSZones and
ForestDnsZones, as well as theMicrosoft DNS container (that you already
mentioned).

I wonder if someone tried to create a duplicate DomainDnsZones partition in
your scenario?

Also, patience is a virtue. Replication lag is a factor in a multi-site
infrastructure. If you delete something in ADSI Edit (or change anything in
AD, depending on domain scope, etc), you have to wait for it to replicate to
all DCs in other sites. The length of time you have to wait is based on your
IP Site link replication settings. Default is 3 hours. I usually set the
site links to 15 minutes (the lowest you can set it at). But keep in mind,
then you have to wait up to 15 minutes after that as well, because you have
to allow the bridgehead to receive the change, then based on the partnership
matrix the KCC created with multiple DCs in a site, the minimum time is 5
minutes, but the max time is 15 minutes for anything to replicate within a
site.

Ace
  Uncle_Nick replied...
22-Jan-09 06:48 AM
Ace - thanks for your feedback

I now have a single non-integrated primary for the troublesome zone,
and 10 DCs within the AD domain all acting as secondaries.
Only negative impacts seem to be
1: a 3rd domain within the forest had its exchange connector broken,
because its DNS server had no forwarders, and had previously found the
target mailserver via AD-integrated DNS
2: a mailserver in the affected domain seems to have lost the capacity
for pass-thru sign-on... and won't   IPConfig /RegisterDNS.    Another
mailserver in the domain has quite happily executed  /RegisterDNS - most
peculiar

Checking ADSIedit, I have no instances of the problem zone anywhere;
forest and domain application partitions are clean, and so is the domain
NC.

Now I need to switch the primary copy of the zone back to being
AD-Integrated, on the DC elsewhere in my forest:  do I need to do
anything to all the secondaries first ?

I ask this because at first try of switching back to AD-Integrated,
everything seemed to break !
I assumed that replication was at fault, rolled back and confirmed that
the Primary/Secondaries structure was functional and left it overnight
to stablise.

You reccommend that the replication scope for the AD-Integrated zone
should be domain rather than forest - why is that ?
Since I want my other domains to also be able to resolve this zone, I
would prefer to have the bigger replication scope - is there any reason
why not ?

Sorry if I am asking foolish questions - duplicate DNS is novel to me
regards
Nick


--
Uncle_Nick
------------------------------------------------------------------------
Uncle_Nick's Profile: http://forums.techarena.in/members/uncle_nick.htm
View this thread: http://forums.techarena.in/server-dns/1078042.htm

http://forums.techarena.in
  Ace Fekay [Microsoft Certified Trainer] replied...
22-Jan-09 10:43 AM
Uncle_Nick <Uncle_Nick.3mezbe@DoNotSpam.com> requesting assistance, typed
the following:

Actually I would have rathered have you point all DCs to ONE common DNS
server. Creating secondaries on each DC was really uneeded administrative
overhead. At least one thing that will make it easy for you is that once you
fix the problem, and put the zone back into AD (making the zone AD
integrated), it should delete all the secondaries automatically, assuming
replication occurs properly.



Not having a forwarder is really not an issue because DNS will use its Root
Hints for external resolution, that is assuming no firewall rules are
blocking DNS traffic to these DNS servers, or that you do not have a Root
zone created (a zone that looks like a period), nor that you have deleted
the Root Hints.



Well, I can now see why you created a secondary on all the DCs. I realize
all your machines are currently pointing to their respective DNS servers.
For this reason I would rather have suggested (and possibly assumed) that
you perform this task during non-production hours to minimize infrastructure
impact.



They should auto-delete once the zone is back in AD.


Well, now that I see that you have multiple domains in the forest, it really
depends on which DNS servers the child domains are using. Is there a
delegation in place? In such a scenario, each domain resources would only be
using that specific domain's DC/DNS servers and would assume a forwarder
from those DC/DNS servers are pointing back to the forest root DC/DNS
servers which will have forwarders to the ISP.

In such a scenario, I would assume your dupe zone would be occuring on only
one of your domains. That would be the only domain I would have suggested to
remove the zone from AD (make it non-AD integrated).

From what you're saying, I am now assuming there is no delegation, but I'm
not sure. Maybe you can elaborate on how the whole thing is setup?



No, there is no reason why not to have this design. In such a design with
all zones' scope set to Forest-wide (ForestDnsZones), all DNS servers would
resolve everything in the forest and no need to forward to the forest root
DC/DNS, but rather ALL DNS servers should have forwarding set to the ISP.


No problem. I was working at one client where they authorized a person in
another location to install a DC. He was also instructed to install DNS, but
not create a zone. However, he did create a zone and it wound up causing a
dupe zone issue. It took me half a day to figure out why the DNS
inconsistencies were occuring until I saw it in ADSI Edit. I then asked and
was later told about the guy in the other location. I told the guy to simply
uninstall DNS and DO NOT delete the zone, or the ramifications would have
been worse, because if you delete a zone on one DC/DNS, you are telling it
to delete it completely out of AD and it's existence. Make sense?

So I am not exactly sure what occured in your scenario. If you have multiple
admins, anything could have happened. Maybe someone created a dupe zone on a
DNS server, realized what they did, then deleted it?


Ace
  Ace Fekay [Microsoft Certified Trainer] replied...
22-Jan-09 10:51 AM
the following:

One more thing, if any of the DCs have multiple NICs, this can cause issues
as well. it is recommend that DCs are not multhomed.

Ace
  Uncle_Nick replied...
22-Jan-09 11:58 AM
many thanks Ace - glad of the clarification regarding the secondaries
auto-deleting once the primary is reset to AD-Integrated.
I am confident about replication - the secondaries picked up new
versions of the zone quickly last night, and an AD change propagated as
expected.

I -did- do the change to non AD-Integrated zone out of production
hours, but because the reversion seemed to be failing, I left the
building to allow replication overnight .... I hadn't arranged
really-late-working authority  ;-]  and this led to the issues
experienced this morning.   Tonight I will switch back to Forest
replication scope, and watch replication logs for an hour....

Apologies for the ambiguous statements - yup, our forest IS
multi-domain, no delegation.   Root domain is not empty, but is a huge
legacy domain.

The broken exchange connector was just pointing at a mailserver in the
damaged zone, but the DNS serving it was in a domain that I had not
given a secondary to - my fault for not checking those DNS servers for
forwarders to our top-tier DNS.

DNS is multi-tier, even within the child domain that has the dodgy dns
zone.
Leaf sites forward to bridgeheads, which forward to core, which forward
out to the forest root, which in turn points out of the domain....

As for the cause - as described in my OP, we are pretty sure it was due
to the leaf site server being promoted, demoted and promoted again in a
very short period of time relative to the replication latency....by a
buffoon...

Thanks again for sharing your experience !
Nick


--
Uncle_Nick
------------------------------------------------------------------------
Uncle_Nick's Profile: http://forums.techarena.in/members/uncle_nick.htm
View this thread: http://forums.techarena.in/server-dns/1078042.htm

http://forums.techarena.in
  Uncle_Nick replied...
23-Jan-09 10:20 AM
Closure - and success
On my remaining Primary DNS server, I sent the zone back into AD with
Forest replication scope.... it replicated from the primary DNS server
to a secondary in the same domain almost immediately, but I had to
restart DNS on every DC in the affected domain before the secondary
disappeared and the AD-Integrated version appeared.   Other domains
behaved similarly.

So - my belt&braces approach, for future reference:
1. In DNS Manager select the Forward lookup zones tree node
2. Expand company.internal zone tree node
3. Right click company.internal node and select properties
4. Change Type to primary if not already set and remove the checkbox
from
store in active directory.
5. Tick the checkbox to allow zone transfers
6. Apply ok, exit DNS manager
7. Wait for replication to remove all AD-Integration on the zone from
other DCs
8. Go to every other DC/DNS server, editing the zone's Properties and
setting the local copy to secondary not primary.
9. On the DNS server hosting the primary zone, open ADSI edit
10. Expand the DC=company,DC=internal tree node, drill down to
System->
MicrosoftDNS
11. Delete all company.internal zones
12. Expand the DC=DomainDNSZones,DC=company,DC=internal tree node,
drill
down to MicrosoftDNS
13. Delete all company.internal zones
14. Allow replication to occur
15. Repeat the ADSIEdit process on the DC that compromised the zone in
the first place [just to make sure].   Look out for compromised
references to Root Servers in the wrong context
16. Allow replication to occur

17. On the DNS server hosting the primary zone, start DNS Manager &
select the Forward lookup zones tree node
18. Expand company.internal zone tree
19. Right click company.internal node and select properties
20. Change Type to AD-Integrated and choose replication scope - either
Forest-wide if you require or Domain-wide [middle button] in simpler
environments
21. Visit another DC in the same domain, check that the change
replicates and the secondary zone is replaced by the AD-Integrated
version.
22. Restart DNS on any DCs in other domains in your forest, and watch
the replication occur
23. Add Aliases or other resource records at arbitrary DNS servers and
confirm the changes replicate to all other DCs
24. celebrate !


--
Uncle_Nick
------------------------------------------------------------------------
Uncle_Nick's Profile: http://forums.techarena.in/members/uncle_nick.htm
View this thread: http://forums.techarena.in/server-dns/1078042.htm

http://forums.techarena.in
  Ace Fekay [Microsoft Certified Trainer] replied...
23-Jan-09 12:20 PM
Uncle_Nick <Uncle_Nick.3mh2bb@DoNotSpam.com> requesting assistance, typed
the following:

SOunds like you got it down to a science now! Awesome!
Break out the Crown Royal!!

Glad I was able to assist.


Post back if you have any further concerns. You can also contact me via
email at aceman@mvps.NOSPAM.org.

Ace
Create New Account
help
Windows Server Cannot join my W2K8 server to my sBS 2003 R2 domain I'm trying to join a Windows 2008 server to a SBS 2003 R2 domain. The SBS 2003 R2 server is fully patched and up to date including KB926505 which needs to be
Windows Server sbs2008 dns issue Hi, I just installed SBS2008 and love it but I have the outside access, are you using http: / / OR = https: / / ? - - = 20 Cris Hanna [SBS - MVP] Co-Contributor, Windows Small Business Server 2008 Unleashed http: / / www.amazon.com / Windows-Small-Business-Server-Unleashed / dp / 06723295 = 73 / ref = 3Dpd_bbs_sr_1?ie = 3DUTF8&s = 3Dbooks&qid = 3D1217269967&sr = 3D8-1 book?< / FONT> < / DIV> access, are you = 20 using http: / / OR https: / / ?< / FONT> < / DIV> Business = 20 Server 2008 Unleashed<BR> <A = 20 href = 3D"http: / / www.amazon.com / Windows-Small-Business-Server-Unleashed / dp / = 0672329573 / ref = 3Dpd_bbs_sr_1?ie = 3DUTF8&s = 3Dbooks&qid = 3D1217269967 = &sr
Windows Server Event ID errors 40961 and 40960 (source = LSASRV) Hi All, I'm desparate and have I can't get a WinXP Pro SP2 (or now SP3) to work with SBS 2003 domain controller. I setup the PC on the main subnet and I believe it was success: -Based on research installed WinXP SP3. -Checked eventvwr and still noticed domain errors; ran windows update again. -Tried to do a ipconfig / registerdns per recommendation of research. -Tried to leave chance this computer has McAfee installed on it? - - = 20 Cris Hanna [SBS - MVP] Co-Author, Windows Small Business Server 2008 Unleashed http: / / www.amazon.com / Windows-Small-Business-Server-Unleashed / dp / 06723295 = 73 / ref = 3Dpd_bbs_sr_1?ie = 3DUTF8&s = 3Dbooks&qid = 3D1217269967&sr = 3D8-1
Windows Server Get rid of DNS 4010 events. . . Hi, We have some event problems with our DNS service (w2003r2 and now upgraded to w2008). At every reboot of the DNS server there is a pile of 4010 and a couple of 4013 events. These servers formerly post above). Thanks for help on this regards jake From event log: 4010 The DNS server was unable to create a resource record for 477e0653-8f6b-4265-ba75-b053508230da._msdcs.mylocaldomain.lan. in zone mylocaldomain.LAN. The Active Directory definition of this resource record is corrupt or contains an invalid DNS name. The event data contains the error. 4010 The DNS server was unable to create a resource record for 1ffcb6ba-c6bf-4037-95bc-2614d7ea9a61._msdcs.mylocaldomain.lan. in zone mylocaldomain.LAN. The Active Directory definition of this resource record is corrupt or contains an invalid DNS name. The