Introduction
Way back when your AD integrated DNS zone data lived inside of the naming context in AD (next to your users and computers) you could protect it from accidental deletion just like any other object. But this can cause a problem years later when you want to move these zones to their own application partition in AD. This is achieved by changing its replication scope. If you have the zone protected, you will get a nasty error message that makes no sense.
- The server is unavailable
- The name limit for the local computer network adapter card was exceeded
This post will focus on the error messages you can expect and how to resolve them.
DNS Zone replication scopes
I am not going to delve into DNS replication scopes as its covered pretty well elsewhere, but I will highlight where we change the scope as this is where we can replicate the errors.
- Select the properties of a DNS zone
- General Tab
- Replication
- Change
Here we have 3 options
1. To all DNS servers running on domain controllers in the this forest:
- This places the data into the ForestDNSZones partition
- For reference, to view this in ADSI edit use DC=forestdnszones,dc=DOMAIN,DC=COM
2. To all DNS Servers running on domain controllers in this domain
- This places the data into the DomainDNSZones partition
- For reference, to view this in ADSI edit user DC=domaindnszones,DC=DOMAIN,DC=COM
3. To all domain controllers in this domain (for windows 2000 compatibility)
- This places the data into the domain partition
Protecting DNS data from accidental deletion
If you have an old domain, from 2000/2003 days, there is a chance you will have DNS zones in your domain partition (technicall nothing wrong with this) and at some point, a Microsoft engineer might have recommended protecting that from accidental deletion. This is where its set.
For the purpose of this exercise, I have created a primary zone called tailspin.com and set its replication scope to “To all domain controllers in this domain (for windows 2000 compatibility)”
- Active directory Users and Computers
- Make sure advanced features is enabled
- Expand system
- MicrosoftDNS
- Tailspin.com
- Right click tailspin.com
- Properties
- Object
Change the replication scope – Error number 1
Lets move on a few years now, another Microsoft engineer might have recommended maybe after an AD health check to move the DNS zone data into the application partition. As all new zones will be created in the domain dns zone partition by default now. This is simply achieved by selecting the relevant radio button on the replication scope on the properties of the zone. If you have the zone protected, expect to see this error message. In this example, the scope has been changed to all servers in this domain
We now get this error message.
“The server is unavailable”. Yes it is available, ive seen customers go down rabbit holes trying to figure this one out. This is also followed up by a couple of event log entries.
Event 4511 – detailing the failed attempt to move the zone
Event 4515 – detailing that a duplicate zone has been found.
This second event also states that it might be a transient condition and it will soon catch up. It wont.
Remove protection for accidental deletion – error number 2
Once you realise the accidental deletion flag is set on the zone and you remove and try to move the zone again using the same procedure as before, you get this nasty error message.
The name limit for the local computer network adapter card was exceeded.
This is followed by NO event log entries.
What is happening here
- The first time we tried to change the replication scope (move the zone data to the new partition), it takes a copy of the data and writes it into the new zone.
- Then it tires to delete the old zone but fails due to the protection
- But it doesn’t clean up the data it had written into the domain dns zone.
- When you remove the protection and try to move again, it cant, as a zone with the same name already exists.
Duplicate zone
The DNS zone still exists in the domain partition
And the duplicate zone data via ADSI edit.
Expand out to MicrosoftDNS and you will see the zone DC=tailspin.com.
You will also notice a zone prefixed “Inprogress-XXXXXXXXXXX-tailspin.com”. this gets created each time you try to move the zone and it fails. I tried to move 2 more times and you can see the additional zones getting created.
Resolution
The solution to this is simple, now that we have removed protection of the original zone, we can simply delete these new zones in ADSI edit. You will need to delete the contents of tailspin.com first before you can delete the zone
Once this is done, the zone replication scope will move with out any errors. The Zone will be removed from the domain partition and only exist in the DNS application partition.
Protecting the new zone data from accidental deletion
Great article here on how to protect DNS data where ever it lives
It boils down to a few powershell commands as we don’t get that check box that we get when the zones are in the domain partition. Change DomainDNSZones to ForestDNSZones to find and protect unprotected Zones at the forest replication scope.
Find ’em
Get-ADObject -Filter 'ObjectClass -like "dnszone"' -SearchScope Subtree -SearchBase "DC=DomainDnsZones,DC=domain,DC=lab" -properties ProtectedFromAccidentalDeletion | where {$_.ProtectedFromAccidentalDeletion -eq $False} | Select name,protectedfromaccidentaldeletion | out-gridviewProtect ’em
Get-ADObject -Filter 'ObjectClass -like "dnszone"' -SearchScope Subtree -SearchBase "DC=DomainDnsZones,DC=domain,DC=lab" -properties ProtectedFromAccidentalDeletion | where {$_.ProtectedFromAccidentalDeletion -eq $False} | Set-ADObject –ProtectedFromAccidentalDeletion $trueCheck ’em
Get-ADObject -Filter 'ObjectClass -like "dnszone"' -SearchScope Subtree -SearchBase "DC=DomainDnsZones,DC=domain,DC=lab " -properties ProtectedFromAccidentalDeletion | where {$_.ProtectedFromAccidentalDeletion -eq $True} | Select name,protectedfromaccidentaldeletion | out-gridview
