With Windows Server 2008 R2 reaching end of life in January 2020, many organizations have been migrating their workloads to Windows Server 2016 or newer. This period is also an opportunity for some to decommission and consolidate domains to reduce complexities where possible. I posted about an upgrade blocker when the File Replication Service is still in use for replicating SYSVOL content here. In there, I also share a link on where you can find useful information on the End of Life Dashboard that one of my follows blogged about.
I this post, I would like to discuss an additional check point you may want to include in your upgrade plan as one of the clean-up actions after removing a domain. This tip would also be applicable when you are looking at removing Active Directory-Integrated Zones that are no longer required or wanted.
Repro Environment Details
I leveraged one of the Azure Quickstart Templates to help accelerate a deployment of a 3-domain forest in my Azure subscription. In there, I have:
- A forest root domain named forestroot.co.za
- 2 child domain named east.forestroot.co.za and west.forestroot.co.za
For demonstration, I decommission one of the child domains (west.forestroot.co.za) and go through the process of cleaning up the expired stub DNS zone that was created in the other child domain (east.forestroot.co.za). Here’s what it initially looks like in the DNS Management Console.
Protecting DNS Zones from accidental deletion
It is recommended to have DNS zones protected from accidental deletion. Here is an oldie but goodie with details:
- How to Save the DNS Cheese. Protect AD-Integrated DNS Zones from Accidental Deletions
In the test lab, I ran the following piece of PowerShell code to protect the west.forestroot.co.za DNS stub zone hosted in the east domain from accidental deletion:
Get-ADObject -Server EASTDC01.east.forestroot.co.za -Filter 'Name -eq "west.forestroot.co.za"' -SearchBase "DC=DomainDNSZones,DC=east,DC=forestroot,DC=co,DC=za" -Properties ProtectedFromAccidentalDeletion | Set-ADObject -ProtectedFromAccidentalDeletion $true |
Decommissioning the child domain
We are now at a point where we need to decommission the west domain. As part of the removal process, the Active Directory Domain Services configuration wizard removes the DNS zone for the west domain, as well as the DNS delegation.
However, the stub zone remains and traces of it are visible in the DNS Management Console after the domain removal. The DNS server from the east domain is unable to load the zone as the transfer of zone data from the master server (the decommissioned DC) failed.
Additionally, there is an error (Event ID 6527) logged in the DNS Server event log stating that the zone expired before it could obtain a successful zone transfer or update from a master server acting as its source for the zone.
The clean-up process
With protection from accidental deletion in place, an attempt to remove this stale zone results in the following error:
The zone cannot be deleted. Access was denied
In this case, I am using an account belonging to the Enterprise Admins group. From a perspective of group membership, inadequate permissions is not an issue here and we already have an idea that this is due to the protection we put on earlier.
What I need to do here is to remove the protection flag by running the following PowerShell code:
Get-ADObject -Server EASTDC01.east.forestroot.co.za -Filter ‘Name -eq “west.forestroot.co.za”‘ -Properties ProtectedFromAccidentalDeletion | Set-ADObject -ProtectedFromAccidentalDeletion $false |
To confirm, here is the PowerShell code that can help us:
Get-ADObject -Server EASTDC01.east.forestroot.co.za -Filter ‘Name -eq “west.forestroot.co.za”‘ -Properties ProtectedFromAccidentalDeletion |
With this flag turned off (or set to false), removal of this zone succeeds.
One more thing to watch out for…
So far, this is pretty straightforward but I would like to leave you my last tip. You may have come across the warning (Event ID 4515) depicted below. The zone west.forestroot.co.za was previously loaded from the directory partition MicrosoftDNS but another copy of the zone has been found in directory partition DomainDnsZones.east.forestroot.co.za.
So what do we have here? The zone west.forestroot.co.za is stored in two partitions – one in DomainDNSZones and another in the domain partition.
Be sure to check if you don’t have a duplicate copy of the zone too if you are not sure why you still get access denied with everything that has been mentioned above in place.
In closing
Protect your Active Directory-Integrated DNS zones from accidental deletion, but don’t forget about this when it’s time to get rid of DNS zones you no longer require. Also please watch out for duplicate copies of DNS zones and remember that storing zones in the domain partition is not recommended. Happy upgrading!
Till next time…