Ned here again. Beginning in Windows Server 2008 R2, Active Directory supports an optional AD Recycle Bin that can be enabled forest-wide. This means that instead of requiring a System State backup and an authoritative subtree restore, a deleted DNS zone can now be recovered on the fly. However, due to how the DNS service “gracefully” deletes, recovering a DNS zone requires more steps than a normal AD recycle bin operation.
Before you roll with this article, make sure you have gone through my article here on AD Recycle Bin:
Note: All PowerShell lines are wrapped; they are single lines of text in reality.
Restoring a deleted AD integrated zone
Below are the steps to recover a deleted zone and all of its records. In this example the deleted zone was called “ohnoes.contoso.com” and it existed in the Forest DNS Application partition of the forest “graphicdesigninstitute.com”. In your scenario you will need to identify the zone name and partition that hosted it before continuing, as you will be feeding those to PowerShell.
1. Start PowerShell as an AD admin with rights to all of DNS in that partition (preferably an Enterprise Admin) on a DC that hosted the zone and is authoritative for it.
2. Load the AD modules with:
3. Validate that the deleted zone exists in the Deleted Objects container with the following sample PowerShell command:
get-adobject -filter ‘isdeleted -eq $true -and msds-lastKnownRdn -eq “..Deleted-ohnoes.contoso.com“‘ -includedeletedobjects -searchbase “DC=ForestDnsZones,DC=graphicdesigninstitute,DC=com” -property *
Note: the zone name was changed by the DNS service to start with “..-Deleted-“, which is expected behavior. This behavior means that when you are using this command to validate the deleted zone you will need to prepend whatever the old zone name was with this “..Deleted-” string. Also note that in this sample, the deleted zone is in the forest DNS zones partition of a completely different naming context, just to make it interesting.
4. Restore the deleted zone with:
get-adobject -filter ‘isdeleted -eq $true -and msds-lastKnownRdn -eq “..Deleted-ohnoes.contoso.com“‘ -includedeletedobjects -searchbase “DC=ForestDnsZones,DC=graphicdesigninstitute,DC=com” | restore-adobject
Note: the main changes in syntax now are removing the “-property *” argument and pipelining the output of get-adobject to restore-adobject.
5. Restore all child “DNSnode” objects of the recovered zone with:
get-adobject -filter ‘isdeleted -eq $true -and lastKnownParent -eq “DC=..Deleted-ohnoes.contoso.com,CN=MicrosoftDNS,DC=ForestDnsZones,DC=graphicdesigninstitute,DC=com“‘ -includedeletedobjects -searchbase “DC=ForestDnsZones,DC=graphicdesigninstitute,DC=com” | restore-adobject
Note: the “msds-lastKnownRdn” has now been removed and replaced by “lastKnownParent”, which is now pointed to the recovered (but still mangled) version of the domain zone. All objects with that as a previous parent will be restored to their old location. Because DNS stores all of its node values as flattened leaf objects, the structure of deleted records will be perfectly recovered.
6. Rename the recovered zone back to its old name with:
rename-adobject “DC=..Deleted-ohnoes.contoso.com,CN=MicrosoftDNS,DC=ForestDnsZones,DC=graphicdesigninstitute,DC=com” -newname “ohnoes.contoso.com“
Note: the rename operation here is just being told to remove the old “..Deleted-” string from the name of the zone. I’m using PowerShell to be consistent but you could just use ADSIEDIT.MSC at this point, we’re done with the fancy bits.
7. Restart the DNS service or wait for it to figure out the zone has recovered (I usually had to restart the service in repros, but then once it worked by itself for some reason – maybe a timing issue; a service restart is likely your best bet). The zone will load without issues and contain all of its recovered records.
If the deleted zone was the delegated _msdcs zone (or both the primary zone and delegated _msdcs zone were deleted and you now need to get the _msdcs zone back):
a. First restore the primary zone and all of its contents like above.
b. Then restore the _msdcs zone like in step 4 (with no contents).
c. Next, restore all the remaining deleted _msdcs records using the lastKnownParent DN which will now be the real un-mangled domain name of that zone. When done in this order, everything will come back together delegated and working correctly.
d. Rename it like in step 6.
Note: If you failed to do step c before renaming the zone because you want to recover select records, the recovered zone will fail to load. The DNS snap-in will display the zone but selecting the zone will report “the zone data is corrupt”. This error occurs because the “@” record is missing. If this record was not restored prior to the rename simply rename the zone back to “..Deleted-“, restore the “@” record, rename the zone once more and restart the DNS Server service. I am intentionally not giving a PowerShell example here as I want you to try all this out in your lab, and this will get you past the “copy and paste” phase of following the article. The key to the recycle bin is getting your feet wet before you have the disaster!
A couple more points
- If the zones were deleted outside of DNS (i.e. not using DNS tools) then the renaming steps will be unnecessary and you can just restore it normally. If that happens someone was really being a goof ball.
- The AD Recycle Bin can only recover DNS zones that were AD-integrated; if the zones were Standard Primary and stored in the old flat file format, I cannot help you.
- I have no idea why DNS has this mangling behavior and asking around the Networking team didn’t give me any clues. I suspect it is similar to the reasoning behind the “inProgress” zone renaming that occurs when a zone is converted from standard primary to AD Integrated, in order to somehow make the zone invalid prior to deletion, but… it’s being deleted, so who could care? Meh. If someone really desperately has to know, ping me in Comments and I’ll see about a code review at some point. Maybe.
As always, you can also “just” run an authoritative subtree restore with your backups and ntdsutil.exe also. If you think my steps looked painful, you should see those. KB’s don’t get much longer.